AWS NAT 게이트웨이는 VPN 방향으로 어떤 소스 IP를 사용할까요?

파트너가 사이트 간 VPN을 통해 어떤 소스 범위가 도착하는지 물었기 때문에 VPC 콘솔을 엽니다. NAT 게이트웨이 페이지에는 Elastic IP가 연결된 퍼블릭 게이트웨이가 표시되며, 그 주소를 보내고 넘어가고 싶어집니다. 인터넷 경로에는 맞는 답이고 VPN 경로에는 틀린 답이며, 차이는 라우팅 테이블이 어느 게이트웨이를 가리키는지에 있습니다. 허용 목록을 쓰기 전에 경로를 따라가 보세요.

허용 목록이 아니라 NAT 게이트웨이 페이지에서 시작하세요

NAT 게이트웨이 페이지는 서브넷, 유형, Elastic IP를 알려 주며 이 세 필드면 시작하기에 충분합니다. 알려 주지 않는 것은 그다음에 트래픽이 가는 경로입니다. 그것은 NAT 게이트웨이의 서브넷에 연결된 라우팅 테이블에서 나옵니다.

퍼블릭인지 프라이빗인지에 따라 나중에 체인에 인터넷 게이트웨이가 나타날지가 결정되므로 먼저 유형을 읽으세요. 두 번째 경로가 거기에 있으므로 그다음 서브넷을 읽으세요.

두 가지 변환을 따르세요

퍼블릭과 프라이빗 NAT 게이트웨이 모두 워크로드의 프라이빗 IPv4 소스를 NAT 게이트웨이 자체의 프라이빗 IPv4 주소로 변환합니다. 이 첫 번째 변환은 유형과 무관하게 일어납니다. 두 번째 변환은 사람들이 잊는 것입니다: 퍼블릭 NAT 게이트웨이는 트래픽을 인터넷 게이트웨이에 넘기고, 그것이 주소를 연결된 Elastic IP에 매핑합니다.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

프라이빗 경로에는 체인에 인터넷 게이트웨이가 없습니다. 트래픽이 전송 게이트웨이나 가상 프라이빗 게이트웨이를 통해 나갈 때, NAT 게이트웨이 안내서는 NAT 게이트웨이의 프라이빗 주소를 원격 측이 받는 소스로 문서화합니다. 파트너가 허용해야 하는 주소는 그것이며 Elastic IP가 아닙니다.

VPN 경로는 보통 프라이빗 주소를 보여 줍니다

10.20.1.0/24에 있는 워크로드가 파트너 접두사에 도달하는 경우, 워크로드 서브넷의 라우팅 테이블은 NAT 게이트웨이를 가리키고 NAT 게이트웨이 서브넷의 라우팅 테이블은 프라이빗 게이트웨이 경로를 가리킵니다. 두 홉 모두 중요하며, 파트너가 무엇을 보는지는 두 번째만 결정합니다. NAT 서브넷에 VPN 경로로 가는 라우트가 없으면 패킷은 결코 도착하지 않으며, 그것은 잘못된 소스 주소와 다른 실패입니다.

주소를 이야기하기 전에 그 두 번째 경로를 확인하세요. 라우트 누락과 잘못 보고된 소스는 트래픽을 보지 못하는 파트너에게 똑같이 보입니다.

두 번째 변환이 답을 바꿀 때

AWS는 전송 게이트웨이 연결에서 명시적이고 일치하는 일대일 NAT 매핑도 제공합니다. 그 매핑은 원격 서비스가 보기 전에 소스를 다시 변환할 수 있으며, 단지 라우팅만 하는 기본 동작이 아닙니다. 의도적으로 구성해야 하므로 우연히 물려받는 것이 아니라 설계 예외로 취급하세요. 팀의 누구도 켠 기억이 없다면 연결을 읽을 때까지 없다고 가정하세요.

설계에서 그것을 사용한다면 허용 목록은 NAT 게이트웨이 주소가 아니라 최종 매핑을 설명해야 합니다. 같은 주의가 가용성 경로에도 적용됩니다: 여러 게이트웨이 주소가 참여할 때 예상 소스 집합은 합집합이며 대표 주소 하나가 아닙니다. 출처 없는 목록은 나중에 감사할 수 없으므로 각 주소가 어느 변환에 속하는지 적어 두세요.

프라이빗 NAT 게이트웨이는 인터넷 게이트웨이를 가리켜도 인터넷 서비스를 얻을 수 없으며 AWS는 그러한 트래픽이 버려진다고 문서화합니다. 유형은 요구 사항의 VPN이라는 단어가 아니라 전체 경로에서 선택하세요.

파트너가 행동할 수 있는 계약을 쓰세요

쓸모 있는 계약에는 네 부분이 있습니다: 흐름이 시작되는 방향, 파트너가 보게 될 변환된 신원, 그 신원에 대한 반환 경로, 적용되는 보호 범위입니다. NAT 게이트웨이 흐름은 지원되는 소스 측에서 시작되므로 프라이빗 워크로드를 노출하기 위한 인바운드 포트 포워딩 서비스가 아닙니다. 이를 일찍 소리 내어 말하면 각 측이 상대가 시작했다고 가정한 설계 검토를 막을 수 있습니다.

변환은 주소 중복 완화와 예측 가능한 소스 정책을 사고, 파트너 로그에서 개별 워크로드 신원을 잃습니다. 감사에 워크로드별 귀속이 필요하면 그 신원을 변환된 소스 주소에서 복구하려 하지 말고 애플리케이션 계층에 유지하세요.

새 연결이나 다시 연결된 서브넷이 답을 조용히 다시 쓰므로 변경이 있을 때마다 두 라우팅 테이블을 다시 확인하세요.