[Erledigt] iptables und conntrack

[borgx]

Du solltest Dir mal die Doku zu netfilter durchlesen. Der -o-Schalter bestimmt den Filter für das Output-Device, sprich: die konkrete Regel wird verwendet, wenn Pakete in Richtung Output-Device geroutet werden. Im von mir erwähnten Fall ins WAN (via DSL).

root@fritz:/var/mod/root# iptables -t nat -A PREROUTING -p tcp -i lan -o dsl --dport 80 -j REDIRECT --to 443
iptables v1.4.11.1: Can't use -o with PREROUTING

Ich hatte es schon so verstanden, dass mit -j REDIRECT niemals irgendwas ins WAN geht. Werde mal versuchen, mehr Pakete (in PREROUTING und POSTROUTING) zu loggen, um das ursprüngliche Problem etwas einzugrenzen.

 

[JohnDoe42]

iptables v1.4.11.1: Can't use -o with PREROUTING

Okay, da hab' ich wohl die Kombi PREROUTING/REDIRECT mit DNAT verwechselt .... und wieder was gelernt.
Trotzdem sollten wir die Frage klären, ob die Box mit vollem NAT (also geladenem und durch entsprechende Regeln benutztem nf_nat) stabil läuft oder nicht.
Ein sinnvoller Test, welcher relativ schnell eine Instabilität belegt, wäre ein Privoxy auf der Box und selbiger transparent benutzt (eben mittels der REDIRECT-Regel).
Dies leitet sämtlichen Verkehr aus dem LAN auf einen anderen Port um und führt ggfs. zeitnah zu einem Reboot.

 

[borgx]

