Nur Port 25 in den Tunnel leiten, nicht den Host

Vier Dinge müssen zusammenpassen, bevor ein Linux-Host nur sein eigenes SMTP durch einen Tunnel schickt: eine Route in einer eigenen Tabelle, eine Policy-Regel, die den Verkehr auswählt, eine Quelladresse, die der Peer akzeptiert, und ein Rückweg, der die Asymmetrie übersteht. Jedes davon ist eine eigene Konfiguration mit eigenem Fehlerbild. Die Reihenfolge unten sorgt dafür, dass ein Fehler auf den Teil zeigt, der wirklich falsch ist. Es ist eine portabhängige Routing-Aufgabe, keine Anfrage nach einer Standardroute über VPN.

Eine Portregel ist keine Standardroute

Eine Regel, die lokal erzeugtes TCP mit Zielport 25 abgleicht, schickt diesen Verkehr in eine Tabelle, die Sie benennen. Die Regel erzeugt für sich genommen nichts: Sie wählt aus, und die Tabelle muss eine Route enthalten, die das Paket tragen kann. Beides zusammen deckt nur die ausgehende Richtung eines Protokolls ab, daher bleiben Weiterleitung für andere Hosts, eingehende Mailverbindungen und IPv6 außerhalb der Regelung. Das als portabhängige Policy statt als VPN-Standard zu bezeichnen, hält diese Grenze ehrlich.

Zwei wg-quick-Einstellungen sind Voraussetzungen, nicht Teil der Policy. AllowedIPs = 0.0.0.0/0 erlaubt dem Peer, beliebige IPv4-Ziele zu tragen, und Table = off hindert wg-quick daran, seine eigene Standardroute für dieses Präfix zu installieren. Mischen Sie diese Anweisungen nicht mit einem Manager, der seine eigene Routenpolitik anwendet, denn beide werden sich uneinig sein, wem die Haupttabelle gehört.

Route, Selektor und Schutz schreiben

Wählen Sie eine Tabellennummer und ein Prioritätenpaar, das sonst niemand nutzt, und wenden Sie dann Route, Selektor und Schutz in dieser Reihenfolge an. Die Zahlen unten sind Beispiele, keine reservierten Werte:

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo beschränkt die Regel auf lokal entstehenden Verkehr, und ipproto tcp dport 25 kennzeichnet die Richtung der Verbindung; die ip-rule-Referenz dokumentiert beide Selektoren. Sie existieren in aktuellen Kerneln und iproute2-Versionen, und auf einem älteren System wird die Regel rundweg abgelehnt, was ein klareres Scheitern ist als eine Regel, die lädt und nichts trifft.

Die unreachable-Regel auf der nächsten Priorität ist der Schutz. Ohne sie fällt eine fehlende Route in Tabelle 51825 auf die gewöhnliche Standardroute durch, und Mail verlässt bei einem Tunnelausfall die physische Verbindung, was genau der Fall ist, den die Policy verhindern sollte.

Die Quelladresse muss passen

Die src-Präferenz der Route füllt nur eine Quelle für Verbindungen, die keine eigene gebunden haben. Sie ist keine Übersetzung und überschreibt keine ausdrückliche Bindung, daher sendet ein an die physische Adresse gebundener Daemon weiter von dieser Adresse. Wenn Sie genau das vorfinden, ändern Sie die Einstellung des Daemons selbst oder entwerfen Sie eine bewusste Übersetzungs-Policy, denn ein spätes pauschales Masquerade ist eine andere Lösung mit anderen Folgen.

Am Gateway muss der Peer des Clients die Quelle autorisieren, die er tatsächlich empfängt, also 10.77.0.2/32 statt eines breiten Zielpräfixes. Das 0.0.0.0/0 des Clients in jeden Gateway-Peer zu kopieren, verwischt, welcher Peer welchen Verkehr besitzt. Das Gateway braucht außerdem Weiterleitung, eine Firewall-Policy, die den Fluss erlaubt, und einen Rückweg, einschließlich ausgehender Übersetzung, wenn das Upstream eine private Tunneladresse nicht routen kann.

Rückweg prüfen, dann Persistenz

Lesen Sie die Lookups, bevor Sie irgendetwas vertrauen, denn sie zeigen, welche Tabelle und welche Quelle jede Richtung bekommt. Ein Ziel auf Port 25 und dasselbe Ziel auf Port 443 genügen:

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

Das erste Lookup sollte wg0 und die beabsichtigte Quelle nennen, und das zweite sollte den gewöhnlichen Uplink behalten. Wenn die Anwendung ihre eigene Adresse bindet, fügen Sie from mit dieser Adresse zum Lookup hinzu. Eine Antwortrichtung, die wg0 erreicht und dann lokal verworfen wird, deutet auf IPv4-Reverse-Path-Filterung hin, denn eine reine Ausgangs-Portregel bringt das Reverse-Lookup nicht dazu, den Tunnel zu wählen.

Wo asymmetrisches Routing erlaubt ist, kann ein schnittstellenbezogener Loose-Modus über net.ipv4.conf.wg0.rp_filter=2 angemessen sein, und es lohnt sich, zuerst das effektive Maximum der Werte von all und der Schnittstelle zu prüfen. Deaktivieren Sie die Prüfung nicht global als Abkürzung. Geben Sie dann Tabelle, Prioritäten und Schutz an das, was die Konfiguration besitzt, und öffnen Sie nach einem Reconnect neue Verbindungen, um zu bestätigen, dass die Auswahl weiterhin hält. Denken Sie daran, dass Antworten eines lokalen SMTP-Listeners Quellport 25 statt Zielport 25 tragen, was eine eigene Policy-Frage ist.