Zugriff auf lokales Netzwerk nicht mehr möglich (DSL-->DG)

[Kasimir4731]

Mein Environment:

• FB7590 mit OS8.02 ist als Router mit dem Deutsche Glasfaser Modem verbunden. Mit ist bewusst, dass wegen CGNAT der IPv4 Zugriff von außen nicht mehr wie früher mit DSL funktionieren kann, es muss über IPv6 laufen.
• IPv6-Unterstützung ist in der FB aktiviert (Native IPv6-Anbindung on, Globale Adr Auto, DHCPv6 Rapid Commit on)
• Firewall-Freigabe für den lokalen RaspberryPi für Ports 80-81 ist für IPv6 aktiviert
• Als DynDns Provider verwende ich freedns.afraid.org, dort habe ich für "Meine-Domain" einen AAAA Eintrag zu der IPV6 Adresse des RPi erstellt.
• Eine Wireguard VPN ist auf der FB eingerichtet und die Credentials sind auf meinem Handy importiert

Seit der Umstellung von DSL zu Glasfaser bekomme ich den Zugriff auf lokale Geräte wie den RPi nicht zuverlässig zum Laufen. Zwischendurch funktionierte es, zumindest konnte ich "von außen", zB mit dem Handy über Mobilnetz, eine Test-Website auf dem RPi Port 81 aufrufen. Auch der letsencrypt "certbot renew" auf Port 80 funktionierte. Bis vor Kurzem.
Seit einigen Tagen geht das alles nicht mehr und ich habe keine Ahnung warum. Mir ist nicht bewusst, dass ich irgendwas geändert habe.

Zum Test von "außen" verwende ich mein iPhone bei ausgeschaltetem WLAN:

• Der Aufruf von http://[IPv6-des-RPi]:81 schlägt fehl.
• "nslookup Meine-Domain 8.8.8.8" funktioniert, es liefert die IPv6 des RPi - an freedns kann es also nicht liegen
• Ebenso schlägt der Aufruf von https://xxxxx.myfritz.net:yyyyy fehl (auch http://[IPv6-der-FB]:yyyyy geht nicht)
• "nslookup xxxxx.myfritz.net 8.8.8.8" funktioniert, es liefert die IPv6 der Fritzbox

Es sieht so aus, als würden generell keine IPv6 Zugriffe über Mobilfunk bei meiner FB ankommen. Aber nun kommt's: wenn ich auf dem iPhone Wireguard VPN einschalte, wird eine Verbindung zur FB aufgebaut, das VPN Symbol auf dem Smartphone erscheint. Und danach komme ich an meine lokalen Devices ran, alle o.g. Aufrufe funktionieren nun, ebenso Zugriffe auf mein lokales 192.168.3.0 IPv4 Netz.
Was ich nicht verstehe:
Wireguard verwendet die xxxxx.myfritz.net URL der FB, als Port wird natürlich ein anderer als bei https verwendet. Aber wieso klappt Wireguard-VPN auf mein lokales Netz, geroutet über die FB (!), und https direkt auf die UI der FB nicht? Ich kapier's nicht. Kann sowas am Provider liegen?

Hat irgendjemand einen Tipp für mich, was ich noch probieren könnte? Ich stehe vor einem Rätsel.

 

[stoney]

Der Raspberry muss selbst seine eigene, individuelle öffentlich erreichbare IPv6 beim DynDNS-Dienst aktualisieren, da es bei IPv6 kein NAT und somit keine Weiterleitungen ins LAN gibt, sondern die Ports nur geöffnet werden.

Siehe zB. auch wenn es aktuell nicht explizit um https geht, der Grund ist gleich:

FRITZ!Box 7590 | Zugriff auf HTTPS-Server im FRITZ!-Heimnetz nicht möglich

Entdecke FRITZ! - Informiere dich über die vielseitigen und benutzerfreundlichen Lösungen für deinen Internetanschluss und deine Heimvernetzung.

fritz.com

 

[Kasimir4731]

