iptables in ds26-14.3 stützt ab

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Auch bei mir führt offenbar Speichermangel zum Absturz. In /proc/net/ip_conntrack ist auffällig, daß fast alle Verbindungen (bis auf 3-4) den Status ESTABLISHED haben und der Timeout-Counter im Bereich >400000s steht - das sind ca. 4,6 Tage.
Zum Vergrößern anklicken....

Bringt es was den Wert runterzusetzen?
Code: 
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
432000
echo 1000 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

EDIT: hab gerade bei meinem PC geschaut. Dort steht auch der Standard-Wert 432000 drin. Allerdings nutze ich auf dem PC iptables nicht. Habe Modul testweise geladen.
 
Zuletzt bearbeitet:
Bin mittlerweile etwas weiter. Die Vermutung, dass der Status ESTABLISHED auch nach Beendigung der TCP-Verbindung nicht korrekt verlassen wird, scheint sich zu bestätigen.

Beispiel: Eine Pop3-Email-Abfrage von einem PC hinter der Fritzbox zeigt mit Ethereal auf dem PC den typischen 3-Wege Handshake:

Zu Beginn:
192.168.0.20:1907 -> 213.165.64.22:110 [SYN] Seq=0
213.165.64.22:110 -> 192.168.0.20:1907 [SYN, ACK] Seq=0 Ack=1
192.168.0.20:1907 -> 213.165.64.22:110 [ACK] Seq=1 Ack=1

dann die Datenverbindung
[...]

und schließlich den Verbindungsabbau:
213.165.64.22:110 -> 192.168.0.20:1907 [FIN, ACK] Seq=168 Ack=43
192.168.0.20:1907 -> 213.165.64.22:110 [ACK] Seq=43 Ack=169
192.168.0.20:1907 -> 213.165.64.22:110 [FIN, ACK] Seq=43 Ack=169
213.165.64.22:110 -> 192.168.0.20:1907 [ACK] Seq=169 Ack=44

soweit, so gut - alles wie im Lehrbuch!

Leider bleibt auf der Fritzbox die Verbindung in der ip_conntrack Tabelle bestehen:

tcp 6 431973 ESTABLISHED src=192.168.0.20 dst=213.165.64.22 sport=1907 dport=110 packets=3 bytes=143 src=213.165.64.22 dst=192.168.0.20 sport=110 dport=1907 packets=2 bytes=144 [ASSURED] mark=0 use=1

Dieser Eintrag gammelt jetzt 5 Tage vor sich hin. Daraus schließe ich: Entweder bekommt netfilter im Fritzbox-Kernel nix mit von der abgebauten Verbindung (blockiert evtl. AVM multid?) oder die Status-Verarbeitung in netfilter/ip_conntrack läuft schief.

Any ideas?

delphisailor
 
Benutzt Du den AVM-Kernel oder einen mit "Replace Kernel" selber kompilierten?

Wenn er selber-compiliert ist, dann kann es nicht sein, dass die Module "irgendwie" nicht zum Kernel passen. Anonsten wäre das eine Theorie.


Dirk
 
