Azure VPN VM 하나에 공인 IP 두 개: 각각 무엇을 하는가
VPN 패킷을 받는 주소가 클라이언트 웹 요청의 공인 출발지를 정하지는 않는다. 진입, 진출, 터널 바인딩을 따로 결정하라.
Azure VPN VM 하나에 공인 IP 두 개를 두면 거의 성립하지 않는 기대가 생긴다. 클라이언트가 접속하는 주소가 웹사이트가 보는 주소도 될 것이라는 기대다. 이 결과는 세 가지 독립적인 결정에서 나오며, 터널 리스너에 관한 것은 첫 번째뿐이다. 두 번째는 전달된 클라이언트 트래픽에 쓰는 게스트 출발지이고, 세 번째는 그 출발지에 적용되는 Azure의 진출 방식이다. 하나를 바꿔도 나머지 둘은 그대로이므로 각각을 명시적으로 결정해야 한다.
결정 1: 터널이 끝나는 지점
Azure 공인 IP는 NIC의 사설 IP 구성에 연결된다. 게스트 운영체제 안에서 추가하는 주소가 아니다. 추측하지 말고 매핑을 읽어라: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. 이 쿼리가 돌려주는 사설 주소가 바로 게스트가 실제로 가져야 하는 주소다.
NIC 하나가 여러 IP 구성을 실을 수 있으므로 공인 주소 두 개에 NIC 두 개가 필요한 것은 아니다. 설계가 정말 NIC 두 개를 쓴다면 각각이 자체 게스트 경로와 다음 홉을 가져오며, 단순화가 아니라 라우팅 결정을 하나 더한 셈이다.
명시적인 로컬 바인딩이 있는 서비스라면 실제 게스트 사설 주소에 바인딩하고, 공인 자리표시자에는 절대 바인딩하지 마라. 모든 주소를 받는 리스너는 자신에 도달하는 모든 IP 구성을 통해 트래픽을 받으므로, 바인딩 순서에 맡기지 말고 네트워크 보안 그룹과 호스트 방화벽으로 진입을 제한하라.
결정 2: 전달된 클라이언트가 쓰는 출발지
게이트웨이가 클라이언트 요청을 복호화한 뒤 전달하는 패킷은 VPN 리스너에 도착한 패킷과 다르다. 게스트에는 전달 기능 활성화, 흐름을 허용하는 방화벽 정책, 클라우드 설계가 허용하는 출발지 주소가 필요하다. 클라이언트의 내부 주소를 변환한다면 Azure가 평가하는 것은 그 변환된 출발지이지 클라이언트의 내부 주소가 아니다.
좁은 SNAT 규칙은 게스트 사설 출발지를 고를 수 있지만 하위 Azure 변환을 이길 수는 없다. VM 안에서 클라이언트별 책임성이 필요하면 SNAT를 선택하라. 서브넷의 진출 설계가 이미 안정적인 공인 출발지를 제공하고 두 번째 변환이 상태만 늘린다면 생략하라.
결정 3: 어떤 Azure 진출 방식이 이기는가
Microsoft는진출 우선순위를 문서화한다. 어플라이언스나 게이트웨이로 가는 적용 가능한 경로가 우선하며, 해당 경로에서는 서브넷의 NAT Gateway 연결이 인스턴스 수준 공인 IP보다 우선한다. 이 순서 때문에 10.20.0.5로 변환해도 웹사이트가 198.51.100.20을 본다는 증명이 되지 않는다. 진출 설계를 받아들이기 전에 유효 경로 테이블, NAT Gateway 연결, NIC의 공인 IP를 함께 읽어라.
다음을Azure NIC 전달 설정으로 두고, Linux 전달과는 별개로 다뤄라. 클라우드 플래그는 출발지나 목적지가 NIC에 할당되지 않은 패킷을 허용하지만 net.ipv4.ip_forward을 켜지는 않으며, 게스트 설정이 클라우드 권한을 주는 것도 아니다.
터널 소켓에는 자체적인 출발지 결정이 있다
wg-quick 아래의 WireGuard Address은 WireGuard 인터페이스에 주소를 할당한다. 바깥쪽 UDP 바인딩 지시가 아니다. 암호화된 소켓의 출발지는 라우팅 테이블을 따르므로 정책 경로나 두 번째 기본 경로가 인터페이스 주소를 건드리지 않고 옮길 수 있다.OpenVPN의 local 옵션과 UDP multihome도 같은 방식으로 동작한다. 이들은 리스너와 그 응답에 관한 것이지 전달되는 각 클라이언트의 인터넷 출발지에 관한 것이 아니다.
터널을 나르는 언더레이 경로를 유지하고, 클라이언트가 예상한 진입 구성에서 여전히 인증된 응답을 받는지 확인하라. 주소 목록 순서를 영구적인 출발지 선택 정책으로 믿지 마라. NIC에 다음으로 추가되는 주소가 어느 쪽이 이길지 바꿀 수 있다.
무엇을, 어떤 순서로 받아들일 것인가
세 가지 결과를 따로 받아들여라. 첫째, 외부 클라이언트가 의도한 VPN 진입에 도달한다. 둘째, 그 VPN 클라이언트의 새로 허용된 요청이 문서화된 인터넷 진출로 나간다. 셋째, 의도하지 않은 리스너 및 전달 경로는 계속 거부된다. 공인에서 사설로의 매핑과 각 결정의 게스트 및 클라우드 책임자를 같은 곳에 기록하라.
성공한 터널은 첫 부분만 증명한다. 진출은 새 흐름으로 시험하라. 캐시된 연결은 경로가 바뀐 뒤에도 오래전 출발지를 계속 쓸 수 있다.