Peering di Azure o VPN da VNet a VNet? Decidi prima di instradare

Azure ti offre almeno due modi per collegare due reti virtuali, e non sono impostazioni intercambiabili sullo stesso oggetto. Il peering unisce le VNet sul backbone di Microsoft senza un gateway; una VPN da VNet a VNet mette una relazione IPsec tra due gateway che distribuisci, dimensioni e monitori. La decisione si riduce a tre condizioni, e se non riesci a rispondere a tutte e tre prima di aggiungere una rotta, stai per costruire un aggiramento per un modello che non hai mai scelto.

Tre condizioni che decidono il modello

La prima è se qualcosa nel requisito ha bisogno di un confine IPsec che sia tuo e che tu possa indicare. La seconda è se gli spazi di indirizzamento sono puliti e le due VNet devono solo parlarsi. La terza è chi possiede un eventuale percorso transitivo e la fattura del gateway. Rispondi in quest'ordine, perché la prima può eliminare il peering per quanto attraente sembri la seconda.

Ciò che entrambi i modelli condividono è una regola di indirizzamento rigida: gli spazi di indirizzamento delle VNet non devono sovrapporsi. Né il peering né una VPN da VNet a VNet sono un modo supportato di rendere inequivocabili due intervalli identici, e una sovrapposizione richiede un progetto di mappatura o una riprogettazione, non un altro tipo di connessione.

Condizione 1: ti serve un confine IPsec che sia tuo?

Il peering trasporta il traffico sul backbone privato di Azure e non richiede un gateway VPN per la connessione peered stessa. È un'affermazione sul trasporto, non un'affermazione sulla cifratura che puoi consegnare a un revisore come «eseguiamo IPsec». Se il requisito nomina un tunnel configurato dal cliente, una policy IKE specifica o un confine che termina su apparecchiature che controlli, il peering non lo soddisfa, per quanto privato sia il backbone.

Una VPN da VNet a VNet fornisce quel confine: due gateway, una relazione IPsec/IKE, chiavi condivise e tutta la superficie operativa che ne deriva. Eredi lo stato del tunnel, la capacità del gateway, i limiti SKU e il monitoraggio che dimostra che il tunnel è attivo. È la risposta corretta quando il requisito riguarda proprio quel confine, descritto in panoramica del peering come un tipo di connessione distinto dal peering.

Sii altrettanto attento nella direzione opposta. «Ci serve cifratura tra le VNet» spesso è soddisfatto dal TLS del carico di lavoro stesso, e allora un gateway è un costo senza requisito dietro. Scrivi la frase che il revisore leggerà prima di scegliere il meccanismo.

Condizione 2: la topologia è diretta, o qualcosa deve transitare?

Il peering non è transitivo. Due VNet peered a un hub non sono per questo collegate tra loro, e una rotta che sembra funzionare in una direzione è di solito un peering che ha raggiunto Connected solo da un lato. Entrambi i lati devono esistere ed entrambi devono mostrare Connected, ed è la prima cosa da controllare quando il traffico sparisce in silenzio.

Se il requisito è raggiungere la rete locale attraverso un hub, il transito del gateway è un progetto separato con ruoli specifici: l'hub possiede il gateway, il peering dello spoke consente il transito del gateway e lo spoke deve consentire il traffico inoltrato. Sono proprietà del peering, non conseguenze automatiche del collegamento delle VNet:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

La tabella delle rotte effettiva è la risposta onesta a «il percorso esiste?». Mostra il tipo di salto successivo che la piattaforma userà davvero, quindi un peering che sembra configurato ma non è collegato appare come una rotta mancante o sbagliata invece che come un mistero.

Condizione 3: chi possiede il percorso transitivo e la fattura?

Ogni salto aggiuntivo ha un proprietario. Con il peering, una nuova VNet significa una nuova coppia di peering su entrambi i lati e, per il transito, un hub che continua a inoltrare traffico e una tabella delle rotte che continua a puntarvi. Con una VPN, una nuova VNet significa un altro gateway o un'altra connessione su uno esistente, con il suo tetto di capacità da sorvegliare.

Il costo segue la stessa forma ma non le stesse voci: gli addebiti del peering sono connessione e trasferimento dati, mentre una VPN aggiunge ore di gateway e i propri addebiti di trasferimento. Confronta il totale per la topologia che eseguirai davvero per un anno, incluso il secondo tunnel e il monitoraggio, non il prezzo di una connessione oggi. Includi il lavoro che nessuno fattura: qualcuno deve ruotare le chiavi, sorvegliare lo stato del tunnel e rispondere all'allarme alle tre di notte quando un gateway si riavvia. Di solito è quella voce a decidere la discussione, perché è l'unica che non compare mai in un preventivo.

Qualunque cosa scegli, prova tre flussi: quello previsto, uno negato che deve restare negato e il caso di ripristino in cui il gateway dell'hub o un peering è giù. Un modello che spiega solo il percorso felice non è stato verificato, è stato dimostrato.

Verifica la scelta contro la sua stessa affermazione

Scrivi una frase che nomini il modello, il confine e il proprietario, poi controlla che lo stato distribuito vi corrisponda. Per il peering questo significa entrambi gli stati di peering a Connected, la rotta effettiva che mostra il salto successivo di peering per il prefisso di destinazione e nessun gateway sul percorso. Per una VPN da VNet a VNet significa entrambe le connessioni a Connected, chiavi e policy corrispondenti su entrambi i gateway e una rotta il cui salto successivo è il gateway di rete virtuale.

Se i controlli contraddicono la frase, correggi prima la frase. La maggior parte della confusione in questi progetti viene da un ibrido che nessuno ha descritto: un peering per la subnet del carico di lavoro, una VPN per un servizio legacy e una tabella delle rotte che ne preferisce uno in silenzio.