Dirigera trafik mellan två filialer genom en Azure VPN-gateway
Två Site-to-Site-anslutningar på en och samma Azure VPN-gateway kan släppa igenom filialtrafik, men bara när båda ändarna lär sig prefixet och returvägen i LAN finns.
Två filialer kan utbyta trafik genom en Azure VPN-gateway utan någon direkt tunnel mellan dem. Varje filial öppnar en Site-to-Site-anslutning till samma gateway, och gatewayen skickar vidare de inlärda prefixen mellan de två anslutningarna. Det som får detta att fungera är inte den andra tunneln utan ruttutbytet: filial A måste lära sig filial B:s prefix, och B måste lära sig A:s. Gå igenom kontrollerna nedan i ordning och stanna vid den första som misslyckas, eftersom varje senare steg beror på den.
Förutsättningar, innan du konfigurerar något
Fyra villkor avgör om den här designen kan fungera överhuvudtaget. Gatewayen måste vara routebaserad och på en SKU som stöder BGP, båda anslutningarna måste ha BGP aktiverat, filialernas adressutrymmen får inte överlappa, och ingen sida får förlita sig på NAT för att dölja sitt riktiga prefix.
Planera ASN:erna medvetet. Azures dokumenterade standardvärde är 65515, och varje filialrouter behöver sitt eget privata ASN som inte krockar med gatewayen eller den andra filialen. Att återanvända ett standardvärde utan att kontrollera en befintlig gatewaykonfiguration är hur en AS-väg senare avvisas.
Bekräfta också att du inte förväntar dig VNet-peeringbeteende. Gatewayen utbyter rutter mellan de två anslutningar du konfigurerade; den gör inte godtyckliga peerings transitiva. Om ett tredje nätverk måste nå båda filialerna behöver det sin egen anslutning eller sin egen ruttväg, inte antagandet att gatewayen sprider ut trafiken. Skriv ner den gränsen före det första ändringsfönstret, eftersom det är designbeslutet som folk återvänder till när en ny plats läggs till senare.
Konfigurera i den här ordningen
Varje steg har ett observerbart resultat, så gå inte vidare förrän det syns.
- Aktivera BGP på den virtuella nätverksgatewayen och notera dess ASN och peer-adress.
- Skapa en lokal nätverksgateway per filial med filialens riktiga adressutrymme, dess ASN och dess BGP-peer-adress.
- Skapa varje Site-to-Site-anslutning och aktivera BGP på själva anslutningen.
- Konfigurera filialroutern att peera med den gatewayadress Azure tilldelade, inte med gatewayens offentliga IKE-slutpunkt utifrån ett antagande.
Det fjärde steget är där de flesta försök fastnar. Den BGP-peer-adress Azure rapporterar är den som filialroutern måste använda som granne, och det är inte alltid den adress folk förväntar sig från tunneldiagrammet.
Annonsera själva filialprefixet, till exempel 10.10.0.0/16 från A och 10.20.0.0/16 från B. Annonsera inte en standardrutt eller ett brett aggregate för att täcka ett saknat specifikt nätverk; gapet kommer tillbaka senare som ett tyst svart hål.
Verifiera ruttutbytet i båda ändar
Anslutningsstatus är inte kontrollen. IPsec kan vara uppe på båda anslutningarna medan inget prefix korsar mellan dem. Läs gatewayens BGP-peers och dess inlärda rutter och bekräfta sedan att rutten mot den andra filialen visas som en användbar väg.
| 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 |
Ett prefix som finns i en BGP-tabell kan fortfarande förlora vidarebefordringsbeslutet till en statisk rutt eller ett mer specifikt prefix. Kontrollera den valda rutten, inte bara den mottagna.
Följ returvägen på LAN-sidan
Det här är delen som ser korrekt ut i Azure och misslyckas på plats. En värd i filial A skickar sitt paket till A:s VPN-router bara om den routern är dess standardgateway, eller om värden eller dess gateway har en rutt för B:s prefix. Samma sak måste gälla i den andra riktningen.
Om en separat kärnswitch är LAN:ets standardgateway behöver den rutten mot den andra filialen som pekar på VPN-routern. Utan den kommer begäran in och svaret lämnar via internetvägen, och användaren ser en anslutning som öppnas och sedan hänger sig.
Ta inte en nätverkssäkerhetsgrupp på gateway-subnätet för att fixa detta. Det subnätet har sina egna krav och en NSG där är inte en stödd ersättning för policy på filialsidan. Filtrering hör hemma på filialernas brandväggar och på själva arbetsbelastningarna, där reglerna kan granskas av dem som äger dem. Att flytta reglerna till en NSG på subnätet döljer dem också för teamet som ska felsöka nästa avbrott.
Tillåt åtgärden och bevisa den sedan med ett nekat test
En inlärd rutt är inte ett tillstånd. Tillåt den källa, destination och tjänst du faktiskt behöver genom filialernas brandväggar och slutpunktspolicyn, och låt resten vara nekad.
Testa från en vanlig arbetsbelastning i filial A till en verklig tjänst i filial B, bekräfta svaret och försök sedan med en åtgärd som ska förbli förbjuden. Trafik som VPN-enheten själv genererar kan använda en annan källadress och hoppa över LAN-routningssteget, så en lyckad ping från routern bevisar mindre än det verkar.
Avsluta med att skriva ner fyra fakta: de utbytta prefixen, de ASN:er som används, LAN-returvägen för varje sida och policyn som tillåter tjänsten. Om någon av dem saknas fungerar installationen fram till den första ändringen, och då kan ingen förklara varför.