muzillah
Anmeldungsdatum: 13. Februar 2012
Beiträge: Zähle...
|
Hallo, ich beschäftige mich nun seit ein paar Wochen mit dem Thema IP-Tables.
Ich bin dabei auf ein Problem gestoßen, welches ich nicht durch "googlen"
lösen konnte und habe mich deshalb entschlossen mal hier nachzufragen. Es geht darum, dass ich bestimmte Regeln in der PREROUTING chain angelegt habe.
Hierbei sollen Pakete (UDP) von einer bestimmten Quelle an eine bestimmte Adresse weitergeleitet werden.
Das funktioniert auch einwandfrei. Nun soll diese Regel aber spontan während einer bestehenden Verbindung
geändert werden können, sodass die Pakete an eine andere Adresse weitergeleitet werden.
Ändere ich die Regel über -R, oder lösche sie zunächst mit -D und lege sie danach neu an mit -A,
ändert sich nichts an der bestehenden Verbindung. Sie wird an die Adresse der alten Regel weitergeleitet.
Auch wenn ich die Schnittstelle mit ifdown und ifup neustarte, bleibt dieses Verhalten bestehen. Kann mir jemand sagen, ob ich gegen Windmühlen kämpfe, oder ob es eine Möglichkeit gibt die Regel auch
für bereits bestehende Verbindungen anzupassen? Gibt es irgendwo eine Datei in der ich diese Regel
tatsächlich finden bzw. löschen kann? (Er merkt sie sich ja offensichlich irgendwie) Danke und Grüße
muzillah
|
mickydoutza
Anmeldungsdatum: 31. Dezember 2010
Beiträge: 2185
|
muzillah schrieb: Ändere ich die Regel über -R, oder lösche sie zunächst mit -D und lege sie danach neu an mit -A,
ändert sich nichts an der bestehenden Verbindung. Sie wird an die Adresse der alten Regel weitergeleitet.
Auch wenn ich die Schnittstelle mit ifdown und ifup neustarte, bleibt dieses Verhalten bestehen.
Poste mal die Ausgaben von:
sudo iptables -L -n -v -t nat
vor und nach deinen Änderungen.
|
muzillah
(Themenstarter)
Anmeldungsdatum: 13. Februar 2012
Beiträge: 12
|
vorher:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 | sudo iptables -t nat -A PREROUTING -s 192.168.4.10 -j DNAT --to-destination 192.168.1.10
Chain PREROUTING (policy ACCEPT 31 packets, 4821 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT all -- * * 192.168.4.10 0.0.0.0/0 to:192.168.1.10
Chain INPUT (policy ACCEPT 28 packets, 4628 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 25 packets, 3914 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 22 packets, 2963 bytes)
pkts bytes target prot opt in out source destination
37 30452 MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0
21 7898 MASQUERADE all -- * eth4 0.0.0.0/0 0.0.0.0/0
|
nachher:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 | sudo iptables -t nat -R PREROUTING 1 -s 192.168.4.10 -j DNAT --to-destination 192.168.1.11
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT all -- * * 192.168.4.10 0.0.0.0/0 to:192.168.1.11
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
37 30452 MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0
21 7898 MASQUERADE all -- * eth4 0.0.0.0/0 0.0.0.0/0
|
Der Übersicht halber einfach mit einer Regel.
|
mickydoutza
Anmeldungsdatum: 31. Dezember 2010
Beiträge: 2185
|
Schreib mal deine Regeln, auch die für die POSTROUTING chain in Scripte, die am Anfang Anfang noch folgende Zeilen beinhalten:
iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -X
und führe die Scripte zu aktivieren der Regeln aus.
|
muzillah
(Themenstarter)
Anmeldungsdatum: 13. Februar 2012
Beiträge: 12
|
Danke erstmal für die schnelle Hilfe.
Es ist in meinem Fall so, dass ich Regeln habe, die während der Änderung anderer Regeln bestehen bleiben müssen.
Das bedeutet, dass ein Flush der kompletten chains nicht in Frage kommt.
Ist das unabdingbar? ~Edit~ Einfach mal trotz dessen mit den oben genannten Kommandos ausgeführt. Ohne Erfolg, die Verbindung bleibt bestehen, auch
wenn ich alles nur flushe und nichts weiter einstelle.
|
mickydoutza
Anmeldungsdatum: 31. Dezember 2010
Beiträge: 2185
|
muzillah schrieb: Ist das unabdingbar?
Zum testen, ja.
Die werden nach dem Flush auch sofort aktiviert. Warum müssen die Regeln permanent bestehen und können nicht neu aktiviert werden? EDIT: OK, dann zumindest so versuchen:
iptables -t nat -F
iptables -t nat -X
|
muzillah
(Themenstarter)
Anmeldungsdatum: 13. Februar 2012
Beiträge: 12
|
Leider hilft das -F und -X nicht.
Ändert zumindest nichts an der bestehenden Verbindung. ☹ ~zur Info~ Als Test habe ich eine bestehende IPERF-UDP-Verbindung. (10000 Sekunden)
|
mickydoutza
Anmeldungsdatum: 31. Dezember 2010
Beiträge: 2185
|
muzillah schrieb: Ändert zumindest nichts an der bestehenden Verbindung.
Dann versuch es mit einer iptables-Regel, die die bestehende Verbindung blockt.
Oder versuch es mit einem tool/Befehl, um die bestehende Verbindung zu unterbrechen.
|
muzillah
(Themenstarter)
Anmeldungsdatum: 13. Februar 2012
Beiträge: 12
|
Blocken à la:
| sudo iptables -A FORWARD -j DROP
|
? Das funktioniert, wenn ich danach die Regeländerung durchführe und
das FORWARD wieder auf ACCEPT stelle, sendet er nur leider weiter
an die alte Adresse.
Oder versuch es mit einem tool/Befehl, um die bestehende Verbindung zu unterbrechen.
Danach suche ich schon den ganzen Tag, finde aber nichts. Es gibt da den Cutter, der für TCP-Verbindungen funktioniert, aber für UDP-Verbindungen kenne ich so etwas nicht.
Einen Vorschlag, vielleicht? ☺
|
mickydoutza
Anmeldungsdatum: 31. Dezember 2010
Beiträge: 2185
|
Bei iperf hast Du ja Sender und Empfänger. Wenn Du einen killst, dann sollte die Verbindung unterbrochen werden. Oder entspricht das Killen nicht deinem realen Anwendungsfall?
EDIT: Oder versuch eine neue Umleitungsregel für iptables, mit der "alten" destination-IP (192.168.1.10) an die "neue" destination-IP (192.168.1.11)
|
muzillah
(Themenstarter)
Anmeldungsdatum: 13. Februar 2012
Beiträge: 12
|
Nein, das "Killen" entspricht leider nicht dem realen Anwendungsfall.
Folgendes soll realisiert werden: Auf der einen Seite hängen beliebig viele Sender in einem Netzwerk an der eth1 vom Server.
Auf der anderen Seite hängen beliebig viele Empfänger in einem anderen Netzwerk an der eth2 vom Server.
Dieser soll nun intern über eine gewisse Zeit die Pakete von Sender1 an Empfänger1, und dann an Empfänger2 leiten.
Der Sender sendet hierbei ununterbrochen.
|
mickydoutza
Anmeldungsdatum: 31. Dezember 2010
Beiträge: 2185
|
Wenn iptables die 192.168.1.10 als destination-IP erkennt, dann versuch mal mit einer 2. DNAT-Regel, in der von 192.168.1.10 nach 192.168.1.11 umgeleitet wird.
|
muzillah
(Themenstarter)
Anmeldungsdatum: 13. Februar 2012
Beiträge: 12
|
Hi,
ich habe das versucht umzusetzen, allerdings verstehe ich nicht so recht wie das funktionieren soll.
| Wenn source-ip: 192.168.4.10 -> 192.168.4.1 über 192.168.1.1 -> 192.168.1.10
( SENDER ) ( SERVER ) ( EMPFÄNGER )
Dann kommt ja etwas von der *.*.4.10, aber es geht nach *.*.4.1 und wird nach *.*.1.10 weitergeleitet. Es kommt aber nichts von der *.*.1.10.
|
Erfolg konnten wir bisher damit verzeichnen, die entsprechende eth mit ifdown über einen bestimmten Zeitraum herunterzufahren und so einen Verbindungstimeout bzw. -abbruch zu erzwingen.
Nach erneutem Hochfahren über ifup wurden die neuen Regeln angenommen.
|
mickydoutza
Anmeldungsdatum: 31. Dezember 2010
Beiträge: 2185
|
muzillah schrieb: Blocken à la:
| sudo iptables -A FORWARD -j DROP
|
? Das funktioniert, wenn ich danach die Regeländerung durchführe und
das FORWARD wieder auf ACCEPT stelle, sendet er nur leider weiter
an die alte Adresse.
Wenn Du FORWARD auf ACCEPT lässt und nur zwischen source- und destination-IP blockst:
sudo iptables -A FORWARD -s 192.168.4.10 -d 192.168.1.10 -j DROP
|
muzillah
(Themenstarter)
Anmeldungsdatum: 13. Februar 2012
Beiträge: 12
|
sudo iptables -t nat -A PREROUTING -s 192.168.4.10 -j DNAT --to-destination 192.168.1.11
sudo iptables -A FORWARD -s 192.168.4.10 -d 192.168.1.11 -j DROP
sudo iptables -t nat -R PREROUTING 1 -s 192.168.4.10 -j DNAT --to-destination 192.168.1.10
sudo iptables -R FORWARD 1 -s 192.168.4.10 -d 192.168.1.10 -j ACCEPT
Lässt die Pakete zwar fallen, allerdings nach dem ACCEPT wieder an die 1.11 weiterleiten. Nicht an die 1.10.
|