La VM Azure non raggiunge IMDS né WireServer dopo l'avvio della VPN

La VM è attiva, il client VPN dice di essere connesso e pochi minuti dopo l'agente Azure inizia a segnalare uno stato non sano. A volte SSH sopravvive e Run Command dal portale no, il che porta le persone a guardare l'agente invece della tabella di routing. Le decisioni di inoltro del guest sono cambiate quando è salito il tunnel, e due indirizzi di piattaforma sono di solito le prime vittime. Lo tratto come sintomo di routing prima che come guasto dell'agente.

Il sintomo sembra un agente rotto

Entrambi gli indirizzi qui sotto vengono proposti come correzione, e non sono lo stesso servizio. Copiare una /32 per uno perché ha funzionato per l'altro è esattamente come un workaround temporaneo diventa una configurazione permanente che nessuno osa rimuovere.

L'ordine che funziona è confermare quale indirizzo la chiamata che fallisce colpisce davvero, poi leggere come il guest lo risolve. Tutto il resto è indovinare con passaggi extra e una finestra di modifica più lunga.

168.63.129.16 non è una destinazione pubblica

168.63.129.16 è l'indirizzo virtuale speciale della piattaforma Azure, e uno dei suoi ruoli è WireServer, che l'agente della VM usa per parlare con la fabric. Microsoft documenta che il traffico dell'agente verso le porte TCP 80 e 32526 deve restare disponibile. Non è un normale host internet, e non è qualcosa che una VPN a tunnel completo dovrebbe portare verso un'uscita remota. Per questo un tunnel che sembra sano può comunque affamare l'agente.

La documentazione dell'indirizzo di piattaforma dice anche che questo indirizzo non è soggetto alle rotte definite dall'utente, il che è una proprietà della fabric Azure e non una promessa sul tuo guest. Una regola locale del firewall o la politica di routing del client VPN stesso possono ancora rompere il percorso, e nessuna delle due vive nella tabella di routing del VNet.

Se è l'agente a segnalare il problema, controlla lo stato del servizio e il percorso verso quell'indirizzo prima di reinstallare qualsiasi cosa.

169.254.169.254 ha le sue regole

169.254.169.254 è l'indirizzo link-local del servizio Azure Instance Metadata Service. Le richieste verso di esso hanno requisiti propri: la NIC e l'IP primari, una configurazione DHCP che supporti l'indirizzo e il bypass di qualsiasi proxy HTTP. Inviarle attraverso un'uscita VPN remota o un gateway internet arbitrario non è il modello di accesso che Microsoft descrive.

Quella clausola sul proxy intercetta chi ha corretto la rotta e vede ancora errori. Un proxy HTTP nel guest può rompere IMDS mentre ip route get restituisce esattamente l'interfaccia che ti aspetti, quindi controlla le esclusioni del proxy oltre alle rotte.

Non incollare risposte di metadati in un ticket di supporto mentre esegui il debug. Possono contenere credenziali e dettagli dell'istanza che sopravvivono all'incidente.

Leggi il routing policy del guest, non solo la tabella principale

Su un guest Linux, tre comandi in sola lettura separano i livelli: ip -4 rule show per le regole di policy, poi ip -4 route get 168.63.129.16 e ip -4 route get 169.254.169.254 per le decisioni che il kernel prende davvero. Eseguili prima e dopo la connessione della VPN. La differenza tra questi due output è il tuo insieme di modifiche, ed è più utile di qualsiasi ipotesi su cosa abbia fatto il client.

Un client VPN che installa regole di policy può lasciare la tabella principale intatta e comunque reindirizzare quelle ricerche. Per questo una correzione solo sulla tabella principale sembra funzionare su un host e non fa nulla sul successivo. I guest con più NIC aggiungono lo stesso problema dall'altro lato, perché la risposta dipende da quale NIC e quale indirizzo sorgente la regola seleziona.

Resisti alla ricetta che aggiunge entrambe le rotte /32 attraverso il vecchio gateway. Un percorso di piattaforma link-local e un prossimo hop WAN generico sono oggetti diversi, e un'eccezione generale nasconde il vero conflitto di policy.

Tieni separati amministrazione e ripristino

Anche la tua risposta SSH o RDP può essere catturata da un default a tunnel completo, ma punta all'indirizzo osservato dell'amministratore e non a un endpoint della piattaforma. Diagnosticarla dalla sua coppia richiesta-risposta, e tieni un canale di ripristino indipendente come la console seriale prima di cambiare la policy VPN. Se un deployment riavvia la VM e l'agente segnala uno stato non sano, ispeziona l'azione registrata e il servizio responsabile invece di presumere che il cambio di rotta abbia causato il riavvio.

Poi verifica i tre flussi separatamente: la risorsa privata che volevi davvero, la comunicazione supportata tra agente e piattaforma, e il percorso amministrativo. Ripristinarne uno non è prova che gli altri due siano sopravvissuti.

Scrivi l'eccezione approvata sotto il proprietario della rete guest e della configurazione VPN, incluso cosa succede alla riconnessione e al riavvio. Gli UDR di Azure non sono la tabella di routing del guest, e modificarli non correggerà una regola di policy locale.