NVA 없이 ExpressRoute를 통한 Azure 프라이빗 IP VPN

오해는 ExpressRoute 프라이빗 피어링을 통한 트래픽 암호화에 네트워크 가상 어플라이언스가 필요하다는 것입니다. 그렇지 않습니다. Azure는 터널 끝점이 회선을 통해 전달되는 프라이빗 RFC1918 주소인 Site-to-Site VPN Gateway를 지원하며, 어플라이언스는 구조적이 아니라 선택 사항입니다. 이 오해가 숨기는 것은 실제로 문제가 되는 부분입니다. 프라이빗 끝점을 두 개가 아닌 한 개 개체에서 사용하도록 설정하는 것, 그리고 직접 피어링 경로가 암호화된 경로를 조용히 이기게 두는 것입니다.

오해가 생겨난 곳

이 주장에는 존중할 만한 유래가 있습니다. 수년 동안 프라이빗 피어링을 통한 IPsec의 실용적 방법은 NVA였습니다. 관리형 게이트웨이가 공용 끝점만 노출했기 때문입니다. 그것이 바뀌었고, 바뀌기 전에 쓰인 답변이 날짜를 아무도 확인하지 않는 스레드에서 여전히 인용됩니다. 수정은 좁습니다. 프라이빗 주소의 VPN 게이트웨이가 존재하며, 그것은 끝점을 바꿀 뿐 그 주변의 라우팅 논리를 바꾸지 않습니다.

이 중 어느 것도 NVA를 은퇴시키지 않습니다. 은퇴하는 것은 어플라이언스가 요구 사항에 이르는 유일한 길이라는 가정입니다.

두 수준 모두에서 프라이빗 끝점 사용

VPN 게이트웨이가 있는 VNet에 연결된 작동하는 ExpressRoute 프라이빗 피어링 연결에서 시작합니다. 온프레미스 측은 이미 해당 회선을 통해 관련 프라이빗 주소에 도달해야 합니다. 터널이 그 주소를 전송 수단으로 사용하기 때문입니다. 다음은 게이트웨이의 전제 조건입니다. 프라이빗 IP VPN에 대한 Microsoft 절차는 Standard 공용 IP 리소스에 구축된 게이트웨이를 요구합니다. 프라이빗 터널 주소 지정은 그 요구 사항을 없애지 않으며, 이는 «프라이빗»이 «어디에도 공용 IP가 없음»을 뜻한다고 가정하는 사람들을 놀라게 합니다.

이제 두 곳 모두에서 플래그를 사용하도록 설정합니다. 게이트웨이 구성에는 프라이빗 IP를 위한 자체 스위치가 있고, 개별 Site-to-Site 연결에는 그 연결이 프라이빗 주소를 사용하도록 만드는 두 번째 스위치가 있습니다. 하나만 설정하고 다른 하나를 설정하지 않는 것이 가장 흔한 불완전한 구성입니다. 터널은 설정되지 않거나 잘못된 끝점으로 설정됩니다.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

설치된 CLI 버전에 대해 속성 이름을 확인하세요. 포털 레이블과 CLI 속성이 항상 같은 표현을 쓰는 것은 아닙니다. 활성-활성 게이트웨이는 두 개의 프라이빗 터널 주소를 노출하며, 그 중복성이 의미를 가지려면 온프레미스 장치에 두 피어가 모두 구성되어 있어야 합니다. 이 프라이빗 주소 터널을 올리는 데만 BGP가 필요한 것은 아니지만, 일반적으로 접두사를 배포하는 방식의 일부입니다.

두 번째 오해: 설정된 터널이 트래픽을 암호화한다

이제 응용 프로그램 네트워크에 두 경로가 도달합니다. 직접 프라이빗 피어링 경로와 VPN을 통한 경로입니다. 둘 다 작동합니다. 이 IPsec 계층을 적용하는 것은 하나뿐입니다. Microsoft는 동일한 접두사가 ExpressRoute와 VPN 모두에서 알려질 때 Azure가 직접 ExpressRoute 경로를 선호한다고 문서화합니다. 따라서 정상 터널과 정상 카운터는 응용 프로그램 패킷이 어디로 갔는지 아무것도 증명하지 않습니다.

문서화된 조정 방법은 ExpressRoute의 포함 범위와 VPN의 더 구체적인 보호 범위, 또는 두 경로의 겹치지 않는 접두사입니다. 예를 들어 프라이빗 피어링이 10.40.0.0/16을 전달하고 VPN이 10.40.12.0/24를 알릴 수 있습니다. 더 구체적인 접두사가 이기고 범위의 나머지는 직접으로 남습니다.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

온프레미스 방향에서도 같은 점검을 하세요. 아웃바운드 트래픽이 어느 쪽으로 나가는지는 라우터의 기본 설정이 결정하기 때문입니다. 그리고 터널 자체의 전송은 ExpressRoute 경로에 두세요. 게이트웨이의 프라이빗 끝점을 터널 안으로 끌어들이는 경로는 터널이 자기 자신에 의존하게 만듭니다.

터널이 끊겼을 때 무슨 일이 일어날지 결정

터널이 끊기면 더 구체적인 VPN 경로가 사라지고 더 넓은 직접 경로는 남습니다. 그러면 트래픽이 암호화 없이 흐르고 모든 것이 정상으로 보입니다. 암호화를 보장하기 위해 존재하는 요구 사항에 있어 최악의 장애 모드입니다. 요구 사항이 그 폴백을 금지한다면 라우팅과 액세스 정책이 터널 가용성에 의존하는 대신 이를 명시해야 합니다.

어떤 접두사가 직접 도달 가능한 상태로 남아도 되는지, 어떤 접두사가 암호화된 경로가 없을 때 중단되어야 하는지 적어 두세요. 그런 다음 허용된 사례를 실제 트래픽으로 테스트하고 연결 카운터를 비교하세요. 라우팅 테이블만으로는 암호화 요구 사항이 여전히 유지되는지 알 수 없습니다.

이 틀은 또한 끝점이 프라이빗이라는 이유로 NVA를 사는 대신 여러 터널, 처리량, 공급업체 검사 같은 실제 기능으로 NVA를 평가할 수 있게 합니다.