Vollständiger Tunnel des Access Server auf EC2: Warum ein Kontrollkästchen nicht reicht

Das Abschalten der Quell- und Zielprüfung auf einer EC2-Instanz ist die am häufigsten wiederholte Antwort auf Fragen zum Internet-Ausgang des Access Server und allein bewirkt sie für Ihre Clients nichts. Die Prüfung ist eine Weiterleitungsbeschränkung von AWS: Sie lässt die Instanz Pakete annehmen, deren Quelle oder Ziel nicht ihre eigene Adresse ist. Sie sagt dem Access-Server-Client nicht, seinen Internetverkehr durch den Tunnel zu senden, sie erzeugt keine Route nach oben und sie fügt kein NAT hinzu. Der Mythos ist, dass das Kontrollkästchen die Funktion sei.

Was die Prüfung tatsächlich steuert

Jede EC2-Netzwerkschnittstelle verwirft Verkehr, der nicht an sie adressiert ist, es sei denn, die Instanz agiert als Router, NAT-Gerät oder VPN-Gateway und Sie deaktivieren diese Prüfung. Das Deaktivieren erteilt die Erlaubnis zur Weiterleitung. Erlaubnis ist keine Konfiguration: Die Instanz braucht weiterhin eine Route zu einem Internet-Gateway oder NAT-Gerät, die VPC-Routentabelle braucht weiterhin den passenden Eintrag, Sicherheitsgruppen müssen den Fluss weiterhin erlauben, und der Server muss den Rückverkehr weiterhin übersetzen oder routen.

Prüfen Sie den aktuellen Wert mit aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck, bevor Sie etwas ändern. Wenn Sie ihn in der Konsole ändern, dann weil die Instanz für andere weiterleitet, nicht weil ein Client das Internet nicht erreicht.

Der Access Server besitzt die Routing-Richtlinie des Clients

Öffnen Sie in Access Server 3 die Access Controls und suchen Sie den Abschnitt Internet Access and DNS. Die Auswahl Internet Gateway bietet vollständigen oder geteilten Tunnel; vollständiger Tunnel weist den Client an, seinen Standardverkehr in das VPN zu routen, geteilter Tunnel lässt den Internetverkehr auf dem lokalen Pfad des Clients. Speichern und über den Produkt-Workflow anwenden, dann einen Testclient neu verbinden, denn die Richtlinie wird beim Verbindungsaufbau ausgeliefert.

Ältere Versionen verwenden andere Menüs, und manche Community-Builds von OpenVPN haben keine entsprechende Steuerung. Prüfen Sie die installierte Hauptversion, bevor Sie nach einem Bildschirm suchen, den es nicht gibt. Bestätigen Sie dann, was der Client erhalten hat: Ein Volltunnel-Profil sollte eine Standardroute durch den Tunnel installieren, ein Split-Tunnel-Profil nicht.

Verfolgen Sie das Paket nach dem Tunnel

Sobald der Client Internetverkehr in den Tunnel schickt, muss der Server ihn weiterleiten und meist übersetzen. Der Access Server verwaltet seine eigenen NAT- und Routingregeln, lesen Sie also die effektive Konfiguration, statt Community-OpenVPN-Regeln an generierte Dateien anzuhängen; unverwaltete Regeln werden beim nächsten Produktupdate überschrieben oder kollidieren. sudo iptables -t nat -L -n -v oder das nftables-Äquivalent zeigt, was tatsächlich übersetzt wird.

Die AWS-Seite ist ein separater Pfad. Eine Instanz in einem öffentlichen Subnetz erreicht ein Internet-Gateway direkt und behält ihre öffentliche Adresse oder elastische IP. Eine Instanz in einem privaten Subnetz braucht eine Route zu einem NAT-Gateway oder einer NAT-Instanz, und das NAT-Gerät braucht seine eigene Route zum Internet-Gateway. Das Anhängen eines Internet-Gateways an die VPC gibt keiner privaten Quelle von sich aus eine öffentliche Rückadresse, weshalb dieselbe Access-Server-Konfiguration in einem Subnetz funktioniert und in einem anderen still scheitert.

Prüfen Sie die Routentabelle, die dem Subnetz der Instanz zugeordnet ist, nicht nur die Haupttabelle der VPC. Subnetz-Zuordnungen überschreiben die Haupttabelle, und eine veraltete Zuordnung ist ein häufiger Grund, warum eine funktionierende Konfiguration nach einem Neuaufbau stoppt.

Halten Sie IP-Ausgang und DNS getrennt

Testen Sie zuerst ein Adressliteral, dann einen Namen, aus derselben Client-Anwendung. Wenn curl -4 https://checkip.amazonaws.com eine öffentliche Adresse zurückgibt, aber Hostnamen fehlschlagen, funktionieren Tunnel und NAT-Pfad, und das Problem ist DNS: der gepushte Resolver, der Resolver-Zustand des Clients oder eine Sicherheitsgruppe, die den Resolver blockiert. Die DNS-Einstellungen des Access Server liegen im selben Internet-Access-Bereich, nehmen aber einen anderen Codepfad.

Vergleichen Sie die zurückgegebene Adresse mit dem Ausgang, den Sie beabsichtigt haben. Ist es die öffentliche Adresse der Instanz, wird der Verkehr von der Instanz übersetzt; ist es eine NAT-Gateway-Adresse, wird der Pfad über das private Subnetz genutzt. Beides kann richtig sein. Was Sie nicht schließen können, ist, dass ein Browser auf dem Server die Weiterleitung für den Client beweist.

Lassen Sie ein Kontrollkästchen die Untersuchung nicht beenden

IPv6 ist eine separate Entscheidung. Eine Volltunnel-Richtlinie für IPv4 sagt nichts darüber, ob IPv6 übertragen, blockiert oder geleakt wird, und ein Dual-Stack-Client kann seinen lokalen IPv6-Pfad weiter nutzen, während IPv4 durch den Tunnel läuft. Testen Sie die Adressfamilie, die Ihnen wirklich wichtig ist, und entscheiden Sie ausdrücklich, ob die andere deaktiviert werden soll.

Testen Sie schließlich den getrennten Zustand. Die Auswahl des vollständigen Tunnels beschreibt die Routing-Richtlinie im verbundenen Zustand, nicht was passiert, wenn der Tunnel abbricht. Wenn die Anforderung ist, dass kein Verkehr außerhalb des VPN entweicht, ist das eine Kill-Switch- und Firewall-Frage, und sie braucht einen eigenen Test statt einer Folgerung aus der Routentabelle.