우리는 사내 머신에서 마이그레이션하면서 새로운 점프 호스트로 마이그레이션하고 있습니다. 또한 SSH를 통해 통신해야 하는 고객이 100명 이상 있습니다. 해당 방화벽은 현재 SSH를 통해 기본 사무실을 허용하지만 AWS 호스트는 허용하지 않습니다. 100개 이상의 고객 방화벽을 마이그레이션하는 데는 시간이 걸리므로 작업이 완료될 때까지 이미 설정된 VPN을 통해 이러한 IP에 대한 모든 트래픽을 라우팅하여 트래픽이 Amazon의 인터넷 게이트웨이(IGW)가 아닌 우리 사무실에서 나가도록 하려고 합니다.
라우팅과 관련된 교육에서 몇 가지 세부 사항이 누락되었습니다. 누군가가 나에게 이에 대해 설명할 수 있다면 좋을 것입니다...
VPC에는 다음 라우팅 테이블이 있습니다.
0.0.0.0/0 -> igw
172.31.254.0/24 -> local
172.27.0.0/16 -> vgw
8.8.4.4 -> vgw
8.8.4.4모든 사람에게 공개되고 ICMP가 활성화되어 테스트에 완벽한 Google의 보조 DNS 서버입니다.
추적 경로에는 홉이 표시되지 않습니다. 아무데도 가지 않으면 연결이 끊어지는 것 같습니다. 분명히 뭔가 빠진 것이 있는데 무엇인지 모르겠습니다. 가상 게이트웨이(vgw)로 이동되는 모든 트래픽이 VPN을 통과하도록 이 설정을 완료하려면 어떻게 해야 합니까?
vgw 세부정보여기서는 별로 유용하지 않습니다.
VPN 상태터널은 1개만 구성됩니다.
VPN 고정 경로 경로 테이블이 172.27.224.0/24주소를 가져온 위치입니다.
답변1
모든 고객에 대한 경로를 생성하려는 경우가 아니라면 VPN을 통해 모든 트래픽을 전송하도록 기본 경로를 변경하고 IGW를 제거하세요. 그러면 회사 라우터가 트래픽을 관리할 수 있습니다.
그러면 라우팅 테이블은 다음과 같습니다.
0.0.0.0/0 -> vgw
172.31.254.0/24 -> local
위의 두 번째 경로 CIDR은 이상해 보입니다. VPC 네트워크가 아닌 서브넷처럼 보입니다. 이를 VPC CIDR로 사용하고 싶습니다.
이것이 모든 트래픽에 대해 올바르게 작동하는지 확인한 후에는 업데이트, S3 스토리지 등과 같은 AWS 리소스에 액세스해야 하는 경우 VPC에 VPC 엔드포인트를 추가할 수 있습니다.
답변2
위의 설정이 맞습니다. 문제는 교체 시 VPN 엔드포인트로 제대로 작동하는 기업 측의 방화벽이 불량한 것으로 확인되었습니다. 기록을 위해 저는 WatchGuard 브랜드 방화벽에 반대하는 것을 강력히 권장합니다. 수년 동안 그것들을 망쳐 놓았는데 대부분의 측면에서 열등하고 일반적으로 버그가 있는 것 같습니다.