Site-to-Site-VPN zwischen AWS und Azure: zuerst die Rückroute schreiben
Ein verbundener Cross-Cloud-Tunnel beweist nichts, solange nicht jedes Workload-Subnetz zum fernen Präfix routet. Arbeiten Sie den Plan der Reihe nach ab und testen Sie dann den Dienst.
Der Tunnel wird hochkommen. Meistens tut er das, denn IKE braucht nur passende Vorschläge und eine erreichbare Peer-Adresse. Was danach scheitert, ist der Rückweg: Die AWS-Workload schickt Pakete in einen Tunnel, aber auf der Azure-Seite weiß nichts, wie man 10.10.0.0/16 beantwortet, oder die Azure-Route steht in einer Tabelle, die das Workload-Subnetz nicht verwendet. Schreiben Sie den Routenplan, bevor Sie eine Konsole anfassen, und der Tunnel wird der uninteressanteste Teil der Arbeit.
Schritt 1: den Adressplan einfrieren
Arbeiten Sie mit konkreten Werten. Eine AWS-Workload liegt auf 10.10.1.20 innerhalb von 10.10.0.0/16 und braucht TCP 443 zu einem Azure-Dienst auf 10.20.1.30 innerhalb von 10.20.0.0/16. Die beiden Bereiche dürfen sich nicht überschneiden, und der Abnahmetest ist das Dienstpaar, nicht der Tunnel.
Schreiben Sie diese vier Fakten vor allem anderen auf, denn jeder spätere Schritt wird dagegen geprüft.
Schritt 2: das Gateway benennen, dem jedes Ende gehört
AWS Site-to-Site VPN kann an einem virtuellen privaten Gateway oder an einem Transit-Gateway enden, und das sind unterschiedliche Routing-Eigentümer. Azure bietet sein verwaltetes VPN Gateway und davon getrennt VM-basierte Appliances, die Kunden selbst betreiben. Halten Sie fest, welches Paar Sie haben, denn der nächste Hop unterscheidet sich in jeder Kombination.
Kopieren Sie bei einem verwalteten Gateway keine Route, die auf eine geratene private Appliance-Adresse zeigt. Bei einer Appliance nehmen Sie nicht an, dass die Routenverteilung in der Cloud das Gastbetriebssystem konfiguriert, denn das tut sie nicht.
Ein Fehler hier ergibt einen Plan, der vollständig aussieht und Pakete an eine Adresse schickt, die nie antwortet.
Schritt 3: die Route schreiben, die jede Workload wirklich nutzt
Jede Grenze unten ist ein eigener Lookup, und eine Route in einer davon ist keine Route für das Paket. Füllen Sie die Tabelle mit Ihren eigenen Werten, bevor der Tunnel live geht.
| 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 ist die Routentabelle des Workload-Subnetzes Ihre zum Aktualisieren, auch nachdem BGP oder ein Tunnel gesund ist; die Routing-Übersicht behandelt das als Teil der Verbindung. In Azure wird eine benutzerdefinierte Routentabelle einem Subnetz zugeordnet und nicht mit dem virtuellen Netzwerk verknüpft, prüfen Sie die effektive Route also an der NIC der Workload und nicht im VNet-Blade.
Ein verwaltetes Azure-Gateway kann das ferne Präfix über Gateway-Weiterleitung lernen, und eine UDR kann diese Entscheidung überstimmen. Fügen Sie die UDR hinzu, wenn Sie einen Grund haben, nicht reflexhaft. Wenn Sie eine hinzufügen, richten Sie sie auf den nächsten Hop, den das Gateway für den VPN-Pfad veröffentlicht, statt eine Appliance-Adresse zu erfinden. Lesen Sie danach die effektiven Routen an der NIC erneut, denn dort wird die Entscheidung tatsächlich getroffen.
Schritt 4: den Umfang abgleichen
Vergleichen Sie bei BGP, was jede Seite ankündigt, mit dem, was die andere Seite tatsächlich gelernt hat, Präfix für Präfix. Vergleichen Sie bei statischem Routing die konfigurierten fernen Bereiche mit den Workload-Routen aus Schritt 3.
Eine IKE-Beziehung, die sich über Kryptografie einig ist, ist kein Beweis dafür, dass eine Seite 10.10.0.0/16 oder 10.20.0.0/16 gelernt hat. Zwei Tunnel können stehen, während eine Seite ein einzelnes /24 statt des geplanten /16 ankündigt. Prüfen Sie das Präfix in der Routentabelle, nicht im Tunnelstatus. Die Abweichung zeigt sich später als ein funktionierendes Subnetz und eines, das nie antwortet.
Schritt 5: den Dienst von der echten Quelle testen
Erlauben Sie den beabsichtigten Fluss in den AWS-Sicherheitsgruppen und Netzwerk-ACLs, in den Azure-NSGs und in jedem Appliance-Filter auf dem Pfad. Öffnen Sie dann eine Verbindung von 10.10.1.20 zur freigegebenen Dienstadresse und zum Port und bestätigen Sie, dass die Antwort zur selben Quelle zurückkommt.
Sowohl Cloud-Sicherheitsgruppen als auch NSGs sind zustandsbehaftet, ein abgelehntes Rückschreiben ist also ein Routing-Symptom und keine Regel, die Sie rückwärts zu schreiben vergessen haben.
Ein Ping von irgendeinem Gateway klärt nichts. ICMP an eine Gateway-Adresse übt den Kontrollebenen-Pfad, nicht den weitergeleiteten TCP-Dienst, den die Workload braucht.
Rollback und Aufzeichnungen
Halten Sie die Routeneigentümer neben den Tunnel-IDs fest und bewahren Sie die Routentabellen von vor der Änderung auf. Muss die Änderung zurückgenommen werden, entfernen Sie die Workload-Routen, bevor Sie den Tunnel abbauen, damit kein Subnetz auf einen nächsten Hop zeigt, der nicht mehr existiert.
Ein späterer Subnetzumzug oder eine Spoke-Anbindung hat dann eine definierte Stelle zum Aktualisieren, statt eines funktionierenden Tunnels, der die Schuld für eine Route trägt, die er nie besessen hat.