☰

CentOS 7 NAT-Routing und IPTABLES

tag-icon • tag-icon linux centos iptables
CentOS 7 NAT-Routing und IPTABLES

Ich habe die CentOS-Instanz als NAT für mein lokales Netz. Es gibt mehrere Subnetze in meinem lokalen Netz. In einem davon befindet sich ein PPTP-VPN-Server. Ich muss diesen Server im Internet veröffentlichen.

nat/PREROUTINGAlso. Mein Problem ist, dass der Verkehr nicht von Kette zu Kette weitergegeben wird filter/FORWARD.

  • 1.1.1.1ist meine externe IP
  • 192.168.10.1ist meine interne IP
  • 10.0.1.1ist die VPN-Server-IP
  • eth0ist eine externe Schnittstelle
  • eth1ist eine interne Schnittstelle

NAT-Regeln(es funktioniert. PKTSund BYTESwird geändert)

-A PREROUTING -d 1.1.1.1/32 -i eth0 -p tcp -m tcp --dport 1723 -j DNAT --to-destination 10.0.1.1
-A PREROUTING -d 1.1.1.1/32 -i eth0 -p gre -j DNAT --to-destination 10.0.1.1

FILTER-Regeln(es funktioniert nicht. PKTSund BYTESwird nicht geändert)

-A FORWARD -d 10.0.1.1/32 -i eth0 -o eth1 -p tcp -m tcp --dport 1723 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.0.1.1/32 -i eth1 -o eth0 -p tcp -m tcp --sport 1723 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 10.0.1.1/32 -i eth0 -o eth1 -p gre -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.0.1.1/32 -i eth1 -o eth0 -p gre -m state --state RELATED,ESTABLISHED -j ACCEPT

Natürlich, net.ipv4.ip_forward = 1und ich kann 10.0.1.1vom NAT-Server aus pingen.

Auf tcpdumpPort 1723 wurden nur Aktionen auf der externen Schnittstelle angezeigt.

Ich habe keine Idee.

UPD1. Ich habe die Weiterleitung mit geprüft ip route get 10.0.1.1 from <src> iif eth0und bekam RTNETLINK answers: Invalid argument. Übrigens hatte ich eine Antwort bekommen, als ich einen beliebigen iifNamen verwendet habe ( eth0, eth1, eth2). Ich habe nur die gültige Route bekommen, als ich kein Argument verwendet habe iif.

UPD2. Ich habe zuerst -A FORWARD -d 10.0.1.1/32 -j ACCEPTeine Regel zur Kette hinzugefügt. Aber nichts. Pakete und Bytes waren null.filter/FORWARD

Antwort1

  • Andere Regeln sind sehr wichtig. Und die Reihenfolge der Regeln ist es auch. Überprüfen Sie also die Ausgabe des iptables-save -cBefehls. Untersuchen Sie die Regeln über denen, die Sie erstellt haben.

  • Zwischen den nat/PREROUTINGund filter/FORWARDKetten wird die Routing-Entscheidung getroffen. Überprüfen Sie das Routing mit ip route get 10.0.1.1 from <src> iif eth0. Es sollte die gültige Route zurückgeben. Wenn es etwas anderes ist, fügen Sie es in die Frage ein.

  • Untersuchen Sie auch die Ausgabe des nstat -azBefehls.

  • Um das PPTP durch das NAT zu leiten, müssen Sie die Module für Conntrack laden:

    • nf_conntrack_proto_gre
    • nf_nat_proto_gre
    • nf_conntrack_pptp
    • nf_nat_pptp

  • In den neueren Kerneln müssen Sie die Conntrack-Helfer explizit aktivieren, insbesondere für PPTP. Sie müssen also die zusätzliche Regel hinzufügen.

iptables -t raw -A PREROUTING -p tcp -m tcp --dport 1723 -j CT --helper pptp
  • Eine andere Möglichkeit, den Helfer zu aktivieren, ist der Sysctl-Befehl:
sysctl -w net.netfilter.nf_conntrack_helper=1
  • Andere Tools zur Fehlerbehebung Ihres Problems:
    • conntrack -E- Überwachung von Conntrack-Ereignissen
    • tcpdump
    • -j NFLOGund tcpdump -ni nflog- erlauben Sie das Erfassen der Pakete aus der iptables-Regel.
    • -j TRACEZiel – Sie können den Pfad von Paketen durch die Firewall-Regeln untersuchen.

PSAktualisieren Sie die Frage, wenn Sie immer noch nicht weiterkommen.

verwandte Informationen