IPTables, NAT- / Filter-Problem

[Merc]

Hallo allerseits.

Ich betreibe meinen Linux-Rechner (Debian 3.1) als am Netz hängenden Router für zwei (oder bei Bedarf auch mehr) andere Linux- als auch Windowsrechner.

Im Router selbst sind zwei Netzwerkkarten verbaut, beide mit statischer IP:

Code: Alles auswählen

eth0      Protokoll:Ethernet  Hardware Adresse 00:60:97:31:5A:7D
          inet Adresse:xxx.xxx.xxx.xxx  Bcast:xxx.xxx.xxx.xxx  Maske:255.255.254.0
          inet6 Adresse: fe80::260:97ff:fe31:5a7d/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:896854 errors:0 dropped:0 overruns:0 frame:0
          TX packets:691673 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:630843260 (601.6 MiB)  TX bytes:53906807 (51.4 MiB)
          Interrupt:12 Basisadresse:0xdc00

eth1      Protokoll:Ethernet  Hardware Adresse 00:50:04:0A:F8:EC
          inet Adresse:10.80.12.1  Bcast:10.255.255.255  Maske:255.0.0.0
          inet6 Adresse: fe80::250:4ff:fe0a:f8ec/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1850958 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3286908 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:122613602 (116.9 MiB)  TX bytes:4261482465 (3.9 GiB)
          Interrupt:5 Basisadresse:0xf80

Um den anderen Rechnern die Möglichkeit zu geben, das Netz zu benutzen, verwende ich NAT, das ich mit einem kleinen Skript aktiviere beim Hochfahren des Routers.

Code: Alles auswählen

#/bin/bash

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.80.12.2 -o eth0 -j SNAT --to xxx.xxx.xxx.xxx
iptables -t nat -A POSTROUTING -s 10.80.12.3 -o eth0 -j SNAT --to xxx.xxx.xxx.xxx
iptables -t filter -A OUTPUT -o eth0 -s 10.0.0.0/8  -j DROP
iptables --table nat --policy POSTROUTING DROP

IPTables-Auszug:

Code: Alles auswählen

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DROP       0    --  localnet/8           anywhere
DROP       0    -f  localnet/8           anywhere

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       0    --  10.80.12.2            anywhere            to:xxx.xxx.xxx.xxx
SNAT       0    --  10.80.12.3            anywhere            to:xxx.xxx.xxx.xxx

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Leider habe ich ein Problem: das NAT scheint nicht 100% zu funktionieren.

Gelegentlich treten Pakete auf, die nicht korrekt geNATet werden.

Kleiner Auszug aus "tcpdump -i eth0 src host 10.80.12.3 -vv" bzw. "tcpdump -i eth0 src host 10.80.12.2 -vv" :

Code: Alles auswählen

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
10:55:33.697732 IP (tos 0x0, ttl 127, id 8573, offset 0, flags [none], proto: TCP (6), length: 40) 10.80.12.3.1082 > www.debian.org.www: R, cksum 0x5d77 (correct), 1990962368:1990962368(0) win 0
10:55:33.698178 IP (tos 0x0, ttl 127, id 8574, offset 0, flags [none], proto: TCP (6), length: 40) 10.80.12.3.1074 > www.google.de.www: R, cksum 0xe425 (correct), 1794908862:1794908862(0) win 0
19:47:50.170403 IP (tos 0x0, ttl 127, id 55010, offset 0, flags [DF], proto: TCP (6), length: 40) 10.80.12.2.1695 > www.kernel.org.ftp: R, cksum 0x9afd (correct), 1546006051:1546006051(0) win 0

Wenn's nach mir ginge, wären mir die wenigen Pakete egal, mein ISP hat allerdings diesbezüglich etwas striktere Regeln, sprich mir wird, sollte das wieder auftreten, der Zugang gesperrt.

Das Problem tritt sporadisch auf, läßt sich aber mit besonders verbindungslastigen Anwendungen (z.B. Torrent) ziemlich gut replizieren.
Allerdings habe ich das auch bei anderen Protokollen, nicht nur TCP, beobachten können.

Gibts eine Möglichkeit, IPTables so zu konfigurieren, das sichergestellt wird, das keine internen IP's ins Netz gelangen (also keine 10.x.x.x) ?

MfG
Merc

[chroiss]

das is ja n ding ....

du könntest versuchen deine interne Rechner noch "höflicher" darauf hinzuweisen ,
dass du das nicht so gerne hast

Code: Alles auswählen

#/bin/bash 

echo 1 > /proc/sys/net/ipv4/ip_forward 
iptables -t nat -A POSTROUTING -s 10.80.12.2 -o eth0 -j SNAT --to xxx.xxx.xxx.xxx 
iptables -t nat -A POSTROUTING -s 10.80.12.3 -o eth0 -j SNAT --to xxx.xxx.xxx.xxx 
iptables -t filter -A OUTPUT -o eth0 -p TCP -s 10.0.0.0/8  -j REJECT --reject-with tcp-reset
iptables -t filter -A OUTPUT -o eth0 -s 10.0.0.0/8  -j DROP 
iptables --table nat --policy POSTROUTING DROP 

Wenn das dann noch immer auftritt, würde ich versuchen die Forward Kette genauer zu kontrollieren ( mit state filtering ). Wenn dann immer noch einzelne Pakete durchkommen ist das höchst seltsam.

gruss chroiss

[Merc]

Hallo.

Erstmal danke für die Antwort.

Ich füge die Zeile mal ein und schaue, was das Log so sagt.


MfG
Merc

ps: Noch'n paar Zeilen aus'm Log. Die Anwendung, die ich da laufen hatte, war ein Torrent-Client. Seltsamerweise tauchen auch solcherlei Pakete auf, wenn ich z.B. den Netscape schließe (was mich irgendwie darauf bringt, das es sich um Pakete handelt, die beim Schließen von Verbindungen "übrig" bleiben und irgendwie nicht mehr geNATet werden).

Code: Alles auswählen

00:24:31.448192 IP (tos 0x0, ttl 127, id 17532, offset 0, flags [DF], proto: TCP (6), length: 108) 10.80.12.3.1806 > ool-4573f4ca.dyn.optonli
ne.net.30177: FP 1296945987:1296946055(68) ack 2289009165 win 17520
00:24:56.881590 IP (tos 0x0, ttl 127, id 18033, offset 0, flags [DF], proto: TCP (6), length: 40) 10.80.12.3.1844 > athedsl-144958.otenet.gr.
4662: F, cksum 0xa18a (correct), 1303956548:1303956548(0) ack 121518096 win 16920
00:25:49.450930 IP (tos 0x0, ttl 127, id 19058, offset 0, flags [DF], proto: TCP (6), length: 108) 10.80.12.3.1938 > ool-4573f4ca.dyn.optonli
ne.net.30177: FP 1322750940:1322751008(68) ack 786194993 win 17520
10:55:33.698178 IP (tos 0x0, ttl 127, id 8574, offset 0, flags [none], proto: TCP (6), length: 40) 10.80.12.3.1074 > home-v1.websys.aol.co
m.www: R, cksum 0xe425 (correct), 1794908862:1794908862(0) win 0

Der vierte Eintrag entstand, als ich, wie gesagt, den Netscape beendet habe.

[Merc]

Sodala,

besagte Zusatzzeile in iptables-Skript hat leider auch nichts gebracht.

@ chroiss:

Wenn das dann noch immer auftritt, würde ich versuchen die Forward Kette genauer zu kontrollieren ( mit state filtering ). Wenn dann immer noch einzelne Pakete durchkommen ist das höchst seltsam.

Könntest du das in iptables-gebräuchliche Schreibweise umformulieren ? Ich selbst habe von iptables nur die rudimentären Grundkenntnisse, wie sich an meinem simplen iptables-Skirpt zeigt.


Hat sonst noch jemand eventuell weitere Ideen diesbezüglich ?


MfG
Merc

[chroiss]

sry, isn bischen spät , aber weihnachten verpflichtet

irgendwie scheint dein SNAT nicht sauber zu fkt.

forward kette wäre nach diesem schema

Code: Alles auswählen

$IPTABLES -A FORWARD -i $INTDEV -o $EXTDEV -p udp -s 10.80.12.0 --dport 53 -m state --state  NEW -j ACCEPT
$IPTABLES -A FORWARD -i $INTDEV -o $EXTDEV -p tcp -s 10.80.12.0 --dport 53 -m state --state  NEW -j ACCEPT
$IPTABLES -A FORWARD -i $INTDEV -o $EXTDEV -p tcp -s 10.80.12.0 --dport 80 -m state --state  NEW -j ACCEPT
$IPTABLES -A FORWARD -i $INTDEV -o $EXTDEV -p tcp -s 10.80.12.0 --dport 110 -m state --state  NEW -j ACCEPT
$IPTABLES -A FORWARD -i $INTDEV -o $EXTDEV -p tcp -s 10.80.12.0 --dport 443 -m state --state  NEW -j ACCEPT
......

$IPTABLES -A FORWARD -m state --state  ESTABLISHED,RELATED -j ACCEPT

Alternativ könntest du mal versuchen masquerade zu verwenden , obwohl das bei fester ip eigentlich quatsch ist ( funktioniert zwar; aber SNAT ist ja eigentlich genau für dein Anliegen da ).
das wäre dann fogendes :

Code: Alles auswählen

iptables -t nat -A POSTROUTING -s 10.80.12.2 -o eth0 -j SNAT --to xxx.xxx.xxx.xxx
iptables -t nat -A POSTROUTING -s 10.80.12.3 -o eth0 -j SNAT --to xxx.xxx.xxx.xxx 

durch

Code: Alles auswählen

$IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE

ersetzen.

Bevor du das ausprobierst was sagt eigentlich ein

Code: Alles auswählen

lsmod | grep ip_conntrack

?

[gms]

ich verstehe dein Problem nicht:

Kleiner Auszug aus "tcpdump -i eth0 src host 10.80.12.3 -vv" bzw. "tcpdump -i eth0 src host 10.80.12.2 -vv" :

Code: Alles auswählen

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
10:55:33.697732 IP (tos 0x0, ttl 127, id 8573, offset 0, flags [none], proto: TCP (6), length: 40) 10.80.12.3.1082 > www.debian.org.www: R, cksum 0x5d77 (correct), 1990962368:1990962368(0) win 0
10:55:33.698178 IP (tos 0x0, ttl 127, id 8574, offset 0, flags [none], proto: TCP (6), length: 40) 10.80.12.3.1074 > www.google.de.www: R, cksum 0xe425 (correct), 1794908862:1794908862(0) win 0
19:47:50.170403 IP (tos 0x0, ttl 127, id 55010, offset 0, flags [DF], proto: TCP (6), length: 40) 10.80.12.2.1695 > www.kernel.org.ftp: R, cksum 0x9afd (correct), 1546006051:1546006051(0) win 0

auf eth0 sollen ja die Pakete von 10.80.12.3 und 10.80.12.2 reinkommen, ansonsten hätten ja diese Regeln wenig Sinn:

Code: Alles auswählen

iptables -t nat -A POSTROUTING -s 10.80.12.2 -o eth0 -j SNAT --to xxx.xxx.xxx.xxx
iptables -t nat -A POSTROUTING -s 10.80.12.3 -o eth0 -j SNAT --to xxx.xxx.xxx.xxx

Bin mir allerdings auch nicht sicher, ob tcpdump überhaupt das geeignete Mittel zum tracen von NAT ist

Gruß
gms

[chroiss]

auf eth0 sollen ja die Pakete von 10.80.12.3 und 10.80.12.2 reinkommen, ansonsten hätte ja diese Regeln wenig Sinn:

klar , aber gerade das ist ja der knackpunkt. sie kommen zwar rein, gehen aber auch raus ( mit gleicher src IP auf debian.org ) - und das darf natürlich nicht.

ich hab sowas noch nie beobachtet - schon seltsam.

gruss chroiss

[gms]

gehen aber auch raus ( mit gleicher src IP auf debian.org )

woher siehst du das, wenn er nur die reinkommenden Pakete traced: "tcpdump -i eht0" ?

