Azure의 VPN 어플라이언스 VM이 반환 경로를 잃는 이유
Azure VM 안의 VPN 어플라이언스는 UDR, NIC 전달 플래그, 게스트 정책이 서로 맞아야 합니다. 브랜치 요청 하나를 세 가지 모두에 통과시켜 보십시오.
VPN 어플라이언스를 실행하는 Azure VM은 서로 독립적인 두 의사 결정 체계 안에 있습니다. 패킷이 어느 서브넷에서 나가는지는 Azure가 라우트 테이블과 NIC의 전달 설정으로 결정합니다. 복호화된 패킷을 다음으로 전달할지는 어플라이언스 자체의 운영 체제가 결정합니다. 완벽하게 올라온 터널도 두 번째 체계에서 실패할 수 있으며, 대부분의 이런 배포가 바로 그 지점에서 멈춥니다.
하나의 경로를 가진 세 주인
브랜치 네트워크는 192.168.50.0/24 이고 워크로드 서브넷은 10.0.10.0/24이며 어플라이언스는 10.0.0.4 자체 서브넷에 있습니다. 요청 하나가 세 가지 별도 구성을 건드립니다.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
대부분의 조직에서 각 행을 서로 다른 팀이 소유하므로, 이 고장은 보통 하나가 아니라 세 개의 티켓으로 도착합니다.
어플라이언스를 가리키는 경로
워크로드 서브넷에 라우트 테이블을 연결하고 브랜치 접두사에 Virtual appliance 유형의 다음 홉을 지정하고 주소는 10.0.0.4 를 씁니다. 어플라이언스의 도달 가능한 사설 주소를 사용하고, 절대 공용 VPN 진입점은 쓰지 마십시오. 다음 홉은 워크로드 서브넷이 이미 도달할 수 있는 주소여야 합니다. 기본 경로를 의도적으로 바꾸기로 하지 않았다면 워크로드의 나머지 라우팅은 그대로 두십시오.
어플라이언스는 자체 서브넷에 두고, 브랜치 트래픽을 어플라이언스로 보내는 경로가 어플라이언스 자체의 아웃바운드 경로까지 잡지 않도록 하십시오. 그런 루프는 응답이 전혀 없는 정상 터널처럼 보이며, 새벽 2시에 디버깅하기에는 매우 괴로운 일입니다.
모두가 잊는 NIC 플래그
Azure에는 NIC별 IP 전달 설정이 있고 기본값은 꺼짐입니다. 전달하는 NIC는 자신이 아닌 다른 대상으로 향한 패킷을 받기 때문에 이 설정이 존재하며, 그것을 조용히 버리는 것이 나머지 모두에게 안전한 기본값입니다.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true 인터페이스 하나에 대해 이 설정을 켭니다. Microsoft의 NIC 전달 지침 은 트래픽을 전달하는 연결된 모든 NIC에 이 설정을 요구하므로, NIC가 하나뿐인 어플라이언스도 그 NIC에 설정해야 합니다.
이 플래그는 경로가 아니고 방화벽 규칙도 아닙니다. 켜면 권한만 주어지고 그 밖의 것은 없습니다.
게스트가 복호화된 패킷으로 하는 일
터널이 끝나면 어플라이언스 자체 스택이 다음 결정을 내립니다. Linux 게스트에서 IPv4 전달은 런타임 설정이며, sysctl -w net.ipv4.ip_forward=1 다음 부팅까지만 유지됩니다. 대신 /etc/sysctl.d/ 아래 파일에 저장하십시오. 벤더 어플라이언스에는 자체적인 동등 기능이 있고, 벤더 플랫폼에 붙여 넣은 Linux 지침은 보통 아무 일도 하지 않습니다.
게스트 방화벽 정책도 다시 별개이고, 워크로드의 네트워크 보안 그룹도 마찬가지입니다. VM의 공용 주소로 UDP 500과 4500을 허용하는 것은 터널을 보호하지만, 복호화된 브랜치 요청이 워크로드 포트에 도달할 수 있는지에 대해서는 아무것도 말해 주지 않습니다.
요청 하나와 그 응답을 따라가 보십시오
허용된 흐름 하나를 골라 처음부터 끝까지 추적하십시오. 브랜치에는 10.0.10.0/24 에 대한 경로가 사이트 연결을 통해 필요하고, 어플라이언스에는 워크로드 서브넷으로 가는 전달 경로가 필요하며, 워크로드 서브넷에는 브랜치 쪽으로 돌아가는 경로가 필요합니다.
설계가 브랜치 원본 주소를 보존하는지 변환하는지 일찍 결정하십시오. NAT는 워크로드가 보는 것을 바꾸므로, 접근 규칙은 추측한 게이트웨이 주소가 아니라 실제로 선택한 모델을 설명해야 합니다.
성공적인 핸드셰이크는 그 사슬의 고리 하나를 증명할 뿐입니다. 응답이 같은 어플라이언스를 통해 돌아오고 워크로드 자체 정책이 이를 허용할 때 경로가 완성됩니다.