Die Quell-/Zielprüfung ist ein Tor, nicht der ganze VPN-Pfad
Eine weiterleitende Instanz braucht AWS-Berechtigung sowie Linux-Routen und Firewall-Regeln. Prüfen Sie die Quell-/Zielvalidierung an der Instanz, die weiterleitet.
Das VPN endet auf einer EC2-Instanz, Sie erreichen die Tunneladresse dieser Instanz, und Verkehr, der durch sie zu einem anderen privaten Host laufen soll, verschwindet. Das sind zwei verschiedene Tests, und sie zu vermischen kostet Stunden. Der erste fragt, ob Sie die Instanz erreichen; der zweite verlangt, dass sie Verkehr für ein Ziel weiterleitet, das nicht ihr eigenes ist, was Linux-Weiterleitung, eine Firewall-Richtlinie, eine Route auf der Gegenseite und eine Berechtigung auf AWS-Ebene erfordert, die nichts mit dem Gastbetriebssystem zu tun hat. Nichts in der Konsole weist auf diesen Unterschied hin. Das Symptom sieht wie ein Routingfehler aus, und meistens ist es keiner.
Trennen Sie die beiden Tests, bevor Sie etwas ändern
Das Erreichen des Gateways beweist den Tunnel, die Route zu seiner Adresse und die Sicherheitsgruppe, die den Austausch erlaubt. Weiterleitung für einen anderen Host beweist nichts davon: Sie nutzt eine andere Quelladresse, ein anderes Ziel und eine Instanz in einer Rolle, für die sie nicht unbedingt gebaut wurde. Schreiben Sie die beiden Tests getrennt auf und notieren Sie, welcher scheitert, denn die Korrektur für jeden liegt in einer anderen Konsole. Eine Gateway-Instanz, die nur Tunnel beenden soll, hat keinen Grund, für etwas anderes weiterzuleiten, und ihre Standardwerte spiegeln das. Deshalb braucht der zweite Test seine eigene Einrichtung statt einer kleinen Anpassung des ersten.
Ein Ping, der zum Gateway funktioniert, und ein Ping, der zum Host dahinter scheitert, ist kein zeitweiliges Problem. Es ist das erwartete Verhalten einer Instanz, der nicht gesagt wurde, dass sie weiterleiten darf.
Schreiben Sie den Pfad auf, bevor Sie eine Einstellung anfassen
Notieren Sie das Client-Präfix, die weiterleitende Instanz oder Netzwerkschnittstelle, das Ziel-Subnetz und die Rückroute. Ein Eintrag in der VPC-Routentabelle, der auf eine Instanz zeigt, konfiguriert das Betriebssystem der Instanz nicht zur Weiterleitung, und ein Gast-Kernel mit aktivierter Weiterleitung erzeugt keine VPC-Route. Beide Enden dieser Beziehung müssen existieren, und sie werden an verschiedenen Orten von Personen mit unterschiedlichem Zugriff bearbeitet.
Prüfen Sie dann die Einstellung der Quell-/Zielprüfung an der tatsächlichen Weiterleitungskomponente, nicht an jeder Instanz im VPC. AWS dokumentiert, warum eine Instanz, die Verkehr für andere weiterleitet, diese Prüfung deaktiviert haben muss, und auch, warum die Einstellung eine Entscheidung pro Instanz und kein VPC-weiter Standard ist.
Vier Grenzen, und die Prüfung ist nur eine davon
Behandeln Sie den Pfad als vier Fragen und beantworten Sie sie der Reihe nach. Die erste scheiternde Antwort zeigt, wo die Arbeit liegt, und keine der anderen wird das ausgleichen.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
Die Reihenfolge zählt, weil die Prüfung billig ist: Routen sind auf einer Seite sichtbar, die Prüfung ist ein einziges Attribut, und die Meinung des Ziels ist meist das Letzte, wonach jemand fragt.
Übersetzung ändert, welche Quelle das Ziel sieht
Ein geroutetes Design bewahrt die Quelladresse des Clients, also braucht das Ziel eine Rückroute zum Client-Präfix. Ein übersetztes Design präsentiert stattdessen die Adresse des Gateways, was diese Anforderung entfernt und durch eine Zustandstabelle auf dem Gateway ersetzt. Entscheiden Sie nach der Architektur, die Sie beabsichtigen, statt Übersetzung hinzuzufügen, weil ein unabhängiges Beispiel sie verwendet hat und zu funktionieren schien.
Wenn Sie übersetzen, begrenzen Sie die Regel auf das Client-Präfix und das beabsichtigte Ziel. Wenn Sie bewahren, bestätigen Sie, dass die Gegenseite die Route tatsächlich kennt, statt anzunehmen, dass sie eine lernt.
Testen Sie vom ursprünglichen Client aus und behalten Sie dann die Änderung
Eine auf dem Gateway erzeugte Anfrage kann gelingen, während eine weitergeleitete Anfrage scheitert, weil es eine andere Quelle und ein anderer Weiterleitungsfall ist. Wiederholen Sie nach einer gezielten Korrektur den genauen Client-zu-Ressource-Test, der gescheitert ist, vom selben Client, und bestätigen Sie, dass die Antwort zurückkommt und nicht nur, dass die Anfrage ankam.
Legen Sie die Einstellung schließlich in der verwalteten Konfiguration des Gateways ab, damit eine Ersatzinstanz sie erhält. Ein erfolgreicher Test, der von einer manuellen Ausnahme abhängt, ist ein Test, der beim nächsten Neuaufbau abläuft, und die Person, die ihn entdeckt hat, wird nicht da sein, um sich zu erinnern, warum.