RasPi von außen nicht pingbar - Portfreigabe mit IPv6 / DS Lite

[Photon]

Jetzt hab ich super viel Hilfe von einem Nutzer hier privat erhalten und es scheint soweit zu laufen. Unglaublich, dass das jetzt doch noch geklappt hat!

Soweit ich es überblicke, war die entscheidende Änderung, dass wir in /etc/dhcpcd.conf "slaac private" zu "slaac hwaddr" geändert haben. Dadurch waren übrigens die lokale und die öffentliche IPv6 übereinstimmend. Dann haben wir noch in der Fritzbox die Freigabe entsprechend angepasst, also die IPv6 Interface-ID von der ifconfig Ausgabe übernommen.

Außerdem haben wir noch, wie schon von lokon vorgeschlagen, die Hostnames der Subdomains, die unter freedns.afraid.org angelegt sind, in die DNS-Rebind Schutz Tabelle der Fritzbox eingetragen und bei freedns die aktualisierte öffentliche IPv6 Adresse des Raspis eingetragen.

Aus irgendeinem Grund ist bei Google's DNS-Server für eine Subdomain noch teils die alte IP drin (manchmal kommt die alte, manchmal die neue, richtig mysteriös), aber sonst läuft nun alles, wie es soll!

 

[Bob.Dig]

Soweit ich es überblicke, war die entscheidende Änderung, dass wir in /etc/dhcpcd.conf "slaac private" zu "slaac hwaddr" geändert haben. Dadurch waren übrigens die lokale und die öffentliche IPv6 übereinstimmend. Dann haben wir noch in der Fritzbox die Freigabe entsprechend angepasst, also die IPv6 Interface-ID von der ifconfig Ausgabe übernommen.

Interessant! Hab keinen Raspberry Pi, aber wäre davon ausgegangen, dass sich das Teil mehr als Server sieht, denn als Client, aber falsch gedacht.

 

[Photon]

Man muss dazu sagen, dass mein Raspi schon seit einiger Zeit in der Ecke rumlag, da ist noch Raspbian Buster drauf... Vielleicht ist das bei neueren Versionen ja besser umgesetzt.

Ich werde wohl die relevanten Konfigurationen sichern und eine Neuinstallation von Bullseye machen. Auf oldoldstable sollte man nicht unbedingt unterwegs sein...

Ergänzung (26. Dezember 2024)

Aus irgendeinem Grund ist bei Google's DNS-Server für eine Subdomain noch teils die alte IP drin (manchmal kommt die alte, manchmal die neue, richtig mysteriös), aber sonst läuft nun alles, wie es soll!

Das scheint sich nun von selbst gelöst zu haben, jetzt ist die IP reproduzierbar richtig und springt nicht mehr zwischen der alten und der aktuellen hin und her. Vielleicht ein Problem bei Googles DNS-Server.

 

[Avenger84]

Soweit ich es überblicke, war die entscheidende Änderung, dass wir in /etc/dhcpcd.conf "slaac private" zu "slaac hwaddr" geändert haben

Veraltetes Raspi OS.
Beim aktuellen ist es komplett anders, so wie von mir beschrieben, aber egal.

Ich würde kein veraltertes OS ins Internet stellen.

 

[TomH22]

Das scheint sich nun von selbst gelöst zu haben, jetzt ist die IP reproduzierbar richtig und springt nicht mehr zwischen der alten und der aktuellen hin und her.

Das hat mehr vermutlich einfach mit den Caches des Google DNS zu tun, unter der 8.8.8.8 ist nicht ein Server sondern ein ganzes Netzwerk von Servern erreichbar. Da müssen sich die Änderungen erst verteilen.

bei freedns die aktualisierte öffentliche IPv6 Adresse des Raspis eingetragen

Die kann sich aber ändern, wenn der Provider Dir beim Neuaufbau der Verbindung ein neues Prefix zuweist. Das Problem hatten wir hier auch schon in anderen Zusammenhängen.

 

[Photon]

Die kann sich aber ändern, wenn der Provider Dir beim Neuaufbau der Verbindung ein neues Prefix zuweist. Das Problem hatten wir hier auch schon in anderen Zusammenhängen.

Klar, da muss ich noch das Updater-Skript auf Vordermann bringen.

Ergänzung (26. Dezember 2024)

Ich würde kein veraltertes OS ins Internet stellen.

Absolut, ich arbeite dran.

 

[lokon]

Ich kenne nur den 8.8.8.8 von Google.

Unter https://developers.google.com/speed/public-dns/docs/using?hl=de sind die IPv6 Adressen der DNS Server von Google aufgelistet.
Andere öffentliche DNS Server in IPv6 sind zB über https://www.ccc.de/de/censorship/dns-howto - und bei den dort erwähnten Projekten gelistet.

