Tücken der Freigabe von Diensten (Webserver, etc.) bei IPv6 mit der FritzBox

Barungar schrieb:
Die andere Adresse sollte "privacy-stable" sein, also auch "verschleiernd", aber doch stabil. Ohne Privacy würde die IPv6 per EUI-64 erzeugt, die ist dann definitiv stable.
Zum Vergrößern anklicken....
Leider hat sich die IPv6 geändert :-(

Code: 
  inet6 2001:xxxx:xxxx:xxxx:5d62:a41f:dd37:b645/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 6932sec preferred_lft 3332sec
 
Gut, in dem Fall musst Du privacy komplett abschalten. Das sollte eine IPv6 nach EU64 erzeugt werden, damit kommt dann auch die FritzBox besser klar.

Weißt Du wie es geht bei Deinem Linux? Ich kann Dir auf jeden Fall versichern, dass es stets geht bei Linux.
 
Das werde ich schon rausfinden wie das geht. Habe nur gerade nicht allzuviel Zeit. Wenn ich es rausgefunden habe beschreibe ich es hier.
 
Eigentlich müsste doch die 3b29:9e7c:4b4c:869b/64 die richtige Host ID sein. Ist die einzige welche keine TTL hat von den IPv6 hier
 
Fusion schrieb:
Eigentlich müsste doch die 3b29:9e7c:4b4c:869b/64 die richtige Host ID sein. Ist die einzige welche keine TTL hat von den IPv6 hier
Zum Vergrößern anklicken....
Das ist die Link Lokale Adresse, die hilft in keiner Weise, wenn Du einen Server im Internet erreichbar machen möchtest.
Die gilt ausschließlich im lokalen (Layer 2) Segment des Netzes.

Und im Privacy-Modus muss es auch keinen Zusammenhang zwischen HostID und LLA geben.
Nur, wenn das Hosts komplett "sauber" alles per EUI-64 generiert, gilt Deine Aussage.
 
Dann vermute ich, dass dort die Privacy Extentsions abgeschaltet sind.
Was auf einem Server "grundsätzlich" sinnvoll ist, bei einem Server möchte man ja grundsätzlich eher nicht, dass sich regelmäßig die IP ändert. Das ist ja eher der Fluch der privaten Server. ;-)
 
Jetzt sieht es wie folgt aus:

Code: 
ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:xxxx:xxxx:xxxx:ba27:ebff:feb4:e874/64 scope global dynamic noprefixroute
       valid_lft 7197sec preferred_lft 3597sec
    inet6 fd00::ba27:ebff:feb4:e874/64 scope global dynamic noprefixroute
       valid_lft 7197sec preferred_lft 3597sec
    inet6 fe80::ba27:ebff:feb4:e874/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Wie man sieht ist der lokale IPv6 Teil bei GUA, ULA und LLA gleich.

Was habe ich geändert:
Code: 
sudo nmcli connection modify "Wired connection 1" ipv6.ip6-privacy 0 ipv6.addr-gen-mode eui64
sudo nmcli connection up "Wired connection 1"

Jetzt beobachte ich das noch mal. Aber ich bin mir ziemlich sicher dass die IPv6 jetzt konstant ist.
 
framp schrieb:
Wie man sieht ist der lokale IPv6 Teil bei GUA, ULA und LLA gleich.
Zum Vergrößern anklicken....
Genau, weil nun für alle Präfixe die EUI-64 verwendet werd. Damit bist Du natürlich nicht mehr anonym.
Weil selbst der Host-Anteil Deiner IPv6-Adresse so eindeutig ist, dass selbst wenn Du das Präfix wechselst, ein (Werbe-)Tracker oder sonstiger Deanonymisierer wiedererkennen könnte.

Wie Du siehst, hat auch die Anzahl der IPv6-Adressen abgenommen. Es wird nun nur noch eine IPv6 je Präfix gebildet.

framp schrieb:
Jetzt beobachte ich das noch mal. Aber ich bin mir ziemlich sicher dass die IPv6 jetzt konstant ist.
Zum Vergrößern anklicken....
Das brauchst Du nicht mehr... die EUI-64 ist absolut stabil! Die wird nämlich aus der MAC der Netzwerkkarte bestimmt, und bleibt so lange gleich, wie die MAC. ;)
 
