VPN da sito a sito Azure con un peer dietro NAT: lista di controllo

Eseguite questi controlli in ordine e fermatevi al primo che fallisce. La maggior parte delle segnalazioni secondo cui Azure non supporta un dispositivo dietro NAT si rivela essere un indirizzo del peer che Azure non riesce a raggiungere, o un tunnel che non si avvia mai dal lato corretto. Il trasporto esterno e l’instradamento interno sono due problemi diversi, e mescolarli fa perdere un pomeriggio. Ogni passaggio qui sotto produce un’osservazione che potete consegnare a qualcun altro.

Passaggio 1: confermate che il peer sia davvero dietro NAT

Confrontate l’indirizzo sull’interfaccia WAN del dispositivo con l’indirizzo che Azure vede per esso. Se differiscono, qualcosa sta traducendo, e quel traduttore ora fa parte del vostro progetto VPN. Chiedete al provider se la mappatura è statica o condivisa, perché una mappatura condivisa cambia ciò su cui potete contare. Un dispositivo con indirizzo WAN privato e senza inoltro è un caso diverso da uno dietro un NAT di livello operatore con una mappatura pubblica stabile.

Se i due indirizzi coincidono, fermatevi qui: NAT non è il vostro problema e il resto di questa lista non aiuterà.

Annotate entrambi gli indirizzi e il modello del traduttore nel ticket. Quella sola riga evita il giro successivo di domande sul perché il peer configurato non risponde.

Passaggio 2: concordate chi inizia

Le domande frequenti su Azure VPN Gateway indicano il supporto di NAT-T e aggiungono che il dispositivo locale dovrebbe iniziare il tunnel IPsec quando si trova dietro NAT. Questo corrisponde a come funziona la traduzione con stato, dato che il traduttore mantiene una mappatura perché il dispositivo interno ha inviato il primo pacchetto. Se ci si aspetta che Azure inizi e non arriva nulla a creare quella mappatura, il tunnel non parte mai.

Configurate il peer in modo che un errore di solo risponditore sia evidente, e verificate se il dispositivo riprova da solo o necessita di un trigger. Alcuni dispositivi alzano un tunnel solo quando compare traffico interessante, il che va bene finché il traffico interessante non è una sonda di salute che non arriva mai.

Osservate lo scambio IKE sul dispositivo durante un avvio manuale; il silenzio lì è una risposta di instradamento o del firewall, non una risposta di Azure.

Passaggio 3: impostate correttamente l’indirizzo del peer

Azure ha bisogno di un indirizzo pubblico raggiungibile per il peer nel suo oggetto gateway di rete locale, di solito l’indirizzo pubblico del traduttore anziché l’indirizzo interno del dispositivo. L’identità con cui il dispositivo si autentica è un campo separato e può legittimamente differire dall’indirizzo che Azure chiama. Tenete i due separati, perché scambiarli produce un errore di autenticazione che sembra esattamente un problema di NAT.

Se l’indirizzo pubblico cambia, quell’oggetto deve cambiare con esso. Un nome che risolve su un indirizzo obsoleto è peggio di un indirizzo statico da aggiornare a mano.

Annotate tutti e tre i valori: indirizzo locale del dispositivo, indirizzo pubblico tradotto, identità del peer configurata.

Passaggio 4: aprite solo le porte che NAT-T richiede

NAT-T trasporta ESP dentro UDP, e l’RFC 3948 descrive quell’incapsulamento con la porta 4500 usata dopo la negoziazione iniziale sulla porta 500. Il vostro firewall e il traduttore devono entrambi consentire lo scambio e il suo traffico di ritorno. Consentire una porta TCP non correlata non dimostra nulla su questo percorso, e una regola che consente l’uscita ma non la risposta fallirà comunque.

Un inoltro di porta in ingresso statico non è automaticamente necessario quando il peer inizia e il traduttore mantiene lo stato. Diventa necessario quando la mappatura è instabile o quando qualcosa sul percorso fa scadere lo stato in modo aggressivo.

Catturate una volta su entrambi i lati del traduttore; la differenza di incapsulamento è subito visibile.

Passaggio 5: separate il trasporto esterno dall’instradamento interno

Un tunnel che si stabilisce e non trasporta nulla è un problema di instradamento, non un problema NAT-T. I siti hanno ancora bisogno di selettori di traffico compatibili, spazi di indirizzi corrispondenti, regole di accesso e un percorso di ritorno per le reti delle applicazioni. Nulla di questo è fornito da uno scambio IKE riuscito.

Se i due siti usano intervalli privati sovrapposti, la traduzione all’interno del tunnel è un progetto separato con le proprie regole. Non rinumerate una sottorete solo perché il gateway esterno si trova dietro un router domestico.

Classificate il guasto per fase prima di cambiare qualsiasi cosa, e mantenete quella classificazione nel ticket così la persona successiva parte da dove vi siete fermati.