Verkeer tussen twee vestigingen routeren via een Azure VPN-gateway
Twee Site-to-Site-verbindingen op één Azure VPN-gateway kunnen vestigingsverkeer doorlaten, maar alleen wanneer beide uiteinden het prefix leren en het LAN-terugpad bestaat.
Twee vestigingen kunnen verkeer uitwisselen via een Azure VPN-gateway zonder een directe tunnel tussen hen. Elke vestiging opent een Site-to-Site-verbinding naar dezelfde gateway, en de gateway geeft de geleerde prefixen door tussen de twee verbindingen. Wat dit laat werken is niet de tweede tunnel, maar de route-uitwisseling: vestiging A moet het prefix van vestiging B leren, en B dat van A. Werk de onderstaande controles op volgorde af en stop bij de eerste die faalt, want elke latere stap hangt daarvan af.
Vereisten, voordat u iets configureert
Vier voorwaarden bepalen of dit ontwerp überhaupt kan werken. De gateway moet route-based zijn en op een SKU die BGP ondersteunt, beide verbindingen moeten BGP hebben ingeschakeld, de adresruimten van de vestigingen mogen niet overlappen, en geen enkele kant mag op NAT vertrouwen om het echte prefix te verbergen.
Plan de ASN's bewust. De gedocumenteerde standaardwaarde van Azure is 65515, en elke vestigingsrouter heeft zijn eigen privé-ASN nodig dat niet botst met de gateway of met de andere vestiging. Een standaard hergebruiken zonder een bestaande gatewayconfiguratie te controleren is hoe een AS-pad later wordt geweigerd.
Bevestig ook dat u geen VNet-peeringgedrag verwacht. De gateway wisselt routes uit tussen de twee verbindingen die u hebt geconfigureerd; hij maakt willekeurige peerings niet transitief. Als een derde netwerk beide vestigingen moet bereiken, heeft het zijn eigen verbinding of eigen routepad nodig, niet de aanname dat de gateway het verkeer uitspreidt. Schrijf die grens op vóór het eerste wijzigingsvenster, want dat is de ontwerpbeslissing waar mensen op terugkomen wanneer later een locatie wordt toegevoegd.
Configureer in deze volgorde
Elke stap heeft een waarneembaar resultaat, dus ga niet verder voordat het verschijnt.
- Schakel BGP in op de gateway van het virtuele netwerk en noteer het ASN en het peeradres.
- Maak per vestiging een lokale netwerkgateway met de werkelijke adresruimte van die vestiging, het ASN en het BGP-peeradres.
- Maak elke Site-to-Site-verbinding en schakel BGP in op de verbinding zelf.
- Configureer de vestigingsrouter om te peeren met het gatewayadres dat Azure heeft toegewezen, niet met het openbare IKE-eindpunt van de gateway op basis van een aanname.
De vierde stap is waar de meeste pogingen vastlopen. Het BGP-peeradres dat Azure rapporteert is het adres dat de vestigingsrouter als buur moet gebruiken, en het is niet altijd het adres dat mensen uit het tunneldiagram verwachten.
Adverteer het prefix van de vestiging zelf, bijvoorbeeld 10.10.0.0/16 uit A en 10.20.0.0/16 uit B. Adverteer geen standaardroute of breed aggregate om een ontbrekend specifiek netwerk af te dekken; het gat komt later terug als een stil zwart gat.
Verifieer de route-uitwisseling aan beide uiteinden
Verbindingsstatus is niet de controle. IPsec kan op beide verbindingen actief zijn terwijl er geen prefix tussen hen overgaat. Lees de BGP-peers van de gateway en de geleerde routes, en bevestig dan dat de route naar de andere vestiging als bruikbaar pad verschijnt.
| 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 |
Een prefix in een BGP-tabel kan de doorstuur beslissing alsnog verliezen aan een statische route of een specifieker prefix. Controleer de geselecteerde route, niet alleen de ontvangen route.
Volg het terugpad aan de LAN-kant
Dit is het deel dat er in Azure correct uitziet en op locatie faalt. Een host in vestiging A stuurt zijn pakket naar de VPN-router van A alleen als die router de standaardgateway is, of als de host of zijn gateway een route voor het prefix van B heeft. Hetzelfde moet in de andere richting gelden.
Als een aparte coreswitch de standaardgateway van het LAN is, heeft die de route naar de andere vestiging nodig die naar de VPN-router wijst. Zonder die route komt het verzoek aan en verlaat het antwoord via het internetpad, en de gebruiker ziet een verbinding die opent en daarna blijft hangen.
Grijp niet naar een netwerkbeveiligingsgroep op het gatewaysubnet om dit op te lossen. Dat subnet heeft eigen vereisten en een NSG daar is geen ondersteunde vervanging voor beleid aan de vestigingskant. Filteren hoort op de firewalls van de vestigingen en op de workloads zelf, waar de regels kunnen worden herzien door de mensen die ze bezitten. Die regels naar een subnet-NSG verplaatsen verbergt ze ook voor het team dat de volgende storing zal debuggen.
Sta de handeling toe en bewijs die daarna met een geweigerde test
Een geleerde route is geen toestemming. Sta de bron, bestemming en dienst die u echt nodig hebt toe via de firewalls van de vestigingen en het endpointbeleid, en laat de rest geweigerd.
Test vanaf een gewone workload in vestiging A naar een echte dienst in vestiging B, bevestig het antwoord en probeer daarna een handeling die verboden moet blijven. Verkeer dat het VPN-apparaat zelf genereert kan een ander bronadres gebruiken en de LAN-routeringsfase overslaan, dus een geslaagde ping vanaf de router bewijst minder dan het lijkt.
Sluit af met vier feiten: de uitgewisselde prefixen, de gebruikte ASN's, het LAN-terugpad per kant en het beleid dat de dienst toestaat. Als een daarvan ontbreekt, werkt de opzet tot de eerste wijziging, en daarna kan niemand uitleggen waarom.