Firewall erlaubt keinen IPv6 Zugriff trotz "exposed host"

pcfann

Neuer User
Mitglied seit
25 Apr 2017
Beiträge
31
Punkte für Reaktionen
0
Punkte
6
Hallo,
ich habe seit kurzem einen Glasfaseranschluss von Deutsche Glasfaser. Dieser besitzt keine öffentliche IPv4 Adresse mehr, jedoch möchte ich auf einen Server hinter der Fritzbox (7490) zugreifen.
Hierzu habe ich eine IPv6-Domain auf die IP des Servers gelegt.
Jegliche Ping-Versuche schlagen jedoch fehl.

Ping wird ausgeführt für XXXX.dynv6.net [IPv6-Adresse des Servers] mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für IPv6-Server:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust)

Ich schließe aus der Fehlermeldung, dass der Domainservice einwandfrei funktioniert und die Domain korrekt auflöst, da die Server-IP stimmt. Jedoch kann dann die aufgelöste IPv6-Adresse nicht angepingt werden, obwohl der Server in meiner Fritzbox unter Internet->Freigaben->Portfreigaben=> in den IPv6-Einstellungen als "exposed host" geführt wird (zu testzwecken). PING6 ist dort ebenfalls freigegeben.
Die Fritzbox lässt sich aus dem Internet problemlos anpingen, der Server jedoch nicht.
Hat jemand eventuell eine Idee, was ich falsch mache?
 
Der Server verwendet als IPv6-Adresse auch diejenige, welche die Interface-ID (die wieder aus der MAC-Adresse abgeleitet wird) enthält? Die FRITZ!Box verwendet die neueste Version der Firmware? Das interne "ping6" funktioniert erwartungsgemäß?

Es gibt da durchaus noch ein paar Lücken in der Beschreibung ... und auch die Ansicht des PCP-Protokolls in den Support-Daten kann sicherlich nicht schädlich sein. Ansonsten kann man ja auch problemlos mit dem Paket-Mitschnitt noch kontrollieren, ob die eingehenden Pakete nun bereits an der Firewall der FRITZ!Box scheitern oder ob diese die Pakete sogar noch ordentlich ins LAN "übersetzt" werden (bei IPv6 ja nicht wirklich notwendig, da reicht die richtige MAC-Adresse des Ziels) und dann der Server daran etwas auszusetzen hat. Die sind für ihn eben "extern" - weil ja keine Adresse übersetzt wird, anders als bei IPv4 - und da kann so manche Firewall dann auch etwas pikiert reagieren ... auch hier ist ja im Moment eher Raten angesagt, was das für ein Server sein mag und ob/welche Firewall dort nun wohl verwendet wird. Wobei ... bei einem "exposed host" sollte man schon davon ausgehen dürfen, daß da die Frage nach dem "ob" nicht wirklich notwendig ist.
 
Vielen Dank für die schnelle Rückmeldung. :) Leider bin ich noch relativ neu in diesem Gebiet...

Die Fritzbox verwendet die neueste Version 06.83.
Ein interner Ping an den Server scheint ebenfalls nicht zu funktionieren. Auch generell ist der Server über IPv6 nicht erreichbar, nur über IPv4.
Der Server ist eine Ubuntu virtuelle Maschine(VirtualBox), die mittels einer Lan-Brücke denselben Lan-Port nutzt, wie das Hostsystem. Das Hostsystem ist erreichbar.
Die Option "exposed host" habe ich lediglich in der Fritzbox aktiviert, ich habe aber ebenfalls mit "ufw disable" die Firewall des Servers deaktiviert.

Update:

Es scheint wohl tatsächlich am Server selbst zu liegen. Ein Wireshark Test zeigt diese Antwort:
Code:
Internet Control Message Protocol v6
    Type: Echo (ping) request (128)
    Code: 0
    Checksum: --- [correct]
    [Checksum Status: Good]
    Identifier: ---
    Sequence: 1
    [No response seen]
        [Expert Info (Warning/Sequence): No response seen to ICMPv6 request in frame 320]
            [No response seen to ICMPv6 request in frame 320]
            [Severity level: Warning]
            [Group: Sequence]
    Data (32 bytes)
        Data: ---...
        [Length: 32]

