Azure VPN의 NAT로는 겹치는 VNet 주소를 해결할 수 없다
같은 사설 범위를 쓰는 두 VNet은 NAT가 있다는 이유만으로 연결되지 않습니다. 먼저 연결 유형을 확인한 뒤 번호를 다시 매기거나 변환 별칭을 직접 소유하세요.
두 VNet 모두 10.40.1.0/24을 쓰고, 터널은 올라오지만 아무것도 동작하지 않습니다. VPN 게이트웨이를 하나 더 추가해도 바뀌지 않고, 경로 메트릭을 낮춰도 마찬가지입니다. 문제는 경로 선택이 아니기 때문입니다. 같은 사설 주소에 응답하는 워크로드가 둘이면 모든 패킷은 모호한 목적지와 검증할 수 없는 반환 경로를 갖게 됩니다. 어떤 변환이든 계획하기 전에 실제로 어떤 연결 유형을 만들었는지 먼저 확인하세요. 그 하나의 선택이 Azure의 NAT 기능을 쓸 수 있는지 자체를 결정합니다.
이 증상이 실제로 말해 주는 것
VNet A의 호스트가 10.40.1.10로 보내면, 라우팅 테이블은 그저 어딘가로 향하게 할 수 있을 뿐입니다. VNet B에도 10.40.1.10이 있으면 그 주소는 경로가 구분할 수 있는 목적지가 아니라 소유자가 둘인 하나의 주소입니다.
흔히 추가로 배포하는 두 번째 게이트웨이는 도움이 되지 않습니다. 다른 터널을 줄 뿐 다른 주소를 주지 않으며, 중복된 범위는 터널 안에서 그대로 흐릅니다. 일관되게 유지해야 할 구성이 두 배가 될 뿐입니다. 그것이 할 수 없는 일은 하나의 주소가 두 호스트를 의미하게 만드는 것입니다.
VPN 피어의 공인 주소를 바꾸는 것도 아무 소용이 없습니다. 그 주소들은 터널의 끝점을 식별하는 것이고, 충돌은 그 안에서 전달되는 사설 범위에 있습니다.
NAT 사용 가능 여부는 연결 유형이 결정한다
Azure VPN Gateway에는 분명 NAT 기능이 있고, 특정 게이트웨이 SKU에서 경로 기반 IPsec 교차 구내 연결에 대해 문서화되어 있습니다. 같은 문서가 VNet-to-VNet과 지점 및 사이트 간 연결을 제외하므로, 이 기능은 모든 게이트웨이 관계에 나타나는 체크박스가 아닙니다.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
기본 VNet-to-VNet도 처음부터 VNet과 로컬 네트워크 범위가 겹치지 않아야 하며, 이는 이 제외와 일관됩니다. 같은 이유로 VNet 피어링도 겹침의 해결책이 아닙니다.
사람들이 기본 유형과 혼동하는 지원되는 대안이 있습니다. 다른 VNet을 로컬 네트워크로 모델링하고 사이트 간 연결로 연결하는 방식입니다. 이것은 다른 리소스이자 다른 설계이므로, 이름만 바꾼 연결은 단순한 개명이 아니라 검증해야 할 변경으로 다루세요.
번호를 다시 매기거나, 별칭을 소유한 무언가로 변환하라
두 VNet이 모두 여러분의 것이라면 계획된 재번호와 변환의 지속 비용을 비교하세요. 재번호는 애플리케이션 구성, DNS 레코드, 보안 규칙, 기존의 모든 연결을 건드리지만, 그 후에는 평범하게 읽히는 네트워크가 남습니다. 한 번에 하나의 서브넷씩 하고 DNS 변경은 마지막에 하세요. 절반만 재번호를 매긴 범위는 두 선택지 어느 쪽보다 나쁩니다. 그러면 다음에 테이블을 읽는 사람에게 두 접두사가 모두 정당해 보이기 때문입니다.
재번호가 현실적이지 않다면 별칭에 실제 소유자가 있는 변환 설계를 쓰세요. VNet A의 호출자는 VNet B의 10.40.1.10에 10.140.1.10로 도달할 수 있지만, 그 별칭에는 변환하는 장치, 그곳으로 가는 경로, 응답에 대한 일치하는 동작이 필요합니다. DNS에만 추가한 주소는 변환이 아닙니다.
두 범위를 양방향으로 기록하세요. 호출자가 무엇을 걸는지, 목적지가 출처로 무엇을 보는지, 어느 쪽이 시작할 수 있는지입니다. Azure 자체의 NAT 규칙에는 SNAT 매핑을 위한 역변환이 포함되므로 대응하는 DNAT 규칙을 손으로 쓰지 않습니다. 다만 그 편의는 이 기능이 지원하는 연결 유형에서 끝납니다.
동작하지 않는 것
사용자 정의 경로나 경로 메트릭은 빠진 주소 구분을 만들어 내지 못합니다. 둘 다 여전히 모호한 목적지에서 동작하고, 패킷은 테이블이 선호하는 다음 홉에 도착합니다.
중복된 범위를 더 구체적인 접두사로 라우트 테이블에 추가하는 것은 모호함을 한 걸음 옮길 뿐입니다. 또한 응답의 출처가 둘로 보이는 반대 방향을 깨뜨리기 쉽습니다.
양방향 트래픽으로 설계를 받아들여라
터널 상태가 아니라 각 측에서의 새로운 허용 작업으로 설계를 증명하세요. 연결된 IPsec 터널은 피어가 암호화에 합의했다는 것만 말하며, 목적지가 구분 가능해졌는지에 대해서는 아무것도 말하지 않습니다.
그다음 거부되어야 할 경로를 실행하세요. 접근할 수 없어야 하는 주소와 정책이 차단해야 하는 서비스입니다. 둘 다 여전히 성공한다면 변환이 설계 의도보다 넓은 것입니다.
나중에 이 구성을 설명할 사실들로 마무리하세요. 원래 범위, 제시된 범위, 변환하는 장치, 그리고 각 측이 시작할 수 있는 방향입니다. 이 중 하나라도 빠지면 다음 엔지니어는 두 호스트가 같은 이름을 공유하고 왜 한쪽이 응답하는지 아무도 기억하지 못하는 네트워크를 물려받습니다.