Il traffico di ritorno di Azure P2S VPN funziona solo in un verso

L’icona del tunnel è verde, l’NSG sembra permissivo, le route effettive sembrano corrette, eppure la VM non riesce ad aprire una connessione verso il client connesso. L’ipotesi abituale è che un tunnel point-to-site funzionante sia simmetrico: se il client raggiunge la VM, la VM raggiunge il client. Quell’ipotesi è l’errore di ragionamento, non di configurazione. Un tunnel può trasportare una direzione di un flusso non richiesto e scartare l’altra, e la correzione dipende da quale livello la scarta.

Mito: un tunnel connesso è un tunnel bidirezionale

Un tunnel VPN è un percorso di criterio, non un cavo. Ogni direzione viene confrontata con selettori, route e filtri, e ciascuno di essi può consentire una direzione bloccando l’altra.

In pratica l’asimmetria è abbastanza comune che la direzione va inserita nella prima prova, non nell’ultima. Il client avvia, il gateway segue il flusso e la risposta segue lo stato che è stato creato. Una VM che avvia un nuovo flusso non ha quello stato, quindi dipende dal fatto che il percorso di ritorno sia esplicitamente instradabile e consentito. Quando quel percorso manca, il tentativo di connessione muore prima che un’applicazione lo veda.

Verificate la direzione prima di verificare la raggiungibilità

Scegliete un indirizzo client, un indirizzo VM e un protocollo. Connettetevi dal client e annotate il risultato; poi avviate la stessa prova dalla VM e annotate anche quello. Se la prima riesce e la seconda fallisce, il pool dei client, l’associazione del gateway e il percorso dal client alla VNet funzionano tutti.

Il passo successivo sono le prove, non altre regole. Controllate l’NSG sulla sottorete della VM in entrambe le direzioni, leggete le route effettive sulla NIC della VM e catturate i pacchetti sulla VM mentre il client invia traffico. Una richiesta che arriva senza risposta è un problema di filtro o di route di ritorno; una richiesta che non arriva mai è un problema di percorso. Non considerate un ping fallito come prova che la VM sia irraggiungibile, perché un criterio ICMP può scartare la risposta mentre TCP funziona.

Il percorso di ritorno IKEv2 point-to-site è il sospetto abituale

Nel report Azure alla base di questo articolo, un client raggiungeva le VM tramite IKEv2, ma l’ICMP in ingresso dalla VM al client falliva finché il tipo di tunnel del gateway non è stato commutato a OpenVPN. L’autore del report afferma che Microsoft ha confermato una limitazione nel percorso IKEv2 point-to-site, dove il traffico di ritorno da una VM al client non viene instradato in modo simmetrico a meno che il client abbia avviato la sessione. IKEv2 si basa sui selettori di traffico e il gateway non ha rispettato la direzione di ritorno in quel caso.

Ciò non rende OpenVPN il tipo di tunnel migliore in generale. Rende il tipo di tunnel una variabile nella matrice di test per questo carico di lavoro.

Cambiare tipo di tunnel è un cambio di servizio, non un interruttore. Ogni client ha bisogno di un profilo compatibile e il gateway potrebbe richiedere un certificato o una configurazione di autenticazione diversi. Riproducete il comportamento unidirezionale con un client di test e una VM di test, cambiate il tipo secondo un calendario approvato e ripetete poi le stesse prove direzionali. Se il comportamento sopravvive al cambio, il tipo di tunnel non era la causa e avete circoscritto il problema senza toccare la produzione.

Mito: la scoperta broadcast attraversa il confine della VNet

Una seconda ipotesi fallisce per un motivo non correlato. Una rete virtuale Azure non trasporta traffico broadcast, quindi una VM non può ricevere frame broadcast da una rete locale tramite una connessione site-to-site o point-to-site. Le applicazioni che trovano i peer tramite broadcast, come la vecchia esplorazione file o alcuni protocolli di scoperta dei dispositivi, non vedranno mai il lato remoto, per quanto bene siano scritte le route.

Sostituite la scoperta broadcast con nomi DNS, un servizio directory o un elenco esplicito di peer. Se l’applicazione non ha un’alternativa unicast, la progettazione ha bisogno di un altro meccanismo di scoperta, non di un tunnel più ampio.

Cosa cambiare e come dimostrarlo

Se la prova direzionale fallisce solo su IKEv2, annotate il tipo di tunnel del gateway, il pool di indirizzi client e la prova ICMP o TCP esatta, poi valutate un profilo OpenVPN approvato per i client interessati. Se fallisce su ogni tipo di tunnel, lavorate sul percorso di ritorno: l’indirizzo del client deve essere instradabile dalla sottorete della VM, qualsiasi route definita dall’utente deve puntare a un hop successivo valido e il firewall del client deve accettare il flusso in ingresso. Allegare le prove NSG e delle route al ticket.

Verificate con l’applicazione, non con ping. Uno scambio ICMP riuscito dopo una modifica non dice nulla sulla porta del servizio, sulla sua autenticazione o sulla risoluzione dei nomi. Ripetete la prova dopo una riconnessione, perché un client che riceve un indirizzo diverso dal pool può cambiare il risultato. Poi ripetetela ancora una volta dopo che il client si è addormentato e risvegliato, perché è in una sessione ripresa che il comportamento unidirezionale spesso riappare.