Danke für dein Feedback.
An einer nicht aktuellen IP-Adresse liegt es (leider) nicht. Die globale IPv6-Adresse, die ich von DG erhalte, ist seit Monaten konstant, auch nach Power Off/On des Modems, ich brauche sie deshalb nicht zu aktualisieren. Ich komme mit den aktuellen, mit ifconfig ausgelesenen IPv6-Adressen von außen weder an den RPi noch an die FB.
Hat ja bis vor einigen Tagen funktioniert. Jetzt nicht mehr, warum auch immer.
Ich hab's nur gemerkt, weil der letsencrypt certbot dryrun nicht mehr wollte und den hatte ich vor ca. 2 Wochen zuletzt erfolgreich ausprobiert. Und jetzt kommt er nicht mehr durch mit http seinem Zugriff auf Port 80. Der hätte am RPi landen müssen. Daraufhin begann ich zu forschen und zu probieren, nach mittlerweile 4 Stunden habe ich aufgegeben und diesen Thread erstellt, weil ich mit meinem Latein am Ende bin.

 

[stoney]

Wie lautet denn die Netzwerkschnittstelle? Noch eth... oder enxb... ?

Ich lief in dieses Problem, nachdem ich von Debian 10 über 11 auf 12 (unter 11 hatte ich es nicht getestet, da dies nur ein Zwischenupdate war) auf meinem RPi3+ geupdatet habe.

Prüfe ob in der FRITZ!Box die selbe IPv6 angezeigt wird, wie auch vom NIC verwendet.

 

[Kasimir4731]

• eth0
• Linux RPi2B 6.1.21-v7+ #1642 SMP Mon Apr 3 17:20:52 BST 2023 armv7l GNU/Linux
• Raspbian GNU/Linux 11 (bullseye)

Ja, die IPv6, die mit ifconfig bei eth0 als erste globale IPv6 angezeigt wird, ist exakt dieselbe, die ich auch in der FB unter Heimnetz-Eigenschaften IPv6-GUA sehe.

 

[stoney]

Bleiben wir zunächst mal bei der Kontaktaufnahme über die IPv6.

Von wo aus greifst Du denn zu? Die externe Anbindung erfolgt schon per IPv6? https://test-ipv6.com

Du könntest ja mal einen Paketmitschnitt der 1. Internetverbindung unter http://fritz.box/support.lua erstellen, von extern versuchen über die IPv6 zuzugreifen und dann mit Wireshark nach der IPv6 des RPi's suchen ob da überhaupt etwas an der FRITZ!Box ankommt um letztendlich am RPi anzukommen (auch ein Pingtest wäre vorab vll. interessant).

 

[Kasimir4731]

oha, support.lua. Genau sowas habe ich schon immer gebraucht, aber nicht gewusst, dass es das gibt. Danke für den Tipp. Das muss ich jetzt genauer erkunden...

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

eieiei... Wireshark, da bin ich echt kein Profi ... also ich kann im Protokoll Zugriffe auf die IPv6 des RPi sehen, die Zeilen sind aber alle rot markiert, die Info-Spalte fängt mit
"[TCP Retransmission] 64119 -> 81 [SYN].... "
an. Ich weiß nicht, was das bedeutet. Jedenfalls sehe ich da Port 81. Aber sonst kann ich mir keinen Reim daraus machen.
Wie kann ich einen Ping-Test machen? Keine Ahnung, wie ich mein iPhone dazu bringe, einen Ping auf eine IPv6 zu schicken. PING6 ist in der Freigabe aktiviert.

Zum Screenshot: die Dest-Adresse habe ich aus naheliegenden Gründen geschwärzt. Die geschwärzte Source-Adresse müsste mein DG Modem sein, schätze ich - meine FB ist es jedenfalls nicht.
Wenn ich auf dem RPi mit tcpdump auf http Zugriffe auf Port 81 scanne, kommt nichts. Gegenprobe: wenn ich im Terminal ein curl ip-adresse:81 mache, reagiert tcpdump. Es kommt also nichts vom Router an.

 

[stoney]

Der Tab stand etwas offen im Browser, weshalb sich dies nun überschnitten hat...
Ich bin leider jetzt auch kein Spzialist in Sachen Paketmitschnitte, sodass ich Dir keine verlässlichen Infos aus dem Effeff dazu geben zu können.

Sieht zumindest so aus, als würde von extern eine Anfrage auf Port 81 eingehen.

Ist denn der Zugriff im LAN auf den Port 81 möglich?

Falls Du nur Consolenzugriff auf den RPi hast, könntest Du zB mit tcpdump mal auf dessen NIC mitschneiden und nach Port 443 filtern:

tcpdump › Wiki › ubuntuusers.de

wiki.ubuntuusers.de

tcpdump -i eth0 -w capture.eth tcp port 443
Somit hast Du in Wireshark dann direkt nur die Pakete für 443 um zu prüfen ob diese dort ankommen, falls ja, musst du dort weitersuchen, weshalb auf Port 81 nichts lauscht.

.. daher würde ich empfehlen den RPi vom Netzwerk zu trennen, in der F!Box unter "Heimnetz > Netzwerk > Netzwerkverbindungen > Ungenutzte Verbindungen" den Eintrag zum RPi löschen, F!Box neu starten und den RPi wieder mit dem Netzwerk verbinden und die Portfreigaben neu einrichten.

 

[Kasimir4731]

Danke ... morgen starte ich neue Versuche, für heute bin ich bedient. Fast der gesamte Tag draufgegangen. Aber als Rentner kann man sich es ja leisten ;-)

 

[Kasimir4731]

Ich weiß nicht, wer hier spinnt, die FB oder der RPi, aber nun wird es ganz verrückt. Ich bin wie von dir gestern abend vorgeschlagen vorgegangen. Nun meldet die FB im Freigabemenü des Rpi eine IPv6 Interface-ID "::aaaa:bbbb:cccc:dddd" und in der Port-Freigabe die "IP-Adresse im Internet " "2a00:6020:a583:b000:aaaa:bbbb:cccc:dddd". Aber diese Adresse wird in ifconfig eth0 des RPi nicht angezeigt und funktioniert auch nicht bei lokalen ping.
Die FB geht also davon aus, dass der RPi aus dem Internet mit der Adresse 2a00:6020:a583:b000:aaaa:bbbb:cccc:dddd auf Port 80 erreichbar sein soll, aber der RPi weiß davon nichts und reagiert nicht.
Die in ifconfig eth0 des RPi angezeigten vollständigen globalen IPv6 Adressen lassen sich anpingen. Und die LLA IPv6 Adresse fe80::6b4a:4b95:e3fc:5be9%eth0 auch! Der Fehler ist, dass die FB sich selber eine scheinbar gültige globale Adresse aus der LLA und dem Prefix gebastelt hat. Und das funktioniert nicht.
Ich probiere jetzt weiter. Ich werde eine Portweiterleitung auf meinen Windows-PC machen und schauen, was support.lua / Wireshark mir erzählen ...

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

Ich habe nun einen lokalen Webserver, der auf Port 8080 reagiert, auf dem PC aktiviert. Auf der FB habe ich eine Portweiterleitung für den PC und Port 8080 nur bei IPv6 aktiviert. Auch hier wird eine falsche globale IPv6 auf Basis der LLA "gebastelt".
Wenn ich eine korrekte IPv6 verwende (also die auch auf einen Ping reagiert), und mit dem Handy auf diese IP:8080 zugreife, sehe ich im Wireshark, dass versucht wird, an IP:8080 etwas zu schicken. Es kommt aber keine Antwort.
Wenn ich lokal curl [IP]:8080 eingebe, sehe ich die Antwort des Webservers. Der Webserver lebt also und reagiert auf IPv6 Anfragen.

Ich habe mir die Paketreihenfolge in Wireshark jetzt mal genauer angesehen, siehe Screenshot
In Paket 19 sendet (vermutlich) der zentrale DG Router ein Paket an meinen PC. Es kommt auf Port 59620 an und wird an Port 8080 weitergeleitet.
In Paket 20 sendet mein Router ein Paket an den DG Router mit der Info "Destination unreachable (Adminstratively prohibited)".
Also meldet mein Router - ohne irgendein Paket an den PC zu schicken - sofort an den DG Router zurück, dass er nicht auf meinen PC zugreifen darf. So deutet ich das. Die Erklärung dürfte sein, dass die FB nur Zugriffe auf die -falsche- IPv6 erlaubt.

Also nächster Versuch. Ich überschreibe die letzten 64 bit der Ipv6 Interface-ID meines PCs im Router durch eine Adresse, die zusammen mit dem Prefix eine gültige IPv6 ergibt, mit der ein lokaler Ping auf meinen PC funktioniert und die ich beim Handy Test verwendet habe: und siehe da, die Website wird angezeigt!!!
Der Zugriff mit dem Handy auf den Webserver des PCs funktioniert nun.