Somit müsste der Router den Ping durchlassen, doch es wird nicht auf ihn geantwortet, sehe ich das richtig? Absender dieses Paketes war der externe Rechner, mit dem ich den Server angepingt habe, als Destination ist die Server-Ip eingetragen.
Damit blockiert dann ja irgendwas im Server die Anfrage über IPv6... Die Firewall des Servers habe ich über "ufw disable" deaktiviert gehabt. Gibt es sonst noch Möglichkeiten, weshalb die Anfrage über IPv6 nicht angenommen wird?

EDIT:
Was ich ebenfalls merkwürdig finde ist, dass ohne etwas zu verändern (ich habe nur sowohl Fritzbox als auch Server neu gestartet, aber dies habe ich auch schon davor mehrmals getan, ohne dass sich etwas verändert..) die Fehlermeldung des Pings nun wie folgt aussieht:
From (IPv6-FRITZBOX) icmp_seq=0 Destination unreachable: Administratively prohibited
 
Zuletzt bearbeitet:
Der Server könnte z.B. einfach mit der falschen IPv6-Adresse konfiguriert sein oder seine Dienste nicht an die extern verwendete Adresse gebunden haben - wobei er bei letzterem sicherlich auf "ping" reagieren sollte, denn das ist ein Dienst des IP-Stacks, der nicht gesondert gestartet werden muß, allerdings gibt es noch diverse Stellen, wo man so etwas blockieren könnte. Ich weiß z.B. gerade nicht (suche jetzt auch nicht extra), ob es auch ein IPv6-Pendant zur Einstellung "net.ipv4.icmp_echo_ignore_all" gibt - zumindest für IPv4 kann man darüber z.B. alle "ping"-Anfragen effektiv abwürgen und die meisten suchen dann erst einmal recht lange, woran das nun wieder liegen könnte.

Ansonsten benutze ich "ufw" nicht, kenne es auch nicht näher und empfinde "uncomplicated" auch als ein Attribut, was wohl eher im Auge des Betrachters liegt - so eine handgemachte Firewall-Konfiguration ist (für mich) eben doch leichter zu realisieren und im Anschluß auch zu lesen/interpretieren.
 
Die IP Adressen werden über DHCP vom Router bezogen.
Ich habe bereits in ufw "sudo ufw default deny incoming" ausgeführt und in ip6tables ebenfalls ein und ausgehende ICMP-ipv6 Verbindungen erlaubt, jedoch ohne Erfolg.
Wireshark liest als Fehler immernoch aus, dass keine Antwort auf echo request gefunden wurden:

[Expert Info (Warning/Sequence): No response seen to ICMPv6 request in frame 16]
[No response seen to ICMPv6 request in frame 16]

Und der Ping von außerhalb des Heimnetzes (auch ohne Dynv6-Domain, direkt mit der IPv6) wird mit der Fehlermeldung "administratively prohibited" abgebrochen.
Innerhalb des Heimnetzes lässt sich der Rechner jedoch nun über seine IPv6 Adresse anpingen (scheinbar dank dem Firewall-Eintrag).

Ich bin leider immoment ziemlich ratlos, was ich noch versuchen konnte. Google hat mir nicht wirklich weiterhelfen können, da die Befehle für die Firewall und ip6tables das Problem nicht gelöst haben.

Kann ich denn irgendwelche weiteren Daten hochladen bzw auswerten, damit sich das Problem konkretisieren lässt?
 
Ich kenne - wie geschrieben - "ufw" nicht ... wenn ich müßte, dann würde ich immer direkt in die resultierenden "iptables"-Chains schauen, z.B. mit "iptables-save". Aber das muß schon ein ziemlich merkwürdiges Stück Software sein, wenn die Anweisung "deny incoming" am Ende dazu führt, daß da eingehender Verkehr erlaubt wird mit einem "deny". Das ist mir zu hoch.