[EDIT:Hätte ich mal die FAQ besser verinnerlicht. Die Erklärung steht da ja schon: http://freetz.org/wiki/FAQ#Funktioniertiptablesnatconntrack]

Ich habe den Eindruck, dass es mit vollem NAT kaum gehen wird, weil es schon gravierende Probleme mit conntrack gibt. Schon die Nutzung von conntrack scheint in jedem Fall nach wenigen Stunden zu einem Reboot zu führen. Auch scheint es schon vorher falsche Daten zu liefern (s.o.). Möglicherweise hängen falsche Daten und Reboot ja zusammen. Ich habe mir mal als Beispiel ein paar Pakete einer Mail-Server-Kommunikation angesehen. Das Problem könnte sein, dass netfilter auf der Fritzbox nicht alle Pakete sieht (?). Hier ein Dump der ersten zehn Pakate (von 21) auf dem Client-PC (alles in Ordnung):

[B]01:22:51.685796 IP onario.fritz.box.53207 > imap.1und1.de.imaps: Flags [S], seq 1674748018, win 29200, options [mss 1460,sackOK,TS val 22530306 ecr 0,nop,wscale 7], length 0
01:22:51.704218 IP imap.1und1.de.imaps > onario.fritz.box.53207: Flags [S.], seq 3581039539, ack 1674748019, win 14480, options [mss 1452,sackOK,TS val 3686763402 ecr 22530306,nop,wscale 9], length 0
01:22:51.704298 IP onario.fritz.box.53207 > imap.1und1.de.imaps: Flags [.], ack 1, win 229, options [nop,nop,TS val 22530324 ecr 3686763402], length 0[/B]
[B]01:22:51.704847 IP onario.fritz.box.53207 > imap.1und1.de.imaps: Flags [P.], seq 1:209, ack 1, win 229, options [nop,nop,TS val 22530325 ecr 3686763402], length 208
01:22:51.726156 IP imap.1und1.de.imaps > onario.fritz.box.53207: Flags [.], ack 209, win 31, options [nop,nop,TS val 3686763407 ecr 22530325], length 0[/B]
01:22:51.733602 IP imap.1und1.de.imaps > onario.fritz.box.53207: Flags [.], seq 1:1441, ack 209, win 31, options [nop,nop,TS val 3686763408 ecr 22530325], length 1440
[B]01:22:51.733686 IP onario.fritz.box.53207 > imap.1und1.de.imaps: Flags [.], ack 1441, win 251, options [nop,nop,TS val 22530354 ecr 3686763408], length 0[/B]
01:22:51.733724 IP imap.1und1.de.imaps > onario.fritz.box.53207: Flags [.], seq 1441:2881, ack 209, win 31, options [nop,nop,TS val 3686763408 ecr 22530325], length 1440
01:22:51.733744 IP onario.fritz.box.53207 > imap.1und1.de.imaps: Flags [.], ack 2881, win 274, options [nop,nop,TS val 22530354 ecr 3686763408], length 0
01:22:51.735051 IP imap.1und1.de.imaps > onario.fritz.box.53207: Flags [.], seq 2881:4321, ack 209, win 31, options [nop,nop,TS val 3686763408 ecr 22530325], length 1440

Auf der Fritzbox sieht tcpdump mit dem gleichen Aufruf anstatt der 21 Pakete nur 6 (zur Orientierung sind die passenden Pakete oben fett geschrieben):

01:22:51.683378 IP onario.fritz.box.53207 > imap.1und1.de.993: Flags [S], seq 1674748018, win 29200, options [mss 1460,sackOK,TS val 22530306 ecr 0,nop,wscale 7], length 0
01:22:51.700493 IP imap.1und1.de.993 > onario.fritz.box.53207: Flags [S.], seq 3581039539, ack 1674748019, win 14480, options [mss 1452,sackOK,TS val 3686763402 ecr 22530306,nop,wscale 9], length 0
01:22:51.701753 IP onario.fritz.box.53207 > imap.1und1.de.993: Flags [.], ack 1, win 229, options [nop,nop,TS val 22530324 ecr 3686763402], length 0
01:22:51.702627 IP onario.fritz.box.53207 > imap.1und1.de.993: Flags [P.], seq 1:209, ack 1, win 229, options [nop,nop,TS val 22530325 ecr 3686763402], length 208
01:22:51.722368 IP imap.1und1.de.993 > onario.fritz.box.53207: Flags [.], ack 209, win 31, options [nop,nop,TS val 3686763407 ecr 22530325], length 0
01:22:51.731445 IP onario.fritz.box.53207 > imap.1und1.de.993: Flags [.], ack 1441, win 251, options [nop,nop,TS val 22530354 ecr 3686763408], length 0

Und konsequenterweise markiert conntrack alle Pakete nach einem verpassten als INVALID:

Dec  6 01:22:51 fritz kern.warn kernel: [IPT] NEW IN=lan OUT=dsl SRC=192.168.178.21 DST=212.227.15.171 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=26992 DF PROTO=TCP SPT=53207 DPT=993 WINDOW=29200 RES=0x00 SYN URGP=0 MARK=0x10 
Dec  6 01:22:51 fritz kern.warn kernel: [IPT] ESTABLISHED IN=dsl OUT=lan SRC=212.227.15.171 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=993 DPT=53207 WINDOW=14480 RES=0x00 ACK SYN URGP=0 
Dec  6 01:22:51 fritz kern.warn kernel: [IPT] ESTABLISHED IN=lan OUT=dsl SRC=192.168.178.21 DST=212.227.15.171 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=26993 DF PROTO=TCP SPT=53207 DPT=993 WINDOW=229 RES=0x00 ACK URGP=0 MARK=0x10 
Dec  6 01:22:51 fritz kern.warn kernel: [IPT] ESTABLISHED IN=lan OUT=dsl SRC=192.168.178.21 DST=212.227.15.171 LEN=260 TOS=0x00 PREC=0x00 TTL=63 ID=26994 DF PROTO=TCP SPT=53207 DPT=993 WINDOW=229 RES=0x00 ACK PSH URGP=0 MARK=0x10 
Dec  6 01:22:51 fritz kern.warn kernel: [IPT] ESTABLISHED IN=dsl OUT=lan SRC=212.227.15.171 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=55354 DF PROTO=TCP SPT=993 DPT=53207 WINDOW=31 RES=0x00 ACK URGP=0 
Dec  6 01:22:51 fritz kern.warn kernel: [IPT] INVALID IN=lan OUT=dsl SRC=192.168.178.21 DST=212.227.15.171 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=26995 DF PROTO=TCP SPT=53207 DPT=993 WINDOW=251 RES=0x00 ACK URGP=0 MARK=0x10

Hier der Filter:

root@fritz:/var/mod/root# iptables -vnL
Chain INPUT (policy ACCEPT 7041 packets, 1184K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 14308 packets, 1675K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   52  3681 TRANS      all  --  *      *       0.0.0.0/0            212.227.15.171      
   43  3279 TRANS      all  --  *      *       212.227.15.171       0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 5699 packets, 833K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain TRANS (2 references)
 pkts bytes target     prot opt in     out     source               destination         
   30  2424 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate ESTABLISHED LOG flags 0 level 4 prefix "[IPT] ESTABLISHED "
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED LOG flags 0 level 4 prefix "[IPT] RELATED "
    5   300 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate NEW LOG flags 0 level 4 prefix "[IPT] NEW "
   60  4236 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID LOG flags 0 level 4 prefix "[IPT] INVALID "
   95  6960 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
root@fritz:/var/mod/root#

 

[PeterPawn]

Das liegt an der "packet acceleration". Was die macht, was die kann und wie man sie in Grenzen beeinflussen kann, findest Du mit C-Kenntnissen und einiger Zeit, die man investieren muß, in den Kernel-Quellen von AVM.

Die Kommandos zur Steuerung über das proc-Interface findet man in der Datei 'avm_pa.c'.

Ich würde an Deiner Stelle mal probieren (habe es selbst aber nicht getestet, alles nur Theorie, jedenfalls was den Effekt des Ganzen betrifft), ob mit einem "echo hw_disable >/proc/net/avm_pa/control" (Kontrolle mit "cat /proc/net/avm_pa/brief") das Ausschalten der Hardware-Beschleunigung schon ausreichend ist, damit alle Pakete auch am IP-Stack vorbeikommen und nicht direkt durchgereicht werden von Interface zu Interface. Den "Holzhammer" mit "disable" für alles würde ich nicht auspacken, ich bin mir nicht sicher, ob damit nicht die komplette Paketfilterung (also die stateful firewall) auch gekillt wird. Wenn ja, muß man wirklich alles in iptables "neu erfinden", ob das überhaupt machbar ist (eben wg. conntrack), weiß ich auch (noch) nicht.

Ich habe jetzt nicht geprüft, was Du für ein Modell verwendest und ob es da das Interface überhaupt schon gibt ... ich testete (die Möglichkeit des Ein-/Ausschaltens der HW-Beschleunigung, nicht den Effekt) mit 113.06.20 (also 7490).

 

[borgx]

Noch ein abschließendes Wort dazu: Es ist also kein Bug, dass contrack nicht geht, sondern das Design des Packet Accelerators. Um das zu verbessern, müsste man theoretisch den Linux-netfilter im PA neu implementieren. Was nicht nur für Einzelpersonen wie mich utopisch sein dürfte.

Da ich PA wahrscheinlich gar nicht brauche, habe ich es entsprechend der FAQ (nur wenn man auf deutsch schaltet) mit "echo disable >/proc/net/avm_pa/control" testweise abgeschaltet. Damit scheinen die invalid States schon weniger zu werden, es gibt aber offenbar immer noch zu viele. (hw_disable scheint auf meiner 7270v2 eher gar nichts zu tun.) Nach ein paar Tagen hat die FB nicht mehr auf ARP requests geantwortet und ich wusste mir nur mit einem Neustart zu helfen. Ich werde dann wohl auf conntrack auf der FB verzichten müssen.

Vielleicht später mal ein neues Thema aufmachen "Wie sichert man vernünftigerweise einen kleinen, vom Internet aus zugreifbaren Server?"...

Danke für die Antworten. Die haben mich schon ein ganzes Stück weiter gebracht.

 

[RalfFriedl]

Es ist also kein Bug, dass contrack nicht geht, sondern das Design des Packet Accelerators.

Ich denke nicht, dass es das Ziel war, dass conntrack nicht mehr geht, sondern nur dass es AVM egal ist. Von daher würde ich es doch als Bug und nicht als Design bezeichnen.