Site-to-Site VPN tëschent AWS an Azure: schreift fir d’éischt d’Zréckroute
E verbonnenen Tunnel tëschent zwou Cloudë beweist näischt, bis all Workload-Subnetz op de wäite Präfix routet. Schafft de Plang an der Rei duerch an testt duerno de Service.
Den Tunnel kënnt erop. Dat geschitt normalerweis, well IKE just passend Proposen an eng erreechbar Peer-Adress brauch. Wat duerno feelt, ass den Zréckwee: d’AWS-Workload schéckt Paketen an en Tunnel, awer op der Azure-Säit weess näischt, wéi een 10.10.0.0/16 äntwert, oder d’Azure-Route steet an enger Tabell, déi de Workload-Subnetz net benotzt. Schreift de Routenplang, ier Dir eng Konsol beréiert, an den Tunnel gëtt den onintressantsten Deel vun der Aarbecht.
Schrëtt 1: fréiert den Adressplang an
Schafft mat konkrete Wäerter. Eng AWS-Workload läit op 10.10.1.20 bannent 10.10.0.0/16 an brauch TCP 443 op en Azure-Service op 10.20.1.30 bannent 10.20.0.0/16. Déi zwou Beräicher däerfen sech net iwwerschneiden, an den Accepttest ass d’Servicepuer, net den Tunnel.
Schreift déi véier Fakten op, ier Dir eppes anescht maacht, well all weidere Schrëtt dogéint gepréift gëtt.
Schrëtt 2: nennt de Gateway, deen all Enn besëtzt
AWS Site-to-Site VPN kann op engem virtuelle private Gateway oder engem Transit-Gateway ophalen, an dat sinn ënnerschiddlech Routing-Besëtzer. Azure bitt säi verwaltete VPN Gateway an, getrennt, VM-baséiert Apparater, déi d’Clienten selwer bedreiwen. Hält fest, wéi eng Koppel Dir hutt, well den nächsten Hopp an all Kombinatioun anescht ass.
Fir e verwaltete Gateway kopéiert keng Route, déi op eng geroden privat Apparatadress weist. Fir en Apparat, hält net ugeholl, datt d’Routenverdeelung am Cloud de Gaaschtbetribssystem konfiguréiert, well dat mécht se net.
E Feeler hei gëtt e Plang, deen komplett ausgesäit a Paketen op eng Adress schéckt, déi ni äntwert.
Schrëtt 3: schreift d’Route, déi all Workload wierklech benotzt
All Grenz hei drënner ass eng eege Sich, an eng Route an enger vun hinnen ass keng Route fir de Paket. Fëllt d’Tabell mat Ären eegene Wäerter, ier den Tunnel live geet.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
Op AWS ass d’Routentabell vum Workload-Subnetz Är ze aktualiséieren, och nodeem BGP oder en Tunnel gesond ass; d’Iwwerbléck iwwer Routing betruecht dat als Deel vun der Verbindung. Op Azure gëtt eng benotzerdefinéiert Routentabell mat engem Subnetz associéiert an net mat dem virtuelle Netzwierk, dofir préift d’effektiv Route op der NIC vun der Workload an net am VNet-Blade.
E verwalteten Azure-Gateway ka de wäite Präfix duerch Gateway-Verdeelung léieren, an eng UDR kann déi Decisioun iwwerstëmmen. Füügt d’UDR dobäi, wann Dir e Grond hutt, net aus Reflex. Wann Dir eng dobäifüügt, richt se op den nächsten Hopp, deen de Gateway fir de VPN-Wee publizéiert, amplaz eng Apparatadress ze erfaën. Liest duerno déi effektiv Routen op der NIC nach eng Kéier, well do gëtt d’Decisioun tatsächlech getraff.
Schrëtt 4: gläicht d’Ausmooss of
Fir BGP vergläicht, wat all Säit annoncéiert, mat deem, wat déi aner Säit tatsächlech geléiert huet, Präfix fir Präfix. Fir statescht Routing vergläicht Dir déi konfiguréiert wäit Beräicher mat de Workload-Routen aus Schrëtt 3.
Eng IKE-Bezéiung, déi sech iwwer Kryptografie eens ass, ass kee Beweis, datt eng Säit 10.10.0.0/16 oder 10.20.0.0/16 geléiert huet. Zwee Tunnen kënnen erop sinn, während eng Säit een eenzegen /24 annoncéiert amplaz vum /16, deen Dir geplangt hutt. Préift de Präfix an der Routentabell, net am Tunnelstatus. D’Diskrepanz daucht méi spéit op als ee Subnetz, dat funktionéiert, an een, dat ni äntwert.
Schrëtt 5: testt de Service vun der richtege Quell
Erlaabt de gewollte Floss an den AWS-Sécherheetsgruppen an den Netzwierk-ACLen, an den Azure-NSGen an an all Apparatfilter um Wee. Öffnet duerno eng Verbindung vun 10.10.1.20 op déi ugehollen Serviceadress a Port a bestätegt, datt d’Äntwert op déiselwecht Quell zréckkënnt.
Souwuel d’Cloud-Sécherheetsgruppen wéi d’NSGen sinn zoustänneg, dofir ass en ofgeleenten Zréckpaket e Routing-Symptom an net eng Regel, déi Dir vergiess hutt ëmgedréint ze schreiwen.
E Ping vun engem Gateway entscheet näischt. ICMP op eng Gatewayadress üübt de Kontrollplang-Wee, net de weidergeleet TCP-Service, deen d’Workload brauch.
Zréckrollen an Opzeechnungen
Hält d’Rout-Besëtzer nieft den Tunnel-Identifikatoren fest a bewaart d’Routentabellen aus der Zäit virun der Ännerung. Wann d’Ännerung eraus muss, entfernt d’Workload-Routen, ier Dir den Tunnel ofbaut, sou datt kee Subnetz op en nächsten Hopp weist, deen et net méi gëtt.
Dann huet eng spéider Subnetzverleeung oder eng Spoke-Verbindung eng definéiert Plaz fir z’aktualiséieren, amplaz vun engem funktionéierende Tunnel, deen d’Schold fir eng Route dréit, déi en ni besass huet.