Site-to-Site VPN mellom AWS og Azure: skriv returvegen først
Ein tilkopla tunnel mellom to skyer beviser ingenting før kvart arbeidslastsubnett ruter til det fjerne prefikset. Følg planen steg for steg, og test tenesta etterpå.
Tunnelen kommer opp. Det gjør den som regel, fordi IKE bare krever samsvarende forslag og en tilgjengelig peer-adresse. Det som svikter etterpå, er returveien: arbeidslasta i AWS sender pakker inn i en tunnel, men ingenting på Azure-siden vet hvordan man svarer på 10.10.0.0/16, eller Azure-ruten finnes i en tabell som arbeidslastsubnettet ikke bruker. Skriv ruteplanen før du rører noen konsoll, og tunnelen blir den minst interessante delen av arbeidet.
Trinn 1: frys adresseplanen
Arbeid med konkrete verdier. En AWS-arbeidslast ligger på 10.10.1.20 inne i 10.10.0.0/16 og trenger TCP 443 til en Azure-tjeneste på 10.20.1.30 inne i 10.20.0.0/16. De to områdene må ikke overlappe, og aksepttesten er tjenesteparet, ikke tunnelen.
Skriv ned de fire fakta før alt annet, fordi hvert senere trinn kontrolleres mot dem.
Trinn 2: navngi gatewayen som eier hver ende
AWS Site-to-Site VPN kan terminere på en virtuell privat gateway eller en transit gateway, og de er forskjellige ruteeiere. Azure tilbyr sin administrerte VPN Gateway og, separat, VM-baserte apparater som kundene driver selv. Noter hvilket par du har, fordi neste hopp er forskjellig i hver kombinasjon.
For en administrert gateway må du ikke kopiere en rute som peker på en gjettet privat apparatadresse. For et apparat må du ikke anta at ruteutbredelse i skyen konfigurerer gjesteoperativsystemet, for det gjør den ikke.
Å ta feil her gir en plan som ser komplett ut og sender pakker til en adresse som aldri svarer.
Trinn 3: skriv ruten hver arbeidslast faktisk bruker
Hver grense nedenfor er et eget oppslag, og en rute i en av dem er ikke en rute for pakken. Fyll ut tabellen med dine egne verdier 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 en tunnel er sunn; ruteoversikten behandler det som en del av forbindelsen. I Azure knyttes en brukerdefinert rutetabell til et subnett i stedet for til det virtuelle nettverket, så kontroller den effektive ruten på arbeidslastens NIC i stedet for i VNet-bladet.
En administrert Azure-gateway kan lære det fjerne prefikset gjennom gateway-utbredelse, og en UDR kan overstyre den beslutningen. Legg til UDR når du har en grunn, ikke per refleks. Hvis du legger til en, pek den mot neste hopp som gatewayen publiserer for VPN-veien, i stedet for å finne opp en apparatadresse. Les deretter de effektive rutene på NIC på nytt, fordi det er på NIC beslutningen faktisk tas.
Trinn 4: avstem omfanget
For BGP, sammenlign hva hver side annonserer med hva den andre siden faktisk lærte, prefiks for prefiks. For statisk ruting, sammenlign de konfigurerte fjerne områdene med arbeidslastrutene du skrev i trinn 3.
Et IKE-forhold som er enige om kryptografi er ikke bevis for at noen side har lært 10.10.0.0/16 eller 10.20.0.0/16. To tunneler kan være oppe mens den ene siden annonserer et enkelt /24 i stedet for det /16 du planla. Kontroller prefikset i rutetabellen, ikke i tunnelstatusen. Uoverensstemmelsen viser seg senere som ett subnett som virker og ett som aldri svarer.
Trinn 5: test tjenesten fra den virkelige kilden
Tillat den tiltenkte strømmen i AWS-sikkerhetsgrupper og nettverks-ACL-er, i Azure NSG-er og i ethvert apparatfilter på veien. Åpne deretter én forbindelse fra 10.10.1.20 til den godkjente tjenesteadressen og -porten, og bekreft at svaret kommer tilbake til samme kilde.
Både skyens sikkerhetsgrupper og NSG-er er stateful, så en avvist returpakke er et rutesymptom, ikke en regel du glemte å skrive omvendt.
En ping fra en gateway avgjør ingenting. ICMP til en gateway-adresse øver kontrollplansveien, ikke den videresendte TCP-tjenesten arbeidslasten trenger.
Tilbakerulling og registreringer
Noter ruteeierne ved siden av tunnel-ID-ene, og ta vare på rutetabellene fra før endringen. Hvis endringen må ut igjen, fjern arbeidslastrutene før du river tunnelen, slik at ingen subnett blir stående og peke på et neste hopp som ikke finnes lenger.
Da har en senere subnettflytting eller spoke-tilkobling ett bestemt sted å oppdatere, i stedet for en fungerende tunnel som får skylden for en rute den aldri eide.