Portweiterleitungen für alle Ports können den eigenen WireGuard-Listener verschlucken

Ein öffentliches Gateway betreibt bereits WireGuard auf UDP 51820, SSH auf 22 und eine Anwendung, die aus dem Internet erreichbar sein muss. Die verlockende Regel leitet jeden Port an den Peer weiter und erklärt die Sache für erledigt. Auf einem WireGuard-Gateway kann diese Regel den eigenen Transport des Tunnels abfangen und Sie von der Maschine aussperren, die ihn terminiert. Veröffentlichung ist eine Routing-Entscheidung mit einer Ausnahme für die Steuerungsebene, keine einzelne DNAT-Zeile.

Öffentlicher Zugang, Tunnelzugang: eins wählen

Einen Dienst zu veröffentlichen schafft einen neuen Interneteinstiegspunkt. Das ist nicht dasselbe, wie einem Peer VPN-Mitgliedschaft zu gewähren, denn der Besucher tritt dem Tunnel nie bei und das Gateway wird zum öffentlichen Gesicht des Backends. Diese Unterscheidung bestimmt die Zielgruppe der Regel und ihr Zertifikat.

Administrative Schnittstellen gehören selten an diese Stelle. Eine Admin-Seite, die autorisierte VPN-Clients erreichen, hält ihre Angriffsfläche innerhalb des Tunnels und vermeidet es, ein Anmeldeformular beliebigem Scanning auszusetzen. Öffentliche Anwendungsendpunkte brauchen weiterhin ihr eigenes TLS-Zertifikat, Authentifizierung und Ratenbegrenzung; der verschlüsselte WireGuard-Sprung schützt nicht das Teilstück des Besuchers bis zum Gateway.

Wenn der Dienst wirklich öffentlich sein muss, notieren Sie den Hostnamen, das Zertifikat, das ihn abdeckt, und die Besucherbereiche, die ihn erreichen sollen. Diese drei Fakten bestimmen später die Form der Regel und die Filterrichtlinie. Alles darüber hinaus ist eine Ausweitung des Umfangs auf einem öffentlichen Listener.

Ein Port hinein, ein Backend hinaus

Verwenden Sie einen einzigen öffentlichen Port und einen Backend-Dienst. In diesem Beispiel trägt eth0 die öffentliche Adresse 198.51.100.20, die Tunneladresse des Gateways ist 10.200.0.1, und der Peer betreibt die Anwendung auf 10.200.0.7. Öffentliches TCP 9443 wird auf TCP 8443 des Peers abgebildet:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

Die SNAT-Regel passt auf das übersetzte Backend und das ursprüngliche öffentliche Ziel, sodass eine weitere Verbindung zum selben Backend-Dienst außerhalb dieser Abbildung bleibt. Sie verbirgt außerdem die Adresse des Besuchers vor dem Peer, und das ist der Kompromiss, der eine quellenerhaltende geroutete Rückkehr zu einem eigenen Entwurf macht. Die Referenz zu iptables-Erweiterungen dokumentiert beide Ziele und ihre Vergleichsoptionen.

Weiterleitung muss weiterhin aktiviert werden, und die Filterkette braucht eine Freigabe für das übersetzte Ziel und den Port sowie für bestehende Antworten. Die FORWARD-Kette sieht das übersetzte Ziel erst nach DNAT, daher passt eine gegen die öffentliche Adresse geschriebene Regel nicht auf das weitergeleitete Paket. Schreiben Sie die Freigabe gegen das Backend-Tupel, nicht gegen das öffentliche.

Der Peer muss die Dienstverbindung von der Tunneladresse des Gateways annehmen und die Antwort durch den Tunnel zurückschicken. Seine AllowedIPs müssen die Quelle autorisieren, die er tatsächlich empfängt, und das ist bei Quellübersetzung die Tunneladresse des Gateways; ein breiter 0.0.0.0/0-Eintrag auf jedem Peer ist für diesen Entwurf nicht nötig. Was den Rückverkehr verwirft, ist ein Peer, dessen Liste diese Adresse auslässt, oder ein quellenerhaltender Entwurf, der stattdessen die eigene Adresse des Besuchers weiterleitet, prüfen Sie also die Quelle, die der Peer wirklich sieht, nicht die in Ihrer Regel.