[edit]
Ich bin mir nicht sicher, soll tcpdump dann das Paket zweimal anzeigen mit unterschiedlicher "source" Adresse, oder nur die Ankommenden oder nur die Ausgehenden ?
Besser wäre hier eine Logging Rule, die alle Pakete logged, die nicht genatted wurden und nachträglich verwirft
[/edit]

[chroiss]

@gms

woher siehst du das, wenn er nur die reinkommenden Pakete traced: "tcpdump -i eht0" ?

das -i bezieht sich lediglich auf das interface ( nicht auf incoming... )

Code: Alles auswählen

10.80.12.3.1082 > www.debian.org.www

und die obere zeile sagt mir das...

[edit]
und die richtung dabei ist eigentlich unverkennbar von "intern" nach extern ( also OUTPUT )
[/edit]

gruss chroiss

[gms]

das -i bezieht sich lediglich auf das interface ( nicht auf incoming... )

so war das nicht gemeint, nachdem ich mich aber unklar ausgedrückt habe, habe ich es oben noch weiter erläutert

Code: Alles auswählen

10.80.12.3.1082 > www.debian.org.www

daraus sieht man eben nicht, ob diese Zeile vor dem PREROUTING nach dem PREROUTING, vor dem POSTROUTING oder nach dem POSTROUTING geloggt wurde.
Schon alleine deswegen würde ich eine Logging Rule in das iptables-Script implementieren, die sicherlich informativer ist als der tcpdump Output ist.
Wenn du allerdings weißt, daß diese Zeile sicherlich nach dem POSTROUTING geloggt wurde, dann ziehe ich meine Bedenken zurück

Gruß
gms

[chroiss]

Wenn du allerdings weißt, daß diese Zeile sicherlich nach dem POSTROUTING geloggt wurde, dann ziehe ich meine Bedenken zurück

wenn dem nicht so wäre müssten ja alle pakete doppelt auftauchen, so wie du auch schon erwähnt hast.
dem ist ja aber nicht so.
So wie ich es kenne werden nur die maskierten/genatteten IP's angezeigt. Insgesamt will ich mich aber auch nicht zu weit aus dem Fenster lehnen.

gruss chroiss

[gms]

nachdem ich es zur Zeit nicht testen kann, habe ich Goggel angeworfen.

Leider habe ich aber keine Beschreibung gefunden, wie es tatsächlich sein sollte, da hat sich irgendwie nicht einmal eine Mehrheit herauskristallisisert

Gruß
gms

[gms]

was mich irgendwie darauf bringt, das es sich um Pakete handelt, die beim Schließen von Verbindungen "übrig" bleiben und irgendwie nicht mehr geNATet werden

das kann schon passieren, wenn die Verbindungen nicht ordnungsgemäß abgebaut werden und die Timeouts (Conntrack) nicht optimal eingestellt sind, können diese Pakete keiner Verbindung zugeordnet werden und können daher auch nicht von SNAT korrekt behandelt werden.
Das sollte sich aber leicht verhindern lassen wenn du entweder nur Pakete mit dem Status "NEW,ESTABLISHED,RELATED" duchläßt, oder alle Pakete mit dem Status "INVALID" verwirfst.

Code: Alles auswählen

iptables -A FORWARD -m state --state INVALID -j DROP

Gruß
gms

[Merc]

Hallo allerseits.

Sorry das ich hab nichts von mir hören lassen, aber über Weihnachten war's etwas schlecht mit der Anbindung (sprich keine vorhanden).

Erstmal danke für die iptables-Regeln, werde die mal einsetzen und schauen, was dabei rauskommt bzw. ob es hilft.

@ chroiss

Bevor du das ausprobierst was sagt eigentlich ein

Code:
lsmod | grep ip_conntrack
?

Das sagt

Code: Alles auswählen

ip_conntrack           44180  3 xt_state,iptable_nat,ip_nat

@ gms

