Site-to-Site VPN mellan AWS och Azure: skriv returvägen först
En ansluten tunnel mellan två moln bevisar ingenting förrän varje arbetslastsubnät dirigerar till det avlägsna prefixet. Gå igenom planen i ordning och testa sedan tjänsten.
Tunneln kommer upp. Det gör den oftast, eftersom IKE bara kräver matchande förslag och en nåbar peer-adress. Det som misslyckas efteråt är returvägen: arbetslasten i AWS skickar paket in i en tunnel, men ingenting på Azure-sidan vet hur man svarar på 10.10.0.0/16, eller Azure-rutten finns i en tabell som arbetslastsubnätet inte använder. Skriv ruttplanen innan du rör någon konsol, och tunneln blir den minst intressanta delen av arbetet.
Steg 1: frys adressplanen
Arbeta med konkreta värden. En AWS-arbetslast ligger på 10.10.1.20 inom 10.10.0.0/16 och behöver TCP 443 till en Azure-tjänst på 10.20.1.30 inom 10.20.0.0/16. De två intervallen får inte överlappa, och acceptanstestet är tjänsteparet, inte tunneln.
Skriv ner de fyra fakta före allt annat, eftersom varje senare steg kontrolleras mot dem.
Steg 2: namnge den gateway som äger varje ände
AWS Site-to-Site VPN kan avslutas på en virtuell privat gateway eller en transit gateway, och de är olika ruttägare. Azure erbjuder sin hanterade VPN Gateway och, separat, VM-baserade enheter som kunderna driver själva. Notera vilket par du har, eftersom nästa hopp skiljer sig i varje kombination.
För en hanterad gateway ska du inte kopiera en rutt som pekar på en gissad privat enhetsadress. För en enhet ska du inte anta att ruttutbredning i molnet konfigurerar gästoperativsystemet, för det gör den inte.
Att göra fel här ger en plan som ser komplett ut och skickar paket till en adress som aldrig svarar.
Steg 3: skriv rutten som varje arbetslast faktiskt använder
Varje gräns nedan är en egen uppslagning, och en rutt i en av dem är inte en rutt för paketet. Fyll i tabellen med dina egna värden innan tunneln går live.
| 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 |
I AWS är arbetslastsubnätets rutttabell din att uppdatera även efter att BGP eller en tunnel är frisk; ruttöversikten behandlar det som en del av anslutningen. I Azure kopplas en användardefinierad rutttabell till ett subnät i stället för till det virtuella nätverket, så kontrollera den effektiva rutten på arbetslastens NIC och inte i VNet-bladet.
En hanterad Azure-gateway kan lära sig det avlägsna prefixet via gateway-utbredning, och en UDR kan åsidosätta det beslutet. Lägg till UDR när du har en anledning, inte per reflex. Om du lägger till en, peka den mot nästa hopp som gatewayen publicerar för VPN-vägen i stället för att hitta på en enhetsadress. Läs sedan om de effektiva rutterna på NIC, eftersom beslutet faktiskt fattas där.
Steg 4: stäm av omfattningen
För BGP, jämför vad varje sida annonserar med vad den andra sidan faktiskt lärde sig, prefix för prefix. För statisk routing, jämför de konfigurerade avlägsna intervallen med arbetslastrutterna du skrev i steg 3.
En IKE-relation som är överens om kryptografi är inte bevis för att någon sida har lärt sig 10.10.0.0/16 eller 10.20.0.0/16. Två tunnlar kan vara uppe medan en sida annonserar ett enda /24 i stället för det /16 du planerade. Kontrollera prefixet i rutttabellen, inte i tunnelstatusen. Avvikelsen visar sig senare som ett subnät som fungerar och ett som aldrig svarar.
Steg 5: testa tjänsten från den verkliga källan
Tillåt det avsedda flödet i AWS-säkerhetsgrupper och nätverks-ACL:er, i Azure NSG:er och i alla enhetsfilter på vägen. Öppna sedan en anslutning från 10.10.1.20 till den godkända tjänstadressen och porten och bekräfta att svaret kommer tillbaka till samma källa.
Både molnets säkerhetsgrupper och NSG:erna är stateful, så ett avvisat returpaket är ett ruttsymtom, inte en regel du glömde skriva omvänt.
En ping från vilken gateway som helst avgör ingenting. ICMP till en gatewayadress övar kontrollplansvägen, inte den vidarebefordrade TCP-tjänst som arbetslasten behöver.
Återställning och register
Notera ruttägarna bredvid tunnel-ID:na och spara rutttabellerna från före ändringen. Om ändringen måste ut igen, ta bort arbetslastrutterna innan du river tunneln, så att inget subnät blir stående och peka på ett nästa hopp som inte längre finns.
Då har en senare subnätflytt eller spoke-anslutning en bestämd plats att uppdatera, i stället för en fungerande tunnel som får skulden för en rutt den aldrig ägde.