Site-to-Site VPN mellem AWS og Azure: skriv returruten først
En tilsluttet tunnel mellem to clouds beviser intet, før hvert arbejdslastsubnet ruter til det fjerne præfiks. Følg planen i rækkefølge, og test derefter tjenesten.
Tunnelen kommer op. Det gør den som regel, fordi IKE kun kræver matchende forslag og en tilgængelig peer-adresse. Det, der fejler bagefter, er returvejen: arbejdslasten i AWS sender pakker ind i en tunnel, men intet på Azure-siden ved, hvordan man svarer på 10.10.0.0/16, eller Azure-ruten findes i en tabel, som arbejdslastsubnettet ikke bruger. Skriv ruteplanen, før du rører ved nogen konsol, og tunnelen bliver den mindst interessante del af arbejdet.
Trin 1: frys adresseplanen
Arbejd med konkrete værdier. En AWS-arbejdslast ligger på 10.10.1.20 inde i 10.10.0.0/16 og skal bruge TCP 443 til en Azure-tjeneste på 10.20.1.30 inde i 10.20.0.0/16. De to områder må ikke overlappe, og accepttesten er tjenesteparret, ikke tunnelen.
Skriv de fire fakta ned før alt andet, fordi hvert senere trin kontrolleres imod dem.
Trin 2: navngiv den gateway, der ejer hver ende
AWS Site-to-Site VPN kan terminere på en virtuel privat gateway eller en transit gateway, og de er forskellige ruteejere. Azure tilbyder sin administrerede VPN Gateway og, separat, VM-baserede apparater, som kunderne selv driver. Noter hvilket par du har, fordi næste hop er forskelligt i hver kombination.
For en administreret gateway må du ikke kopiere en rute, der peger på en gættet privat apparatadresse. For et apparat må du ikke antage, at ruteudbredelse i skyen konfigurerer gæsteoperativsystemet, for det gør den ikke.
At tage fejl her giver en plan, der ser komplet ud og sender pakker til en adresse, der aldrig svarer.
Trin 3: skriv den rute, hver arbejdslast faktisk bruger
Hver grænse nedenfor er et separat opslag, og en rute i en af dem er ikke en rute for pakken. Udfyld tabellen med dine egne værdier, før tunnelen 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 er arbejdslastsubnettets rutetabel din at opdatere, også efter at BGP eller en tunnel er sund; ruteoversigten betragter det som en del af forbindelsen. I Azure knyttes en brugerspecificeret rutetabel til et subnet snarere end til det virtuelle netværk, så kontroller den effektive rute på arbejdslastens NIC i stedet for i VNet-bladet.
En administreret Azure-gateway kan lære det fjerne præfiks gennem gateway-udbredelse, og en UDR kan tilsidesætte den beslutning. Tilføj UDR, når du har en grund, ikke pr. refleks. Hvis du tilføjer en, skal du pege den på det næste hop, som gatewayen offentliggør for VPN-vejen, i stedet for at opfinde en apparatadresse. Læs derefter de effektive ruter på NIC igen, fordi det er på NIC, beslutningen faktisk tages.
Trin 4: afstem omfanget
For BGP skal du sammenligne, hvad hver side annoncerer, med hvad den anden side faktisk har lært, præfiks for præfiks. For statisk routing skal du sammenligne de konfigurerede fjerne områder med de arbejdslastruter, du skrev i trin 3.
Et IKE-forhold, der er enige om kryptografi, er ikke bevis for, at nogen side har lært 10.10.0.0/16 eller 10.20.0.0/16. To tunneler kan være oppe, mens den ene side annoncerer et enkelt /24 i stedet for det /16, du planlagde. Kontroller præfikset i rutetabellen, ikke i tunnelstatus. Uoverensstemmelsen viser sig senere som et subnet, der virker, og et, der aldrig svarer.
Trin 5: test tjenesten fra den rigtige kilde
Tillad den tilsigtede strøm i AWS-sikkerhedsgrupper og netværks-ACL’er, i Azure NSG’er og i ethvert apparatfilter på vejen. Åbn derefter én forbindelse fra 10.10.1.20 til den godkendte tjenesteadresse og -port, og bekræft, at svaret kommer tilbage til samme kilde.
Både skyens sikkerhedsgrupper og NSG’er er stateful, så en afvist returpakke er et routing-symptom, ikke en regel, du glemte at skrive omvendt.
En ping fra en gateway afgør intet. ICMP til en gateway-adresse øver kontrolplansvejen, ikke den videresendte TCP-tjeneste, som arbejdslasten har brug for.
Tilbagerulning og registreringer
Noter ruteejerne ved siden af tunnel-id’erne, og gem rutetabellerne fra før ændringen. Hvis ændringen skal ud igen, skal du fjerne arbejdslastruterne, før du river tunnelen ned, så intet subnet bliver pegende på et næste hop, der ikke længere findes.
Så har en senere subnetflytning eller spoke-tilslutning ét bestemt sted at opdatere, i stedet for en fungerende tunnel, der får skylden for en rute, den aldrig ejede.