La VM d'Azure no pot arribar a IMDS ni a WireServer després d'iniciar la VPN

La VM està engegada, el client VPN diu que està connectat, i al cap de pocs minuts l'agent d'Azure comença a informar que no està sa. De vegades l'SSH sobreviu i el Run Command del portal no, cosa que fa que la gent miri l'agent en lloc de la taula de rutes. Les decisions de reenviament del convidat van canviar quan va pujar el túnel, i dues adreces de plataforma solen ser les primeres víctimes. Ho tracto com un símptoma d'encaminament abans que com una fallada de l'agent.

El símptoma sembla un agent espatllat

Totes dues adreces següents es proposen com a solució, i no són el mateix servei. Copiar una /32 per a una perquè va funcionar per a l'altra és exactament com una solució temporal es converteix en una configuració permanent que ningú no gosa treure.

L'ordre que funciona és confirmar quina adreça apunta realment la crida que falla, i després llegir com la resol el convidat. Qualsevol altra cosa és endevinar amb passos extra i una finestra de canvi més llarga.

168.63.129.16 no és una destinació pública

168.63.129.16 és l'adreça virtual especial de la plataforma Azure, i un dels seus papers és WireServer, que l'agent de la VM fa servir per parlar amb el teixit. Microsoft documenta que el trànsit de l'agent cap als ports TCP 80 i 32526 ha de romandre disponible. No és un amfitrió d'internet ordinari, i no és una cosa que una VPN de túnel complet hagi de portar cap a una sortida remota. Per això un túnel que sembla sa encara pot deixar l'agent sense menjar.

La documentació de l'adreça de plataforma també diu que aquesta adreça no està subjecta a rutes definides per l'usuari, cosa que és una propietat del teixit d'Azure i no una promesa sobre el teu convidat. Una regla de tallafocs local o la política d'encaminament del propi client VPN encara poden trencar el camí, i cap de les dues viu a la taula de rutes de la VNet.

Si és l'agent qui informa del problema, comprova l'estat del servei i el camí cap a aquesta adreça abans de reinstal·lar res.

169.254.169.254 té les seves pròpies regles

169.254.169.254 és l'adreça link-local del servei Azure Instance Metadata Service. Les peticions cap a ella tenen requisits propis: la NIC i la IP primàries, una configuració DHCP que admeti l'adreça i l'omissió de qualsevol proxy HTTP. Enviar-les per una sortida VPN remota o una passarel·la d'internet arbitrària no és el model d'accés que descriu Microsoft.

Aquesta clàusula de proxy atrapa qui ha arreglat la ruta i encara veu fallades. Un proxy HTTP al convidat pot trencar IMDS mentre ip route get retorna exactament la interfície que esperes, així que revisa les exclusions de proxy a més de les rutes.

No enganxis respostes de metadades en un tiquet de suport mentre ho depures. Poden portar credencials i detalls de la instància que sobreviuen a l'incident.

Llegeix l'encaminament per política del convidat, no només la taula principal

En un convidat Linux, tres ordres de només lectura separen les capes: ip -4 rule show per a les regles de política, després ip -4 route get 168.63.129.16 i ip -4 route get 169.254.169.254 per a les decisions que el nucli pren realment. Executa-les abans i després que la VPN es connecti. La diferència entre aquestes dues sortides és el teu conjunt de canvis, i és més útil que qualsevol conjectura sobre què va fer el client.

Un client VPN que instal·la regles de política pot deixar la taula principal intacta i encara redirigir aquestes consultes. Per això una solució que només toca la taula principal sembla funcionar en un amfitrió i no fa res al següent. Els convidats amb diverses NIC hi afegeixen el mateix problema des de l'altra banda, perquè la resposta depèn de quina NIC i quina adreça d'origen tria la regla.

Resisteix la recepta que afegeix les dues rutes /32 per la passarel·la antiga. Un camí de plataforma link-local i un salt següent WAN general són objectes diferents, i una excepció global amaga el conflicte de política real.

Mantén l'administració i la recuperació separades

La teva resposta SSH o RDP també pot ser capturada per un default de túnel complet, però apunta a l'adreça observada de l'administrador i no a cap extrem de plataforma. Diagnostica-la a partir del seu propi parell de petició i resposta, i mantén un canal de recuperació independent com la consola sèrie abans de canviar la política de VPN. Si un desplegament reinicia la VM i l'agent informa que no està sa, inspecciona l'acció registrada i el servei responsable en lloc d'assumir que el canvi de ruta va causar el reinici.

Després verifica els tres fluxos per separat: el recurs privat que realment volies, la comunicació admesa de l'agent i la plataforma, i el camí d'administració. Restaurar-ne un no és prova que els altres dos hagin sobreviscut.

Escriu l'excepció aprovada sota qui posseeix la xarxa del convidat i la configuració de la VPN, incloent què passa en reconnectar i reiniciar. Els UDR d'Azure no són la taula de rutes del convidat, i editar-los no arreglarà una regla de política local.