Azure Point-to-Site VPN이 공인 IP를 바꾸지 않는 이유
지점 및 사이트 간 터널은 가상 네트워크 경로만 전달하므로, 강제 터널링과 방화벽 SNAT가 송신을 Azure로 옮기기 전까지 공인 IP는 로컬에 그대로 남습니다.
Windows 노트북에서 Azure VPN 클라이언트를 연결하고 주소 에코 페이지를 열면 집 라우터가 할당한 것과 같은 공인 주소가 보입니다. 그동안 10.20.0.4의 점프 박스는 응답하고 프라이빗 엔드포인트 이름도 확인되므로 터널은 끊긴 것이 아닙니다. 지점 및 사이트 간 게이트웨이는 기본 구성이 말하는 대로 정확히 동작합니다. 프라이빗 접두사를 전달하고 나머지는 모두 로컬 링크에 남깁니다. Azure 소유의 송신 주소를 얻는 것은 라우팅 설계의 변경이지 수리가 아닙니다.
게이트웨이가 기본으로 알리는 것
게이트웨이는 가상 네트워크 주소 공간에 대한 경로와 게이트웨이 전송이 허용된 피어 네트워크, 사이트 간 연결이나 BGP로 학습한 온프레미스 접두사를 푸시합니다. 그 집합에는 0.0.0.0/0이 없습니다. 운영 체제는 기본 경로를 Wi-Fi 또는 이더넷에 유지하므로 공인 API로 가는 패킷은 애초에 터널에 들어가지 않습니다.
클라이언트가 터널 안에서 받는 주소는 지점 및 사이트 간 풀에서 나온 프라이빗 임대입니다. 이 주소는 VNet의 리소스에 클라이언트를 식별시킵니다. 인터넷이 볼 수 있는 주소가 아니며 SaaS API로 가는 아웃바운드 요청의 원본으로 나타나지도 않습니다. 그 임대를 전제로 만든 허용 목록 항목은 공급업체 로그에 나타나기를 아무리 기다려도 동작할 수 없습니다.
분할 터널과 강제 터널링 비교
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
원격 서비스가 보는 주소를 바꾸는 것은 두 번째 행뿐입니다. 그 표의 나머지 전부는 송신을 Azure 안에서 검사하거나 변환해야 할 때 받아들이는 비용과 운영 표면입니다. 누군가 공인 IP를 바꾸라고 한다면 오른쪽 열 전체를 요구하는 것이지 클라이언트를 조금 손보라는 것이 아닙니다.
무언가를 다시 만들기 전에 이름을 붙여 둘 중간 옵션이 있습니다. VNet 안의 프록시나 게이트웨이 VM은 그쪽으로 향하게 할 수 있는 애플리케이션에 통제된 원본 주소를 제공하며, 클라이언트의 기본 경로는 옮기지 않습니다. 이렇게 하면 일반 브라우징은 로컬에 남고 Azure에서 API 호출 하나만 도착하면 되는 파트너도 만족합니다. 요구 사항이 정말 모든 트래픽에 관한 것이라면 실패합니다. 프록시 설정을 무시하는 것은 여전히 로컬로 나가기 때문입니다.
터널이 기본 경로를 전달하게 하기
가상 네트워크 게이트웨이에서 클라이언트의 모든 인터넷 트래픽을 터널로 보내는 지원되는 방법은 지점 및 사이트 간 구성에 사용자 지정 경로를 추가하는 것입니다: 두 개의 절반이 IPv4 공간 전체를 덮고, 각각이 로컬 기본 경로보다 구체적이므로 클라이언트는 아무것도 삭제하지 않고 이를 선호합니다.
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1그 줄은 예시일 뿐 그대로 복사할 수 있는 완전한 것이 아닙니다. 먼저 Get-AzVirtualNetworkGateway로 게이트웨이 개체를 가져와 GWOBJ 대신 넣고, 실행하기 전에 SKU와 배포 모델이 사용자 지정 경로를 허용하는지 확인하십시오. 같은 접두사는 포털의 지점 및 사이트 간 구성 페이지에도 있으며, 게이트웨이를 아직 스크립트로 관리하지 않는다면 그곳에서 설정하는 편이 더 안전합니다.
이 접두사를 바꾸면 클라이언트 패키지가 무효가 됩니다. 경로가 프로필 안에 들어 있으므로 VPN 클라이언트 패키지를 다시 내려받아 재설치하십시오. 이전 프로필로 다시 연결한 클라이언트는 이전 경로 집합을 유지하며, 도달하지 못한 변경을 디버깅하느라 한 시간을 잃을 수 있습니다.
보호된 Virtual WAN 허브에서는 지점 및 사이트 간 게이트웨이와 연결된 허브 경로 테이블의 기본 경로가 그에 해당하며, 트래픽은 허브의 Azure Firewall이 맡습니다. 방화벽은 인터넷으로 향하는 연결을 자체 공인 IP 주소로 변환하고, 그 변환에서 새 송신 주소가 나옵니다. 방화벽에 공인 IP가 여러 개 있으면 그중 어느 것이든 원본으로 나타날 수 있으므로 허용 목록에는 전부 포함해야 합니다.
위의 두 설계는 모두 IPv4입니다. 두 개의 /1 접두사는 IPv6에 아무 효과가 없고, 지점 및 사이트 간 IPv6 지원은 좁아서 동등성을 약속하기 전에 조합을 시험해야 합니다.
경로를 확인한 다음 출구를 확인
패키지를 재설치하고 다시 연결한 뒤 클라이언트가 실제로 절반을 설치했는지 확인하십시오. Windows에서는 Get-NetRoute -DestinationPrefix 0.0.0.0/1과 128.0.0.0/1에 대한 같은 쿼리가 터널 인터페이스를 가리켜야 하고, route print는 원래 기본 경로 옆에 둘 다 표시합니다. Linux에서는 ip route show가 두 접두사를 나열해야 합니다. 나열하지 않으면 프로필이 그것을 전달한 적이 없습니다.
그다음 클라이언트에서 공인 주소를 다시 확인하고 같은 연결에 대한 방화벽 로그를 읽으십시오. 원본은 변환된 포트를 가진 방화벽의 공인 IP여야 합니다. 두 경로가 있는데도 클라이언트가 여전히 로컬로 나간다면 패킷이 Azure에 도달한 뒤 다른 경로로 나간 것입니다. 게이트웨이 서브넷의 사용자 정의 경로, 그 자체가 온프레미스로 강제 터널링된 방화벽, 또는 변환 전에 흐름을 버리는 정책입니다.
같은 세션에서 프라이빗 대상 하나를 다시 시험하십시오. 변경 후 응답을 멈추는 점프 호스트는 새 접두사가 무언가를 밀어냈다는 흔한 신호입니다. 이전에 알려지던 더 좁은 로컬 경로이거나, 이제 프라이빗 영역에 대한 포워더가 없는 리졸버로 가는 이름 확인입니다.
분할 터널을 그대로 둘 때
목표가 프라이빗 API, 프라이빗 엔드포인트, 내부 관리 페이지에 도달하는 것뿐이라면 기본 동작이 더 저렴하고 조용합니다. 강제 터널링은 방화벽 시간과 데이터 처리 요금, 더 긴 경로, 모든 클라이언트 흐름이 실패할 수 있는 지점을 하나 더 추가합니다. 관심 있던 단일 대상보다 훨씬 많은 트래픽도 잡습니다.
요구 사항이 송신 관점에서 제시될 때 사용하십시오. 파트너가 고정 Azure 주소를 봐야 하거나, 보안이 연결을 기록하고 검사하기를 원하거나, 데이터가 하나의 통제된 지점으로 나가야 하는 경우입니다. 그때도 설계는 모든 사용자에게 공유 출구를 주므로 사용자별 책임은 원본 주소가 아니라 애플리케이션의 ID에서 와야 합니다.
변경을 마치기 전에 설치된 클라이언트 패키지가 새것인지, 두 개의 /1 경로가 터널 인터페이스에 있는지, 프라이빗 대상이 여전히 응답하는지, 원격 서비스 로그에 방화벽 주소가 표시되는지 네 가지를 확인하십시오.