Am späten (Samstag-(!)) Nachmittag hat AVM nun auch die 7360 mit einem Bugfix-Release von Fritz!OS bedacht. Die Installation hat zwei komische Seiteneffekte bei mir gehabt.
Vorausschicken muß ich, daß ich zwischen meinen Fritz!Boxen IPSec-VPNs aufgebaut habe, die die jeweiligen LANs miteinander sprechen lassen. In der Regel ist auch nicht die Fritz!Box das Default-GW, sondern ein Linux-Server, der per OpenVPN-Tunnel und OLSR für das Routing meiner /24 IPv4-Netze sorgt. Das OpenVPN-Netz bildet ein Overlay-Netz über die xDSL-Verbindungen sowie z. T. eines über die IPSec-Tunnel, was an dieser Stelle aber nicht relevant ist.
Die lokalen Linux-Gateways haben Hostrouten über die jeweilige lokale Fritzbox zu den jeweiligen, per IPSec verbundenen, Fritzboxen. Die Fritzboxen haben im jeweiligen VPN-Setup entsprechend die LANs hinter jeder entfernten Fritzbox bei ›allow‹ eingetragen sowie IPv4-Routen über das jeweilige lokale Linux-Gateway in ihre lokalen Netze.
Zwar sagt ja ein Bild mehr als tausend Worte, aber ein solches ohne geeignete Werkzeuge zu malen, ist tausend mal schwerer als mit jenen. Ich hab’s dennoch mal probiert ;)
Anyway: Ich bin dieses Wochenende nicht in GT, somit mußte ich das Firmwareupgrade der 7360 dort von Berlin aus anstoßen; kein Problem, da die Netze ja über das IPSec-VPN als auch die Linux-Router erreichbar sind.
Problem 1: das Browserfenster des FW-Upgrades der 7360 ›hängt‹; augenscheinlich klappt die Rückmeldung von der 7360 nicht, daß sie wieder oben ist. Gut, Fenster geschlossen, URL erneut geladen, 7360 ist da.
Inklusive eines nicht von mir initiierten zweiten Reboots; sonderbar.
Problem 2: Das wiegt etwas schwerer: die 7360 antwortet nicht mehr auf ping/traceroute, oder die 7490 kommt mit der Antwort nicht klar.
Normales »traceroute« klappt nach wie vor, außer in einem Fall:
Aus Gütersloh:
user@host:~$ traceroute 192.168.175.1 traceroute to 192.168.175.1 (192.168.175.1), 64 hops max, 40 byte packets 1 albert.uu.org (192.251.226.33) 0 ms 0 ms 0 ms 2 FB-VDSL-GTSO.uu.org (192.168.177.1) 1 ms 0 ms 0 ms 3 FB-DSL-BRLN.uu.org (192.168.175.1) 63 ms 62 ms 64 ms user@host:~$ traceroute 192.168.176.1 traceroute to 192.168.176.1 (192.168.176.1), 64 hops max, 40 byte packets 1 albert.uu.org (192.251.226.33) 0 ms 0 ms 0 ms 2 FB-VDSL-GTSO.uu.org (192.168.177.1) 0 ms 0 ms 0 ms 3 FB-VDSL-BRLN.uu.org (192.168.176.1) 44 ms 44 ms 43 ms user@host:~$ traceroute 192.168.45.1 traceroute to 192.168.45.1 (192.168.45.1), 64 hops max, 40 byte packets 1 albert.uu.org (192.251.226.33) 0 ms 0 ms 0 ms 2 FB-VDSL-GTSO.uu.org (192.168.177.1) 0 ms 0 ms 0 ms 3 fb-loc-2.loc-2.gt (192.168.45.1) 66 ms 63 ms 63 ms
Aus Berlin, über die 7570, die über Alice verbunden ist:
user@host:~$ ping -c 3 192.168.177.1 PING 192.168.177.1 (192.168.177.1) 56(84) bytes of data. 64 bytes from 192.168.177.1: icmp_seq=1 ttl=62 time=64.8 ms From 193.26.120.113: icmp_seq=2 Redirect Host(New nexthop: 192.168.175.1) 64 bytes from 192.168.177.1: icmp_seq=2 ttl=62 time=64.1 ms 64 bytes from 192.168.177.1: icmp_seq=3 ttl=62 time=63.8 ms --- 192.168.177.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 63.817/64.272/64.837/0.514 ms user@host:~$ traceroute 192.168.177.1 traceroute to 192.168.177.1 (192.168.177.1), 64 hops max, 40 byte packets 1 gw.berlin.uu.org (193.26.120.113) 1 ms 1 ms 0 ms 2 FB-DSL-BRLN.uu.org (192.168.175.1) 1 ms 1 ms 4 ms 3 FB-VDSL-GTSO.uu.org (192.168.177.1) 69 ms 74 ms 66 ms
Aus Berlin, über die 7490 (6.03), die über congstar verbunden ist:
user@host:~$ ping -c 3 192.168.177.1 PING 192.168.177.1 (192.168.177.1) 56(84) bytes of data. --- 192.168.177.1 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2015ms user@host:~$ traceroute 192.168.177.1 traceroute to 192.168.177.1 (192.168.177.1), 64 hops max, 40 byte packets 1 gw.berlin.uu.org (193.26.120.113) 1 ms 0 ms 0 ms 2 FB-VDSL-BRLN.uu.org (192.168.176.1) 1 ms 1 ms 1 ms 3 * * * 4 ^C user@host:~$ tcptraceroute 192.168.177.1 Selected device eth0, address 193.26.120.1xx, port 53127 for outgoing packets Tracing the path to 192.168.177.1 on TCP port 80 (www), 30 hops max 1 gw.berlin.uu.org (193.26.120.113) 0.567 ms 0.474 ms 0.451 ms 2 192.168.176.1 0.935 ms 0.995 ms 0.804 ms 3 192.168.177.1 [open] 55.460 ms 55.624 ms 57.564 ms user@host:~$ traceroute 192.168.45.1 traceroute to 192.168.45.1 (192.168.45.1), 64 hops max, 40 byte packets 1 gw.berlin.uu.org (193.26.120.113) 1 ms 0 ms 0 ms 2 FB-VDSL-BRLN.uu.org (192.168.176.1) 1 ms 1 ms 1 ms 3 192.168.45.1 (192.168.45.1) 65 ms 65 ms 65 ms
Mit anderen Worten: die Verbindung zwischen meiner Berliner 7490 (Fritz!OS 6.03) und meiner Gütersloher 7360 (6.03) ist partiell gestört, ICMP (ping, traceroute) scheint auf einer der beiden Seiten nicht mehr korrekt behandelt zu werden.
Auf der Verbindung 7490 (6.03) zu 7270 v2 (5.52) hingegen funktioniert das.
Ähnliches Suchspiel aus der Gütersloher Sicht: alles funktioniert wie vorher, also 7360 (6.03) zu 7570 (4.91), 7270 v2 (5.52) oder 7490 (6.03).
Da TCP funktioniert, schließe ich Probleme im Routing oder NAT auf meiner Seite aus; aber sonderbar bleibt es, und ein no-go ebenso: wer Netzwerkdiagnose behindert, gehört meines Erachtens standrechtlich erschossen. Da ich keine Filter zwischen den Netzen aktiviert, und die 7360 direkt nach der 7490 auf 6.03 gebracht habe, frage ich mich nun, wo ich ansetzen soll; ich werde wohl die 7570 durch eine auf 6.03 aktualisierte 7270 v3 ersetzen müssen, um das weiter einzugrenzen. Danke, AVM :-(