daraus sieht man eben nicht, ob diese Zeile vor dem PREROUTING nach dem PREROUTING, vor dem POSTROUTING oder nach dem POSTROUTING geloggt wurde.
Schon alleine deswegen würde ich eine Logging Rule in das iptables-Script implementieren, die sicherlich informativer ist als der tcpdump Output ist.
Wenn du allerdings weißt, daß diese Zeile sicherlich nach dem POSTROUTING geloggt wurde, dann ziehe ich meine Bedenken zurück

Ich denke, wenn es vor dem POSTROUTING geloggt würde, würden mehr Pakete mit internen IP's auftauchen und nicht nur die sporadischen, die den Ärger verursachen.
Allerdings kann ich mich diesbezüglich auch irren

MfG
Merc

ps: Ich setze mal einen weiteren Rechner mit zwei NIC's auf und schaue, ob bei dem mit dem selben Kernel die gleichen Probleme auftauchen. Ein Neuinstall des derzeitigen Routers wollte ich vermeiden ^^

[gms]

Schon alleine deswegen würde ich eine Logging Rule in das iptables-Script implementieren, die sicherlich informativer ist als der tcpdump Output ist. Wenn du allerdings weißt, daß diese Zeile sicherlich nach dem POSTROUTING geloggt wurde, dann ziehe ich meine Bedenken zurück

Die Bedenken bezüglich dem tcpdump Output ziehe ich zurück, habe es zwischenzeitlich schon in der Firma getestet. tcpdump dürfte vor dem PREROUTING und nach dem POSTROUTING loggen
Eine zusätzliche Logging Regel in der POSTROUTING Chain wäre allerdings trotzdem hilfreich, wenn du die Pakete dort loggen kannst, kannst du sie auch anschließend droppen.

ps: Ich setze mal einen weiteren Rechner mit zwei NIC's auf und schaue, ob bei dem mit dem selben Kernel die gleichen Probleme auftauchen. Ein Neuinstall des derzeitigen Routers wollte ich vermeiden ^^

eine Neuinstallation ist sicherlich nicht nötig

wenn das wegschmeißen der INVALID Pakete nicht hilft, füge einmal testweise diese Regeln NACH den SNAT Regeln ein:

Code: Alles auswählen

iptables -t nat -A POSTROUTING -s 10.80.12.2 -o eth0 -j DROP
iptables -t nat -A POSTROUTING -s 10.80.12.3 -o eth0 -j DROP

Bin mir allerdings auch hier nicht sicher, ob hier schon die SNAT Adresse zieht, oder noch die alte


Gruß
gms

[Merc]

Hallo.

Ich habe die oben von euch geposteten Regeln mal übernommen.
Bisher sieht es ganz gut aus, aber man soll den Tag nicht vor dem Abend loben ^^

Nebenbei noch eine kurze Frage: ist es möglich, das SNAT auf bestimme MAC-Addressen zu beschränken ?
Sprich, 10.80.12.2 hat diese und 10.80.12.3 hat jene MAC-Addresse.

Ich möchte nur verhindern, das, wenn die Rechner mit den obigen IP's "aus" sind, jemand anderes sich dieser IP's bedient und somit die Möglichkeit hat, über den Router ins Netz zu kommen.
Speziell für das Problem einen DHCP aufzusetzen, der IP's nur an bestimmte MAC's vergibt, wollte ich eigentlich nicht.

Wäre dieses ebenfalls per iptables lösbar ?


MfG
Merc

[nepos]

So vielleicht: -m mac --mac-source XX:XX:XX:XX:XX:XX in der Regel für das SNAT?

[Merc]

Der Vorschlag sieht gut aus, ich werd's mal ausprobieren.

Danke


MfG
Merc

[edit]
So wie's ausschaut, funktioniert das mit den MAC's nur in der PREROUTING, FORWARD oder INPUT chain.
(Nachzulesen unter http://www.pl-forum.de/t_netzwerk/iptables.html , so auf Anfang des letzten Drittels der Seite)
DIe SNAT-Geschichten stehen dummerweie leider im POSTROUTING
[/edit]

[Merc]

Hallo nochmal.

Nach nunmehr fast 2 Wochen des Testen kann ich sagen, das eure Vorschläge funktionieren und somit geholfen haben

Nochmals danke an alle.


MfG
Merc