VM-ul Azure nu ajunge la IMDS sau WireServer după ce pornește VPN-ul

VM-ul rulează, clientul VPN spune că este conectat, iar câteva minute mai târziu agentul Azure începe să raporteze o stare nesănătoasă. Uneori SSH supraviețuiește, iar Run Command din portal nu, ceea ce îi trimite pe oameni la agent în loc de tabela de rutare. Deciziile de forwardare ale guestului s-au schimbat când a urcat tunelul, iar două adrese de platformă sunt de obicei primele victime. Tratez asta ca simptom de rutare înainte de a o trata ca defect al agentului.

Simptomul arată ca un agent stricat

Ambele adrese de mai jos sunt propuse ca remediu, iar ele nu sunt același serviciu. Copierea unui /32 pentru una pentru că a funcționat pentru cealaltă este exact modul în care o soluție temporară devine o configurație permanentă pe care nimeni nu îndrăznește să o elimine.

Ordinea care funcționează este să confirmi mai întâi ce adresă vizează de fapt apelul eșuat, apoi să citești cum o rezolvă guestul. Orice altceva este ghicit cu pași în plus și o fereastră de schimbare mai lungă.

168.63.129.16 nu este o destinație publică

168.63.129.16 este adresa virtuală specială a platformei Azure, iar unul dintre rolurile ei este WireServer, pe care agentul VM îl folosește pentru a vorbi cu fabric. Microsoft documentează că traficul agentului către porturile TCP 80 și 32526 trebuie să rămână disponibil. Nu este un host de internet obișnuit și nu este ceva ce un VPN cu tunel complet ar trebui să ducă la o ieșire îndepărtată. De aceea un tunel care pare sănătos poate înfometa în continuare agentul.

Documentația adresei de platformă spune de asemenea că această adresă nu este supusă rutelor definite de utilizator, ceea ce este o proprietate a fabricului Azure, nu o promisiune despre guestul tău. O regulă locală de firewall sau politica de rutare a clientului VPN pot rupe în continuare calea, și niciuna nu trăiește în tabela de rutare a VNet-ului.

Dacă agentul este cel care raportează problema, verifică starea serviciului și calea către acea adresă înainte de a reinstala ceva.

169.254.169.254 are propriile reguli

169.254.169.254 este adresa link-local pentru Azure Instance Metadata Service. Cererile către ea au cerințe proprii: NIC-ul și IP-ul primare, o configurație DHCP care suportă adresa și ocolirea oricărui proxy HTTP. Trimiterea lor prin ieșirea unui VPN îndepărtat sau printr-un gateway de internet arbitrar nu este modelul de acces pe care îl descrie Microsoft.

Clauza aceea despre proxy îi prinde pe cei care au reparat ruta și încă văd eșecuri. Un proxy HTTP în guest poate rupe IMDS în timp ce ip route get returnează exact interfața așteptată, așa că verifică excluderile de proxy alături de rute.

Nu lipi răspunsuri de metadate într-un tichet de suport în timp ce depanezi asta. Pot purta acreditări și detalii de instanță care supraviețuiesc incidentului.

Citește rutarea pe politică a guestului, nu doar tabela principală

Pe un guest Linux, trei comenzi doar-citire separă straturile: ip -4 rule show pentru regulile de politică, apoi ip -4 route get 168.63.129.16 și ip -4 route get 169.254.169.254 pentru deciziile pe care kernelul le ia efectiv. Rulează-le înainte și după ce VPN-ul se conectează. Diferența dintre cele două ieșiri este setul tău de modificări și este mai utilă decât orice presupunere despre ce a făcut clientul.

Un client VPN care instalează reguli de politică poate lăsa tabela principală neatinsă și totuși redirecționa acele căutări. De aceea o remediere doar în tabela principală pare să funcționeze pe un host și nu face nimic pe următorul. Guesturile cu mai multe NIC adaugă aceeași problemă din cealaltă parte, pentru că răspunsul depinde de ce NIC și ce adresă sursă alege regula.

Rezistă rețetei care adaugă ambele rute /32 prin gateway-ul vechi. O cale de platformă link-local și un următor hop WAN general sunt obiecte diferite, iar o excepție generală ascunde conflictul real de politică.

Ține administrarea și recuperarea separate

Răspunsul tău SSH sau RDP poate fi capturat și de un default de tunel complet, dar vizează adresa observată a administratorului, nu un endpoint al platformei. Diagnostichează-l din propria pereche cerere-răspuns și păstrează un canal de recuperare independent, cum ar fi consola serială, înainte de a schimba politica VPN. Dacă o implementare repornește VM-ul și agentul raportează o stare nesănătoasă, inspectează acțiunea înregistrată și serviciul responsabil în loc să presupui că schimbarea rutei a cauzat repornirea.

Apoi verifică cele trei fluxuri separat: resursa privată pe care o doreai cu adevărat, comunicarea acceptată dintre agent și platformă și calea administrativă. Restaurarea uneia nu este dovada că celelalte două au supraviețuit.

Scrie excepția aprobată la proprietarul rețelei guestului și al configurației VPN, inclusiv ce se întâmplă la reconectare și repornire. UDR-urile Azure nu sunt tabela de rutare a guestului, iar editarea lor nu va repara o regulă locală de politică.