Trafic tëschent zwou Filialen duerch en Azure VPN-Gateway leeden
Zwou Site-to-Site-Verbindungen op engem eenzegen Azure VPN-Gateway kënnen de Filialstrafic duerchloossen, awer nëmmen wann béid Enner de Präfix léieren an de LAN-Réckwee existéiert.
Zwou Filialen kënnen Trafic duerch en Azure VPN-Gateway austauschen, ouni datt en direkten Tunnel tëschent hinnen existéiert. All Filial mécht eng Site-to-Site-Verbindung zum selwechte Gateway op, an de Gateway gëtt déi geléiert Präfixen tëschent den zwou Verbindungen weider. Wat dat schaffe mécht, ass net den zweeten Tunnel, mä den Austausch vu Routen: d'Filial A muss de Präfix vun der Filial B léieren, an d'B dee vun der A. Gitt déi folgend Kontrollen der Rei no duerch a stoppt bei der éischter, déi feelt, well all weidere Schrëtt dovun ofhänkt.
Viraussetzungen, ier Dir eppes konfiguréiert
Véier Bedingungen entscheeden, ob dësen Design iwwerhaapt ka funktionéieren. De Gateway muss routebaséiert sinn an op enger SKU lafen, déi BGP ënnerstëtzt, béid Verbindungen mussen BGP aktivéiert hunn, d'Adressraim vun de Filialen däerfen sech net iwwerschneiden, an keng Säit däerf sech op NAT verloossen, fir hire richtegen Präfix ze verstoppen.
Plangt d'ASN bewosst. Den dokumentéierte Standard vun Azure ass 65515, an all Filialsrouter brauch seng eegen privat ASN, déi net mam Gateway oder mat der anerer Filial kollidéiert. En Standard erëm ze benotzen, ouni eng existéierend Gateway-Konfiguratioun ze kontrolléieren, ass de Wee, wéi en AS-Pad spéider verworf gëtt.
Bestätegt och, datt Dir kee VNet-Peering-Verhalen erwaart. De Gateway tauscht Routen tëschent den zwou Verbindungen aus, déi Dir konfiguréiert hutt; hien mécht willkürlech Peeringe net transitiv. Wann en drëtt Netzwierk béid Filialen erreeche muss, brauch et seng eegen Verbindung oder säi eegene Routenpad, net d'Unahme, datt de Gateway den Trafic verdeelt. Schreift déi Grenz virum éischte Ännerungsfenster op, well dat ass d'Designentscheedung, op déi d'Leit zréckkommen, wann spéider engem Site bäikënnt.
Konfiguréiert an dëser Rei
All Schrëtt huet en observéierbare Resultat, also gitt net virun, bis en erschéngt.
- Aktivéiert BGP um virtuelle Netzwierk-Gateway a notéiert seng ASN a seng Peer-Adress.
- Erstellt ee lokale Netzwierk-Gateway pro Filial mam richtegen Adressraum vun där Filial, hirer ASN an hirer BGP-Peer-Adress.
- Erstellt all Site-to-Site-Verbindung an aktivéiert BGP op der Verbindung selwer.
- Konfiguréiert de Filialsrouter, fir mat der Gateway-Adress ze peeren, déi Azure zougewisen huet, an net mat dem ëffentlechen IKE-Endpunkt vum Gateway op Grond vun enger Unnahme.
De véierte Schrëtt ass dee Punkt, wou déi meescht Versich hänke bleiwen. D'BGP-Peer-Adress, déi Azure mëttelt, ass déi, déi de Filialsrouter als Noper muss benotzen, an et ass net ëmmer d'Adress, déi d'Leit aus dem Tunneldiagramm erwaarden.
Annoncéiert de Präfix vun der Filial selwer, zum Beispill 10.10.0.0/16 vun A an 10.20.0.0/16 vun B. Annoncéiert keng Standardroute an och keen breeden Aggregat, fir ee fehlend spezifescht Netzwierk ofzedecken; d'Lück kënnt spéider als stille schwaarze Lach zréck.
Verifizéiert den Austausch vu Routen op béiden Enner
De Verbindungsstatus ass net d'Kontroll. IPsec ka op béide Verbindungen uewe sinn, während keen Präfix tëschent hinne passéiert. Liest d'BGP-Peeren vum Gateway an seng geléiert Routen, a bestätegt dann, datt d'Route Richtung aner Filial als benotzbare Pad erschéngt.
| 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 |
E Präfix, deen an enger BGP-Tabell steet, ka nach ëmmer d'Weiderleitungsentscheedung un eng statesch Route oder u ee méi spezifesche Präfix verléieren. Kontrolléiert déi ausgewielte Route, net nëmmen déi empfaangen.
Verfollegt de Réckwee op der LAN-Säit
Dëst ass deen Deel, deen an Azure richteg ausgesäit an um Site feelt. En Host an der Filial A schéckt säi Paket nëmmen dann un den VPN-Router vun A, wann dee Router säin Standardgateway ass, oder wann den Host oder säi Gateway eng Route fir de Präfix vun B huet. Datselwecht muss och an der anerer Richtung richteg sinn.
Wann een separate Core-Switch den Standardgateway vum LAN ass, brauch hien d'Route Richtung aner Filial, déi op den VPN-Router weist. Ouni si kënnt d'Ufro un an d'Äntwert verléisst de Site iwwer den Internetpad, an de Benotzer gesäit eng Verbindung, déi sech opmécht an dann hänke bleift.
Gräift net op eng Netzwierksécherheetsgrupp um Gateway-Subnetz zeréck, fir dat ze behiewen. Dee Subnetz huet seng eege Fuerderungen, an eng NSG do ass kee ënnerstëtzten Ersatz fir d'Politik op der Filialssäit. Filtering gehéiert op d'Filialsfirewalls an op d'Workloaden selwer, wou d'Regelen vun de Leit, déi se besëtzen, iwwerpréift kënne ginn. Dës Regelen an eng Subnetz-NSG ze verréckelen, verstoppt se och virum Team, dat den nächsten Ausfall wäert debuggen.
Loosst d'Operatioun zou a bewäist se dann mat engem verweigerte Test
Eng geléiert Route ass keng Erlaabnes. Loosst d'Quell, den Zil an de Service, déi Dir wierklech braucht, duerch d'Filialsfirewalls an d'Endpoint-Politik zou, a loosst de Rescht verweigert.
Test vun enger gewéinlecher Workload an der Filial A bis zu engem richtege Service an der Filial B, bestätegt d'Äntwert, a versicht dann eng Operatioun, déi verbuede musse bleiwen. Den Trafic, deen de VPN-Apparat selwer generéiert, ka mat enger anerer Quelladress schaffen an d'LAN-Routingstuf iwwersprangen, also bewäist e erfollegräiche Ping vum Router manner, wéi et ausgesäit.
Schléisst of, andeems Dir véier Fakten opschreift: déi ausgetauscht Präfixen, déi benotzt ASN, de LAN-Réckwee pro Säit an d'Politik, déi de Service erlaabt. Wann ee vun hinnen feelt, schafft de Setup bis zur éischter Ännerung, an duerno kann keen erklären, firwat.