Nur mal so einen Hinweis: Als ich nur IPV4 bei mir aktiv hatte, konnte ich ohne Probleme auf mein OpenVPN von remote zugreifen. Alles per IPv4.
Über mein Mobile komme ich immer noch ohne Probleme. Wenn ich aus meinem Netz @home zum Testen per GUA versuche zu connecten, klappt das nur, wenn ich am System IPv6 disable. So wie ich es sehe muss ich in OpenVPN auch noch was zu IPv6 konfigurieren :(

Dazu habe ich jetzt gerade keine Lust. Ich habe ja einen Workaround. Es ist aber schon festzustellen, dass man sich schon auf Änderungen einstellen muss, wenn man bei sich IPv6 aktiviert. Ich bedauere es nicht - ich will ja IPv6 kennenlernen. Aber ich verstehe Leute, die die Aktivierung scheuen.
 
Das "Problem" kannst Du auch ganz einfach lösen, in dem Du für Dein OpenVPN eine Hostname verwendest, der keinen AAAA-Eintrag hat. Der "Fehler" ist, dass Du vermutlich einen Hostname verwendest, der einen A und einen AAAA Record hat. In diesem Fall wird der Client eine IPv6-Verbindung bevorzugt versuchen... findet er nur einen A Record, so wird er eine IPv4-Verbindung machen.

Großartig konfigurieren musst Du da eigentlich nicht, Du musst beim OpenVPN-Server eigentlich nur IPv6 aktivieren. Du bist deswegen ja nicht gezwungen auch im VPN-Tunnel IPv6 zu aktivieren. Der OpenVPN-Server muss lediglich bei IPv4 UND IPv6 auf eingehende Verbindungen auf seinem Port lauschnen.
 
Ahh ... jetzt verstehe auch warum da A-AAAA bei meinem DynDNS Provider steht. Einen A Eintrag unterstützt der leider nicht. D.h. bei dem RR Eintrag wird erst IPv6 probiert. Aber warum findet dann kein Fallbackup aif IPv4 statt? Hätte ich vermutet.

Barungar schrieb:
Du musst beim OpenVPN-Server eigentlich nur IPv6 aktivieren
Zum Vergrößern anklicken....
Klar. Habe ich auch schon nachgesehen wie :) , aber dazu habe ich eben wirklich keine Lust bzw Zeit. Das gehe ich an wenn ich mal wieder mehr Zeit habe.
 
framp schrieb:
Aber warum findet dann kein Fallbackup aif IPv4 statt? Hätte ich vermutet.
Zum Vergrößern anklicken....
Das entscheidet der Client... also sowohl was er nimmt, die meisten bevorzugen IPv6 und wie er im Fehlerfall ein Fallback macht.
Firefox z.B. wenn es zu einer Webseite einen AAAA und A Record erhält, versucht erst eine IPv6-Verbindung und wenn das fehlschlägt versucht er nach einer Zeit X eine IPv4-Verbindung.
 
Irgendwo muss man allerdings doch noch werkeln oder ein Auge drauf haben.
Habe gerade mal ein openVPN server getestet der IPv4 im Tunnel spricht und via IPv4/IPv6 ansprechbar ist.
Allerdings setzt der keine IPv6 route, vermutlich ist deshalb der client mit seiner öffentlichen Mobilfunk IPv6 bei Gegenstellen im Netz sichtbar. IPv4 im remote LAN Geräte erreichen ist kein Problem.

Muss man also den Traffic durch das VPN zwingen, je nach Wunsch.
 
Es kommt halt auf das Ziel an, wenn man "nur" sicher auf sein Heimnetz zugreifen will und nicht allen Verkehr des Endgerätes durch das VPN "zwingen" will, braucht es die Route auch nicht.
 
Sind also zwei paar Dinge die zu konfigurieren sind:

1) Den OpenVPN Server sowohl per IPv4 als auch IPv6 zu finden
2) Sämtlichen Traffic des Clients sowohl per IPV4 als auch IPv6 zu tunneln
 
Naja, Punkt 2 halt nur, wenn Du mit dem VPN auch bezwecken willst, das zwingend aller Datenverkehr durch das VPN geleitet wird.
Mir geht es bei einem VPN nach Hause in der Regel darum, dass ich auf mein Heimnetz zugreifen will, nicht das ich meinen gesamten Verkehr umleite.
 
Um auf deutsche Mediatheken zuzugreifen ist es z.b. ganz nett, wenn man über den Anschluss zu Hause gehen kann. In dem Fall wäre es blöd, wenn die IPv6 am Tunnel vorbei funkt.
In allen anderen Fällen reicht mir, wenn ein Weg auf die Ziele im remote LAN führt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
7.962
Beiträge
78.231
Mitglieder
8.641
Neuestes Mitglied
CarryBeckmann

Teilen

Zurück
Oben