Ansonsten ist ein "administratively prohibited" normalerweise ein Zeichen dafür, daß irgendeine Firewall die Pakete für diesen Port eben nicht forwarden will ... ob die Nachricht nun von der FRITZ!Box-Firewall kommt oder doch das Ergebnis Deiner Experimente mit "deny incoming" ist, kann ich nicht sagen (das zeigt ja wieder der Mitschnitt, woher die Antwort nun wirklich kommt) - ich fände letzteres zumindest beruhigend, weil das mein Weltbild bzgl. "allow" und "deny" wieder in die richtigen Bahnen lenken würde.

Ich könnte mir noch vorstellen (aber für "ufw" gibt es sicherlich auch irgendwo eine Dokumentation und wenn nicht, muß man sich halt die iptables-Chains ansehen), daß mit "default" irgendwelche Standardregeln eingerichtet werden, die zumindest ein "ping" aus dem lokalen Netz zulassen - aber ggf. nur für "link local"-Adressen und die fangen bei IPv6 eben anders an als global gültige.

Es mag ja sein, daß diese "ufw" bei IPv4 irgendwie "uncomplicated" konfiguriert werden kann, wie der Name suggerieren soll ... ist denn überhaupt sicher, daß dieses Paket auch für IPv6 korrekt arbeitet? Anders als bei IPv4 kann man da ja schon an der Adresse festmachen, ob ein Request nun "von außen" kommt oder irgendwo aus dem eigenen LAN - wenn da "ufw" passende Regeln nicht nur anhand des Interfaces und anhand der Chain erzeugen sollte, sondern auch die unterschiedlichen IPv6-Adresstypen einbezieht, dann kann selbst so ein "ping" auf eine "global unicast"-Adresse am Ende schiefgehen.

So direkt beim Einstieg in das IPv6-Thema sollte man auch erst einmal einiges lesen, bevor man mit Experimenten beginnt - da sind schon gewaltige Unterschiede zu IPv4 vorhanden. Das geht schon beim DHCP los und endet bei SLAAC und automatischer Suche von Routern auch noch lange nicht. Ich weiß nicht, wie man "relativ neu" nun bewerten soll ... aber wenn da wirklich Ratlosigkeit aufkommt, würde ich mir anstelle vergeblicher Konfigurationsversuche eher eine für mich verständliche Einführung in IPv6 inkl. "unique local unicast", "global unicast", "link local" und "multicast" (für SLAAC und im Prinzip alles, was mit "neighborhood discovery" zusammenhängt) suchen und damit erst einmal meinen Server so konfigurieren, daß die notwendigen Dienste lokal im LAN unter der passenden Adresse und auf dem passenden Port erreichbar sind.

Dann kann man sich immer noch daran machen, diese Dienste in der FRITZ!Box dann freizugeben. Man kann zwar nicht alle IPv4-Erfahrungen vergessen ... aber es ist auch lange nicht so, daß jemand so etwas mit IPv6 automatisch auch richtig konfigurieren kann, wenn er es mit IPv4 konnte. Die Konzepte sind eben doch wesentlich anders - gerade wenn es um NAT und "connection tracking" geht.
 
Zuletzt bearbeitet:
... wird mit der Fehlermeldung "administratively prohibited" abgebrochen.
Code:
... From (IPv6-[color=red]FRITZBOX[/color]) icmp_seq=0 Destination unreachable: Administratively prohibited ...

Teste mal in deinem LAN, ob die FritzBox den Hostnamen des Servers (wie in der IPv6-Freigabe eingetragen/verwendet) auch auf die global gültige IPv6-Adresse (mit der freigegebenen Interface-ID) auflösen kann.

Code:
host -t AAAA <hostname>.fritz.box

Wenn nicht, dann mit z. B. nsupdate (oder gleichwertig) das (als Test) mal machen.

