Un VNet Azure con peering necessita di una propria gateway VPN?

Compare una nuova VNet spoke, l’hub ha già un gateway site-to-site funzionante, e la domanda ovvia è se si debba pagare un secondo gateway. Di solito no: il transito del gateway consente allo spoke di usare il gateway dell’hub attraverso il peering. Tre condizioni decidono se funzionerà, e nessuna è visibile dal badge di stato del peering. La connettività del peering e l’autorizzazione a usare il gateway altrui sono impostazioni separate, quindi due VM che già si fanno ping non dimostrano nulla sul percorso VPN.

Prima condizione: il gateway e l’assenza di un gateway nello spoke

Azure supporta il transito del gateway per SKU di VPN Gateway diversi da Basic, e sia il peering regionale sia quello globale possono trasportarlo. Lo spoke consuma un gateway che non possiede, quindi non può averne uno proprio: se nello spoke esiste già un gateway, o è già selezionata un’opzione di gateway remoto, l’impostazione di transito desiderata sarà non disponibile o inefficace. Verificalo prima di eseguire qualsiasi debug, perché la casella disattivata è il sintomo, non il guasto. Leggi prima lo SKU e il gateway esistente, poi guarda le impostazioni del peering.

Non eliminare un gateway spoke esistente per far comparire l’opzione finché non sai da cosa dipende. L’ordine di migrazione conta più della casella di controllo.

Seconda condizione: un’impostazione in ogni direzione del peering

Un peering è due oggetti, uno su ciascuna VNet, e le impostazioni di transito vivono su lati diversi di quella coppia. Il peering dell’hub verso lo spoke deve consentire al gateway dell’hub di servire lo spoke; il peering dello spoke verso l’hub deve accettare il gateway dell’hub. la guida al transito del gateway di Microsoft li nomina per direzione, ed è l’unico modo per tenerli corretti:

Un controllo etichettato remote cambia significato a seconda del peering di quale VNet stai modificando, quindi leggi la direzione, non la parola. Imposta entrambi i lati, salva e conferma che il peering risulti connesso in entrambi i punti.

Terza condizione: spazio degli indirizzi e limiti delle autorizzazioni

Il transito non può far sì che lo stesso prefisso di destinazione significhi due reti, quindi gli intervalli dell’hub, dello spoke e della rete locale devono essere disgiunti prima che qualcosa di questo funzioni. Le VNet possono anche trovarsi in sottoscrizioni o tenant diversi; non è un divieto, ma l’identità che crea o aggiorna ogni peering necessita delle autorizzazioni richieste su quella rete. Le modifiche tra sottoscrizioni spesso falliscono per i permessi, e l’errore è facile da interpretare male come problema di topologia.

Annota gli intervalli e i proprietari prima della modifica. Indovinare l’uno o l’altro produce un peering che si connette e non instrada nulla.

Verifica con le route effettive, non con lo stato del peering

Guarda le route effettive sull’interfaccia di rete di un carico di lavoro dello spoke e trova il prefisso locale reale. Controlla la tabella delle route della subnet e se la propagazione delle route del gateway è disabilitata, perché una route definita dall’utente o un appliance di ispezione possono sovrascrivere il percorso suggerito dai flag del peering. Poi conferma l’altra direzione: la rete locale deve sapere come raggiungere il prefisso dello spoke attraverso la connessione site-to-site, tramite annunci appresi o tramite una route esplicita e una voce di rete protetta corrispondente sul dispositivo del cliente. Se il prefisso manca su uno dei due lati, i flag del peering non sono ciò che va cambiato.

Prova un servizio da un carico di lavoro dello spoke e segui la risposta. Un test dal gateway VPN o da una VM dell’hub esercita un prefisso di origine e un percorso diversi.

Se la topologia serve anche client point-to-site, convalida separatamente le loro route installate. I pacchetti client di Windows possono richiedere una rigenerazione dopo un cambio di topologia, e questo è un compito di routing lato client, non la prova che la condivisione del gateway sia fallita.

Cosa non concede la condivisione di un gateway

Il transito del gateway è una comodità di routing, non un’autorizzazione. I gruppi di sicurezza di rete, i filtri locali e le regole a livello di servizio decidono ancora a cosa può arrivare un carico di lavoro dello spoke, quindi abilita il servizio specifico da origine a destinazione invece di presumere che il tunnel condiviso permetta tutto ciò che sta dietro.

Anche il peering non è transitivo come le persone sperano. Aggiungere un altro spoke, o un endpoint privato, introduce i propri requisiti di routing e accesso che l’impostazione di transito esistente non copre.