DasPREROUTINGSeite scheint zu suggerieren, dass, wenn es in der Kette der Tabelle eine Regel gibt, die das Ziel in natübersetzt , dann die Regeln in der und -Kette auf und nicht auf übereinstimmen sollten .1.2.3.4:8010.1.1.1:8080INPUTFORWARD10.1.1.1:80801.2.3.4:80
Was ist, wenn man eine Reihenfolge der Operationen implementieren möchte, die eher der hier beschriebenen entspricht?Hier? Das heißt, wie führen Sie vor NAT eine Filterung anhand der Paketeigenschaften durch?
Eine Möglichkeit scheint die Verwendung der PREROUTINGKette der rawTabelle zu sein. Das Problem ist, dass Conntrack nicht verfügbar ist raw/PREROUTING(siehe Anmerkung 1) und z. B. ein nicht initiales UDP-Fragment nicht mit dem initialen Fragment verknüpft ist und unerwartete Übereinstimmungen erzeugt.
Bitte lassen Sie mich wissen, ob ich das Dilemma klar beschrieben habe und ob es eine Problemumgehung gibt.
Anmerkung 1: Korrigieren Sie mich, wenn ich falsch liege, aber als ich versuchte, conntrack in zu verwenden raw/PREROUTING, waren alle anfänglichen SYN-Pakete mit " INVALID" statt " NEW" gekennzeichnet. Außerdem scheint es, als ob im Netfilter-Flussdiagramm "conntrack" nach steht raw/PREROUTING.
Antwort1
Sie benötigen keine raw/PREROUTINGRegeln. Sie können die conntrackÜbereinstimmung verwenden, um die Pakete nach der ursprünglichen (vor der Übersetzung) Ziel-/Quelladresse/Portnummer zu filtern. Dies conntrackist ein Nachfolger der älteren Übereinstimmung. Es kann verschiedene zusätzliche Metadaten überprüfen, die mit (und NAT) statezusammenhängen .conntrack entry
Einige Beispiele:
# allow any port-forwarded packets
iptables -t filter -A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
# check the original destination address of DNATed packets
iptables -t filter -A FORWARD -p tcp --dport 8080 -m conntrack --ctstate DNAT --ctorigdstport 80 --ctorigdst X.X.X.X --ctdir ORIGINAL -j ACCEPT
Weitere Einzelheiten finden Sie in der Ausgabe von iptables -m conntrack --helpund man iptables-extensions.
Antwort2
DerPaketfluss in Netfilter und allgemeinem Networkingbeschreibt die Beziehungen zwischen den verschiedenen Hooks, die ein Paket sehen. Hier ist ein kleinerer Teil davon:
Wenn Sie also interagieren möchtenstattlichmit PaketenVornat, die logische Wahl ist mangle/PREROUTING: dieKontaktHook hat das Paket bereits verfolgt: Es wird keinen INVALID-Status erhalten, abernatürlichist immer noch nicht passiert.
Denken Sie daran, dass iptables'natürlichsieht nur das erste Paket und alles weitere wird dann direkt vonKontakt, immer noch an der gleichen Stelle: zwischen mangle/PREROUTINGund der Routing-Entscheidung.
Die andere Methode wird beschrieben in Anton DanilovsAntwort: durch AbfragenKontaktum die frühere Adresse anhand der Nachschlagetabelle zu überprüfen.