[SOLVED] Eigenen Server über IPv6 öffentlich erreichen. Wie Schnittstellen-ID fest definieren?

  • Hallo zusammen,


    mein Provider war so "freundlich" und hat ohne Vorankündigung in einer Nacht und Nebel Aktion meinen Anschluss auf IPv6 umgestellt. Ich hatte/habe zwar in meiner FritzBox noch eine IPv4 Adresse, kann diese von anderen Providern aus nicht erreichen (Dual-Stack-Betrieb mit NAT).


    Deshalb habe ich nun auf IPv6 umgestellt.

    Ich habe eine .de Domain. Diese bekommt über einen DynDNS Dienst (im Moment noch manuell später evtl. wieder über Fritz!Box 7490 oder Cronjob) ein AAAA Register (TTL 900) mit der aktuellen public IPv6 Adresse meines Servers. A Register Eintrag wurde entfernt, da IPv4 ja nicht mehr geht.

    Das funktioniert auch schon - bis zur Zwangstrennung.


    Dadurch bekomme ich eine neue Präfix- und Teilnetz-ID zugewiesen. Soweit auch kein Problem. Bei IPv4 gibts ja auch alle 24 Stunden eine neue - daher ja DynDNS.


    Jedoch ändert sich damit auch meine gesamte Public IPv6 Adresse, also auch die Schnittstellen-ID meines Servers. Das wäre ja auch nicht so schlimm, das könnte er ja auch über einen Cronjob aktualisieren. Das Problem daran: In der Fritz!Box ist die Schnittstellen-ID fürs NAT erforderlich. Ich müsste also alle 24 Stunden die NAT Regel bearbeiten und dort die aktuelle Schnittstellen-ID, was ich natürlich nicht will.


    Demnach müsste ich wohl die IPv6 Adresse(n) an meinem Xubuntu 16.04 Server fest vergeben damit diese mit der in der Fritz!Box hinterlegten übereinstimmt. Allerdings bin ich bei IPv6 noch nicht ganz so fit (wie wohl die meisten hier) und hoffe auf eure Unterstützung. Ich bin schon froh, dass ich die Umstellung in ca. 3 Stunden hinbekommen habe.



    Kleines Beispiel wie die IP-Adressen sich geändert haben:

    23.01 - 2a01:5c0:18:3b91:9d21:3e85:ba80:ea7e

    24.01 - 2a01:5c0:1e:e371:93aa:aa9d:c1ff:37b4


    Bitte erspart mir Diskussionen zum Thema NAT vs Firewall. Ist bekannt; andere Baustelle.


    P.S.: Dass das ganze IPv6 Thema noch nicht ausgereift, zeigt sich hier mal wieder. Von Vodafone (DSL & LTE) aus habe ich ca. 70% Signalverlust beim Ping. Andere Online Test und Telekom (nicht mein Provider) sind jedoch stabil und schnell. Somit kann das ja nicht an mir sondern nur am Routing zwischen Vodafone und meinem Provider liegen.


    VDR:
    HW: ASUS M3N78-EM (NV-GF8300) • 4GB DDR2 • AMD Athlon II X4 • 32GB SSD • 4TB HDD • 2x Hauppauge WINTV Nova-HD-S2

    SW: easyVDR3.0 64Bit stable based on Ubuntu 14.04 Trusty Tahr • Kodi 17 Krypton • VDPAU • SoftHDDevice

  • Du hast offensichtlich auf deinem Server die IPv6 Privacy Extensions aktiviert. Dadurch werden nach Ablauf einer gewissen Zeit immer wieder neue IPv6 Suffixe erzeugt. Für einen Server taugt das nicht.

    Wenn die Privacy Extensions deaktiviert sind, erzeugt der Host eine dauerhaft konstantes Suffix aus der MAC Adresse der Netzwerkschnittstelle. Die FritzBox bekommt es hin, dass entsprechende Portfreigaben nach einem Präfixwechsel erhalten bleiben. Man erkennt diese Adresse an den Bytes FF:FE in der Mitte des Suffixes.

    Je nach OS hat man auch mit aktivierten PEs eine zusätzliche konstante Adresse. Dann reicht es, in der FritzBox diese einzusetzen.

  • Danke, das ist doch mal ein guter Hinweis.

    Von "PE" habe ich auch schon was gelesen, jedoch wurde dabei die Abkürzung nicht erklärt und somit hat mir das nichts gesagt.

    Hatte mich eh schon gewundert, warum bei mir nicht die MAC Adresse im Suffix aufgetaucht ist (was ja bei Linux und Apple angeblich Standard ist).


    Habe mal die Datei /etc/sysctl.d/10-ipv6-privacy.conf wie folgt angepasst (2 auf 0 geändert = Privacy Extensions nicht aktiv):


    net.ipv6.conf.all.use_tempaddr = 0

    net.ipv6.conf.default.use_tempaddr = 0


    Ich teste mal und melde mich wieder.




    VDR:
    HW: ASUS M3N78-EM (NV-GF8300) • 4GB DDR2 • AMD Athlon II X4 • 32GB SSD • 4TB HDD • 2x Hauppauge WINTV Nova-HD-S2

    SW: easyVDR3.0 64Bit stable based on Ubuntu 14.04 Trusty Tahr • Kodi 17 Krypton • VDPAU • SoftHDDevice

  • Kann man dafür nicht die link-local Adresse benutzen? Die sollte sich doch eigentlich nicht ändern, oder?

    Ich versuche auch immer mal wieder, mich in IPv6 einzulesen, aber es scheitert auch regelmäßig... :)


    Lars.

  • Kann man dafür nicht die link-local Adresse benutzen? Die sollte sich doch eigentlich nicht ändern, oder?

    Ich versuche auch immer mal wieder, mich in IPv6 einzulesen, aber es scheitert auch regelmäßig... :)


    Lars.


    Eins vorweg: Meine Antwort basiert auf gefährlichem Halbwissen


    Die Link-Local Adresse ist wie der Name ja schon sagt lokal und wird nicht geroutet. In den AAAA Register meiner .de Domain muss demnach ein globale Adresse die auch von außen erreichbar ist.

    Und jetzt wende ich gleich mal mein neu gelerntes Wissen an:

    Auch die Bildung der Link-Local Adresse hängt davon ab, ob die Privacy Extensions aktiviert sind oder nicht. Wenn nicht wird sie nach EUI-64 aus der MAC-Adresse gebildet (und ist damit für diesen PC immer eindeutig).

    Ist PE aktiviert dann wir diese nach RFC 4941 generiert. Scheint jedoch dabei für immer gültig zu sein (was jedoch in meinem Anwendungszenario nichts bringt weil nur lokal).


    ip -6 addr



    VDR:
    HW: ASUS M3N78-EM (NV-GF8300) • 4GB DDR2 • AMD Athlon II X4 • 32GB SSD • 4TB HDD • 2x Hauppauge WINTV Nova-HD-S2

    SW: easyVDR3.0 64Bit stable based on Ubuntu 14.04 Trusty Tahr • Kodi 17 Krypton • VDPAU • SoftHDDevice

  • Das mit der link-local Adresse (not routed) ist doch nach meinem (auch Halb)-Wissen auch erstmal in Ordnung, man kann ja IIRC mittels DHCPv6 drüber bügeln ... ?


    Regards

    fnu

    HowTo: APT pinning

  • Ich dachte an Portforwarding an die link-local Adresse. Die ändert sich nicht (PE deaktivieren sollte man ja sowieso auf dem Server) und dann braucht man wie bisher nur die Adresse des Routers.


    Mit unser aller Halbwissen wird das schon... :)


    Lars

  • Wieder einen Schritt weiter....

    Leider habe ich mit der oben geschriebenen Änderung noch immer keine eindeutige Interface-ID bekommen. Obwohl selbst im GUI die IPv6-Privatsphärenerweiterung deaktiviert war.


    Ich musste noch unter /etc/NetworkManager/system-connections/"Meine Verbindung"

    Von addr-gen-mode=stable-privacy auf addr-gen-mode=eui64 ändern.

    Sollte ip6-privacy nicht auf 0 stehen dann das auch noch ändern (das entspricht in der GUI der IPv6 Privatspohären... Einstellung)


    Vielleicht hilft es ja jemanden.


    ------------------------------


    Momentan habe ich noch ein Problem mit DynDNS.

    Die FritzBox und mein Provider können zwar beide IPv6. Jedoch übergibt die FritzBox mit dem Parameter <ip6addr> natürlich nur Ihren Präfix ohne die Interface-ID meines Servers.

    Hänge ich nun die Suffix/Interface-ID einfach an die Update-URL an, funktioniert dies leider nicht. Vermutlich endet <ip6addr> mit ::/60. Wenn ich daran dann noch die Interface-ID anhänge passt das natürlich nicht.

    Leider sind die Infos im Netz hier sehr rar. Evtl. Frage ich mal bei AVM nach.



    Von Hand kann ich so aktualisieren:

    Code
    https://passwort:user@ddns.do.de/?hostname=geheim.de&myip=2a01:5c0:10:84f1:1234:12ff:fe12:1234

    Dann werde ich mir wohl ein Skript schreiben und das dann über CronJob automatisieren.


    VDR:
    HW: ASUS M3N78-EM (NV-GF8300) • 4GB DDR2 • AMD Athlon II X4 • 32GB SSD • 4TB HDD • 2x Hauppauge WINTV Nova-HD-S2

    SW: easyVDR3.0 64Bit stable based on Ubuntu 14.04 Trusty Tahr • Kodi 17 Krypton • VDPAU • SoftHDDevice

    Einmal editiert, zuletzt von fnu ()

  • Bei IPv6 ist es so vorgesehen, dass der Dyndns Dienst auf deinem Server läuft. Die Fritzbox kümmert sich nur um die Löcher in ihrer Firewall und um sich selbst.

    Danke. So werde ich es auch machen. Entweder durch einen vorhandenen Client oder ich schreibe mir ein kurzes Script.



    Das bedeutet am Schluss aber auch, dass man für jedes einzelne Gerät, welches man von außen erreichen will ein eigenes DynDNS Konto benötigt.

    Früher verwies der über DynDNS gesetzte A Record einer Domain auf die IP-Adresse der Fritzbox. Über NAT konnte man dann verschiedene Geräte hinter der Fritzbox (WebCam, VDR, NAS...) zugreifen.

    Da nun der AAAA Record bis zum Endgerät geht ist dies nicht mehr möglich. Kann das Endgerät kein IPv6 (wie meine WebCam), hat man gleich ganz verloren. Selbst wenn das Gerät IPv6 kann, dafür aber kein DynDNS unterstützt (Drucker, Webcams, und das IoT Gedöns halt) wird es schwierig (klar wenn man einen richtigen Server hat kann der den Eintrag auch setzen).


    Finde ich jetzt nicht so Toll.


    Lustig, dass man doch von Laien immer wieder hört, das quasi jedes Gerät mit IPv6 direkt im Internet hängt.


    VDR:
    HW: ASUS M3N78-EM (NV-GF8300) • 4GB DDR2 • AMD Athlon II X4 • 32GB SSD • 4TB HDD • 2x Hauppauge WINTV Nova-HD-S2

    SW: easyVDR3.0 64Bit stable based on Ubuntu 14.04 Trusty Tahr • Kodi 17 Krypton • VDPAU • SoftHDDevice

    2 Mal editiert, zuletzt von Mehlwurmdieb ()

  • Aber das müsste doch trotzdem noch gehen, oder? Du musst halt nur die IPv6 der FB per DynDNS irgendwo eintragen und dann ein Portforwarding auf deinen Server machen. Dann sollte er unter der einen FB-IP erreichbar sein. Und verschiedene Ports kannst du dann auf verschiedene Rechner weiterleiten.


    Lars.

  • Gerade getestet, scheint aber nicht zu funktionieren:


    Ich komme zwar auf die FritzBox über Port 444 wenn ich den Zugriff von außen zulasse:


    https://[2a01:5d1:13:d380::1]:444 *IP Geändert





    https://[2a01:5d1:13:d380::1]:888 wird jedoch nicht an meine IPv4 Webcam weiter geleitet.


    P.S.: Habe auch die volle Public IPv6 (also mit Suffix/Interface-ID) getestet. Geht auch nicht.



    Aber vielleicht mache ich ja auch was falsch.


    VDR:
    HW: ASUS M3N78-EM (NV-GF8300) • 4GB DDR2 • AMD Athlon II X4 • 32GB SSD • 4TB HDD • 2x Hauppauge WINTV Nova-HD-S2

    SW: easyVDR3.0 64Bit stable based on Ubuntu 14.04 Trusty Tahr • Kodi 17 Krypton • VDPAU • SoftHDDevice

  • Habe dazu mal etwas hier gefunden:


    Zitat
    1. NAT von 6 nach 4:Rein Theoretisch kann man auch die Globale IPv6 Adresse benutzen um Pakete zu empfangen und die dann an einen IPv4 Rechner weiterleiten Das funktioniert wie oben für IPv4 beschrieben nur das die IP die im Internet ist ein IPv6 Adresse ist. Es gibt Erweiterungen für IP-Tabels die das können. Da soetwas nur von wenigen gebraucht wird ist es nicht in dem offiziellen iptables Paket enthalten.

    Ok, du scheinst Recht zu haben. Aber nur in der Theorie. In der Praxis hat man dann einen 200€ Router bei dem man nicht die benötigte iptables Erweiterung installieren kann (sofern die FritzBox überhaupt intern iptables nutzt). Dabei finde ich den Bedarf eigentlich nicht so exotisch, siehe mein letzter Post.


    VDR:
    HW: ASUS M3N78-EM (NV-GF8300) • 4GB DDR2 • AMD Athlon II X4 • 32GB SSD • 4TB HDD • 2x Hauppauge WINTV Nova-HD-S2

    SW: easyVDR3.0 64Bit stable based on Ubuntu 14.04 Trusty Tahr • Kodi 17 Krypton • VDPAU • SoftHDDevice

  • Kann das Endgerät kein IPv4 (wie meine WebCam)

    Ah, ok, da hast du dich wohl verschrieben, die Webcam kann kein IPv6. Du willst von außen per IPv6 auf ein internes IPv4-Gerät zugreifen...


    Wenn du nicht direkt auf die Webcam forwarden kannst, könntest du deinen Server entsprechend das Umsetzen von IPv6 auf v4 machen lassen. Also den Port per IPv6 auf deinen Server weiterleiten und dort den Port dann (mit dem passenden iptables) auf die IPv4 der Webcam.


    Lars.

  • Ja, da habe ich mich verschrieben, danke für den Hinweis. Hab auch noch kein Gerät gesehen, dass nur IPv6 kann. Ich fixe das gleich.


    Klar kann ich über den Server viel machen. Aber es ist alles mit sehr viel mehr Aufwand verbunden als mit v4.

    Und nicht jeder hat einen Server bzw. ist dieser 24/7 in Betrieb.


    VDR:
    HW: ASUS M3N78-EM (NV-GF8300) • 4GB DDR2 • AMD Athlon II X4 • 32GB SSD • 4TB HDD • 2x Hauppauge WINTV Nova-HD-S2

    SW: easyVDR3.0 64Bit stable based on Ubuntu 14.04 Trusty Tahr • Kodi 17 Krypton • VDPAU • SoftHDDevice

  • Das kann sicherlich auch ein RPi als Gateway/Router hinter der Fritzbox machen, um deine IPv4-Geräte in dein IPv6-Netz zu bringen. Muss ja nicht gleich ein "dicker" Server sein.


    Lars.

  • Klar. Aber der Otto-Normal Windoofie bekommt das sicher nicht mehr hin. Und kaufen und den zusätzlichen Strom bezahlen muss man auch.


    Ich setze den Thread mal auf erledigt und danke allen für die super Unterstützung.


    Ich werde aber sehr gerne hier weiter über die Hürden der Umstellung und meine Erfahrungen damit berichten und mit euch darüber diskutieren. Wer weiß, vielleicht wird ja der nächste morgen zwangsumgestellt.

    Ich sehe es als sportliche Herausforderung und mit IPv6 wollte ich mich sowieso schon länger beschäftigen. Das was ich wollte funktioniert ja soweit (bis auf das Vodafone Routing Problem). Auf die Kamera muss ich jetzt nicht unbedingt von außen drauf oder mach wie angesprochen ne Weiterleitung am Server.

    Ich fand es jedoch schon dreist von meinem Provider dies nicht vorab anzukündigen.


    P.S.: Für 5€ mehr gäbe es auch bei meinem Provider auch ne fixe IPv4. Letzten Endes zögert man das unvermeidliche damit aber ja auch nur raus.


    VDR:
    HW: ASUS M3N78-EM (NV-GF8300) • 4GB DDR2 • AMD Athlon II X4 • 32GB SSD • 4TB HDD • 2x Hauppauge WINTV Nova-HD-S2

    SW: easyVDR3.0 64Bit stable based on Ubuntu 14.04 Trusty Tahr • Kodi 17 Krypton • VDPAU • SoftHDDevice

  • Bei Gelegenheit werde ich mal die angesprochene Weiterleitung nach dieser Anleitung einrichten und hier Meldung machen.


    Bitte auch meinen vorherigen Post nicht falsch verstehen. Das Gelöst habe ich gesetzt, weil das ursprünglich Angefragte Thema längst erledigt ist und sich der Thread in eine allgemeine Diskusion gewandelt hat (welche ich auch gerne fortführe).


    VDR:
    HW: ASUS M3N78-EM (NV-GF8300) • 4GB DDR2 • AMD Athlon II X4 • 32GB SSD • 4TB HDD • 2x Hauppauge WINTV Nova-HD-S2

    SW: easyVDR3.0 64Bit stable based on Ubuntu 14.04 Trusty Tahr • Kodi 17 Krypton • VDPAU • SoftHDDevice

  • one step forward, two steps back


    Mein Provider hat mir gerade eben eine Rückstellung meines Anschluss auf eine öffentlich erreichbare IPv4 mitgeteilt. Ich hatte vor zwei Tagen das schlechte Routing zwischen ihm und Vodafone bemängelt (siehe erster Post). Das wahr wohl die einfachste Art der Problemlösung für den Provider :huh:


    So wie es aussieht gibt es wirklich noch massive Probleme bei den Providern und Router Firmwares. Ich bin froh über die IPv6 Erfahrung und trotzdem auch froh auf die Rückumstellung zu V4, lasse V6 aber weiterhin im DualStack aktiv.
    Die Erlebnisse der letzten Tage zusammengefasst:


    Die kurze Version:

    Ein stabiler Betrieb war nicht möglich.

    Kann das auf meine Cloud zugreifende Gerät kein IPv6 oder der Provider kann es nicht (bzw. Provider kann es aber es ist nicht beim Kunden im Router aktiviert) -> Kein Zugriff möglich. Das sollen in Europa aktuell noch ca. 50-80% der Anschlüsse sein! Deckt sich auch mit Google: Aktuell in Deutschland 35% V6 fähig.

    Lange Latenzen, bis hin zu 70% Signalverlust bei sonst absolut stabilen Internetverbindungen auf beiden Seiten (Routing Problem)


    Das sind alles Probleme, auf die man leider keinen Einfluss hat. Ich weiß ja nicht, was der Empfänger meiner OwnCloud Freigabe für einen Anschluss oder Gerät hat.


    Spätestens, wenn man Dienste für andere anbietet ist IPv6 in meinen Augen am Privatanschluss absolut unbrauchbar.


    Es fühlt sich ein bisschen so an wie der Umstieg von ISDN/Analog auf VoIP. Tausche bewährtes gegen unausgereiftes. Natürlich ist mir die Notwendigkeit von IPv6 bewusst.




    Die lange Version:

    FrizBox

    • Meine eigene FritzBox macht keine Namenslösung auf meine Domain mehr (unknown host). Nach einem Neustart hat sie zumindest einmal versucht auf einen dann natürlich veralteten AAAA Eintrag zuzugreifen, danach wieder unknown host. Intern habe ich normalerweise über /etc/hosts die Domain auf die IPv4 des Servers umgeleitet. Da sonst der gesamte Traffic vom PC zu meiner Cloud über das Internet läuft. Würde ich im Client am PC die IP Adresse statt der Domain verwenden, wäre das Zertifikat ungültig (abweichender Domainname).
    • Einmal war die FritzBox online, jedoch war selbst kein Ping/Zugriff auf die public IPv6 Adresse meines Servers möglich. Reboot tat gut.
    • Eine Änderung des Präfixes kam beim Server nicht an. Somit hatte die public IPv6 Adresse des Servers noch den alten Präfix. Verursacht vermutlich durch kurz aufeinanderfolgende Interneteinwahlen. Ich gehe davon aus, dass dies kein Fehler ist, sondern dass die IPv6 Adresse für mindestens zwei Stunden als gültig definiert war. Intern über Hostname keine Verbindungsaufbau mehr auf den Server; nur über IPv4 Adresse noch möglich. Lösung Serverneustart.


    Provider:

    • Android Handy: Zugriff über WLAN möglich (sofern Namensauflösung funktioniert), D2/Vodafone kann kein IPv6 :wand. Sollte eigentlich Ende 2017 eingeführt werden. Vergleich: iPhone mit D1-Netz - Wenige Minuten nach der DynDNS Aktualisierung alles OK
    • Vodafone DSL: An einem getesteten Standort total instabil


    DNS:

    • Subjektiv gefühlt verteilt sich ein IPv4 Eintrag schneller auf alle DNS-Server im Internet als ein IPv6. In der Praxis wir wohl vermutlich die Aktualisierung von IPv4 Adressen klar priorisiert.



    Und das sind nur die Probleme, die ich ein einer halben Woche bemerkt habe. Unter IPv4 lief alles über Jahre ohne Probleme.


    Also ganz Ehrlich, wenn euch keiner dazu zwingt. spart euch den Stress und die Zeit und macht was Sinnvolleres (mach ich jetzt auch). Lasst erst mal die Banane IPv6 bei den Providern reifen. Für dieses Anwendungszenario ist es momentan einfach zu füh. Wer nur Surft hat damit aber keine Probleme (Achtung: Gaming ist wohl auch so ne Sache, mach ich aber nicht)



    P.S.: Habe heute bei einem Kunden auch mit dem dortigen Netzwerkadmin (ein wirklich sehr Fähiger) darüber geredet. Auch er hat mir Bestätigt, dass das NAT von IPv6 auf IPv4 nicht mit der FritzBox geht. Über iptables wie angedacht ist es machbar.


    VDR:
    HW: ASUS M3N78-EM (NV-GF8300) • 4GB DDR2 • AMD Athlon II X4 • 32GB SSD • 4TB HDD • 2x Hauppauge WINTV Nova-HD-S2

    SW: easyVDR3.0 64Bit stable based on Ubuntu 14.04 Trusty Tahr • Kodi 17 Krypton • VDPAU • SoftHDDevice

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!