Die Weiterleitung eines Ports an einen Host, der hinter dem eigenen VPN-Client des Routers sitzt, scheitert auf eine Weise, die wie ein Firewallproblem aussieht, denn die Anfrage kommt eindeutig an. Der Dienst protokolliert eine Verbindung, der Client wartet, und nichts kommt zurück. Die Zielübersetzung hat ihre Arbeit getan; das Antwortpaket ist der Teil, der verschwunden ist. Eine einzelne selektive Quell-NAT-Regel auf dem Router behebt das, und der interessante Teil ist zu entscheiden, wie eng diese Regel sein kann.

Warum die Antwort einen anderen Weg nimmt

Eine Portweiterleitung schreibt um, wohin ein Paket geht, nie, woher es kam. Die Adresse des Internet-Clients bleibt auf dem gesamten Weg durch den Tunnel im Quellfeld, sodass der entfernte Dienst einen Fremden sieht und so antwortet, wie er es kennt: über sein eigenes Standard-Gateway. Dieses Gateway ist der VPN-Konzentrator auf der Gegenseite, der keine Route zurück zu einer beliebigen öffentlichen Adresse hat.

Sehen Sie sich einen Mitschnitt auf der Tunnelschnittstelle an, und die Asymmetrie ist offensichtlich: Anfragepakete hinaus, nichts hinein. Die Weiterleitungskette hat den Fluss erlaubt, und der Tunnel hat ihn befördert, also geschieht das Verwerfen, nachdem der entfernte Host bereits einen Rückweg gewählt hat.

Eine Quellregel, eng genug, um ihr zu trauen

Machen Sie den Router zur Quelle, an die der entfernte Host antwortet. In diesem Aufbau ist die WAN-Adresse 203.0.113.24, das LAN ist 192.168.88.0/24, die Tunneladresse des Routers ist 172.20.5.1, und der Dienst antwortet unter 172.20.5.40:8443. Die Regel unten trifft das Paket nach der Zielübersetzung, deshalb nennt sie die übersetzte Adresse und nicht die öffentliche. Nichts daran hängt von der Adresse des Clients ab, und genau das ist der Punkt.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Jede Übereinstimmung in dieser Zeile existiert, um das Umschreiben auf einen Dienst an einem Tunnel zu beschränken. Entfernen Sie die Schnittstelle oder den Port, und Sie schreiben mehr Verkehr um, als das Problem verlangt, und so wird aus einer gezielten Korrektur ein Rätsel für die nächste Person.

Wann eine pauschale Maskerade die ehrliche Wahl ist

Wenn der Router viele Dienste in dasselbe VPN-Subnetz weiterleitet, wird eine Regel pro Dienst zu einer Liste, die niemand pflegt. Alles zu maskieren, was die Tunnelschnittstelle verlässt, ist einfacher und vorhersehbarer, auf Kosten dessen, dass der ursprüngliche Client vor jedem Host auf der Gegenseite verborgen wird. Wählen Sie es, wenn die Protokolle dort nicht zur Zuordnung dienen; behalten Sie die enge Regel, wenn doch.

Die beiden Optionen scheitern auch unterschiedlich. Eine fehlende enge Regel bricht einen Dienst; eine breite Maskerade, die zu viel trifft, kann Verkehr stillschweigend umschreiben, der bereits funktionierte, einschließlich der eigenen ausgehenden Verbindungen des Routers.

Prüfen Sie die Zähler, bevor Sie veröffentlichen

Regeln, die nie treffen, sehen identisch aus wie Regeln, die funktionieren, bis Sie Pakete zählen. Lesen Sie die Tabelle mit Byte-Zählern erneut, bevor sich ein Client verbindet, verbinden Sie sich dann aus einem Netz, das nicht das LAN ist, und lesen Sie sie erneut. Zwei Messungen sind das, was eine Vermutung in eine Tatsache verwandelt. Veröffentlichen Sie die Weiterleitung erst, nachdem sich die zweite bewegt.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Ein Nullzähler auf der Quellregel nach einer echten Verbindung bedeutet, dass die Übereinstimmung falsch ist, meist weil Ziel oder Port nicht zum Paket nach der Übersetzung passen. Steigt der Zähler, aber der Client läuft weiterhin in eine Zeitüberschreitung, ist der Rückweg repariert und etwas anderes verwirft die Antwort, also sehen Sie sich als Nächstes die Weiterleitungsrichtlinie auf der Gegenseite an. Hairpin-Zugriff aus dem LAN ist ein separates Problem und braucht eine eigene Regel, nicht eine breitere Version dieser hier.

Ähnliche Artikel