Halten Sie die eigenen Listener des Gateways aus der Regel heraus

Ersetzen Sie den Portvergleich durch eine Regel, die jedes TCP- und UDP-Ziel abdeckt, und der eigene WireGuard-Socket des Gateways fällt darunter. Die Zielübersetzung geschieht, bevor die Maschine entscheidet, dass ein Paket lokal ist, daher kann UDP 51820 beim Peer landen statt bei dem Prozess, der jede Peer-Verbindung hält. Die Regel lädt erfolgreich und der Tunnel stirbt, ein Fehler, der von der Peerseite schwer zu lesen ist.

SSH, Monitoring-Agenten und jeder andere auf dem Gateway gehostete Dienst haben dieselbe Exposition. Eine Regel, die alles weiterleitet, unterscheidet die Steuerungsebene nicht von der veröffentlichten Anwendung, und der erste Neustart nach der Änderung ist der Moment, in dem die Aussperrung offensichtlich wird. Die Catch-all-Regel warnt nicht vor dem Dienst, den sie stillschweigend übernimmt. Sie entdecken es, wenn die nächste Verbindung fehlschlägt.

Wenn breite Weiterleitung wirklich nötig ist, reservieren Sie die Steuerungsports vor der Catch-all-Regel oder nutzen Sie eine separate öffentliche Adresse für die Veröffentlichung. Die zweite Option ist sauberer, weil die Steuerungsadresse ihre eigene Richtlinie behält, aber der Anbieter muss diese Adresse liefern; ein DNS-Eintrag weist keine zu.

Breite TCP- und UDP-Weiterleitung sind auch nicht alle Protokolle. ICMP, IPv6, Pfad-MTU-Rückmeldung und der äußere VPN-Transport brauchen ihre eigene Richtlinie, und eine Regel, die TCP und UDP abdeckt, überlässt diese Fälle der Standardkette.

Wählen Sie das Modell, bevor Sie Regeln schreiben

Vier Formen decken die meisten Gateway-Veröffentlichungen ab, und die Wahl hängt davon ab, wie viele Dienste Sie betreiben und wie viel Risiko für die Steuerungsebene Sie tolerieren. Die Tabelle unten ordnet sie von der engsten zur breitesten.

Beginnen Sie mit dem engen Modell, auch wenn Sie später mehr Dienste erwarten. Es lässt sich am leichtesten prüfen, und eine Menge enger Regeln in eine geprüfte Catch-all-Regel umzuwandeln ist einfacher, als herauszufinden, welchen Listener eine breite Regel abgefangen hat. Welches Modell Sie auch wählen, halten Sie die Regeln beim Firewall-Eigentümer. iptables-Zeilen neben einer UFW- oder nftables-Konfiguration anzuwenden, die dieselben Ketten ebenfalls verwaltet, erzeugt eine Richtlinie, die sich je nach Bootreihenfolge ändert.

Belegen Sie sowohl die Veröffentlichung als auch den Kontrollpfad

Testen Sie von einem autorisierten externen Client mit dem genehmigten Hostnamen und einem dafür gültigen Zertifikat. Bestätigen Sie, welches Backend geantwortet hat, und prüfen Sie dann, dass unabhängige öffentliche Ports weiterhin abgelehnt werden. Eine deaktivierte Zertifikatsprüfung ist kein bestandener HTTPS-Test, und eine Verbindung, die das falsche Backend erreicht, ist schlimmer als eine fehlgeschlagene.

Prüfen Sie danach das Gateway selbst: Verbinden Sie einen WireGuard-Peer, öffnen Sie eine SSH-Sitzung und bestätigen Sie, dass das Monitoring weiterhin berichtet. Der veröffentlichte Dienst kann funktionieren, während die Steuerungsebene defekt ist, daher gehören beide Prüfungen in dasselbe Änderungsfenster. Starten Sie einmal neu, um zu belegen, dass die Regeln in der erwarteten Reihenfolge erneut angewendet werden, entfernen Sie dann die Veröffentlichung und bestätigen Sie, dass das Entfernen tatsächlich zum Hinzufügen passt. Ein großer Satz von Start-Hinzufügungen mit unvollständigem Rückbau ist der Weg, auf dem ein temporärer Test zu einer dauerhaften Öffnung wird.