Hallo, ich habe momentan ein seltsames Problem mit ein Knoten in mein Heimnetz. Es geht um diesen HIER. Ich kann innerhalb meines Netzwerk die externe IP nicht erreichen, und somit nicht per SSH verwalten oder die Info Seite aufrufen. Viel schlimmer: nach eine Weile verliert er die Verbindung zu unsere Gateways (L2TP) und kann diese nicht mehr aufbauen.
Es macht kein Sinn. Vorher war das Teil in ein eigenes Vlan samt Netz, dabei ging alles. Da ich mein Netzwerk umgebaut habe ist dies aber nicht mehr nötig. Ich habe keine sonderbare iptables rules auf mein Heimrouter mit LEDE.
Ein ähnliches Problem hatte ich vor kurzem auch: SSH über die öffentliche IPv6-Adresse funktioniert nicht mehr, WLAN-Mesh/Batman läudt aber noch. Ich habe dann über einen benachbarten Router mit Mesh-Verbindung die Link-local-Adresse weitergeleitet und konnte mich dann per SSH anmelden.
Szenario:
Router A: Öffentliche Adresse geht nicht mehr, SSH-Zugang vorhanden
~# ping6 -c2 ff02::1%bat0
PING ff02::1%bat0 (ff02::1%bat0): 56 data bytes
64 bytes from fe80::c66e:1fff:fe82:10d6: seq=0 ttl=64 time=0.810 ms
64 bytes from fe80::62e3:27ff:fe59:ecc0: seq=0 ttl=64 time=5.569 ms (DUP!)
64 bytes from fe80::32b5:c2ff:fe81:284c: seq=0 ttl=64 time=6.540 ms (DUP!)
64 bytes from fe80::2aba:b5ff:febf:7f99: seq=0 ttl=64 time=28.584 ms (DUP!)
64 bytes from fe80::2255:31ff:fe27:84eb: seq=0 ttl=64 time=30.619 ms (DUP!)
64 bytes from fe80::582c:50ff:fe49:8f1f: seq=0 ttl=64 time=32.677 ms (DUP!)
64 bytes from fe80::5c6d:63ff:fe97:bf1b: seq=0 ttl=64 time=46.110 ms (DUP!)
Welche Adresse zu ‚B‘ gehört, muss mann ausprobieren, es in der Regel das erste bis x-te Duplikat wobei x die Anzahl der direkten Mesh-Nachbarn ist.
Dann kann man über den Router B die Adresse weiterleiten und anschließend auf Router B einloggen:
Ich konnte noch mit meine lokale ipv6 per ssh rein. Am schlimmsten ist eben, das nach einige Stunden der Knoten die Verbindung verliert und diese nicht wieder aufbaut. Ich habe nun mein Netzwerk wieder rückgebaut, da ich keine logische Lösung gefunden habe und mir die Logs nicht weiterhelfen. Es wird solange so bleiben bis ich mir ein anderen Hauptrouter besorgt habe, wo ich mehr als 2 Netzwerkkarten habe und somit Freifunk wieder in ein eigenes Netz packen kann.
Es gab doch bei euch in Recklinghause zu dem betreffenden Zeitpunkt eine Störung im IPV6-Bereich. Bird hatte den radv-Dienst (mal wieder) eingestellt. Jetzt geht es wieder:
mpw@Server0:~$ ssh root@2a03:2260:200d:300:f6f2:6dff:fe22:8b72
The authenticity of host '2a03:2260:200d:300:f6f2:6dff:fe22:8b72 (2a03:2260:200d:300:f6f2:6dff:fe22:8b72)' can't be established.
RSA key fingerprint is SHA256:RTxiP2XvdvE/LTjxkSalTbQZwm8EfsIdQWK7Le9nu7w.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '2a03:2260:200d:300:f6f2:6dff:fe22:8b72' (RSA) to the list of known hosts.
root@2a03:2260:200d:300:f6f2:6dff:fe22:8b72's password:
Nun, die Probleme betreffen nur, wenn man im selben Netz wie der Knoten unterwegs ist (also im Normal Fall das typische Heimnetz). Getrennt läuft es einwandfrei. Liegt es wirklich an den radv-Dienst? Für mich hört sich das alles an nach ein Problem mit den Heimnetz/iptables. Gerade wenn der Knoten nach eine Weile komplett offline geht. Konnte aber keine Anzeichen dafür finden wieso. Nur eben, dass der Tunneldigger keine Verbindung mehr aufgebaut kriegt.
Es gab am Wochenende diverse Probleme bei euch im Netz. Von ausgefallenen Gateways, über Konfigurationsänderungen für die neue Karte bis hin zur einem streikenden Tunneldigger und dem Problem mit dem radv-Dienst. Das ist meiner Erfahrung nach normal, wenn man viel ändert. Das pendelt sich dann wieder ein und läuft dann wieder stabil.
Ich weiß halt, das IPV6 zeitweise kaputt war, weil bird6 keine Standardroute für IPV6 ausgegeben hat. Dadurch funktioniert IPV6 zwar netzintern aber nicht nach außen, weil die Knoten und Endgeräte keine Standardroute (Gateway) erhalten. Hast du weiterhin Probleme? Ich konnte dein SSH-Problem nicht (mehr) nachstellen.
Eventuell gibt es auch ein Problem mit dem IPV6 in deinem privaten Netz?
Soweit ich das beurteilen kann, ist alles in Ordnung. Die Umbauten bei uns sind mir bekannt, ich werde es dann die Tage wieder probieren wenn unser Netz wieder rund läuft.
Kann da super drauf zugreifen. Und SSH scheint auch zu gehen, habe natürlich auf das Gerät keinen Zugriff:
mpw@Server0:~$ ssh root@2a03:2260:200d:300:6670:2ff:feaa:bb46
The authenticity of host '2a03:2260:200d:300:6670:2ff:feaa:bb46 (2a03:2260:200d:300:6670:2ff:feaa:bb46)' can't be established.
RSA key fingerprint is SHA256:0QuO0I48xHYnpOO+QUhjJU0HlbpcNUoIl/e9Ff2ko78.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '2a03:2260:200d:300:6670:2ff:feaa:bb46' (RSA) to the list of known hosts.
root@2a03:2260:200d:300:6670:2ff:feaa:bb46's password:
Eher nicht wenn ich die Adresse anpingen kann. Noch ein Grung mehr wieso ich das nicht verstehe. An mein Anbieter kann es auch nicht liegen, andere haben es auch getestet. Ich sehe auch nicht wie ich das sonst debuggen kann. Ich bin für Vorschläge offen.
Ja, aber hinter der Fritte steht mein LEDE Router. Der übernimmt die DNS Anfragen wobei DNS Rebing ausgeschaltet ist: er sendet lokal an meinen pi-Hole die anfragen weite zweck Werbung und Telemetrie filtern. Am Knoten selbst habe ich keine DNS Änderungen gemacht.
Somit sollte das dns rebind der Fritte kein Problem sein, wenn diese bis auf für sich selbst, keine DNS Anfragen verwaltet. Oder? Im pi-Hole steht in den Logs nichts, dass er da was blocken würde.
Das Problem ist auch noch ohne pi-Hole da. Und lässt auch nicht erklären wieso alles läuft wenn der Knoten wieder in ein extra vlan + lokales Netz landet, wo am Ende dns auch in den pi-Hole landet Wie schon gesagt am Knoten selbst habe ich nichts am dns geändert.
Trotzdem danke für die Mühe.
EDIT: ich konnte das Problem auf LEDE eingrenzen. Direkt an der Fritzbox läuft alles einwandfrei. Nur trotz dmz an Lede bestehen die Probleme weiterhin.
Ich werde es später probieren. Ich will die Tage mir eine Testumgebung einrichten nur um herauszufinden woran das hier liegt, da ich nicht ständig an mein Heimnetz basteln will. Der Knoten liegt jetzt wieder in ein eigenes vlan + lokales Netz, womit dann erstmal alles wieder läuft.
Als Hinweis: Es gab dererlei Probleme auf einigen Batman-Versionen.
Da waren Knoten innerhalb des Meshes gut erreichbar, auch vom Gateway aus.
Nur „über das Gateway hinweg“ kamen sie nicht hinaus.
Vermutlich irgendwie „Routingtabelle zum Gateway defekt“.
Da half dann nur ein Reboot (vermutlich hätte auch ein batman-interface-restart auf dem Knoten geholfen)
Aus der Zeit ahben wir „außerhalb des Batman-Netzes“ eine IPv6-Alias-IP, z.B. auf einem Map und einem FW-Server als non-preferrred angelegt.
Und ein automaticher Reboot, wenn diese anycast-Adresse (für den Knoten) im laufen Betrieb verschwindet und verschwunden bleibt.
Wie schon gesagt am Knoten selbst habe ich nichts am dns geändert.