MARKIERTE Pakete, die nicht wie erwartet routen

667
GroovyDotCom

UPDATE: Lösung: Ich hätte die OUTPUT-Kette verwenden sollen - nicht die PREROUTING-Kette. Dieses Beispiel funktioniert immer noch nicht, aber ich werde es in Kürze aktualisieren.

Dies scheint mir, als sollte es funktionieren. Ich verschiebe alle Routing-Regeln von der Haupttabelle in die Tabelle 4 und dann MARK und leite die Pakete, die an Port 80/443 gerichtet sind, in die Tabelle 4. Ich würde erwarten, dass Port 80 genauso funktioniert, als ob ich nichts getan hätte, aber Gethostbyname schlägt fehl?

#!/bin/bash -x # # Reset/Flush iptables iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT  # Reset/Flush table 4 ip route flush table 4  # move all routing rules from the main table to table 4 ip route show table main | grep -v linkdown | while read ROUTE do ip route add table 4 $ROUTE ip route del table main $ROUTE done  # MARK all HTTP(S) destination packets with a 4 iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-mark 4 iptables -t mangle -A PREROUTING -p tcp --dport 443 -j MARK --set-mark 4 iptables -t mangle -A PREROUTING -p udp --dport 53 -j MARK --set-mark 4  # packets marked as 4 find their routes via table 4 ip rule add fwmark 4 table 4 ip route flush cache
0
Ihre iptables-Regeln werden nicht erreicht, da es keine Route in der Haupttabelle gibt. Da sie nicht ausgeführt werden, werden sie niemals die Markierung setzen, um Tabelle 4 zu verwenden. Sie haben also keine Route ... Können Sie jetzt sagen, welches Problem Sie eigentlich damit lösen wollen? A.B vor 7 Jahren 1
Also muss eine Route gefunden werden, bevor das Pre-Routing ausgeführt wird. Das scheint das Falsche zu sein, da die Regel etwas tun könnte, um das Routing zu ändern (wie in meinem Fall)? GroovyDotCom vor 7 Jahren 0
Was das Problem angeht: Ich muss so etwas wie einen transparenten Proxy über ein TUN-Gerät für alle Ports außer HTTP und DNS ausführen. Das heißt, wenn eine App etwas an foo.com:22 sendet, muss sie tatsächlich auf ein TUN-Gerät gehen, und meine Proxy-App muss sie wirklich an foo.com:22 senden. Also oben nicht angezeigt ist die Standardregel in main, die alles an mein TUN-Gerät sendet. Ich habe also eine Route in der Haupttabelle, aber das hilft nicht. GroovyDotCom vor 7 Jahren 0
Okay. Ich sehe jetzt. Ich hätte die OUTPUT-Kette verwenden sollen - nicht die PREROUTING-Kette. GroovyDotCom vor 7 Jahren 0
Ich habe es auch probiert, bevor ich antwortete. Keine Änderung. Wenn keine Route vorhanden ist, wird weder das PREROUTING noch das OUTPUT verwendet. Sie sollten in TPROXY von iptables investieren und sehen, was Sie damit machen können. Oder Sie können nur die Hauptrouten beibehalten, also sollten iptables auslösen, das fwmark setzen und am Ende wird die Tabelle 4 verwendet A.B vor 7 Jahren 0

1 Antwort auf die Frage

2
A.B

iptables (und / oder netfilter) hat verschiedene Haken im Routing-Stack. Wenn ein Paket einen bestimmten Schritt im Routing-Stack durchläuft und dort ein iptables-Hook vorhanden ist, wird der iptables-Hook ausgeführt. Wenn das Paket einen solchen Schritt nicht erreicht, wird natürlich kein iptables-Hook ausgeführt. Wenn es "keine Route zum Hosten" gibt, gibt der Routing-Stack früher auf und erreicht diese Schritte nicht. Das ist, was in Ihrem Beispiel passiert, nachdem Sie die Routen der (Haupttabelle) gelöscht und eine Routing-Tabelle hinterlassen haben, die davon abhängig ist, dass iptables verwendet wird. Das ist ein Henne-und-Eier-Problem, aber es muss nicht alles so gemacht werden. Sie brauchen nur eine Route, eine beliebige Route, damit Ihre Regeln diese Route auslösen und ändern.

Ich lief dein Skript und bekam mit meinen Einstellungen:

# ip route (nothing) # ip route show table 4 default via 10.0.3.1 dev eth0  10.0.3.0/24 dev eth0 proto kernel scope link src 10.0.3.66

Die OUTPUT-Regeln hinzugefügt:

iptables -t mangle -A OUTPUT -p udp -m udp --dport 53 -j MARK --set-xmark 0x4/0xffffffff iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 53 -j MARK --set-xmark 0x4/0xffffffff iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 443 -j MARK --set-xmark 0x4/0xffffffff iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 80 -j MARK --set-xmark 0x4/0xffffffff

Nichts funktioniert.

Die LAN-Route und ein falsches, falsches Gateway 10.0.3.9 wurden hinzugefügt:

# ip route default via 10.0.3.9 dev eth0  10.0.3.0/24 dev eth0 scope link   # ip neigh flush dev eth0 # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. ^C --- 8.8.8.8 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1006ms # ip neigh 10.0.3.9 dev eth0 FAILED # ip neigh del 10.0.3.9 dev eth0 # dig +short @8.8.8.8 google.com. 172.217.22.142 # ip neigh 10.0.3.1 dev eth0 lladdr fe:d6:50:75:27:c9 REACHABLE

Beachten Sie, dass jetzt die Route aus Tabelle 4 verwendet wurde. Es brauchte aber zuerst eine Arbeitsroute ("on the paper", auch wenn sie nicht wirklich funktioniert), sonst hätte die Routing-Entscheidung allein die Anwendung der OUTPUT-Regel verhindert. Sie können es mit iptables-save -csehen, um Zähler zu sehen.

Genau richtig. Der Wechsel zu OUTPUT hat mein Problem gelöst, da ich dort eine Adresse hatte. Ich habe es in meiner Frage nicht gezeigt, weil ich versuchte, ein kleineres Beispiel für das Problem darzustellen, und mir nicht vorstellen konnte, dass dieses Detail relevant ist. Vielen Dank! GroovyDotCom vor 7 Jahren 0

Verwandte Probleme