Azure UDR로 VPN 게이트웨이 연결: 모든 송신이 아닌 하나의 대상

외부 프리픽스 하나에 사용자 정의 경로를 추가하고 VPN 게이트웨이로 향하게 했는데도 트래픽은 여전히 Azure의 인터넷 경로로 나갑니다. 아니면 올바르게 나가지만 응답이 돌아오지 않습니다. 두 결과 모두 같은 실수에서 나옵니다. Azure의 다음 홉을 설계 전체로 보는 것입니다. 경로 테이블은 Azure 내부에서 패킷이 어느 출구를 택할지만 결정합니다. 터널을 나온 뒤 무슨 일이 생기고 응답이 어떻게 돌아오는지는 여러분이 만들어야 할 나머지 절반입니다.

다음 홉은 게이트웨이이지 어플라이언스 IP가 아닙니다

UDR은 일치하는 프리픽스를 다음 홉 유형으로 보내며, VirtualNetworkGateway는 주소가 아니라 유형입니다. 사람들은 게이트웨이의 사설 IP를 VirtualAppliance 경로에 붙여 넣고 왜 아무것도 맞지 않는지 궁금해하는데, 그 유형은 대신 NIC나 내부 부하 분산 장치를 기대하기 때문입니다. Microsoft의 라우팅 문서도 게이트웨이 다음 홉을 게이트웨이가 VPN 게이트웨이인 가상 네트워크로 제한합니다. ExpressRoute, Route Server, Virtual WAN 허브는 이 옵션으로 처리되지 않습니다.

경로를 쓰기 전에 가상 네트워크가 실제로 무엇을 가지고 있는지 확인하십시오. 설계가 허브를 통해 라우팅한다면 그 경로는 편집 중인 스포크가 아니라 허브의 라우팅 소유자에게 속합니다.

무엇이든 바꾸기 전에 유효 경로를 읽으십시오

Azure는 시스템 경로, BGP로 학습한 프리픽스, UDR을 NIC별 유효 경로 테이블로 결합하며, 출처와 관계없이 가장 길게 일치하는 프리픽스가 이깁니다. 같은 프리픽스에서는 UDR이 BGP 경로를 이깁니다. 이런 순서 때문에 이전 실험에서 남은 오래된 UDR이 방금 터널을 통해 학습한 프리픽스를 조용히 덮어쓸 수 있습니다.

먼저 유효 테이블을 보고, 그다음 경로를 추가할지 교체할지 결정하십시오:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

프리픽스뿐 아니라 소스 열도 읽으십시오. 올바른 프리픽스와 잘못된 소스를 가진 경로는 어떤 개체를 편집해야 하는지 알려 주고, 첫 경로에 지는 두 번째 경로를 추가하는 일을 막아 줍니다.

실제 프리픽스와 서브넷에 맞춰 경로를 작성하십시오

포럼 게시물에서 복사한 공인 범위가 아니라 실제로 도달하는 서비스에서 가져온 목적지의 실제 프리픽스를 사용하십시오. 모든 출구를 옮기는 기본 경로를 고려하기 전에 승인된 서비스 하나로 시작하십시오. 그다음 경로 테이블을 워크로드 서브넷에 연결합니다. 게이트웨이 서브넷에는 자체 요구 사항이 있으며, 거기에 테이블을 연결하면 워크로드를 유도하는 대신 게이트웨이가 깨집니다.

경로를 만든 다음 테이블을 워크로드가 있는 서브넷에 바인딩하십시오:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

전파도 중요합니다. 해당 테이블에서 BGP 전파가 켜져 있으면 학습된 프리픽스가 직접 쓴 것과 나란히 나타나며, 더 구체적인 학습 프리픽스가 더 넓은 UDR을 이길 수 있습니다. 해당 서브넷에 대해 UDR 집합이 권위를 가지길 원할 때만 전파를 끄십시오.

온프레미스 쪽 절반을 끝내지 않으면 흐름이 거기서 죽습니다

온프레미스 게이트웨이는 Azure 원본을 받아들여 목적지로 전달하고 애플리케이션을 허용해야 합니다. 그 다음 경로는 인터넷 출구나 다른 사설 홉일 수 있지만, 그 결정은 Azure 경로 테이블이 아니라 계획에 속합니다. 흔한 실패는 반환 경로입니다. 인터넷 목적지는 사설 Azure 원본을 여러분에게 되돌려 라우팅하지 않으므로 응답은 자체 기본 게이트웨이로 가서 사라지거나, 아예 나가지 않습니다.

두 가지 설계가 이를 해결하며 서로 바꿔 쓸 수 없습니다. 출구에서 원본을 변환하십시오, 그러면 목적지는 온프레미스 네트워크가 소유한 공인 주소로 응답합니다. 또는 원본을 보존하고 응답이 터널을 통해 돌아오도록 라우팅된 반환 관계를 만드십시오. 하나를 선택하고 애플리케이션이 어떤 주소를 보게 될지 적어 두십시오.

선택기와 허용 목록은 이 모든 것과 별개입니다. Azure 다음 홉을 고른다고 VPN 트래픽 선택기가 넓어지지 않고, 외부 서비스의 원본 허용 목록도 바뀌지 않습니다.

목적지가 관찰한 원본으로 검증하십시오

다른 서브넷의 점프 호스트가 아니라 실제 워크로드에서 요청을 보내고, 목적지가 관찰한 원본 주소를 읽으십시오. 그 값 하나가 두 가지 반환 설계 중 어느 것이 적용되었는지 알려 줍니다. 그다음 응답 경로를 확인하고 VM으로 가는 일반 관리 트래픽이 여전히 동작하는지 확인하십시오. 실수로 추가한 기본 경로는 애플리케이션이 깨지기 훨씬 전에 끊긴 SSH 세션으로 나타나기 때문입니다.

선택한 프리픽스를 통한 전송은 강제 터널링보다 훨씬 좁은 변경입니다. 좁게 유지하면 롤백은 경로 하나를 삭제하는 것입니다.