Zu meinem – aus meiner Sicht nach wie vor viel zu milden – Alice-Bashing noch ein Nachtrag, wat mut, dat mut: Donnerstag Nachmittag rief die Alice-(Kriesen-?)Kundenbetreuung an, um mit den Auftraggeberinnen zu sprechen. Quintessenz war dann wohl, daß das Einschreiben doch schon durch die Alice-internen Abläufe nach oben gespühlt wurde (ich glaube, die Frist war da zwei(?) Wochen abgelaufen?) und man sich für den Ablauf zu entschuldigen suchte. (Einsehend, daß man einen Monat Unerreichbarkeit schwerlich ungeschehen machen könne; immerhin.) Mit kleinen Erlaß-Gesten und einer »beschleunigten« Alice-Mobile-Bestellungs-Ausführung möchte man die Wogen glätten.
Kommentar: ich finde es erschreckend, wie langsam diese Mühlen mahlen, insbesondere, wenn ich bedenke, daß ich seit Abschaltung des Analog- und Nichtschaltung des Alice-Anschlusses in der ersten Woche fast täglich, in der zweiten schriflich und müdlich im Wechsel keinen Hehl aus der Unzumutbarkeit des Verhaltens von Alice seinem Kunden gegenüber gemacht habe. Und ich muß leider davon ausgehen, daß ohne das Einschreiben mit Rückschein es nicht einmal diesen Anruf – der ja auch nichts ungeschehen machen kann; immerhin schien man das verstanden zu haben – gekommen wäre. Nunja. Mitte nächster Woche sind zwei Wochen rum, ich bin gespannt, ob die angeblich automatische Schaltung des ADSL2+-16-MBit-Profils auch wirklich stattfindet (und wie; das Modem trennt die DSL-Verbindung ja nicht von sich aus, und da am DSL die NGN-Telefonie hängt, würde ich ja schon erwarten, daß man die Schaltung mit dem Anschlußinhaber koordiniert, damit keine telefonische Unerreichbarkeit aufgrund von DSL-Problemen resultiert. Aber auch hier fokussiere ich wahrscheinlich zu sehr auf die Kundeninteressen …).
Daily Archives: 2009-07-23
ip_conntrack my $whatever
*sigh* Das hat jetzt doch etwas gedauert.
Lessons learned 1: Nicht noch schnell vor’m Schlafengehen eine zweite Kiste aufsetzen mit munterem copy-and-paste der Konfiguration.
Nicht alles, was außerhalb des LANs sinnvoll ist, funktioniert genausogut innerhalb des LANs; also zum Beispiel jetzt das lokale Netz über den OpenVPN-Tunnel zu jagen ist i. d. R. kontraproduktiv und führt zu sehr selektiver Dysfunktion … Nicht wirklich hilfreich ist es ferner, diese Tunnel mit identischen (war ja nur’n schneller Test) Credentials aufzubauen und munter IP- und Socket-Adressen mit bestehenden Tunneln zu verzwurbeln. Da wird dann der Tunnel einseitig established, dank des identischen Schlüssels kommen auch Pakete an; leider auf dem falschen Tunnelendpunkt, die Kommunikation war arg einseitig.
Lessons learned 2: NAT ist böse. Also nicht so böse, wie IPv6-Protaginisten z. B. bei Heise schreiben, aber schon böse, wenn ip_conntrack lustig auf die alte T-Online-IP nattet, obwohl das schon die von (Vor-)Vorgestern ist.
tcpdump auf Fritz!Boxen hat schon was; da sieht man dann endlich, daß die Pakete, die auf dem Tunnelgegenüber rausgehen, nicht ankommen. Und wenn man dann – mit etwas Ruhe – dann darauf kommt, daß man irgendwo in der Tunnelaufbauphase wohl gucken muß, warum die Pakete, die lt. tcpdump auf dem Tunnelendpunkt von der Fritz!Box ankommen und mit korrekten Antwort-IP auch wieder in diesem Tunnel zur Fritz!Box verschwinden, letztlich nicht im Tunnel auf der FB ankommen.
Skizze? Skizze:
LAN ppp0 RZ-LAN [Fritz!Box_________[Router]________[Internet]________[OpenVPN-Server] \_________________________________________________/ OpenVPN-Tunnel 192.168.5.248 zu 195.... (ovpn: ifconfig 192.168.44.8 192.168.44.9)
Eigentlich simpel das Ganze. Die Fritz!Box baut einen OpenVPN-Tunnel auf, sie hat im LAN eine RFC1918-Adresse. Der Router (angejahrtes full-blown-Linux-System, Kernel 2.4) macht für die RFC1918-Adressen ein SNAT auf die aktuelle ppp0-IP (via /etc/ppp/ip-*.local) und schickt das Paket auf Reisen über ppp0. Auf dem OpenVPN-Server hat – für dieses Szenario – jede Verbindung ihren eigenen OpenVPN-Daemon und mithin ein dediziertes Socket, sprich IP & Port. Kommuniziert wird normalerweise über UDP, fallweise auch mal über TCP. Rennt hammergeil – eigentlich. Nur die Fritz!Box, die ich zwischen T-ISDN und meinen heimischen S0-Bus gehängt habe und die nun auch lustige VoIP-Geschichet, teils zu anderen FBs, teils über einen zentralen Asterisk, macht plötzlich Probleme.
Gut, nach längeren Suchen stieß ich drauf, daß zwei Routen zum gleichen Ziel, eines directly connected, eines über den Tunnel (der über das directly connected LAN liefe) eher kontraproduktiv sind (Lesson 1).
Jetzt aber, ums verrecken tut der eine Tunnel nicht, der zum obigen Setup. (Die FB unterhält noch einen zweiten Tunnel zum zentralen Asterisk, primär um SIP durch die NAT-Welt da draußen zu bekommen, sekundär aber auch zwecks Erhöhung der Privatheit der Kommunkation. Anyway, der Tunnel rannte schon immer.)
Nach langem Gedumpe kam ich dann drauf zu verifizieren, ob denn der Tunnelaufbau überhaupt klappt oder ich vielleicht an völlig falscher Stelle debugge. Und irgendwann fiel’s mir wie Schuppen aus den Haaren: die Pakete gehen korrekt raus. Äh, halt, da stimmt doch die IP der anderen Tunnelseite nicht‽
08:42:18.273448 IP 195....10000 > 93.217.189.219.10000: UDP, length 60
Tja, leider; mittlerweile hatte es mind. 1 Zwangstrennung gegeben, aber davon wollte ip_conntrack nichts wissen:
root@router:~ # grep 189.219 /proc/net/ip_conntrack tcp 6 137482 CLOSE_WAIT src=192.168.5.108 dst=XX.XXX.XX.XXX sport=36553 dport=443 src=XX.XXX.XX.XXX dst=93.217.189.219 sport=443 dport=36553 [ASSURED] use=1 tcp 6 101822 CLOSE_WAIT src=192.168.5.108 dst=XXX.XX.XXX.XXX sport=36398 dport=5228 src=XXX.XX.XXX.XXX dst=93.217.189.219 sport=5228 dport=36398 [ASSURED] use=1 tcp 6 94463 CLOSE_WAIT src=192.168.5.108 dst=XX.XXX.XX.XXX sport=60622 dport=443 src=XX.XXX.XX.XXX dst=93.217.189.219 sport=443 dport=60622 [ASSURED] use=1 tcp 6 137480 CLOSE_WAIT src=192.168.5.108 dst=XX.XXX.XX.XXX sport=52715 dport=80 src=XX.XXX.XX.XXX dst=93.217.189.219 sport=80 dport=52715 [ASSURED] use=1 tcp 6 322804 ESTABLISHED src=192.168.5.108 dst=XXX.XX.XXX.XXX sport=53735 dport=5228 src=XXX.XX.XXX.XXX dst=93.217.189.219 sport=5228 dport=53735 [ASSURED] use=1 udp 17 172 src=192.168.5.247 dst=195... sport=10000 dport=10000 src=195... dst=93.217.189.219 sport=10000 dport=10000 [ASSURED] use=1 [...]
Unter anderem die OpenVPN-Links standen noch munter mit der alten externen IP dort; wieso einige TCP-Verbindungen angeblich noch ESTABLISHED sein sollen, wo doch die externe IP nun ganz woanders endet – ich weiß es nicht. Tendentiell wäre das mit TCP schon aufgeflogen, da der Tunnel sich nicht hätte aufbauen können (Three-Way-Handshake); da ich aber UDP nutze, bekommt der OpenVPN-Server ein gültiges Paket von der falschen (falsch genatteten) Adresse, das reicht für den Tunnelaufbau. Pakete von der Fritz!Box kamen auch an, nur die Antwortpakete gingen an die falsche Zieladresse — was OpenVPN auch berichtete:
Jul 23 07:58:50 azrael openvpn[4711]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Lessons learned 3: Auch mal ‘nen Layer hochschauen. Wenn der Tunnel einseitig tut, nicht im Tunnel den Fehler suchen oder im Routing oder vermuteten Filtern, sondern auch mal ins syslog gucken …
Eigentlich war jede Info da; es hätte schneller gehen müssen, aber so ist das, wenn schon verkorkst, dann richtig :( Der Trigger für mich war die syslog-Meldung (nach Neustart des Tunnels auf der Britz!Box):
Jul 23 07:58:50 azrael openvpn[4711]: Peer Connection Initiated with 93.217.189.219:10000 Jul 23 07:58:50 azrael openvpn[4711]: Initialization Sequence Completed Jul 23 07:58:50 azrael openvpn[4711]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Also Verbindung hergestellt und sofort wieder EHOSTUNREACH, wie kann das sein, zumal Pakete reinkommen?
Die Überprüfung der iptables-Einstellungen ergab … nichts; da war die korrekte IP als SNAT-Ziel eingestellt. Also ab, herausfinden, wie das NATing eigentlich funktioniert und auf /proc/net/ip_conntrack gestoßen. Nach längerem Googlen stellte sich einerseits heraus, daß sowas wohl gelegentlich vorkommt beim 2.4er Kernel, bei 2.6 wird derlei wohl wieder anders gehandhabt. Und die oft propagierte Lösung lautet: Modul entladen — was bei einem Router mit n Interfaces nur wegen der technisch unnötigen T-Online-24h-Zwangstrennung eher no go ist.
Zum Glück fand’ sich ein Lösungsansatz aus 2005 (für jemanden, der das Problem mit seinem OpenWRT-Router offensichtlich auch hat); ich habe ihn ausprobiert …
UDPTO=`cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout`; UDPTOSTREAM=`cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream` ; echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream && echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout && sleep 10 && echo ${UDPTOSTREAM} > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream && echo ${UDPTO} > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
… und, juhee, die alten UDP-Einträge sind futsch und wie von Zauberhand rennt der Tunnel:
traceroute to 192.168.45.1 (192.168.45.1), 30 hops max, 38 byte packets 1 192.168.44.9 (192.168.44.9) 44.464 ms 45.643 ms 45.539 ms 2 192.168.45.1 (192.168.45.1) 97.082 ms 95.747 ms 96.096 ms
Tja, reif für die Insel würde ich sagen :( Warum noch immer da TCP-Sessions als ESTABISHED stehen, wo ich das fragliche Endgerät im LAN doch schon vor ‘ner halben Stunde abgeschaltet habe — ich weiß es nicht und derzeit ist es mir auch eher egal; ein 2.6-basierter neuer Router ist schon am Betatest, insofern wird’s obige Zeile in der ip-up.local wohl für die nächste Zeit tun. NAT an sich finde ich gar nicht schlimm oder schlecht; nur, wenn sowas dazu kommt, dann wird’s haarig ;)
Respekt …
… muß ich dann mal wieder Google zollen: sie hosten da ein Projekt, für welches es für ihr eigenes Handy-OS, Android, keine Clients gibt. #fail auf der einen Seite, aber irgendwie auch so angenehm un-Apple …