Perché aggiungere un prefisso Azure VPN interrompe la connessione

Un prefisso aggiunto all’oggetto Azure sbagliato produce una connessione che segnala Connected e non inoltra nulla, ed è il tipo di errore più costoso in questa pila. Sono coinvolte tre risorse e solo una di esse possiede lo spazio degli indirizzi remoto: il gateway di rete virtuale, il gateway di rete locale che descrive il lato remoto e la connessione che li unisce. Il prefisso appartiene al gateway di rete locale, la connessione deve essere ricostruita perché la modifica abbia effetto, e il gateway stesso di solito viene lasciato intatto. L’ordine non è negoziabile, e il portale ne mostra solo una parte.

Tre oggetti, uno dei quali contiene il prefisso

Lo spazio degli indirizzi della rete virtuale risponde a un’altra domanda: cosa vive dentro Azure. Aggiungere lì un prefisso remoto non instrada il traffico verso di esso, allarga solo lo spazio che la piattaforma ritiene di possedere, il che può entrare in collisione con l’intervallo remoto reale. Il gateway di rete locale è l’oggetto che contiene i prefissi remoti, e la connessione fa riferimento a entrambi i gateway più una chiave condivisa in anticipo.

C’è una terza prenotazione da tenere a mente. GatewaySubnet ospita le istanze gestite del gateway, deve portare esattamente quel nome, e per gli SKU non Basic ci si aspetta che sia almeno /27.

Nient’altro appartiene a quella subnet, e una modifica del prefisso non ha motivo di toccarla. Un prefisso assente dal gateway di rete locale è irraggiungibile qualunque cosa dica lo stato della connessione, perché il gateway offre solo i prefissi di cui è stato informato quando negozia il tunnel. Per questo il sintomo è asimmetrico: il tunnel è attivo, l’associazione di sicurezza è a posto, e una subnet non compare mai nei selettori di traffico. Se manca un solo intervallo remoto mentre i vicini funzionano, smettete di guardare il tunnel e leggete il gateway di rete locale.

Perché viene rimossa la connessione

L’oggetto connessione fissa la configurazione negoziata per tutta la sua vita. Per questo la procedura documentata rimuove prima la connessione, aggiorna il gateway di rete locale e poi ricrea la connessione con la stessa chiave condivisa. Le istanze del gateway non vengono ricostruite per una modifica che riguarda solo il prefisso, il che limita l’interruzione allo smontaggio della connessione invece di una ridistribuzione del gateway.

Quella cancellazione è l’interruzione, quindi trattatela come una modifica pianificata con un inizio e una fine attesi invece che come una modifica rapida. In PowerShell la sequenza è breve: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, poi Set-AzLocalNetworkGateway con il nuovo -AddressPrefix array, poi New-AzVirtualNetworkGatewayConnection con la stessa -SharedKey e gli stessi gateway. Riusare la chiave conta, perché il lato remoto non viene riconfigurato e una nuova chiave significa coordinarsi con chi possiede il dispositivo remoto. Se quel dispositivo è gestito da un altro team, concordate la finestra con loro prima di rimuovere qualsiasi cosa.

Quando il gateway stesso deve essere ricostruito

Una seconda risposta che circola su questo problema dice che il gateway deve essere ricreato e la chiave scambiata di nuovo. È corretto per un altro insieme di operazioni: cambiare il tipo di gateway o lo SKU, passare tra punto a sito e sito a sito, o riparare un gateway la cui configurazione è errata. Tali modifiche alterano davvero la risorsa gateway, quindi la ricostruzione è davvero necessaria.

Un gateway creato per punto a sito non può semplicemente ricevere una connessione sito a sito. La configurazione punto a sito deve essere rimossa e il gateway ricreato, il che produce anche una nuova chiave condivisa e un nuovo pacchetto client.

Il pacchetto punto a sito merita una nota propria perché scade. Il portale genera un file di breve durata, quindi l’approccio pratico è scaricarlo una volta e distribuirlo insieme al certificato client invece di inviare agli utenti un link del portale che sarà morto quando faranno clic. Per la questione del prefisso, nulla di questo si applica. Tenere le due procedure separate è tutta la disciplina: i prefissi sono una modifica a livello di connessione, e le proprietà del gateway sono una modifica a livello di gateway.

Leggete lo stato, non il badge del portale

Leggete lo stato dalla risorsa invece che dal badge nel portale. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 restituisce ConnectionStatus insieme ai contatori di byte in ingresso e in uscita, e sono i contatori a separare un tunnel connesso che non trasporta nulla da uno che non si è mai stabilito.

I contatori che smettono di crescere a metà di un trasferimento puntano al percorso e non all’autenticazione. I contatori che non si muovono affatto puntano all’insieme dei prefissi o alla chiave condivisa.

I timer spiegano una classe di disconnessioni attribuite erroneamente alla VPN. Il bilanciatore di carico di Azure chiude i flussi inattivi dopo il timeout configurato, quattro minuti per impostazione predefinita quando sono state scritte queste note e configurabile verso l’alto, quindi un server OpenVPN su una VM senza keepalive può cadere ogni pochi minuti mentre tutto il resto sembra sano. Un gateway che la piattaforma riavvia ciclicamente può anche interrompere una connessione VNet verso una Web App, e quel guasto sta sul lato della piattaforma e non in una configurazione client. L’indizio è se la disconnessione segue un intervallo fisso o una modifica che avete fatto.

Tenete i tre oggetti e i loro valori in un unico record: lo spazio degli indirizzi della rete virtuale, l’elenco dei prefissi del gateway di rete locale e il riferimento alla chiave condivisa della connessione. articolo PowerShell da sito a sito documenta i comandi del gateway di rete locale e l’ordine a cui appartengono. Confrontare una modifica del prefisso con la memoria è il modo in cui un tunnel funzionante viene ricostruito due volte.

Poi verificate nell’ordine in cui avete modificato: il gateway di rete locale mostra il nuovo elenco di prefissi, la connessione è di nuovo Connected, e i contatori si muovono quando inviate traffico a un host nel nuovo intervallo. Se il terzo passo fallisce mentre i primi due passano, il lato remoto non ha accettato il nuovo selettore di traffico e il dispositivo remoto ha bisogno della voce di fase 2 corrispondente. È una conversazione con l’altro estremo del tunnel, non un’altra modifica in Azure.