Site-to-Site VPN tussen AWS en Azure: schrijf eerst de retourroute
Een verbonden tunnel tussen twee clouds bewijst niets tot elk workload-subnet naar het verre prefix routeert. Werk het plan op volgorde af en test daarna de dienst.
De tunnel komt wel omhoog. Meestal gebeurt dat, omdat IKE alleen overeenkomende voorstellen en een bereikbaar peeradres nodig heeft. Wat daarna misgaat, is de terugweg: de AWS-workload stuurt pakketten een tunnel in, maar niets aan de Azure-kant weet hoe het 10.10.0.0/16 moet beantwoorden, of de Azure-route staat in een tabel die het workload-subnet niet gebruikt. Schrijf het routeplan voordat u een console aanraakt, en de tunnel wordt het minst interessante deel van het werk.
Stap 1: bevries het adresplan
Werk met concrete waarden. Een AWS-workload staat op 10.10.1.20 binnen 10.10.0.0/16 en heeft TCP 443 nodig naar een Azure-dienst op 10.20.1.30 binnen 10.20.0.0/16. De twee bereiken mogen niet overlappen, en de acceptatietest is het dienstpaar, niet de tunnel.
Schrijf die vier feiten op vóór al het andere, want elke volgende stap wordt ertegen gecontroleerd.
Stap 2: benoem de gateway die elk uiteinde bezit
AWS Site-to-Site VPN kan eindigen op een virtuele privé-gateway of een transit-gateway, en dat zijn verschillende route-eigenaren. Azure biedt zijn beheerde VPN Gateway en, apart, VM-gebaseerde apparaten die klanten zelf beheren. Leg vast welk paar u heeft, want de volgende hop verschilt per combinatie.
Kopieer voor een beheerde gateway geen route die naar een geraden privé-apparaatadres wijst. Voor een apparaat moet u niet aannemen dat routepropagatie in de cloud het gastbesturingssysteem configureert, want dat doet het niet.
Een fout hier levert een plan op dat volledig lijkt en pakketten naar een adres stuurt dat nooit antwoordt.
Stap 3: schrijf de route die elke workload echt gebruikt
Elke grens hieronder is een aparte opzoeking, en een route in een daarvan is geen route voor het pakket. Vul de tabel met uw eigen waarden voordat de tunnel live gaat.
| 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 |
In AWS is de routetabel van het workload-subnet aan u om bij te werken, ook nadat BGP of een tunnel gezond is; het routingoverzicht ziet dat als deel van de verbinding. In Azure wordt een door de gebruiker gedefinieerde routetabel aan een subnet gekoppeld in plaats van aan het virtuele netwerk, dus controleer de effectieve route op de NIC van de workload en niet in de VNet-blade.
Een beheerde Azure-gateway kan het verre prefix leren via gateway-propagatie, en een UDR kan die beslissing overrulen. Voeg de UDR toe wanneer u een reden heeft, niet uit reflex. Als u er een toevoegt, wijs die dan naar de volgende hop die de gateway voor het VPN-pad publiceert in plaats van een apparaatadres te verzinnen. Lees daarna de effectieve routes op de NIC opnieuw, want daar wordt de beslissing echt genomen.
Stap 4: verzoen de scope
Vergelijk voor BGP wat elke kant aankondigt met wat de andere kant werkelijk heeft geleerd, prefix voor prefix. Vergelijk voor statische routing de geconfigureerde verre bereiken met de workload-routes die u in stap 3 schreef.
Een IKE-relatie die het over cryptografie eens is, is geen bewijs dat een kant 10.10.0.0/16 of 10.20.0.0/16 heeft geleerd. Twee tunnels kunnen omhoog staan terwijl één kant één /24 aankondigt in plaats van de geplande /16. Controleer het prefix in de routetabel, niet in de tunnelstatus. De mismatch komt later naar voren als één werkend subnet en één dat nooit antwoordt.
Stap 5: test de dienst, vanaf de echte bron
Sta de bedoelde stroom toe in de AWS-beveiligingsgroepen en netwerk-ACL’s, in de Azure NSG’s en in elk apparaatfilter op het pad. Open daarna één verbinding van 10.10.1.20 naar het goedgekeurde dienstadres en de poort, en bevestig dat het antwoord naar dezelfde bron terugkomt.
Zowel cloudbeveiligingsgroepen als NSG’s zijn stateful, dus een geweigerd retourpakket is een routesymptoom, niet een regel die u vergat omgekeerd te schrijven.
Een ping van welke gateway dan ook beslist niets. ICMP naar een gatewayadres oefent het pad van het controlevlak, niet de doorgestuurde TCP-dienst die de workload nodig heeft.
Terugdraaien en registratie
Leg de route-eigenaren vast naast de tunnel-ID’s en bewaar de routetabellen van vóór de wijziging. Moet de wijziging eruit, verwijder dan de workload-routes voordat u de tunnel afbreekt, zodat geen subnet blijft wijzen naar een volgende hop die niet meer bestaat.
Een latere subnetverhuizing of spoke-koppeling heeft dan één bepaalde plek om bij te werken, in plaats van een werkende tunnel die de schuld draagt voor een route die hij nooit bezat.