BTW: Wo genau hast Du wireshark verwendet?
Der Server ist eine Ubuntu virtuelle Maschine(VirtualBox), die mittels einer Lan-Brücke denselben Lan-Port nutzt, wie das Hostsystem. Das Hostsystem ist erreichbar.
Kannst Du das Hostsystem, _per IPv6_ aus dem Internet erreichen?

EDIT:

Versuch mal auch mit:
Code:
sudo ip6tables -I INPUT [color=red]1[/color] -p ipv6-icmp -j ACCEPT
sudo ip6tables -I OUTPUT [color=red]1[/color] -p ipv6-icmp -j ACCEPT
statt ufw, und danach mit:
Code:
sudo ip6tables -nvx -L
 
Zuletzt bearbeitet:
Ein Ping aus dem Heimnetz an Server.fritz.box wird auf eine IPv6 Adresse aufgelöst, diese steht bei ifconfig beim Interface enp0s3 in der dritten Zeile(B:B:B:B:B:B:B:B):
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.178.49 netmask 255.255.255.0 broadcast 192.168.178.255
inet6 A::A:A:A:A prefixlen 64 scopeid 0x20<link>
inet6 B:B:B:B:B:B:B:B prefixlen 64 scopeid 0x0<global>
inet6 B:B:B:B:C:C:C:C prefixlen 64 scopeid 0x0<global>


Die unteren beiden Adressen lassen sich beide aus dem Heimnetz anpingen, von außen jedoch nicht. Der Dynv6 Hostname wird auf die obere Adresse aufgelöst, während Seiten zum IP-Adresse abfragen mir bei dem Server die untere Adresse als meine Adresse anzeigen.

Das Hostsystem kann ich nur per IPv4 aus dem Internet erreichen. Ein IPv6 Ping schlägt ebenfalls fehl.

sudo ip6tables -nvx -L

gibt folgende Übersicht zurück:
https://de.**********ca/3808245
//EDIT:
//Schade, derLink zum hochgeladenen Text wird wohl nicht angezeigt... Die Funktion Anhang anhängen funktioniert bei mir auch nicht, und einen konnte ich auch nicht finden... Ist es erlaubt, wenn ich jetzt sage dass der Link auf pastebin verweisen sollte?:rolleyes:



Den Wireshark-Mitschnitt habe ich über die capture-Funktion der Fritzbox auf der "Schnittstelle 0 Internet" erzeugt.

137 7.715444 externer_Rechner_IPv6 Server-Adresse(B:B:B:B:B:B:B:B) ICMPv6 94 Echo (ping) request id=0xa47d, seq=0, hop limit=250 (no response found!)
138 7.715526 IPv6-ROUTER externer_Rechner_IPv6 ICMPv6 142 Destination Unreachable (Administratively prohibited)

ebenfalls getestet habe ich die "untere" Adresse:

38 8.611484 externer_Rechner_IPv6 Server-Adresse(B:B:B:B:C:C:C:C) ICMPv6 94 Echo (ping) request id=0x9a7e, seq=0, hop limit=250 (no response found!)
39 8.611565 IPv6-ROUTER externer_Rechner_IPv6 ICMPv6 142 Destination Unreachable (Administratively prohibited)
 
Zuletzt bearbeitet:
Ein Ping aus dem Heimnetz an Server.fritz.box wird auf eine IPv6 Adresse aufgelöst, diese steht bei ifconfig beim Interface enp0s3 in der dritten Zeile(B:B:B:B:B:B:B:B):
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.178.49 netmask 255.255.255.0 broadcast 192.168.178.255
inet6 A::A:A:A:A prefixlen 64 scopeid 0x20<link>
inet6 B:B:B:B:B:B:B:B prefixlen 64 scopeid 0x0<global>
inet6 B:B:B:B:C:C:C:C prefixlen 64 scopeid 0x0<global>


