Volltunnel-OpenVPN: ein Internet-Ausgang auf der Serverseite

Ein Client authentifiziert sich, erhält eine Adresse aus dem Pool und erreicht Dienste auf dem VPN-Host, doch jedes öffentliche Ziel läuft in einen Timeout. So sieht ein Tunnel ohne Ausgang aus, und so bleibt es, bis vier getrennte Dinge zutreffen. Der Client muss eine Standardroute akzeptieren, der Server muss weiterleiten, die Firewall muss den Transit erlauben, und Antworten brauchen einen Weg zurück in den Pool. Alle vier Fehler teilen ein Symptom, ändern Sie daher pro Versuch genau einen Punkt und notieren Sie das Ergebnis.

Schieben Sie die Standardroute und prüfen Sie, was der Client installiert hat

Die Zeile auf der Serverseite ist kurz, und sie betrifft nur Clients, die gepushte Optionen akzeptieren. Die def1-Form installiert zwei halbe Standardrouten, statt die bestehende Standardroute zu löschen, was die aktuelle Verbindung am Leben hält und trotzdem jedes Ziel erfasst.

push "redirect-gateway def1"

Lesen Sie nach dem erneuten Verbinden die Routing-Tabelle des Clients, statt dem Profil zu vertrauen. Unter Linux erscheinen die beiden /1-Einträge neben der ursprünglichen Standardroute, und Windows zeigt dasselbe Paar als 0.0.0.0/1 und 128.0.0.0/1. Ein Client, der gepushte Optionen ignoriert oder so konfiguriert ist, sie abzulehnen, behält seine alte Standardroute und schickt nie Internetverkehr in den Tunnel. Klären Sie diese Frage, bevor Sie irgendetwas am Server ändern, denn keine serverseitige Regel kann das ausgleichen.

Weiterleitung ist eine Servereinstellung, keine VPN-Einstellung

Lesen Sie das Weiterleitungs-Flag, bevor Sie das Routing anfassen. Eine Null dort bedeutet, dass der Kernel das Paket des Clients annimmt und es ablehnt weiterzugeben, was genau wie ein Firewall-Block von der Gegenseite aussieht. Setzen Sie den Wert über das Konfigurationsverzeichnis des Systems, damit er einen Neustart übersteht.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Prüfen Sie als Nächstes, ob der Host selbst eine funktionierende Route zum Internetausgang hat. Eine Anfrage aus der Shell des Servers beweist, dass der Upstream-Pfad nutzbar ist, und sagt überhaupt nichts über die Weiterleitung eines Client-Pakets aus, behandeln Sie beides also als zwei getrennte Tests. Wenn der Server das Ziel nicht erreicht, hilft keine Menge an Weiterleitungskonfiguration.

Erlauben Sie genau den Transit, den Sie wollen, und sonst nichts

Weitergeleitete Pakete durchqueren den forward-Pfad; Verkehr, der an den VPN-Host selbst adressiert ist, durchquert input. Das sind unterschiedliche Entscheidungen, und das Öffnen des input-Pfads erlaubt keinen Transit durch die Maschine. Die Verwechslung ist der häufigste Grund, warum eine Firewall alles zu erlauben scheint, während Clients weiterhin in Timeouts laufen.

Eine minimale Policy akzeptiert neue Verbindungen aus dem Pool zur Ausgangsschnittstelle und akzeptiert Antworten, die zu etablierten Flows gehören. Legen Sie sie in den Regelsatz-Eigentümer, den Ihre Distribution verwendet, statt bei jedem Boot eine doppelte Regel anzuhängen; doppelte Regeln sammeln sich an und die Zähler bedeuten nichts mehr.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Jede Kette auf Accept zu schalten lässt den Test bestehen und nimmt der Firewall ihren Daseinsgrund. Halten Sie den Umfang auf Pool und Ausgangsschnittstelle begrenzt und lassen Sie unverwandte Weiterleitung in Ruhe.

Geben Sie den Antworten ein Ziel

Pool-Adressen sind privat, ein öffentlicher Server kann eine Antwort also nicht direkt dorthin zustellen. Entweder übersetzt der VPN-Host die Quelladresse auf dem Weg nach draußen, oder ein Gerät weiter oben hält eine Route zurück in den Pool.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Fügen Sie genau eine Übersetzungsschicht hinzu. Ein zweites NAT weiter oben verdeckt das erste und macht beide Protokolle nahezu nutzlos, wenn später etwas kaputtgeht. Wenn ein Router weiter oben den Pool bereits zurückroutet, ist die Übersetzung auf dem Host überflüssig, und der Rückweg hängt dann von der Konfiguration dieses Routers ab statt von Ihrer.

Cloud-Instanzen fügen ein weiteres Tor hinzu, weil manche Plattformen Pakete verwerfen, deren Quelladresse nicht die der Instanz ist, sofern diese Prüfung nicht gelockert wird. Diese Einstellung liegt außerhalb des Gastes und wird leicht vergessen, wenn eine lokale Testmaschine funktioniert.

Beweisen Sie es vom Client aus, nicht aus der Shell des Servers

Beginnen Sie mit einer numerischen IPv4-Anfrage, dann einer Namensauflösung, dann der Anwendung. Ein Ping beweist Weiterleitung und Übersetzung;über die Namensauflösung beweist er nichts, weil DNS-Optionen erst wirken, wenn die Client-Integration sie installiert.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Notieren Sie Änderungen und den Rückabwicklungsschritt laufend, damit die Ausgangspolicy bei einem fehlgeschlagenen Test mit einer Aktion zurückgenommen werden kann. Dieses Rezept deckt nur IPv4 ab; erfassen Sie IPv6 separat, bevor Sie behaupten, das Deployment trage den gesamten Verkehr.