Schön das eine funktionierende Konfiguration gefunden wurde - siehe Probleme in 02/2023 c't Artikel . Ob das schon alles behoben wurde

 

[Photon]

Falls jemand auf dieses Thema stoßen sollte, hier eine funktionierende Konfiguration für den Network-Manager: https://forum-raspberrypi.de/forum/...tellen-bei-bookworm/?postID=575901#post575901

 

[thomasschaefer]

Also meine manpage sagt nichts davon, dass nur numerische Argumente zulässig wären:

ipv6.addr-gen-mode

If the per-profile setting is either "default" or "default-or-eui64", the global default is used. If the default is unspecified, the fallback value is either
"stable-privacy" or "eui64", depending on whether the per-profile setting is "default" or "default-or-eui64, respectively.

https://networkmanager.dev/docs/api/1.32.10/settings-ipv6.html

zeigt nur, dass es letztendlich numerisch behandelt wird.

 

[Photon]

Ich habe heute versucht, bei einem ehemaligen Kommilitonen, der aktuell auch an seinem Raspi bastelt, allerdings eine aktuellere Distro installiert hat (ich glaube, es ist ein Ubuntu), diese Option so zu setzen, aber es hat aus irgendeinem Grund nicht geklappt, die Symptome waren wie bei mir (kein Ping möglich, lokale und öffentliche IPv6 unterschiedlich).

Ich habe also stattdessen in /etc/NetworkManager/conf.d eine .conf-Datei erstellt und dort die beiden Optionen eingetragen, wie in dem verlinkten Thread vorgeschlagen, dann ging es.

Kann aber gut sein, dass das Problem an anderer Stelle war, ich verstehe nicht wirklich, warum es beim ersten Versuch nicht klappte...

 

[Avenger84]

Falls jemand auf dieses Thema stoßen sollte, hier eine funktionierende Konfiguration für den Network-Manager: https://forum-raspberrypi.de/forum/...tellen-bei-bookworm/?postID=575901#post575901

da fragt man sich manchmal, warum man sich die Mühe macht und die Lösung für Buchwurm präsentiert, wenn die Antwort vom TE nicht mal gelesen wird.

 

[Photon]

@Avenger84 Weil mein eigener RasPi ja noch mit Buster unterwegs ist, da ist die Lösung für Bookworm nicht anwendbar gewesen.

 

[Photon]

Hallo nochmal,

jetzt ist einige Zeit vergangen und irgendwann hab ich feststellen müssen, dass der Zugriff von außen wieder nicht so ganz hinhaut...

Ich kann aus dem lokalen Netzwerk sowohl via URL als auch via externer IPv6 die Webseite aufrufen. Von extern kann ich die externe IPv6 anpingen und der Portscan sagt, dass 80 und 443 offen sind. Bei meinem DynDNS-Anbieter ist auch die korrekte IPv6 eingetragen.

Allerdings lässt sich die Webseite weder per URL noch per IP von extern aufrufen. Im Access-Log von Nginx ist auch kein Zugriff geloggt. Irgendwie kommen Zugriffe von Extern nicht bei Nginx an, obwohl der Port laut Portscan (der ja auch von extern prüft) offen ist. Und aus dem lokalen Netzwerk beantwortet Nginx brav alle Anfragen und kann die Webseite aufrufen. Sehr mysteriös...

Nachtrag: Offenbar klappt der Zugriff via IPv6 bloß aus meinem mobilen Netz und auch nicht aus dem Netz meiner Arbeitsstelle nicht... Habe mich gerade per AnyDesk in den Rechner meiner Eltern eingewählt (die nicht im lokalen Netzwerk sind) und von dort aus ging es.

 

[thomasschaefer]

Arbeitsstellen sind leider oft noch ohne IPv6 ausgestattet.
Das ist auch der Grund dafür, dass die IPv6 Statistik wöchentlich schwankt und während allgemeiner arbeitsfreier Tage besonders hoch ausfällt.

 

[Photon]

Verstehe, danke für den Hinweis!

 

[KitKat::new()]

Offenbar klappt der Zugriff via IPv6 bloß aus meinem mobilen Netz und auch nicht aus dem Netz meiner Arbeitsstelle nicht...

Hast du bei deinem mobilen Netz IPv6 (de) aktiviert?

 

[Photon]

Ich habe nichts aktiv unternommen, wie kann man denn beim mobilen Netz IPv6 (de)aktivieren?

Nachtrag: Hab's gefunden, in den APN-Einstellungen war IPv4 gewählt, ich habe dann auf IPv4/IPv6 umgestellt und nun klappt es! Danke für den Tipp!