PortProxy
Anmeldungsdatum: 28. Januar 2018
Beiträge: 28
|
Hallo, SNAT/MASQUERADE ändern die Absender-IP, z.B.
sudo iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
oder
sudo iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to [IP von eth1]
Das verstehe ich soweit. Das Paket kommt an die POSTROUTING-Stelle und die IP wird geändert, geht zum Ziel-Server mit Absender-Adresse unseres Routers. Bei SNAT kann man das Netzwerkkabel an eth1 ziehen und wieder einstecken und die Verbindungen laufen weiter, bei MASQUERADE wird der Zustand verworfen, da es für dynamische IPs gedacht wird. Zusätzlich muss bei jeder neuen Verbindung die aktuelle IP nachgeschlagen werden, was esw ein bisschen langsamer als SNAT macht. Client schickt also nun eine Anfrage an einen Server via unseren Router. Der Server schickt eine Antwort, Zieladresse ist die Adresse des Routers. Der Router muss diese nun auf die ursprüngliche Client-Adresse ändern, damit dies auch ankommt. Wir haben nirgends eingetragen, dass er dies auch tun soll. Nachdem die Verbindung trotzdem klappt, wird also ein implizites DNAT verwendet. Leider findet sich dazu kaum etwas (oder ich habe die falschen Suchbegriffe) im Netz. Weder in den Manpages oder in den NAT Tutorial ist erwähnt, was genau mit dem ankommenden Paket passiert, wo wird die Zieladresse geändert? Meiner Meinung nach sollte es für das zurückkommende Paket in der PREROUTING-Chain passieren. Die beste/vollständigste Grafik zum Paketfluss, die ich bisher finden konnte ist unter https://de.wikibooks.org/wiki/Linux-Praxisbuch:_Linux-Firewall_mit_IP-Tables#Prinzipielle_Funktionsweise_unter_Linux abgebildet. In der Prerouting-Chain macht das auch am meisten Sinn. Ein NAT macht man ja hautpsächlich (oder nur?, von 1:1 Mapping bei gleichen IP-Bereichen in 2 Netzten einmal abgesehen) damit mehrere Clients über eine einzige öffentliche IP-Adresse online gehen können. Das bedingt doch in diesem Anwendungsfall immer, dass net.ipv4.ip_forward = 1 aktiviert ist, oder? Da wird in den meisten Tutorials zu NAT wird das meiner Meinung nach zu wenig betont / zu undeutlich geschrieben.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
PortProxy schrieb: Wir haben nirgends eingetragen, dass er dies auch tun soll. ... Das bedingt doch in diesem Anwendungsfall immer, dass net.ipv4.ip_forward = 1 aktiviert ist, oder? ...
Um was geht es dir? Um dein System (Client) auf dem Du die S-NAT/MASQUERADE-Regel (warum auch immer) konfiguriert hast oder um deinen Router? Was für einen Router ist das?
|
PortProxy
(Themenstarter)
Anmeldungsdatum: 28. Januar 2018
Beiträge: 28
|
Um dein System (Client) auf dem Du die S-NAT/MASQUERADE-Regel (warum auch immer) konfiguriert hast oder um deinen Router?
Um einen Router. Anders macht das SNAT doch keinen Sinn oder welchen Anwendungsfall könnte es geben wo man das brauchen kann? Es ist im Moment mehr oder weniger nur ein Testgerät um mich in IP-Tables einzuarbeiten. Hauptsächlich geht es mir zu verstehen wie der Paketfluss durch iptables läuft, der vom Server zurückkommt.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
PortProxy schrieb: Um einen Router. Anders macht das SNAT doch keinen Sinn oder welchen Anwendungsfall könnte es geben wo man das brauchen kann?
Doch, es gibt schon Szenarien für S-NAT (MASQUERADE) auch auf einem Client (oder Server). Z. B. wenn es um VPN geht:
Chain POSTROUTING (policy ACCEPT 1679 packets, 110607 bytes)
pkts bytes target prot opt in out source destination
49 4116 MASQUERADE all -- * tap+ 0.0.0.0/0 0.0.0.0/0
|
PortProxy
(Themenstarter)
Anmeldungsdatum: 28. Januar 2018
Beiträge: 28
|
Doch, es gibt schon Szenarien für S-NAT (MASQUERADE) auch auf einem Client (oder Server). Z. B. wenn es um VPN geht:
Welchen Einsatzfall deckst du damit ab? Kannst du noch etwas zum Paketfluss vom Server zum Client zurück sagen? Wo wird in der iptables Kette das Paket per DNAT zurückgeschrieben?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
PortProxy schrieb: Doch, es gibt schon Szenarien für S-NAT (MASQUERADE) auch auf einem Client (oder Server). Z. B. wenn es um VPN geht:
Welchen Einsatzfall deckst du damit ab?
Z. B. um mit Hilfe des VPN-Clienten oder des VPN-Servers als Gateway hinter einem Router (d. h. im W/LAN des Routers), andere Clients im W/LAN des Routers via VPN zu erreichen. PortProxy schrieb: Wo wird in der iptables Kette das Paket per DNAT zurückgeschrieben?
Welche iptables Kette (chain) meinst Du? DNAT wird in der PREROUTING oder in der OUTPUT chain verwendet, damit das Ziel erreicht werden kann. Ein funktionierender Rückweg (für das Datenpaket) ist damit noch nicht garantiert. Evtl. ist dafür zusätzliches Routing oder weiteres NAT erforderlich.
|
PortProxy
(Themenstarter)
Anmeldungsdatum: 28. Januar 2018
Beiträge: 28
|
Z. B. um mit Hilfe des VPN-Clienten oder des VPN-Servers als Gateway hinter einem Router (d. h. im W/LAN des Routers), andere Clients im W/LAN des Routers via VPN zu erreichen.
Hier ist allerdings wieder Routing mit im Spiel, entweder auf deinem VPN Client oder Server und da macht NAT definitiv Sinn. Welche iptables Kette (chain) meinst Du? DNAT wird in der PREROUTING oder in der OUTPUT chain verwendet, damit das Ziel erreicht werden kann. Ein funktionierender Rückweg (für das Datenpaket) ist damit noch nicht garantiert. Evtl. ist dafür zusätzliches Routing oder weiteres NAT erforderlich.
Genau darauf will ich ja hinaus. Masquerade aktiviert ein implizites DNAT, ansonsten würde es ja nicht funktionieren.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
PortProxy schrieb: Z. B. um mit Hilfe des VPN-Clienten oder des VPN-Servers als Gateway hinter einem Router (d. h. im W/LAN des Routers), andere Clients im W/LAN des Routers via VPN zu erreichen.
Hier ist allerdings wieder Routing mit im Spiel, entweder auf deinem VPN Client oder Server und da macht NAT definitiv Sinn.
Naja, aber die statische Route (für die Geräte im W/LAN) mit dem VPN-Clent oder -Server als Gateway, ist im Router eingetragen. Auf dem VPN-Clent oder -Server muss lediglich "net.ipv4.ip_forward" konfiguriert sein. Aber OK, wenn Du das Routing nennen willst ...
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8625
Wohnort: Münster
|
PortProxy schrieb: […] Hauptsächlich geht es mir zu verstehen wie der Paketfluss durch iptables läuft, der vom Server zurückkommt.
Die Vorstellung, IP-Pakete würden die Tabellen und Regeln von iptables durchlaufen, ist gängig und anschaulich, aber im Grunde ungenau und teilweise sogar falsch:
Sie ist ungenau, da die meisten (s.u.) IP-Pakete von der Linux-Kernel-Komponente Netfilter verarbeitet werden. Das Programm iptables ist lediglich eine (nicht die einzig mögliche) Bedienoberfläche zur Konfiguration von Netfilter. Die Datenstrukturen von Netfilter entsprechen nicht alle 1:1 den ipfilter-Regeln, sondern es gilt dies nur für die zustandslosen Verarbeitungen. Hierbei hängt die Verarbeitung des IP-Paketes nur von diesem selbst ab und ändetn nicht den Zustand des Routers. In diesen Fällen ist die gängige Vorstellung der „Funktionsweise von iptables“ im Ergebnis zutreffend. Das Verfahren MASQUERADE (und nicht nur dieses!) erfordert jedoch Verarbeitungen, die nicht nur vom aktuell betrachteten IP-Paket, sondern auch vom internen Zustand des Routers abhängen. Schließlich muss sich der Router merken, welchen Source-Port er für welche Kombination Source-Adresse/Source-Port substituiert hat. In diesen Fällen führt die gängige Vorstellung der „Funktionsweise von iptables“ in die Irre. Es gibt noch die Möglichkeit, dass IP-Pakete an der Linux-Kernel-Komponente Netfilter vorbeilaufen. (Deshalb wurde oben „die meisten“ verwendet.) Jedes Programm, welches einen "raw socket" erstellen kann, hat die Möglichkeit, Netzwerkpakete an Netfilter vorbeilaufen zu lassen. Diese Paket werden also von iptables überhaupt nicht gesehen. Aus diesem Grund ist übrigens jede firewall, die auf demselben Gerät läuft, welches sie schützen soll, eine fragwürdige Angelegenheit.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
kB schrieb: Jedes Programm, welches einen "raw socket" erstellen kann, hat die Möglichkeit, Netzwerkpakete an Netfilter vorbeilaufen zu lassen. Diese Paket werden also von iptables überhaupt nicht gesehen.
Hat man da nicht die Möglichkeit, diese Pakete mit der "raw table" (in der PREROUTING chain) zu filtern? https://unix.stackexchange.com/questions/243079/netfilter-iptables-why-not-using-the-raw-table#244527
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8625
Wohnort: Münster
|
lubux schrieb: kB schrieb: Jedes Programm, welches einen "raw socket" erstellen kann, hat die Möglichkeit, Netzwerkpakete an Netfilter vorbeilaufen zu lassen. […]
Hat man da nicht die Möglichkeit, diese Pakete mit der "raw table" (in der PREROUTING chain) zu filtern?
Das "raw" in "raw socket" hat nichts mit dem "raw" in "raw table" zu tun! Ein IP-Paket, welches an Netfilter vorbeiläuft, läuft (wenn man im anschaulichen Bild bleiben möchte) an jeder Tabelle (table) von iptables vorbei. DHCP beispielsweise benutzt das. Mit dem NOTRACK-Target, welches man in der raw-table von iptables benutzen kann, hat das gar nichts zu tun. Mit diesem Target kann man zustandslose Filter bauen, die robuster gegen denial-of-service Angriffe sind. Das wird jetzt aber OT. Ich wollte nur darauf hinweisen, dass man das gängige (und durchaus gute) Bild der Wirkungsweise von iptables nicht überbeanspruchen darf. Manches ist halt komplizierter.
|
PortProxy
(Themenstarter)
Anmeldungsdatum: 28. Januar 2018
Beiträge: 28
|
kB schrieb: PortProxy schrieb: […] Hauptsächlich geht es mir zu verstehen wie der Paketfluss durch iptables läuft, der vom Server zurückkommt.
Die Vorstellung, IP-Pakete würden die Tabellen und Regeln von iptables durchlaufen, ist gängig und anschaulich, aber im Grunde ungenau und teilweise sogar falsch:
Sie ist ungenau, da die meisten (s.u.) IP-Pakete von der Linux-Kernel-Komponente Netfilter verarbeitet werden. Das Programm iptables ist lediglich eine (nicht die einzig mögliche) Bedienoberfläche zur Konfiguration von Netfilter. Die Datenstrukturen von Netfilter entsprechen nicht alle 1:1 den ipfilter-Regeln, sondern es gilt dies nur für die zustandslosen Verarbeitungen. Hierbei hängt die Verarbeitung des IP-Paketes nur von diesem selbst ab und ändetn nicht den Zustand des Routers. In diesen Fällen ist die gängige Vorstellung der „Funktionsweise von iptables“ im Ergebnis zutreffend. Das Verfahren MASQUERADE (und nicht nur dieses!) erfordert jedoch Verarbeitungen, die nicht nur vom aktuell betrachteten IP-Paket, sondern auch vom internen Zustand des Routers abhängen. Schließlich muss sich der Router merken, welchen Source-Port er für welche Kombination Source-Adresse/Source-Port substituiert hat. In diesen Fällen führt die gängige Vorstellung der „Funktionsweise von iptables“ in die Irre. Es gibt noch die Möglichkeit, dass IP-Pakete an der Linux-Kernel-Komponente Netfilter vorbeilaufen. (Deshalb wurde oben „die meisten“ verwendet.) Jedes Programm, welches einen "raw socket" erstellen kann, hat die Möglichkeit, Netzwerkpakete an Netfilter vorbeilaufen zu lassen. Diese Paket werden also von iptables überhaupt nicht gesehen. Aus diesem Grund ist übrigens jede firewall, die auf demselben Gerät läuft, welches sie schützen soll, eine fragwürdige Angelegenheit.
Danke, dass ist eine sehr gute Erklärung, insbesondere die RAW-Sockets hatte ich nicht bedacht. Hier https://superuser.com/questions/1210742/does-iptables-perform-a-automatically-snat-for-response-packet-if-it-does-when habe ich noch eine schöne Erklärung gefunden. Es wird tatsächlich implizit ein DNAT in der Prerouting-Tabelle durch MASQUERADE/SNAT ausgelöst. Netfilter keeps tracking information on what you send to the MASQUERADE target. When corresponding responses (packets) are received, they are subject to the nat table. The path for incoming packets moving through the nat table is as follows: 1. ingress at router external interface
2. nat - PREROUTING
convert external IP to internal IP
3. nat - POSTROUTING
4. egress at router internal interface
5. ingress at internal computer interface The DNAT is performed in the PREROUTING chain of the nat table. If the original source of the packets was an internal computer on your LAN, the packets will not pass through the filter table of the router because they are recognized as previously NAT'ed packets based on their source and or destination IP's. However, if your router was the original source, and packets are ultimately destined for the router itself, then they would pass through the filter table of the router.
|