VPN이 시작된 후 Azure VM이 IMDS나 WireServer에 도달하지 못함

VM은 켜져 있고 VPN 클라이언트는 연결됐다고 말하는데, 몇 분 뒤 Azure 에이전트가 비정상 상태를 보고하기 시작합니다. 때로 SSH는 살아 있고 포털의 Run Command는 안 되어, 사람들이 라우팅 테이블 대신 에이전트를 들여다보게 됩니다. 터널이 올라올 때 게스트 자체의 전달 결정이 바뀌었고, 보통 두 개의 플랫폼 주소가 첫 희생자입니다. 저는 이것을 에이전트 고장으로 다루기 전에 라우팅 증상으로 다룹니다.

증상은 고장 난 에이전트처럼 보입니다

아래 두 주소 모두 해결책으로 제안되지만 같은 서비스가 아닙니다. 하나에 통했으니 다른 하나에도 /32를 복사하는 것이야말로 임시 우회책이 아무도 지우지 못하는 영구 설정이 되는 길입니다.

통하는 순서는 먼저 실패한 호출이 실제로 어느 주소를 대상으로 하는지 확인하고, 그다음 게스트가 그것을 어떻게 해석하는지 읽는 것입니다. 나머지는 단계만 늘어난 추측이고 변경 창은 더 길어집니다.

168.63.129.16은 공용 목적지가 아닙니다

168.63.129.16은 Azure의 특별한 가상 플랫폼 주소이며, 그 역할 중 하나가 WireServer입니다. VM 에이전트가 패브릭과 통신할 때 사용합니다. Microsoft는 에이전트의 TCP 80 및 32526 포트 트래픽이 계속 사용 가능해야 한다고 문서화합니다. 이것은 평범한 인터넷 호스트가 아니며, 전체 터널 VPN이 원격 출구로 실어 보내야 할 대상도 아닙니다. 그래서 건강해 보이는 터널도 에이전트를 굶길 수 있습니다.

플랫폼 주소 문서는 또한 이 주소가 사용자 정의 경로의 적용을 받지 않는다고 밝힙니다. 이는 Azure 패브릭의 속성일 뿐 게스트에 대한 약속이 아닙니다. 로컬 방화벽 규칙이나 VPN 클라이언트 자체의 라우팅 정책은 여전히 경로를 끊을 수 있고, 둘 다 VNet의 라우팅 테이블에 있지 않습니다.

문제를 보고하는 것이 에이전트라면, 무엇이든 다시 설치하기 전에 서비스 상태와 그 주소로 가는 경로를 확인하십시오.

169.254.169.254에는 자체 규칙이 있습니다

169.254.169.254는 Azure Instance Metadata Service의 link-local 주소입니다. 이 주소로 가는 요청에는 자체 조건이 있습니다. 기본 NIC와 기본 IP, 주소를 지원하는 DHCP 구성, 그리고 모든 HTTP 프록시 우회입니다. 원격 VPN 출구나 임의의 인터넷 게이트웨이로 보내는 것은 Microsoft가 설명하는 접근 모델이 아닙니다.

그 프록시 조항은 경로를 고쳤는데도 실패를 보는 사람을 잡아냅니다. 게스트 HTTP 프록시가 IMDS를 깨뜨릴 수 있는 반면 ip route get은 기대한 인터페이스를 정확히 반환하므로, 경로뿐 아니라 프록시 예외도 확인하십시오.

이것을 디버깅하는 동안 메타데이터 응답을 지원 티켓에 붙여 넣지 마십시오. 사고보다 오래 남는 자격 증명과 인스턴스 세부 정보를 담을 수 있습니다.

게스트의 정책 라우팅을 읽으십시오. 메인 테이블만 보지 마십시오

Linux 게스트에서는 세 개의 읽기 전용 명령이 계층을 나눕니다. 정책 규칙에는 ip -4 rule show, 커널이 실제로 내리는 결정에는 ip -4 route get 168.63.129.16와 ip -4 route get 169.254.169.254입니다. VPN 연결 전과 후에 실행하십시오. 그 두 출력의 차이가 여러분의 변경 집합이며, 클라이언트가 무엇을 했는지에 대한 어떤 추측보다 유용합니다.

정책 규칙을 설치하는 VPN 클라이언트는 메인 테이블을 건드리지 않고도 그 조회를 우회시킬 수 있습니다. 그래서 메인 테이블만 고치는 해법은 한 호스트에서는 되는 듯하고 다음 호스트에서는 아무것도 하지 않습니다. NIC가 여러 개인 게스트는 같은 문제를 반대 방향에서 추가합니다. 답은 규칙이 어느 NIC와 소스 주소를 선택하느냐에 달려 있기 때문입니다.

예전 게이트웨이를 통해 두 /32 경로를 모두 추가하는 처방에 저항하십시오. link-local 플랫폼 경로와 일반 WAN 다음 홉은 다른 객체이며, 포괄적 예외는 실제 정책 충돌을 가립니다.

관리와 복구를 분리하십시오

SSH나 RDP 응답도 전체 터널 기본 경로에 잡힐 수 있지만, 그것은 플랫폼 엔드포인트가 아니라 관리자의 관측 주소를 대상으로 합니다. 자체 요청-응답 쌍으로 진단하고, VPN 정책을 바꾸기 전에 직렬 콘솔 같은 독립 복구 채널을 확보하십시오. 배포가 VM을 재시작하고 에이전트가 비정상을 보고하면, 경로 변경이 재시작을 일으켰다고 가정하지 말고 기록된 작업과 책임 서비스를 확인하십시오.

그다음 세 흐름을 따로 검증하십시오. 실제로 원했던 프라이빗 리소스, 지원되는 에이전트와 플랫폼 통신, 그리고 관리 경로입니다. 하나를 복구한 것이 나머지 둘이 살아남았다는 증거는 아닙니다.

승인된 예외를 게스트 네트워크와 VPN 구성의 소유자 명의로 기록하고, 재연결과 재시작 시 무슨 일이 일어나는지 포함하십시오. Azure UDR은 게스트의 라우팅 테이블이 아니며, 그것을 편집해도 로컬 정책 규칙은 고쳐지지 않습니다.