Due indirizzi VPN locali: due peer Azure, non uno

Il diagramma ha due collegamenti internet presso la filiale e un gateway VPN Azure, quindi il gateway di rete locale riceve entrambi gli indirizzi pubblici. Sembra ordinato e non funziona come il diagramma lascia intendere. Ogni dispositivo VPN locale è una relazione peer separata, e la progettazione multi-dispositivo di Microsoft dà a ciascuno la propria risorsa di gateway di rete locale e la propria connessione. Aggiungere un secondo indirizzo a una singola risorsa non crea un secondo peer. Crea una risorsa che non descrive correttamente nessuno dei due dispositivi.

Il mito: un gateway, due indirizzi

Un gateway di rete locale è la descrizione di un peer remoto: un endpoint pubblico e i prefissi privati dietro di esso. Non esiste un modo supportato per far significare a quella risorsa «uno qualsiasi di questi due apparati».

La stessa confusione va nella direzione opposta, dove due IP pubblici Azure vengono letti come prova che esistono due gateway Azure.

Contate gli oggetti, poi i tunnel

Prendete due dispositivi locali gestiti in modo indipendente, ciascuno con il proprio indirizzo pubblico e accesso alle stesse reti private, più un gateway Azure basato su routing in modalità attivo-attivo. Il gateway Azure ha due istanze attive con IP pubblici separati. Ogni dispositivo locale si connette a entrambe le istanze. È la mesh completa, e il conteggio degli oggetti ne deriva, non dal diagramma.

L’aritmetica è abbastanza breve da incollarla nel documento di progettazione:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

Una risorsa di connessione può trasportare più di un tunnel sottostante, quindi quattro tunnel non implicano quattro gateway di rete virtuale. Due IP pubblici Azure non sono nemmeno gli stessi oggetti dei due gateway di rete locale che descrivono il sito remoto.

Cosa aggiunge l’attivo-attivo sul lato Azure

L’attivo-attivo trasforma il gateway Azure da un’istanza attiva a due, ciascuna con il proprio IP pubblico, ed è ciò che rende possibile una mesh completa. Non raddoppia il throughput di un singolo flusso. Non elimina nemmeno la necessità che il lato locale supporti il multipath a costo uguale se entrambi i dispositivi inoltrano contemporaneamente. Confermate la modalità del gateway, lo SKU e le capacità del dispositivo remoto prima di effettuare il provisioning di qualsiasi cosa.

Un gateway in standby passivo è una progettazione del tutto valida; produce semplicemente un conteggio dei tunnel diverso.

BGP rende utilizzabili entrambi i percorsi

Per la progettazione multi-dispositivo, entrambi i dispositivi locali eseguono BGP. Date a ciascuno un indirizzo peer BGP univoco e annunciate gli stessi prefissi privati previsti sui percorsi pertinenti. I prefissi privati identificano le reti protette, mentre gli indirizzi pubblici identificano dove terminano le connessioni di trasporto cifrate. Confondere i due produce una progettazione in cui ogni tunnel è attivo e le route sono sbagliate.

Pianificate il routing di ritorno e qualsiasi ispezione con stato che debba tollerare l’uno o l’altro percorso. Una sessione IKE sana su ogni endpoint non dimostra che un carico di lavoro possa usare ogni route annunciata.

La selezione per flusso non è aggregazione di larghezza di banda

Azure seleziona un percorso per flusso usando un hash sull’indirizzamento e sulle porte del flusso. In condizioni stazionarie, i pacchetti di un dato flusso TCP o UDP prendono normalmente lo stesso tunnel, e il lato locale può scegliere un tunnel diverso per la direzione di ritorno. Due dispositivi e quattro tunnel migliorano quindi la disponibilità, non la velocità di un trasferimento. Quando una slide del fornitore promette aggregazione, sta descrivendo un’altra funzionalità o un fraintendimento.

Provate con flussi paralleli se volete vedere i percorsi distribuirsi, e con un solo flusso se volete vedere il limite.

Quale ridondanza avete effettivamente rimosso

Due indirizzi WAN su un solo dispositivo migliorano le opzioni del collegamento di accesso ma condividono alimentazione, software e stato di guasto di quel dispositivo. Non sono la stessa cosa di due dispositivi, e nessuna configurazione lato Azure lo cambia. Seguite la progettazione dual-WAN o in cluster supportata dal fornitore invece di dedurre la ridondanza dal numero di indirizzi. Poi provatela: rimuovete un percorso alla volta e confermate le route rimanenti più uno scambio applicativo reale in entrambe le direzioni.

Aspettatevi ritardi di rilevamento e convergenza, e aspettatevi che alcune sessioni esistenti terminino.