Azure P2S: VNet 변경 후 Windows 클라이언트 한 대에서 경로가 사라짐

노트북 두 대가 같은 Azure point-to-site 게이트웨이에 인증하며, 새로 연결된 VNet에 도달하는 것은 한 대뿐입니다. 둘 다 Connected를 표시하므로 인증은 차이가 아닙니다. 차이는 각자 보유한 대상 경로입니다. 실패하는 클라이언트에서 시작해 하나의 대상을 비교하고, 그다음에야 게이트웨이 패키지와 로컬 경로 테이블 중 무엇이 문제인지 결정합니다.

게이트웨이가 아니라 실패하는 클라이언트에서 시작

노트북을 탓하기 전에 토폴로지를 확인합니다. 어떤 VNet이 게이트웨이 VNet에 연결되어 있는지, 새 네트워크가 직접 피어링되었는지 아니면 별도의 site-to-site 터널로 도달하는지 확인합니다. 새 VNet이 게이트웨이 VNet에 전혀 연결되어 있지 않다면 어떤 클라이언트 패키지도 그곳으로 라우팅할 수 없고, 작동하는 노트북이 오히려 설명해야 할 예외입니다. 답을 적어 두십시오. 클라이언트를 디버깅하는지 게이트웨이를 디버깅하는지가 여기서 결정됩니다.

토폴로지가 맞으면 두 노트북을 나란히 둡니다. 같은 게이트웨이, 같은 주소 풀, 같은 프로토콜, 같은 클라이언트 빌드가 원하는 비교입니다. 그 밖의 것은 나중에 제거해야 할 두 번째 변수입니다.

route print로 하나의 대상 비교

허용된 리소스 IP를 고르고 두 노트북을 두 번 비교합니다. 연결 해제 상태와 연결 상태입니다. Windows에서 route print -4은 대상 접두사, 인터페이스, 다음 홉, 메트릭과 함께 IPv4 경로를 나열합니다. VPN이라는 단어가 들어간 항목을 세는 대신 해당 대상에서 실제로 이길 행을 기록하십시오.

선택은 먼저 가장 긴 접두사, 다음으로 메트릭 순이므로 더 구체적인 로컬 경로가 잘못 보이지 않으면서 터널 경로를 이길 수 있습니다. 의도한 대상이 10.24.0.0/16 안에 있으면 정상 클라이언트는 VPN 인터페이스에 일치하는 경로를 표시하고, 실패하는 클라이언트는 같은 주소를 기본 게이트웨이로 보냅니다.

충돌하는 로컬 접두사도 같은 증상을 만들 수 있습니다. 무엇이든 추가하기 전에 두 경우 중 어느 것인지 결정하십시오. 터널 경로가 전혀 없는지, 아니면 더 구체적인 경로에 지는지입니다.

TTL expired는 경로 배포 버그가 아님

TTL expired in transit을 반환하는 ping은 패킷이 홉 허용량을 다 썼다는 뜻이며, 보통 VPN 드라이버 고장이 아니라 전달 루프를 의미합니다. Windows ping은 255까지의 TTL을 받아들이고, 값을 올려도 루프는 고쳐지지 않습니다. 같은 오류만 늦출 뿐입니다. 이 메시지는 경로의 증상으로 다루고 경로 배포에 대한 증거로 보지 마십시오.

tracert -4 10.24.1.10를 사용해 경로가 어디서 반복되는지 확인합니다. 같은 두 홉이 계속 나타나면 터널로 향하는 트래픽을 다시 터널로 보내거나 되돌려 보내는 로컬 라우터로 보내는 경로를 찾으십시오.

소유한 게이트웨이에서 패키지 다시 생성

Microsoft는 관련 토폴로지 변경 후 Windows 클라이언트 패키지를 다시 내려받아 설치해야 한다고 문서화합니다. 이 프로필을 제공하는 Azure 게이트웨이에서 현재 패키지를 받은 다음 해당 클라이언트에 지원되는 절차로 적용합니다. 관련 없는 VPN 응용 프로그램의 실행 파일을 교체하는 것은 게이트웨이별 설정을 다시 생성하는 것과 같은 작업이 아닙니다. 패키지를 다시 내려받는 것은 저렴하지만 로컬 경로를 추측하는 것은 그렇지 않습니다.

다시 연결하고 원래 대상의 경로를 다시 읽습니다. 변경 기록과 함께 변경 전후 행을 보관하면 결과가 클라이언트를 다시 설치했다는 표현보다 정확해집니다.

Azure P2S 라우팅 시나리오는 직접 피어링된 VNet과 다른 터널을 통해 도달하는 네트워크를 구분하며, 새 패키지로 피어링을 전이적으로 만들 수는 없습니다. 일부 Windows site-to-site 또는 BGP 시나리오는 수동으로 구성한 원격 경로도 필요하므로 패키지 새로 고침은 보편적인 경로 배포 방식이 아닙니다.

임시 경로는 임시로 유지

수동 경로는 누락된 클라이언트 경로를 분리할 수 있지만 실제 설계에서 만들어야 합니다. route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42을 영구 플래그 없이 사용해 재부팅 시 사라지게 하십시오. 인터페이스 인덱스와 다음 홉은 연결된 VPN 어댑터에서 고르고 추측하지 마십시오.

실험용 경로를 영구적인 경쟁 소유자로 남기지 마십시오. 향후 프로필 업데이트가 같은 접두사를 다른 메트릭으로 추가하면 수동 항목이 어느 경로가 이기는지 조용히 결정합니다. 제거 단계를 변경에 기록하십시오.

올바른 경로가 활성화되면 ping 대신 대상 응용 프로그램을 시험합니다. 패킷이 Azure에 도달하지만 서비스가 계속 실패하면 네트워크 보안 그룹과 반환 경로를 확인하십시오. 이는 노트북이 접두사를 학습했는지와 별개입니다.