Instradare il traffico tra due sedi tramite un gateway VPN di Azure
Due connessioni site-to-site su un unico gateway VPN di Azure possono far passare il traffico delle sedi, ma solo quando entrambe le estremità apprendono il prefisso e il percorso di ritorno LAN esiste.
Due sedi possono scambiarsi traffico attraverso un gateway VPN di Azure senza alcun tunnel diretto tra loro. Ogni sede apre una connessione site-to-site verso lo stesso gateway, e il gateway trasmette i prefissi appresi tra le due connessioni. Ciò che lo fa funzionare non è il secondo tunnel ma lo scambio di route: la sede A deve apprendere il prefisso della sede B, e B quello della A. Percorrete i controlli seguenti in ordine e fermatevi al primo che fallisce, perché ogni passo successivo dipende da quello.
Prerequisiti, prima di configurare qualsiasi cosa
Quattro condizioni decidono se questo progetto può funzionare. Il gateway deve essere basato su route e su uno SKU che supporti BGP, entrambe le connessioni devono avere BGP abilitato, gli spazi degli indirizzi delle sedi non devono sovrapporsi, e nessun lato può affidarsi a NAT per nascondere il proprio prefisso reale.
Pianificate gli ASN con attenzione. Il valore predefinito documentato di Azure è 65515, e ogni router di sede necessita del proprio ASN privato che non entri in collisione con il gateway o con l'altra sede. Riusare un valore predefinito senza verificare una configurazione di gateway esistente è il modo in cui un percorso AS viene rifiutato più tardi.
Confermate anche di non aspettarvi il comportamento del peering VNet. Il gateway scambia route tra le due connessioni configurate; non rende transitivi i peering arbitrari. Se una terza rete deve raggiungere entrambe le sedi, necessita della propria connessione o del proprio percorso, non del presupposto che il gateway distribuirà il traffico. Annotate questo confine prima della prima finestra di modifica, perché è la decisione progettuale a cui le persone tornano quando più avanti viene aggiunta una sede.
Configurate in questo ordine
Ogni passo ha un risultato osservabile, quindi non proseguite finché non compare.
- Abilitate BGP sul gateway di rete virtuale e annotate il suo ASN e il suo indirizzo peer.
- Create un gateway di rete locale per ogni sede con lo spazio degli indirizzi reale di quella sede, il suo ASN e il suo indirizzo peer BGP.
- Create ogni connessione site-to-site e abilitate BGP sulla connessione stessa.
- Configurate il router della sede per il peering con l'indirizzo del gateway assegnato da Azure, non con l'endpoint IKE pubblico del gateway per presupposto.
Il quarto passo è dove si bloccano la maggior parte dei tentativi. L'indirizzo peer BGP riportato da Azure è quello che il router della sede deve usare come vicino, e non è sempre l'indirizzo che le persone si aspettano dallo schema del tunnel.
Annunciate il prefisso della sede stesso, per esempio 10.10.0.0/16 da A e 10.20.0.0/16 da B. Non annunciate una route predefinita o un aggregato ampio per coprire una rete specifica mancante; il vuoto torna più tardi come buco nero silenzioso.
Verificate lo scambio di route a entrambe le estremità
Lo stato della connessione non è il controllo. IPsec può essere attivo su entrambe le connessioni mentre nessun prefisso attraversa tra loro. Leggete i peer BGP del gateway e le sue route apprese, poi confermate che la route verso l'altra sede appare come un percorso utilizzabile.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Un prefisso presente in una tabella BGP può comunque perdere la decisione di inoltro a favore di una route statica o di un prefisso più specifico. Controllate la route selezionata, non solo quella ricevuta.
Seguite il percorso di ritorno sul lato LAN
Questa è la parte che sembra corretta in Azure e fallisce sul posto. Un host nella sede A invia il suo pacchetto al router VPN di A solo se quel router è il suo gateway predefinito, o se l'host o il suo gateway detiene una route per il prefisso di B. Lo stesso deve valere nella direzione opposta.
Se uno switch core separato è il gateway predefinito della LAN, ha bisogno della route verso l'altra sede che punta al router VPN. Senza di essa la richiesta arriva e la risposta esce dal percorso Internet, e l'utente vede una connessione che si apre e poi si blocca.
Non ricorrete a un gruppo di sicurezza di rete sulla sottorete del gateway per correggere questo. Quella sottorete ha i propri requisiti e un NSG lì non è un sostituto supportato della policy lato sede. Il filtraggio appartiene ai firewall delle sedi e ai carichi di lavoro stessi, dove le regole possono essere riviste dalle persone che le possiedono. Spostare quelle regole in un NSG di sottorete le nasconde anche al team che eseguirà il debug del prossimo guasto.
Consentite l'operazione, poi dimostratela con un test negato
Una route appresa non è un'autorizzazione. Consentite l'origine, la destinazione e il servizio che vi servono davvero attraverso i firewall delle sedi e la policy dell'endpoint, e lasciate il resto negato.
Provate da un carico di lavoro ordinario nella sede A verso un servizio reale nella sede B, confermate la risposta, poi tentate un'operazione che deve restare vietata. Il traffico generato dall'appliance VPN stessa può usare un altro indirizzo di origine e saltare la fase di routing LAN, quindi un ping riuscito dal router dimostra meno di quanto sembri.
Concludete annotando quattro fatti: i prefissi scambiati, gli ASN in uso, il percorso di ritorno LAN per ciascun lato e la policy che consente il servizio. Se ne manca uno, la configurazione funziona fino al primo cambiamento, e poi nessuno sa spiegare perché.