Die unteren beiden Adressen lassen sich beide aus dem Heimnetz anpingen, von außen jedoch nicht. Der Dynv6 Hostname wird auf die obere Adresse aufgelöst, während Seiten zum IP-Adresse abfragen mir bei dem Server die untere Adresse als meine Adresse anzeigen.

Das Hostsystem kann ich nur per IPv4 aus dem Internet erreichen. Ein IPv6 Ping schlägt ebenfalls fehl.

Du hast mich nicht richtig verstanden. Es geht nicht um den Dynv6-Hostname, sondern um das DNS bzw. rDNS des Hostnamen im (W)LAN und um die globale IPv6-Adresse, mit der FritzBox als DNS-Server.



Den Wireshark-Mitschnitt habe ich über die capture-Funktion der Fritzbox auf der "Schnittstelle 0 Internet" erzeugt.

Versuch mal auf dem Ubuntu-Host bzw. in der VM, mit z. B.:
Code:
sudo tcpdump -vvveni <Interface> icmp6 and '(ip6[40] == 128) or (ip6[40] == 129)'
 
Parallel möchte ich noch einmal auf die Support-Daten hinweisen ... dort findet sich im PCP-Abschnitt dann die Aufstellung, welche IPv6-Adressen von extern erreichbar sein soll(t)en und auf welchen Ports bzw. mit welchen Protokollen. Es gab ja irgendwo anders auch mal Probleme, als da jemand nicht die aus Prefix und Interface-ID gebildete IPv6-Adresse verwenden wollte und die Firmware ihn dann bei irgendeiner Erneuerung (solche "refreshs" finden bei PCP in regelmäßigen Intervallen statt, iirc bei der FRITZ!Box alle 120 Sekunden) überstimmte und anstelle der eingestellten Adresse die mit der Interface-ID freigab. Das muß es hier nicht auch sein, aber der aktuelle "Schnappschuß" in den Support-Daten sollte zumindest Auskunft geben, ob es nun an der nicht stattfindenden Weiterleitung der Pakete an sich liegt oder ob bereits die Konfiguration anders aussieht, als man es erwartet.

- - - Aktualisiert - - -

PS: Ich mag mich ja extrem glatt anstellen ... aber welcher Service soll sich denn hinter der zensierten URL verbergen bzw. warum muß man dazu eigentlich über einen externen Dienstleister irgendwo anders nachsehen? Das hat ja parallel auch noch den Nachteil, daß so ein Link früher oder später gar nicht mehr funktionieren wird und dann die "Nachnutzer" dieses Threads sich das auch nicht mehr ansehen können - das ist keine wirklich sinnvolle Lösung.

Wenn das Arbeiten mit Anhängen aus irgendwelchen Gründen nicht funktionieren sollte (wobei es ja auch auffallen sollte beim Korrekturlesen, wenn so eine URL "zensiert" wird), dann gibt es hier einige Threads, wo das thematisiert wurde.

EDIT:
OK, inzwischen steht es oben ... besser ist es aber, wenn Du die Sache mit den Anhängen hier im Forum in Ordnung bringst - das Argument mit dem "Verschwinden" externer Links ist ja nach wie vor gültig.
 
Zuletzt bearbeitet:
sudo tcpdump -vvveni <Interface> icmp6 and '(ip6[40] == 128 ) or (ip6[40] == 129)'

Bei einem Ping vom externen Rechner erscheint dort nichts. Wenn ich aus dem Heimnetz über IPv6 pinge kommen dort die Pings mit ICMP6 Paketen an.


Meintest du dies mit der Auflösung des Hostnamen im Lan?:
root@Server:/home/# host -t AAAA Servername.fritz.box
Servername.fritz.box has IPv6 address 2a00:X:X:X:A:A:A:A
Servername.fritz.box has IPv6 address 2a00:X:X:X:B:B:B:B

Und an welcher Stelle der Supportdaten müsste ich dort suchen bzw. nach welchem Stichwort? Ich würde nur ungerne die kompletten Supportdaten ins Internet stellen.
 
