Ja, aber trotzdem unbefriedigend. Die beiden Speedtests gehen nicht, Facebook geht nicht, heise.de geht nicht
Nö, läuft super. Ergo: Knotenname, VPN-Uplink lt. Karte, IPv4-Gateway lt. Netzwerkinfo des Endgerätes. Unter Android tut »Network Info II« da gute Dienste, iOS wird jemand anderes wissen, wie man die Info herausbekommt. Ggf. noch hilfreich: DNS1 & DNS2. (Sollten GW & 10.255.128.53 sein.) Und, da das schon gesehen wurde: hat das Gerät überhaupt eine 10er IP bekommen? Gelegentlich sah’ ich 0.0.0.0 als IPv4-Adresse, das tut natürlich nicht — wenn das auch woanders beobachtet wird, muß man das mal debuggen.
Das es bei dir läuft ist schön aber bei mir und scheinbar auch ein paar anderen nun mal nicht. Wenn dir das was hilft hier die Daten:
33330-Buschkamp-Consulting
IPv4 configured
IPv6 not configured
fastd running for 2812.737 seconds
There are 9 peers configured, of which 1 are connected:
mesh_vpn_event_peer_test01: not connected
mesh_vpn_backbone_peer_gw06: not connected
mesh_vpn_backbone_peer_gw03: not connected
mesh_vpn_backbone_peer_gw01: not connected
mesh_vpn_backbone_peer_gw04: not connected
mesh_vpn_backbone_peer_gw02: connected for 2771.849 seconds
mesh_vpn_event_peer_event02: not connected
mesh_vpn_event_peer_event01: not connected
mesh_vpn_backbone_peer_gw05: not connected
tl;dr: Detlev, warum lieferst Du nicht einfach die nachgefragten Infos? Ich vermisse das weiterhin: IPv4-Gateway lt. Netzwerkinfo des Endgerätes. Da gehen Deine Daten lang, oder eben kaputt. Diese Infomation hat der Knoten nicht, die hat nur ein verbundenes Gerät, eben jenes, wo »nix geht«.
Technischer Hintergrund:
Alle anderen Informationen sind ggf. zur Ursachenforschung/-korrelation hilfreich, aber über »geht« oder »geht nicht« von IPv4 entscheidet erst einmal das von batman_adv ausgewählte IPv4-Gateway. Ab dort kann von hier aus nachvollzogen werden, wo die Daten langlaufen sollten (zwei mögliche Wege je Gateway und bis zu sechs mögliche Wege ab der nächsten Ebene).
Kurzum: ohne die Angabe, über welches Default-Gateway Deine IPv4-Pakete laufen, ist die individuelle Fehlersuche nicht möglich. Und wie Du rausfindest, über welches IPv4-Gateways Dein Endgerät seine Daten in die Welt schickt, ist OS-abhängig.
Im konkreten Fall allerdings war gw04 defekt, dmesg spuckte Fehlermeldungen aus, siehe Admin-Tagebuch. Meine Verbindung über gw02 (10.255.0.12) war fehlerfrei. Über gw04 (10.255.0.14) sollte es entsprechend nun auch wieder gehen.
Hmm, NS sind das 1. das lokale GW, 2. der zentrale DHCP-Server per ANYCAST. Zum GW hätte DNS tun müssen, zum DHCP-Server geht’s über Tunnel, ergo hätte da das fehlende MSS-Clamping von gw02 zu dem Zeitpunkt die Verbindung auch kaputt gemacht (truncated UDP response => Retry per TCP, der mit falscher MTU dann auch versandet). Soweit die Theorie; ohne Dump kaum Chance, das zu belegen oder zu falsifizieren
Tja, wird wohl Zeit für Servicechecks, Idee ist hier, Gluon-VMs fix an GWs zu binden und dahinter Linux-VMs zu booten und jene zu monitoren. Blech dafür hätten wir nun, jetzt müßte »man« es nur noch machen
