eth0:0 ist eine Bezeichnung, kein Gerät: die SNAT-Regel richtig stellen

Eine NAT-Regel, die einem VPN-Client-Pool eine eigene öffentliche Adresse geben sollte, steht bei null Paketen, während derselbe Pool weiter mit der falschen Quelle hinausgeht. Meist liegt der Fehler nicht an der Adresse, sondern an der Schnittstelle. -o eth0:0 verweist auf ein Gerät, das es nicht gibt, denn eth0:0 ist eine Bezeichnung, die an einer Adresse auf eth0 hängt. Die Zähler anzusehen ist der schnellste Weg, das zu bestätigen, und die Korrektur ist kleiner, als die Untersuchung vermuten lässt.

Prüfen, wie der Kernel das Gerät nennt

Lesen Sie die beiden Sichten getrennt, bevor Sie etwas ändern:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

Die Link-Auflistung zeigt Schnittstellen. Die Adressauflistung kann eine zweite IPv4-Adresse zeigen, die die Bezeichnung eth0:0 trägt, und das Gerät für diese Adresse ist weiterhin eth0. Das iproute2-Handbuch für Adressen behandelt die Bezeichnung als Namen der Adresse, nicht als zweite Verbindung, und genau darum geht es bei dem ganzen Problem.

Die Geschichte erklärt die Verwirrung. Die alte ifconfig eth0:0 Syntax sah wirklich wie eine neue Schnittstelle aus, und Skripte aus dieser Zeit verweisen noch immer auf eine. Auf einem heutigen System ist der Alias eine Bezeichnung an einer Adresse, und nichts im Routing- oder Netfilter-Pfad behandelt ihn als eigenen Ausgangspunkt.

Prüfen, was die Regel tatsächlich getroffen hat

Lesen Sie die Zähler zusammen mit der Regelliste statt aus dem Gedächtnis:

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

Eine Regel, deren Paketzähler bei null bleibt, während passender Verkehr fließt, wird nicht ausgewertet, und eine Bedingung für die Ausgangsschnittstelle, die eth0:0 nennt, ist eine häufige Ursache. Das von der Route gewählte Ausgabegerät ist eth0, eine Bedingung, die einen anderen Namen sucht, wird also nie wahr, egal welche Quelladresse der Kernel gewählt hat.

Ändern Sie die Bedingung auf das echte Gerät und lassen Sie die Bezeichnung daraus weg. Wenn Sie zwei Client-Pools unterscheiden müssen, die sich dieses Gerät teilen, unterscheiden Sie sie nach Quellpräfix, nicht nach einem Schnittstellennamen, den es nicht geben kann. Zwei Regeln, deren -s -Treffer sich nicht überlappen, sind lesbar und testbar; eine Regel mit einem erfundenen Gerät ist weder das eine noch das andere. Geben Sie jeder Regel einen Kommentar, der den Pool nennt, denn in einem halben Jahr sagt das Präfix allein niemandem mehr, warum sie dort steht.

Prüfen Sie die Route, die das Gerät gewählt hat

Postrouting-NAT läuft, nachdem die Route bereits eine Ausgangsschnittstelle gewählt hat, also muss die Schnittstelle in der Regel die sein, die die Route gewählt hat. Fragen Sie den Kernel direkt mit ip route get für eine repräsentative Client-Adresse und lesen Sie sowohl das Gerät als auch die Quelle, die er meldet.

Wenn die Antwort eth0 nennt, ist der Schnittstellenteil der Regel geklärt. Wenn sie ein Tunnelgerät nennt, erreicht das Paket die Regel, die Sie bearbeiten, nie, und die Suche wandert zur Routing-Tabelle und ihren Prioritäten. Eine Regel, die nie passt, weil das Paket woanders hinausging, sieht in der Zählerausgabe genauso aus wie eine Regel mit einem falsch geschriebenen Gerät. Bestätigen Sie, welchen der beiden Fälle Sie haben, bevor Sie etwas ändern, denn der zweite braucht eine Änderung am Routing statt am Text.

Die übersetzte Quelle bewusst wählen

Wenn das Gerät stimmt, ist die Quelladresse eine eigene Entscheidung. Dies ist nur ein beispielhafter IPv4-Pool und eine Beispieladresse:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

Eine Adresse in --to-source zu schreiben, sorgt nicht dafür, dass jemand sie zu Ihnen zurückroutet. Der Upstream-Anbieter oder der Adressinhaber muss Antworten für diese Adresse an diesen Host zustellen, und die Adresse muss eine sein, die Sie verwenden dürfen. Ist sie das nicht, passt die Regel, übersetzt, und die Antworten gehen trotzdem woanders hin.

Die Quelladresse zu ändern ist nicht dasselbe wie den Uplink zu ändern. Wenn die eigentliche Anforderung ein anderer physischer Pfad ist, muss die Routing-Richtlinie zuerst diesen Pfad wählen; SNAT schreibt die Quelle dann auf dem Gerät um, das die Richtlinie gewählt hat. Weitere Bezeichnungen an eth0 liefern weder die Route noch die Berechtigung.

Mit einer gerade geöffneten Verbindung prüfen

Öffnen Sie eine neue Client-Verbindung, statt eine bestehende weiterzuverwenden. Die Verbindungsverfolgung behält die Übersetzung, die sie beim Start des Flusses festgehalten hat, sodass eine alte Sitzung weiter die vorherige Quelladresse nutzen und eine korrekte neue Regel kaputt aussehen lassen kann. Beobachten Sie, wie der Zähler steigt, und sehen Sie sich dann die übersetzte Quelle auf der Leitung oder am fernen Ende an.

Geben Sie bei mehreren Pools, die sich eine Schnittstelle teilen, jedem einen ausdrücklichen Quell-Treffer und seine eigene Übersetzungsadresse, halten Sie sie in der verwalteten Konfiguration der Firewall und notieren Sie die Reihenfolge, in der sie ausgewertet werden. Dann halten Sie fest, was Sie geprüft haben: das Gerät aus ip route get, den Zähler, der sich bewegt hat, und die Quelle, die die Gegenseite gesehen hat. Dieser Eintrag beantwortet den nächsten Bericht, ohne die Verwirrung um den Alias zu wiederholen.