Zuletzt bearbeitet:
Meintest du dies mit der Auflösung des Hostnamen im Lan?:
root@Server:/home/# host -t AAAA Servername.fritz.box
Servername.fritz.box has IPv6 address 2a00:X:X:X:A:A:A:A
Servername.fritz.box has IPv6 address 2a00:X:X:X:B:B:B:B

Ja. Hast Du privacy extensions aktiviert? Weil hier zwei globale IPv6-Adressen (mit dem IPv6-Präfix) aufgelöst werden?
Wie wird die Interface-ID generiert? Evtl. mit:
Code:
slaac hwaddr
?

Funktioniert aus dem (W)LAN auch das rDNS? Z. B. so:
Code:
:~$ dig -x <globale-IPv6-Adresse-Server> @192.168.178.1 +short
<Servername>.fritz.box.
 
:~$ dig -x <globale-IPv6-Adresse-Server> @192.168.178.1 +short
<Servername>.fritz.box.

Liefert mir die IPv4-Adresse des Servers im Lan.
Ich habe in /etc/sysctl.d/10-ipv6-privacy.conf die Werte
Code:
net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0
eingestellt.
"slaac hwaddr" habe ich in /etc/dhcpd.conf eingestellt, vorher stand dort private.
Jetzt müssten die privacy extensions doch aus sein, richtig?
Bei
Code:
host -t AAAA Servername.fritz.box
erhalte ich nun 4 IPv6 Adressen, statt 2:
Code:
Server.fritz.box has IPv6 address 2a00:6020:X:X:A:A:A:A
Server.fritz.box has IPv6 address 2a00:6020:X:X:B:B:B:B
Server.fritz.box has IPv6 address 2a00:6020:X:X:C:C:C:C
Server.fritz.box has IPv6 address 2a00:6020:X:X:D:D:D:D






Was ich allerdings ebenfalls etwas seltsam finde, sind die Adressen des Servers in der Fritzbox(Ende abgeschnitten):
ipv6.PNG
Wieso hat der Server so viele Adressen?
 

Anhänge

  • ipv6.PNG
    ipv6.PNG
    5 KB · Aufrufe: 12
Und an welcher Stelle der Supportdaten müsste ich dort suchen bzw. nach welchem Stichwort? Ich würde nur ungerne die kompletten Supportdaten ins Internet stellen.
Das war auch mehr der Hinweis, daß Du selbst in diesen Daten nachsehen sollst - die sind nun nicht wirklich schwer zu interpretieren ... aber unabhängig davon zitiere ich mich einfach einmal selbst und hebe dabei dann den wesentlichen Teil des Satzes typographisch hervor, vielleicht bringt Dich das auf die richtige Idee?

PeterPawn schrieb:
[...] dort findet sich im PCP-Abschnitt dann die Aufstellung [...]

Aber ich verabschiede mich dann ohnehin erst einmal ... was ich zu schreiben hatte, habe ich geschrieben und nachdem nun Probleme mit der IP-Konfiguration des Servers und der Namensauflösung ausgeschieden sind (oder zumindest mir die Phantasie fehlt, wo das Problem nach erfolgreicher Namensauflösung und offensichtlich konfigurierten IP-Adressen nun noch liegen mag, wenn es nicht die - für mich immer noch unbekannte - Firewall-Konfiguration ist), ist das für mich durch, bis neue Fakten oder Testergebnisse vorliegen.

Auch mit dem zusätzlichen "Hinweis", daß es sich um "Pastebin" handeln würde (wobei ein "pastebin" eben eher eine Kategorisierung für eine Webanwendung ist), kann ich nichts anfangen ... wieso sollte eine solche URL für den bekanntesten Dienst (den unter der com-Domain) nun auf einmal mit "de." beginnen und unter einer kanadischen Domain laufen? Also wird es wohl irgendein anderer "pastebin"-Service sein und dafür fehlt mir immer noch die Phantasie (inkl. Zeit und Wille), um da nun alle in Frage kommenden URLs durchzuspielen.