delphisailor, das sieht schonmal gut aus. Ich habe noch ein wenig zu dem Thema mehrere Suchmaschienen bedient. Es gab schonmal so einen Bug, allerdings ist er schon im Kernel 2.6.10 behoben (http://lists.netfilter.org/pipermail/netfilter-devel/2004-December/017908.html)
Grob gesagt, wurde damals nicht aufgeräumt, weil das FIN Paket als Invalid verworfen wurde.
Eventuell hat es wieder was mit Invalid-Paketen zu tun. im 2.6.13er Kernel läuft noch irgendwas schief, dass zu viele Pakete als Invalid erkannt werden. Such-Stichwort ip_conntrack_tcp_be_liberal . Leider gerade kein Link parat.
Kannst Du bitte deinen Test nochmal mit aktiviertem Logging der Invaliden Pakete machen? Ich kann es nicht testen, da bei mir dein Fehler nicht auftritt (Hab kein 3-Stunden-Problem :cool:).

Aktivieren des Invalid-Loggings:
Code: 
echo 1 >  /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
iptables -I OUTPUT   -m state --state INVALID  -j LOG  --log-level debug --log-prefix "OUT INVALID state -- ACCEPT "
iptables -I INPUT    -m state --state INVALID  -j LOG  --log-level debug --log-prefix "IN  INVALID state -- ACCEPT "
iptables -I FORWARD  -m state --state INVALID  -j LOG  --log-level debug --log-prefix "FWD INVALID state -- ACCEPT "
 
Das Invalid-Logging - wie von alxweb vorgeschlagen - ist eine gute Idee. Leider kam ich mit dem Logging nur bedingt weiter. Ich habe die Pakete einer POP3-Abfrage geloggt, wobei ich sowohl gültige als auch ungültige Pakete mit entsprechendem Tagging rausgeschrieben habe.

Das Log ist nicht vollständig. In einem anderen Beitrag wurde ebenfalls berichtet, dass beim Paket-Logging Einträge verloren gehen. Die fehlenden Zeilen habe ich PC-seitig mit Ethereal rekonstruiert.

Code: 
01 FWD VALID state -- ACCEPT IN=eth0 OUT=dsl SRC=192.168.0.20 DST=213.165.64.22 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=43522 DF PROTO=TCP SPT=1327 DPT=110 WINDOW=64960 RES=0x00 SYN URGP=0
02 FWD VALID state -- ACCEPT IN=dsl OUT=eth0 SRC=213.165.64.22 DST=192.168.0.20 LEN=48 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=110 DPT=1327 WINDOW=5840 RES=0x00 ACK SYN URGP=0 
03 FWD VALID state -- ACCEPT IN=eth0 OUT=dsl SRC=192.168.0.20 DST=213.165.64.22 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=43523 DF PROTO=TCP SPT=1327 DPT=110 WINDOW=65340 RES=0x00 ACK URGP=0 
04 FWD VALID state -- ACCEPT IN=dsl OUT=eth0 SRC=213.165.64.22 DST=192.168.0.20 LEN=97 TOS=0x00 PREC=0x00 TTL=54 ID=31933 DF PROTO=TCP SPT=110 DPT=1327 WINDOW=5840 RES=0x00 ACK PSH URGP=0 
05 FWD VALID state -- ACCEPT IN=eth0 OUT=dsl SRC=192.168.0.20 DST=213.165.64.22 LEN=55 TOS=0x00 PREC=0x00 TTL=127 ID=43528 DF PROTO=TCP SPT=1327 DPT=110 WINDOW=65283 RES=0x00 ACK PSH URGP=0 
06 fehlt
07 fehlt
08 FWD INVALID state -- ACCEPT IN=eth0 OUT=dsl SRC=192.168.0.20 DST=213.165.64.22 LEN=55 TOS=0x00 PREC=0x00 TTL=127 ID=43533 DF PROTO=TCP SPT=1327 DPT=110 WINDOW=65244 RES=0x00 ACK PSH URGP=0 
09 fehlt
10 FWD INVALID state -- ACCEPT IN=eth0 OUT=dsl SRC=192.168.0.20 DST=213.165.64.22 LEN=46 TOS=0x00 PREC=0x00 TTL=127 ID=43538 DF PROTO=TCP SPT=1327 DPT=110 WINDOW=65214 RES=0x00 ACK PSH URGP=0 
11 fehlt
12 FWD INVALID state -- ACCEPT IN=eth0 OUT=dsl SRC=192.168.0.20 DST=213.165.64.22 LEN=46 TOS=0x00 PREC=0x00 TTL=127 ID=43624 DF PROTO=TCP SPT=1327 DPT=110 WINDOW=65205 RES=0x00 ACK PSH URGP=0 
13 fehlt
14 FWD INVALID state -- ACCEPT IN=dsl OUT=eth0 SRC=213.165.64.22 DST=192.168.0.20 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=31939 DF PROTO=TCP SPT=110 DPT=1327 WINDOW=5840 RES=0x00 ACK FIN URGP=0 
15 FWD INVALID state -- ACCEPT IN=eth0 OUT=dsl SRC=192.168.0.20 DST=213.165.64.22 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=43640 DF PROTO=TCP SPT=1327 DPT=110 WINDOW=65172 RES=0x00 ACK URGP=0 
16 FWD INVALID state -- ACCEPT IN=eth0 OUT=dsl SRC=192.168.0.20 DST=213.165.64.22 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=43645 DF PROTO=TCP SPT=1327 DPT=110 WINDOW=65172 RES=0x00 ACK FIN URGP=0

Bis Zeile 5 ist alles OK, ab da werden die Pakete nur noch als INVALID getaggt. Damit wird auch FIN nicht erkannt und der conntrack-Eintrag bleibt bestehen.

Angenommen, die fehlenden Einträge tun nix zur Sache und sind nur im Log verloren gegangen (schließlich wurde der POP3-Transfer ordnungsgemäß durchgeführt), dann stellt sich die Frage, warum ab einem bestimmten Zeitpunkt der Verbindung die Pakete als INVALID erkannt werden. Irgendwo im IPPF war mal was von QoS und Fair Queuing gesagt, doch ein Kernel mit ausgeschaltetem CONFIF_NET_SCHED führte zur Recovery der Fritzbox, die zwar offenbar hochfuhr, aber an keinem IF IP-Pakete annahm.

Wo könnte man die Ursache für die INVALIDs finden?

delphisailor
 
Hast Du es schon mit "echo 1 >/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal" versucht? (s.o.)

Bei mir scheint jetzt alles zu gehen, bis auf fehlende Log-Zeilen. Ich habe aber auch eine andere Box und einen anderen Mod.


Dirk
 
Im 2.6.9-er Kernel wurde die Erkennung des out-of Window "verbessert". Dadurch fallen fast alle Pakete als Out-of-Window in invalid state. Genau habe ich das Problem auch nicht verstanden. Das umschalten auf die "Alte" Erkennung geht mit

echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal

Paar Links dazu:
http://lists.netfilter.org/pipermail/netfilter-devel/2005-September/021438.html
http://www.archivum.info/netfilter/2006-05/msg00235.html
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.9 [NETFILTER]: Add tcp window tracking
Das Thema wurde schon bei Problem mit iptables auf der SL WLAN erwähnt.
 
Danke für Eure Antworten!

Code: 
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal

habe ich schon seit 2 Wochen gesetzt. Das bringt zwar eine deutliche Verbesserung, gelöst ist das Problem damit jedoch nicht - zumindest nicht vollständig. Die Reboots wegen Speichermangel auf Grund der zu großen Conntrack-Table kommen zwar nicht mehr alle 3-4h, aber immer noch 1-2 Mal pro Tag.
 
Du loggst zwar jetzt die invalid-Pakete, lässt sie jedoch durch. Ich kann es mir gut vorstellen, dass wenn invalid-Pakete gedropt werden, dass der dazuge Eintrag in der conntrack-Tabelle gelöscht wird. Bei mir werden alle invalid-Pakete gedropt und die conntrack-Tabelle ist sauber.

also, teste nochmal mit
Code: 
echo 1 >  /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
iptables -I OUTPUT   -m state --state INVALID  -j DROP 
iptables -I OUTPUT   -m state --state INVALID  -j LOG  --log-level debug --log-prefix "OUT INVALID state -- ACCEPT "
iptables -I INPUT    -m state --state INVALID  -j DROP
iptables -I INPUT    -m state --state INVALID  -j LOG  --log-level debug --log-prefix "IN  INVALID state -- ACCEPT "
iptables -I FORWARD  -m state --state INVALID  -j DROP 
iptables -I FORWARD  -m state --state INVALID  -j LOG  --log-level debug --log-prefix "FWD INVALID state -- ACCEPT "

EDIT: Hier ist vorher ein echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal pficht, da man an sonsten nichtmal auf die FB kommt, da fast die gesamte Kommunikation "invalid" ist.
 
Zuletzt bearbeitet:
Zwischenzeitlich habe ich nochmal eine original AVM-Firmware als Referenz probiert. Ergebnis: Auch mit AVM's SW bricht die Internet-Verbindung 1-2 mal pro Tag ab (unabhängig von der Zwangstrennung natürlich).

Damit scheint die Ursache woanders zu liegen und das iptables-Problem sehe ich mit ip_conntrack_tcp_be_liberal=1 als gelöst an. Zumindest konnte ich mit einer frisch übersetzten ds26-15.2 die überlaufende conntrack-Tabelle nicht mehr in flagranti erwischen.

Vielen Dank für Eure Hilfe! The fun has just begun!

delphisailor
 
Ich hab einen Kernelpatch in r2016 eingecheckt, der den hashsize fest auf 256 setzt und be_liberal auf eins setzt (Tut er doch hoffentlich!?).

MfG Oliver
 
Ich habe das mal ausprobiert. Allerdings bleibt er (auch nach make kernel-dirclean) bei make an folgender Stelle stehen:
Code: 
*
* Linux Kernel Configuration
*
*
...
    *
    * Core Netfilter Configuration
    *
    Netfilter netlink interface (NETFILTER_NETLINK) [N/m/y/?] n
    Netfilter Xtables support (required for ip_tables) (NETFILTER_XTABLES) [M/n/y/?] m
      "CLASSIFY" target support (NETFILTER_XT_TARGET_CLASSIFY) [M/n/?] m
      "DSCP" target support (NETFILTER_XT_TARGET_DSCP) [N/m/?] n
      "MARK" target support (NETFILTER_XT_TARGET_MARK) [M/n/?] m
      "NFQUEUE" target Support (NETFILTER_XT_TARGET_NFQUEUE) [M/n/?] m
      "NOTRACK" target support (NETFILTER_XT_TARGET_NOTRACK) [N/m/?] (NEW)
mit Enter habe ich ihn mal weiter machen lassen.

Mir fehlen unter build/modified/filesystem immer noch xt_tcpudp.ko xt_conntrack.ko xt_multiport.ko xt_state.ko u.a. (EDIT)

Von be_liberal sehe ich in dem Changeset nichts, ist aber doch tatsächlich gesetzt. Wo(durch) passiert das?

Ob alles noch stabil ist, kann ich wohl erst in ein paar Stunden beurteilen.


Dirk
 
Zuletzt bearbeitet:
dsteinkopf schrieb:
Von be_liberal sehe ich in dem Changeset nichts, ist aber doch tatsächlich gesetzt. Wo(durch) passiert das?
Zum Vergrößern anklicken....

Genau dort. Aus der Revision 2016. Wird aus irgendeinem Grund nur nicht im trac angezeigt.

Code: 
cat ~cinereous/trunk/make/linux/patches/2.6.19.2/200-ip_conntrack.patch |grep liberal
     be liberal in what you accept from others."
-int ip_ct_tcp_be_liberal __read_mostly = 0;
+int ip_ct_tcp_be_liberal __read_mostly = 1;
 
delphisailor schrieb:
Code: 
...
05 FWD [B]VALID[/B] state -- ACCEPT IN=eth0 OUT=dsl SRC=192.168.0.20 DST=213.165.64.22 LEN=55 TOS=0x00 PREC=0x00 TTL=127 ID=43528 DF PROTO=TCP SPT=1327 DPT=110 WINDOW=65283 RES=0x00 ACK PSH URGP=0 
06 fehlt
07 fehlt
08 FWD [B]INVALID[/B] state -- ACCEPT IN=eth0 OUT=dsl SRC=192.168.0.20 DST=213.165.64.22 LEN=55 TOS=0x00 PREC=0x00 TTL=127 ID=43533 DF PROTO=TCP SPT=1327 DPT=110 WINDOW=65244 RES=0x00 ACK PSH URGP=0

Angenommen, die fehlenden Einträge tun nix zur Sache
Zum Vergrößern anklicken....

Ich finde, das ist doch eine sehr gewagte Annahme. Da zunächst alles gut aussieht, dann Pakete fehlen, dann die nächsten Pakete als Invalid markiert sind, ist es auch gut möglich, daß gerade die fehlenden Pakete der Grund dafür sind, daß dies passiert. Ein einmaliges Auftreten ist dafür natürlich noch kein Beweis, aber da Du schon den kompletten Aufbau dafür hast, könntest Du es mehrmals laufen lassen und überprüfen.
 
dsteinkopf schrieb:
Mir fehlen unter build/modified/filesystem immer noch xt_tcpudp.ko xt_conntrack.ko xt_multiport.ko xt_state.ko u.a.
Zum Vergrößern anklicken....
Warum gibts da in der modules.dep keine Abhängigkeiten? Wie sehe ich denn die Abhängigkeiten wenn nicht dort?

MfG Oliver
 
olistudent schrieb:
Warum gibts da in der modules.dep keine Abhängigkeiten? Wie sehe ich denn die Abhängigkeiten wenn nicht dort?
Zum Vergrößern anklicken....
Weil in der modules.dep nur die Abhängigkeiten zwischen den Modulen stehen (können). Die von mir "vermissten" Module werden aber nur von iptables-Regeln benötigt. Ich nehme an, bei Kerneln mit Module-Autoloading werden die dann auch automatisch geladen - jedenfalls ist es ja bei einem "richtigen" Linux so. Ich habe nur experimentell festgestellt, dass dies die Kernel-Module sind, die ich brauche, damit ich meine iptables-Regeln absetzen kann.

Ähnliches gilt vermutlich auch für die entsprechenden Shared-Libs, aber da hatte ich bisher kaum Probleme.

P.S. Nach knapp 5 Stunden Uptime scheint noch alles ok. /proc/net/ip_conntrack ist rel. kurz (33 Einträge). Kein Absturz.

P.P.S. Danke, dass Du dich so geduldig darum kümmerst.


Dirk
 
delphisailor schrieb:
Zwischenzeitlich habe ich nochmal eine original AVM-Firmware als Referenz probiert. Ergebnis: Auch mit AVM's SW bricht die Internet-Verbindung 1-2 mal pro Tag ab (unabhängig von der Zwangstrennung natürlich).

Damit scheint die Ursache woanders zu liegen und das iptables-Problem sehe ich mit ip_conntrack_tcp_be_liberal=1 als gelöst an. Zumindest konnte ich mit einer frisch übersetzten ds26-15.2 die überlaufende conntrack-Tabelle nicht mehr in flagranti erwischen.
Zum Vergrößern anklicken....

Kommando zurück:
Während es sich bei den Abbrüchen mit der AVM-Firmware "nur" um ein Problem mit der Internet-Verbindung handelt (Box läuft nämlich durch), sind die Abbrüche mit der ds26-15.2-Firmware echte Box-Reboots.
Damit sind die Ursachen der beiden Ereignisse doch nicht identisch, obwohl die Wirkung ähnlich ist.

Eigentlich brauche ich iptables nur, um das WLAN-Interface als reinen Gast-Internet-Zugang zu konfigurieren und keinen Zugriff auf Fritzbox und internes Netz zu erlauben. Connection Tracking ist dafür im Prinzip nicht notwendig.

Also habe ich mal ip_conntrack, ip_conntrack_ftp und ipt_state entfernt und betreibe netfilter jetzt als reinen zustandslosen Filter. Das Ergebnis: Während der letzten 48h habe ich keine Reboots feststellen können.

delphisailor
 
Mit meiner 7170 29.04.37ds26-15.2

mache ich beim booten folgendes:


echo 1 >/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
echo 1 >/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
iptables -I OUTPUT -m state --state INVALID -j DROP
iptables -I OUTPUT -m state --state INVALID -j LOG --log-level debug --log-prefix "OUT INVALID state -- ACCEPT "
iptables -I INPUT -m state --state INVALID -j DROP
iptables -I INPUT -m state --state INVALID -j LOG --log-level debug --log-prefix "IN INVALID state -- ACCEPT "
iptables -I FORWARD -m state --state INVALID -j DROP
iptables -I FORWARD -m state --state INVALID -j LOG --log-level debug --log-prefix "FWD INVALID state -- ACCEPT "

#Die oberen Zeilen habe ich aus diesem Thread. Die 3 unten sind der eigentliche Grund warum ich iptables nutze. Ich möchte die Cisco-VPN Tunnel tun0 mit meinem internen LAN verbinden.


iptables -A FORWARD -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Trotzdem die 3 Stunden abstürze.

cat /proc/net/ip_conntrack | wc -l zeigt jetzt nach knapp über 3 Stunden gerade mal 16 Einträge.

:-(
 
Da du noch dsmod nutzt, wird bei dir die hashsize doch garnicht auf 256 gesetzt :confused:
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Keine Mitglieder online.
Gesamt: 503 (Mitglieder: 0, Gäste: 503)

Neueste Beiträge

Statistik des Forums

Themen
246,167
Beiträge
2,247,306
Mitglieder
373,705
Neuestes Mitglied
brunomuehl
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück