Site-to-Site VPN mellom AWS og Azure: skriv returruta først
Ein tilkopla tunnel mellom to skyer bevisar ingenting før kvart arbeidslastsubnett ruter til det fjerne prefikset. Følg planen i rekkjefølgje, og test deretter tenesta.
Tunnelen kjem opp. Det gjer han som regel, fordi IKE berre krev samsvarande framlegg og ei tilgjengeleg peer-adresse. Det som sviktar etterpå, er returvegen: arbeidslasta i AWS sender pakkar inn i ein tunnel, men ingenting på Azure-sida veit korleis ein svarar på 10.10.0.0/16, eller Azure-ruta finst i ein tabell som arbeidslastsubnettet ikkje brukar. Skriv ruteplanen før du rører nokon konsoll, og tunnelen blir den minst interessante delen av arbeidet.
Trinn 1: frys adresseplanen
Arbeid med konkrete verdiar. Ei AWS-arbeidslast ligg på 10.10.1.20 inne i 10.10.0.0/16 og treng TCP 443 til ei Azure-teneste på 10.20.1.30 inne i 10.20.0.0/16. Dei to områda må ikkje overlappe, og aksepttesten er tenesteparet, ikkje tunnelen.
Skriv ned dei fire fakta før alt anna, fordi kvart seinare trinn blir kontrollert mot dei.
Trinn 2: namngje gatewayen som eig kvar ende
AWS Site-to-Site VPN kan terminere på ein virtuell privat gateway eller ein transit gateway, og dei er ulike ruteeigarar. Azure tilbyr sin administrerte VPN Gateway og, separat, VM-baserte apparat som kundane driv sjølve. Noter kva par du har, fordi neste hopp er ulikt i kvar kombinasjon.
For ein administrert gateway må du ikkje kopiere ei rute som peikar på ei gjett a privat apparatadresse. For eit apparat må du ikkje anta at ruteutbreiing i skyen konfigurerer gjesteoperativsystemet, for det gjer ho ikkje.
Å ta feil her gir ein plan som ser komplett ut og sender pakkar til ei adresse som aldri svarar.
Trinn 3: skriv ruta kvar arbeidslast faktisk brukar
Kvar grense nedanfor er eit eige oppslag, og ei rute i ein av dei er ikkje ei rute for pakken. Fyll ut tabellen med dine eigne verdiar 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 rutetabellen til arbeidslastsubnettet din å oppdatere, også etter at BGP eller ein tunnel er sunn; ruteoversynet handsamar det som ein del av sambandet. I Azure blir ein brukardefinert rutetabell knytt til eit subnett i staden for til det virtuelle nettet, så kontroller den effektive ruta på NIC-en til arbeidslasta i staden for i VNet-bladet.
Ein administrert Azure-gateway kan lære det fjerne prefikset gjennom gateway-utbreiing, og ein UDR kan overstyre den avgjerda. Legg til UDR når du har ein grunn, ikkje per refleks. Viss du legg til ein, peik han mot neste hopp som gatewayen publiserer for VPN-vegen, i staden for å finne opp ei apparatadresse. Les deretter dei effektive rutene på NIC-en på nytt, fordi det er på NIC-en avgjerda faktisk blir teken.
Trinn 4: avstem omfanget
For BGP, samanlikn kva kvar side annonserer med kva den andre sida faktisk lærte, prefiks for prefiks. For statisk ruting, samanlikn dei konfigurerte fjerne områda med arbeidslastrutene du skreiv i trinn 3.
Eit IKE-tilhøve som er samde om kryptografi er ikkje bevis for at noka side har lært 10.10.0.0/16 eller 10.20.0.0/16. To tunnelar kan vere oppe medan den eine sida annonserer eit enkelt /24 i staden for det /16 du planla. Kontroller prefikset i rutetabellen, ikkje i tunnelstatusen. Uoverensstemminga viser seg seinare som eitt subnett som verkar og eitt som aldri svarar.
Trinn 5: test tenesta frå den verkelege kjelda
Tillat den tiltenkte straumen i AWS-tryggleiksgrupper og nettverks-ACL-ar, i Azure NSG-ar og i kva apparatfilter som helst på vegen. Opne deretter éi tilkopling frå 10.10.1.20 til den godkjende tenesteadressa og -porten, og stadfest at svaret kjem tilbake til same kjelda.
Både tryggleiksgruppene i skyen og NSG-ane er stateful, så ein avvist returpakke er eit rutesymptom, ikkje ein regel du gløymde å skrive omvendt.
Ein ping frå ein kva som helst gateway avgjer ingenting. ICMP til ei gateway-adresse øver kontrollplansvegen, ikkje den videresende TCP-tenesta arbeidslasta treng.
Tilbakerulling og registreringar
Noter ruteeigarane ved sida av tunnel-ID-ane, og ta vare på rutetabellane frå før endringa. Viss endringa må ut igjen, fjern arbeidslastrutene før du riv tunnelen, slik at ingen subnett blir ståande og peike på eit neste hopp som ikkje finst lenger.
Då har ei seinare subnettflytting eller spoke-tilkopling eitt bestemt stad å oppdatere, i staden for ein fungerande tunnel som får skulda for ei rute han aldri åtte.