Wobei auch die Maskierung aller Teile von IPv6-Adressen hinter dem zugewiesenen Präfix recht überflüssig ist bei solchen Problemen - bei der ausgehenden Adresse für die eigene Internet-Benutzung des Servers ist das i.d.R. ohnehin eine mit "privacy extensions", die sich regelmäßig ändert (zumindest sollte man das so konfiguriert haben) und bei der freigegebenen Adresse mag zwar die Interface-ID auch die MAC-Adresse enthalten, aber dann kann man immer noch deren Hexadezimal-Ziffern gezielt ersetzen und wenigstens die Anzeige drin lassen, ob das nun die IID nach RFC 4291 (Anhang A) ist oder nicht und auch die "Struktur" der Adressen erhalten.

Ansonsten ist es ohnehin so, daß die L2-Adresse genau bis zum nächsten Router Verwendung findet - es ist zwar nicht vollkommen falsch, daß man mittels der MAC-Adresse auch tracken kann, aber spätestens bei der "Veröffentlichung" einer Server-Adresse im Internet (und sei es über den MyFRITZ!-Service, bei dessen Benutzung jede E-Mail von der Box dann auch den DynDNS-Namen bei diesem Service enthält) ist dann auch diese IID bekannt.

Das gesamte IPv6-System ist nun einmal für die eineindeutige Adressierung praktisch jedes Netzteilnehmers gedacht und gegen das Tracken der Netznutzung so eines IPv6-Clients gibt es diese "privacy extensions", bei denen eben auch so ein Server bei eigenen Anfragen ins Internet nicht mit seiner "eingehenden" Adresse operiert, sondern mit einer zufälligen, die auch noch in regelmäßigen Abständen gewechselt wird. Für Server-Dienste braucht es ohnehin eine eindeutige und feste Adresse, theoretisch ist da aber nicht einmal die Benutzung einer auf der Basis der MAC-Adresse generierten IID zwingend (RFC 7136), aber diese Form wird halt am häufigsten verwendet und ist auch für den Gebrauch mit der FRITZ!Box zu empfehlen. Es macht aber praktisch gar nichts, wenn man diese IID ohne den zugehörigen Präfix dann auch "veröffentlicht" in irgendwelchen Beiträgen - wer paranoid ist (das muß nichts Schlechtes sein), sollte dann aber auch bei solchen Maskierungen immer darauf achten, daß der Adressat des eigenen Textes durch die vorgenommenen Maskierungen nicht daran gehindert wird, die eigentlichen Fehler zu entdecken oder gezwungen wird, weitere Nachfragen zu stellen (das findet der dann auch nicht mehr komisch auf Dauer).

@sf3978:
Ich bin etwas verwirrt ... welchen Zusammenhang kann es zwischen der Reverse-Auflösung eines (lokalen) DNS-Namens und einer IPv6-Freigabe für einen Service (oder meinetwegen auch den kompletten Host) ins Internet geben? Ich habe da ein(e/n) "missing link".

- - - Aktualisiert - - -

@pcfann:
Gibt es irgendeinen Grund, warum Du die "privacy extensions" jetzt ausgeschaltet hast?
 
... welchen Zusammenhang kann es zwischen der Reverse-Auflösung eines (lokalen) DNS-Namens und einer IPv6-Freigabe für einen Service (oder meinetwegen auch den kompletten Host) ins Internet geben?
Bei _meiner_ FritzBox(-cable) funktioniert die IPv6-Freigabe nicht, mit einer per "slaac hwaddr" vom Client generierten Interface-ID, wenn die FritzBox die lokale Namensauflösung für die globale IPv6-Adresse des Clienten, nicht machen kann.
 
Ich habe leider nicht wirklich viel Erfahrung mit IPv6 generell...

Ist dies hier der korrekte Ausschnitt aus dem PCP-Abschnitt?
Zeile 8956:

