Perché il punto a sito richiede un gateway Azure VPN basato su route

Un gateway basato su criteri costruisce un tunnel IPsec selezionato dai selettori di traffico e non ha alcuna interfaccia a cui consegnare le route dei client. La connessione punto a sito è una funzione di routing: il gateway possiede un pool di indirizzi client e installa route verso quei client nella rete virtuale. È questa discrepanza il motivo per cui il portale non mostra alcuna opzione per aggiungerla. Nulla sul gateway esistente può essere commutato per produrre l’interfaccia, quindi la modifica è una sostituzione e non una modifica della configurazione.

L’ordine conta più dei singoli passaggi. Se la sequenza è sbagliata, l’interruzione da sito a sito supera la finestra di manutenzione.

Cosa fa realmente un gateway basato su criteri

Un gateway basato su criteri confronta i pacchetti con i selettori di traffico configurati sulla connessione e invia le corrispondenze in un unico tunnel. Non esiste un’interfaccia di tunnel con un indirizzo, e nessuna route per client compare da nessuna parte nella rete virtuale. La tabella di routing riceve semplicemente i prefissi locali che puntano al gateway. Quel modello basta per una connessione da sito a sito tra due spazi di indirizzi fissi.

Un gateway basato su route funziona al contrario: presenta un’interfaccia di tunnel e le route decidono cosa vi entra. Il punto a sito, e qualsiasi progetto il cui insieme di peer cambia, dipendono dall’esistenza di quell’interfaccia.

Perché il pool di client ha bisogno di quell’interfaccia

Quando un portatile si connette, il gateway gli assegna un indirizzo dal pool punto a sito. La rete virtuale ha quindi bisogno di una route che dica che questo indirizzo è raggiungibile attraverso il gateway. Senza un’interfaccia di tunnel non c’è nulla a cui collegare quella route.

Il pool proviene da un intervallo che si designa, e il gateway assegna da lì. Se quell’intervallo si sovrappone alla rete locale o a una rete virtuale con peering, il conflitto compare solo dopo che un client si è connesso, che è un brutto momento per scoprirlo. Prenota il pool prima che inizi la migrazione.

Anche il tipo non è un’impostazione per connessione. Un gateway ha un solo tipo, e ogni connessione che mantiene si comporta di conseguenza, quindi un progetto misto richiede un secondo gateway e non una seconda connessione.

Il tipo è fissato alla creazione

Microsoft afferma che un gateway di rete virtuale non può essere cambiato tra basato su criteri e basato su route dopo la distribuzione. Non esiste un comando di conversione né un interruttore nel portale. Creare un secondo gateway nella stessa subnet non è nemmeno una soluzione alternativa, perché Azure consente un gateway per rete virtuale. La migrazione è quindi rimuovere, ricostruire e riconnettere.

Questo integra anche la decisione sullo SKU nella stessa costruzione. Passare a uno SKU più grande in seguito è un’altra sostituzione di gateway con un’altra interruzione.

Un gateway, una GatewaySubnet

Il gateway risiede in una subnet chiamata GatewaySubnet, e solo un gateway la occupa. Il dimensionamento di quella subnet fa parte della preparazione, perché uno SKU più grande richiede più indirizzi e una subnet non può essere ridotta in seguito. Annota le impostazioni attuali da sito a sito, la chiave condivisa, il gateway di rete locale e le route effettive prima di toccare qualcosa. Poi tratta la finestra come un’interruzione, perché il tunnel da sito a sito resta abbassato finché la nuova connessione non è configurata.

Un ordine di ricostruzione che mantiene contenuta l’interruzione: crea il gateway basato su route, ricrea la connessione da sito a sito verso lo stesso gateway di rete locale, conferma il tunnel e una richiesta da host a host, e solo allora aggiungi il punto a sito e genera un nuovo pacchetto client.

Cosa non risolve la sostituzione

Un secondo limite appartiene al peer e non ad Azure. Un dispositivo locale basato su criteri può raggiungere solo la rete virtuale a cui si connette, e non può transitare verso altre reti locali o altre reti virtuali attraverso lo stesso gateway. Sostituire il lato Azure non cambia ciò che il peer può selezionare.

Se il requisito è davvero il transito tra siti, la risposta è un dispositivo peer basato su route o una topologia in cui ogni destinazione termina separatamente. Decidilo prima di promettere una data, perché la sola sostituzione del gateway non lo fornirà.

Ordine delle operazioni e dei controlli

Verifica ogni capacità separatamente. Prima lo stato del tunnel da sito a sito e una richiesta da host a host, poi una connessione punto a sito e una risorsa privata, poi qualsiasi percorso di transito che il progetto dichiari. Uno stato verde del gateway dimostra solo che l’associazione di sicurezza è salita, e nulla di più. Mantieni i controlli in quell’ordine così che un guasto indichi la fase che lo ha introdotto.

Rigenera i pacchetti client dopo ogni modifica della topologia e tieni il pool lontano da ogni intervallo locale e con peering. I vincoli e le differenze tra SKU sono raccolti nella guida alle impostazioni di Azure VPN Gateway.