Nächster Versuch. Gleiches Spiel mit dem RPi. Ich überschreibe die Interface-ID mit den unteren 64bit einer gültigen globalen IP, Ergebnis: funktioniert. Der Webserver des RPi ist nun vom Internet aus erreichbar.
Und der certbot renew --dryrun funktioniert jetzt auch wieder. Heureka!

Offensichtlich hat das Löschen, Abklemmen, wieder Anklemmen und neu Konfigurieren der Portfreigabe für den RPi geholfen, denn die IPv6, die ich beim RPi verwende, ist dieselbe, die ich auch gestern benutzt habe - ich hatte die im Laufe meiner vielen Versuche schon angepasst. Ich habe mir die Wireshark Protokolle von gestern jetzt nochmal genau angesehen:
Das Anfragepaket vom DG Router an Port 81 des RPI wurde nicht mit einem "Destination unreachable (Adminstratively prohibited)" Paket abgelehnt. Stattdessen kam keine Antwort und der DB Router sendete mehrere TCP Retransmission Pakete. Mein Router hat also die IPv6 Adresse akzeptiert, aber trotzdem kein Paket an den RPi gesendet. Da muss sich etwas total verklemmt haben im Router. Das Zurücksetzen der Freigabe hat anscheinend geholfen.
Wie ich schon in meinem ersten Beitrag geschrieben habe, hatte das Ganze schon mal funktioniert. Anscheinend muss durch irgendwas meine FB aus dem Tritt gekommen sein und eine Neukonfiguration des RPi war notwendig.

Bleibt festzuhalten:
Wenn eine Portfreigabe für lokale Device über IPV6 konfiguriert wird, erzeugt die FB eine falsche IPv6 Interface-ID. Diese muss manuell überschrieben werden mit einer funktionierenden Adresse. Diese kann man mit ifconfig (linux) oder ipconfig (Windows) ermitteln.
Mag sein, dass dieses Fehlverhalten nur in meiner Konfiguration (FB 7590 8.02 im Routermodus an DG-Modem) auftritt.
Ich werde das weiter beobachten.

Danke, stoney, für die beiden Tipps: support.lua und Neuinstall RPi.

 

[stoney]

Eine 7590 am Anschluss der Deutschen Glasfaser ist ja nichts ungewöhnliches, daran dürfte es also nicht liegen.

Meine IPv6 Einstellungen auf der LAN-Seite sehen wie im Anhang zu sehen aus, sodass meine Dienste auf den zwei vorhandenen RPis von außen erreichbar sind (ok, hab einen vollwertigen DS-Anschluss), wie HTTPS, Teamspeak³ Server, bei Bedarf mein PC um gelegentlich mal ein ungestörtes 1 on 1 CS:S zocken zu können).

Möglicherweise hätte ein Neustart von F!Box oder/und RPi auch schon ausgereicht - dabei fällt mir gerade so ein, gibt es außer der F!Box noch weitere Geräte welche für das Netzwerk zuständig sind?

Oder die Neuanalge der Portfreigabe(n), nach einem Wechsel von primärer Internetverbindung auf LTE-Fallback scheint aktuell auch noch nicht alles rund zu laufen, denn beim Zurückschalten wird die IPv4 Freigabe nicht immer zuverlässig von der vorherigen (IPv4 only durch LTE-Stick) auf die primäre Verbindung umgeswitcht, was jedoch dank der IPv6 Erreichbarkeit keine für mich relevanten Auswirkungen im privaten Umfeld.

 

[Kasimir4731]

Möglicherweise hätte ein Neustart von F!Box oder/und RPi auch schon ausgereicht - dabei fällt mir gerade so ein, gibt es außer der F!Box noch weitere Geräte welche für das Netzwerk zuständig sind?

Nö, nur die FB ist für DHCP und DNS zuständig. Es ist auch kein pihole o.ä. aktiv. Neustarts von FB und Rpi hatte ich während meiner Experimente unzählige, hatten alle nichts gebracht.
Scheint jetzt zu laufen. Einzig ein mir unerklärliches Verhalten bei WireGuard VPN ist nach wie vor da. Aber das erkläre ich besser in einem ->separaten Thread.