GCP VM으로 가는 Cloud VPN: NAT IP가 아니라 내부 IP를 사용하세요

온프레미스 네트워크가 Cloud VPN을 통해 VPC에 도달하면 Compute Engine 서비스의 목적지는 보통 VM의 내부 주소입니다. 외부 IPv4 주소는 같은 사설 경로에 대신 넣을 수 있는 두 번째 주소가 아닙니다. 이 분야의 혼란은 대부분 세 가지 역할을 가진 세 주소를 서로 바꿔 쓸 수 있는 것으로 취급하는 데서 생기므로, 먼저 특정 패킷이 어느 것을 쓰는지 이름 붙이는 것부터 시작하세요.

세 주소, 세 가지 역할

그중 어느 것을 디버그하기 전에 세 가지를 모두 이름 붙이세요. 답에 따라 다음에 살펴볼 객체가 달라지기 때문입니다.

첫 번째는 터널에 속합니다. 두 번째는 경로와 방화벽 설계에 속합니다. 세 번째는 인바운드 인터넷 접근에 속하며 매핑되는 것이지 연결되는 것이 아닙니다. 그중 하나에 통하는 설계가 나머지 둘에 대해 말해 주는 것은 없습니다.

외부 주소가 두 번째 인터페이스가 아닌 이유

주소 지정 가이드는 Compute Engine에서 내부와 외부 도달 가능성이 어떻게 다른지에 대한 권위입니다. Compute Engine의 외부 IPv4는 인스턴스의 단일 내부 NIC에 대한 일대일 매핑이므로, 게스트는 그 NIC에서 두 번째 인터페이스나 두 번째 주소를 결코 보지 못합니다. VM이 내부에서 보고하는 것은 여전히 하나의 기본 내부 주소입니다.

그래서 터널을 통해 10.24.1.7 로 라우팅하는 사설 클라이언트와 VM의 외부 주소를 대상으로 하는 클라이언트는 서로 다른 경로에 있습니다. 공용 주소에 대해 방화벽 규칙을 열어도 터널 트래픽을 실어 나를 VPC 경로는 달라지지 않고, 게스트의 경로를 편집해도 플랫폼의 매핑은 움직이지 않습니다. 경로가 이름 붙이는 주소를 고르고, 그 주소를 지배하는 객체만 확인하세요. 이 규율은 이 문제 해결 경로에서 추측의 대부분을 없앱니다.

gcloud로 경로를 따라가기

인스턴스에서 시작해 같은 객체에서 두 주소를 모두 읽으세요. 문서가 어느 것을 말하는지 알 수 있습니다.

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

그다음 경로가 실제로 의존하는 라우팅과 권한을 확인하세요.

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

터널이 광고하고 학습한 범위 읽기, 워크로드 서브넷의 VPC 경로, 온프레미스 원본을 허용하는 방화벽 규칙까지입니다. 게스트의 리스너가 의미를 가지려면 이 셋이 먼저 일치해야 합니다.

그다음 게스트를 확인하세요. 서비스가 내부 주소에서 수신하는지, 반환 경로가 다시 VPC를 통과하는지 봅니다. 공용 주소에만 바인딩된 리스너는 클라우드 쪽 객체가 모두 올바르더라도 이 테스트에 실패합니다.

공용 프리픽스는 다른 질문

위의 어느 것도 VPN 안에서 운반되는 모든 주소가 RFC1918이어야 한다는 뜻은 아닙니다. 원격 네트워크는 플랫폼이 라우팅을 지원하고 운영자가 주소 권한을 가지면 공용 공간에서 정당하게 번호를 부여할 수 있습니다. 이것은 정상적인 설계 선택입니다.

이것은 일반적인 외부 NAT 주소를 또 다른 내부 서브넷 주소처럼 취급하는 것과 같지 않습니다. 하나는 라우팅하는 프리픽스이고, 다른 하나는 플랫폼이 인바운드 접근에 적용하는 매핑입니다.

외부 IPv6와 특별히 설계된 주소 배치는 고유한 의미론을 가집니다. 계획이 그중 하나에 의존한다면 IPv4 사례에서 일반화하지 말고 해당 기능의 플랫폼 문서를 읽으세요. IPv4 매핑은 흔한 사례이지 유일한 사례가 아니며, 예외마다 고유한 규칙이 있습니다.

겹치는 범위는 다른 문제

겹치는 사설 범위는 사람들이 공용 주소로 손을 뻗는 실제 이유이며, 그것은 잘못된 지렛대입니다. 목적지를 VM의 NAT 주소로 바꾸는 것은 겹침을 해결하지 않습니다. 패킷이 어느 주소를 위한 것이라고 주장하는지만 바꿀 뿐, 반환 경로가 어떻게 동작하는지는 정의하지 않습니다.

겹침을 의도적으로 해결하세요. 다시 번호를 매기거나, 지원되는 변환 설계를 쓰거나, 프리픽스가 충돌하지 않는 네트워크로 라우팅하세요. 각각은 책임자가 있는 설계입니다. NAT 주소는 설계가 아닙니다.

두 필드를 따로 문서화하기

터널 피어와 워크로드 목적지를 두 개의 별도 런북 필드로 기록하고, 각각을 뒷받침하는 경로와 방화벽 규칙을 함께 적으세요. 올라온 IPsec 터널은 양측이 합의했다는 것만 알려 줍니다. 워크로드가 어느 주소에서 도달 가능한지도, 사설 경로가 완전한지도 말해 주지 않습니다.

반대편의 실제 클라이언트로 검증하세요. 이름을 확인하고, 내부 주소를 반환하는지 확인하고, 연결한 뒤 반환 트래픽을 확인합니다. Compute Engine IP 주소 문서 가 위에서 사용한 내부와 외부의 구분에 대한 참고 자료입니다.