Veröffentlichen Sie einen VPN-Client-Port hinter CGNAT: Checkliste

Stellen Sie einen Dienst auf einem Laptop hinter Carrier-Grade-NAT bereit, richten Sie diesen Laptop über ein VPN auf einen VPS aus, und niemand außerhalb kann ihn erreichen. Sie fügen eine Destination-NAT-Regel auf dem VPS hinzu und bekommen etwas Schlimmeres als Stille: Verbindungen öffnen sich und bleiben dann hängen. Die Antwort fehlt nicht, sie verlässt den Client über dessen eigene Standardroute, was bedeutet, dass der Server sie nie sieht. Arbeiten Sie diese fünf Prüfungen der Reihe nach ab und halten Sie bei der ersten an, die nicht standhält.

Bestätigen Sie, dass der Server überhaupt weiterleiten wird

Setzen Sie dieses Häkchen, bevor Sie auch nur eine Übersetzung schreiben. Eine DNAT-Regel für ein Paket, das der Kernel nicht weiterleiten will, wird vom Regelparser akzeptiert und dann vom Weiterleitungspfad verworfen, was einen Timeout erzeugt, der wie ein Firewallproblem aussieht.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

Es im laufenden Kernel zu setzen ist nicht dasselbe wie es über einen Neustart hinweg zu setzen. Schreiben Sie net.ipv4.ip_forward=1 in eine Datei unter /etc/sysctl.d/, führen Sie sysctl --system aus und lesen Sie den Wert dann zurück, statt darauf zu vertrauen, dass die Datei übernommen wurde. Ein Container, der seinen eigenen Netzwerk-Namespace verwaltet, braucht denselben Wert innerhalb dieses Namespace, nicht nur auf dem Host.

Ist der Rücklesewert immer noch null, hören Sie hier auf. Nichts weiter unten wird funktionieren.

Fixieren Sie die Tunneladresse, bevor eine Regel darauf verweist

Der Pool vergibt Adressen in Verbindungsreihenfolge, sodass eine Regel, die für das heutige Lease geschrieben wurde, nächste Woche still auf einen anderen Client zeigen kann. Binden Sie die Adresse an die Zertifikatsidentität statt an die Ankunftsreihenfolge.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

Dieses Paar ist das Client-Ende und das Peer-Ende eines Punkt-zu-Punkt-Tunnels, wobei der Server auf den Common Name des Zertifikats geschlüsselt ist. Unter einer Subnetz-Topologie wird der zweite Wert stattdessen als Netzmaske gelesen, schreiben Sie also die Form, die zur verwendeten Topologie passt. Verbinden Sie dann den Client neu und lesen Sie die Adresse auf dem Client selbst, denn die Sicht des Servers auf den Pool ist kein Beweis dafür, was der Client konfiguriert hat.

Ändert sich die Adresse nach einem erneuten Verbinden, hören Sie auf. Eine NAT-Regel, die einem beweglichen Ziel folgt, wird zeitweise fehlschlagen und Ihnen nichts beibringen.

Übersetzen Sie in beide Richtungen

Die Destination-Übersetzung schickt das eingehende Paket zum Client. Die Source-Übersetzung ist es, die den Client dazu bringt, dem Server statt dem ursprünglichen Absender zu antworten, und genau diese Regel lassen die Leute weg.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

Ohne die zweite Regel antwortet der Client über seinen ISP-Uplink, sodass der entfernte Peer eine Quelladresse sieht, mit der er nie gesprochen hat, während der Server keinen Tracking-Eintrag für die Antwort hat. Der äußere Beobachter sieht einen Handshake, der zur Hälfte abschließt, und das ist genau das Symptom, das Leute auf die Suche nach einem Firewallfehler schickt, der nicht existiert.

Lesen Sie beide Regeln mit iptables -t nat -S zurück und bestätigen Sie, dass der Schnittstellenname der ist, der die öffentliche Adresse trägt. Auf einem Host, der bereits mit nftables filtert, schreiben Sie die Übersetzung in eine nftables-NAT-Kette der passenden Adressfamilie, statt Werkzeuge zu mischen.

Lassen Sie die Filtertabelle durch

Die NAT-Tabellen schreiben Header um; sie erteilen keine Erlaubnis. Bei einer Standard-DROP-Policy braucht der weitergeleitete Fluss seine eigene Freigabe, plus die Rückrichtung, die die meisten Policies bereits mit einer established,related-Regel abdecken.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Prüfen Sie die Policy der FORWARD-Kette, bevor Sie etwas hinzufügen, denn die Reihenfolge eines frühen DROP entscheidet, ob Ihre Regel überhaupt befragt wird. Auf einem Host, dessen Filterung in nftables lebt, fügen Sie die äquivalente Regel zum forward-Hook der inet-Tabelle hinzu und bestätigen Sie, dass die Basiskette tatsächlich weitergeleiteten Verkehr sieht und nicht nur lokalen Input. Bleibt ein Paketzähler an der neuen Regel auf null, während die NAT-Zähler steigen, wird das Paket vor Ihrer Regel verworfen. Das ist das Signal, die Kettenreihenfolge zu lesen, nicht eine zweite Kopie derselben Regel hinzuzufügen.

Beweisen Sie es aus einem externen Netzwerk

Testen Sie aus einem nicht verbundenen Netzwerk. Eine Sonde von einem anderen Rechner im selben LAN kann über Hairpin-NAT-Unterstützung laufen und den Pfad, den ein entfernter Client nutzt, nie ausüben, ein grünes Ergebnis dort beweist also das Falsche.

tcpdump -ni any port 29443
conntrack -L | grep 29443

Führen Sie die Aufzeichnung auf dem Server und auf dem Client gleichzeitig aus. Die Server-Aufzeichnung zeigt, ob das übersetzte Paket in Richtung Tunnel verlässt; die Client-Aufzeichnung zeigt, ob die Anfrage ankommt und wohin die Antwort adressiert ist. Ein Übersetzungseintrag in conntrack -L beweist, dass die Regel gegriffen hat, und sein Fehlen beweist, dass das Paket die NAT-Kette nie erreicht hat.

Portscanner sind schwache Beweise. Sie melden den Port als geschlossen, bis die Anwendung gebunden ist und lauscht, verwenden Sie also eine echte Verbindung zum echten Dienst. Wenn es endlich funktioniert, halten Sie die Exposition auf diesen einen Port beschränkt: SSH oder ein Admin-Panel weiterzuleiten, weil die erste Regel unangenehm wirkte, ist eine viel größere Entscheidung als einen Dienst zu veröffentlichen.