Code:
MAP  ICMPv6 [IP-A]:128 [IP-A]:128 use 1, lifetime 120 secs, expire in 83 secs
     uniqid 7412, cfgflags ignore_proxy_errors
     nonce xxxxxxxxxxxx
     desc "Ping Servername"
     wanted_lifetime 120 lifetime 120
     pid 2745 caddr [IPv6 eines per Wlan verbundenen Handys?]

Die IP-A setzt sich aus dem IPv6-Präfix und der
Code:
 inet6 fe80::X:X:X:X prefixlen 64  scopeid 0x20<link>
Adresse zusammen.


Um nochmal zur Ausgangsfrage zurückzukommen:
Ich möchte lediglich erreichen, dass ich meinen Cloud-Server hinter der Fritzbox von unterwegs aus erreichen kann. VPN ist leider keine Möglichkeit, da es an einigen Endgeräten nicht gestattet ist.
IPv4 kann ich nichtmehr verwenden, da mein neuer ISP mir keine öffentlich erreichbare IPv4 mehr gibt bzw. er mehrere Benutzer in einem NAT bündelt. Somit kann auf meine öffentliche IPv4 nicht zugegriffen werden, weshalb ich nun gezwungenermaßen zu IPv6 wechseln möchte.
Könnte das Problem der Erreichbarkeit des Servers denn noch an irgendetwas anderem liegen, oder was genau müsste ich nun machen, um ihn von unterwegs aus erreichen zu können?
 
Könnte das Problem der Erreichbarkeit des Servers denn noch an irgendetwas anderem liegen, oder was genau müsste ich nun machen, um ihn von unterwegs aus erreichen zu können?

Mach mal eine IPv6-Freigabe für den Ubuntu-Host (Client der FritzBox) und teste, ob Du diesen per icmp6 aus dem Internet erreichen kannst. Wenn das nicht funktioniert, dann hast Du entweder die IPv6-Freigabe in deiner FritzBox nicht richtig konfiguriert oder/und ist evtl. auch dein Ubuntu für die Erreichbarkeit per IPv6 aus dem Internet, nicht richtig konfiguriert.

Wenn das geklärt ist, kann man weiter nach dem Server in der VM schauen.
 
Ich habe in der Fritzbox-Oberfläche nun unter Internet->Freigaben->Portfreigaben->Freigabe für neues Gerät->Mein Rechnername die Option "Ping6 freigeben" angekreuzt. Ein Test ergibt, dass ein Ping ebenfalls mit "administratively prohibited" abgewiesen wird. Ein Wireshark-Mitschnitt der Schnittstelle 0 'internet' zeigt das gleiche Ergebnis, wie auch der Mitschnitt des Pings an den Server.

Code:
46    6.381464   IPv6-extern    IPv6-Rechner    ICMPv6    94    Echo (ping) request id=0x9a2d, seq=0, hop limit=250 (no response found!)
47    6.381544    IPv6-Router    IPv6-extern    ICMPv6    142    Destination Unreachable (Administratively prohibited)

Ausgehende Verbindungen meines Rechners werden über dieselble IPv6-Adresse, die ich angepingt habe, aufgebaut (Wireshark-Mitschnitt).
 
Ausgehende Verbindungen meines Rechners werden über dieselble IPv6-Adresse, die ich angepingt habe, aufgebaut

Wie ist die Interface-ID dieser IPv6-Adresse? Hast Du diese Interface-ID in deiner FritzBox, auch für die IPv6-Freigabe konfiguriert?
 
Also ich musste die Interface-ID von Hand eingeben, die Fritzbox hat diese nicht automatisch ermitteln können (bei anderen Geräten war dieses Feld früher immer automatisch ausgefüllt?).
Die Interface-ID habe ich mit Hilfe eines Online-Tools aus der MAC-Adresse aus "ipconfig /all" (Windows) berechnen lassen.
 

Statistik des Forums

Themen
244,640
Beiträge
2,215,725
Mitglieder
371,219
Neuestes Mitglied
csgaming
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.