Plötzliche Probleme mit IPv6: Server von aussen nicht mehr erreichbar, Ping nach aussen geht...

  • Hallo zusammen.


    Ich habe seit gestern ein eigenartiges Problem:

    Eine Verbindung von extern auf meinen Server per IPv6 Adresse klappt nicht mehr.


    Jedes ping6 oder traceroute6 arbeitet der Server ohne Probleme ab, (ipv6.google.com z.B.)

    Problematisch wird's, wenn ich mich auf den Server verbinden will: Dann sagt mir leider jedes Tool "Netzwerk nicht erreichbar".


    Auf dem Server läuft ein VPN (StrongSwan), das auch IPv6 tunnelt (und nebenbei alles aus dem VPN an der Firewall vorbeischläust).

    Logge ich mich ins VPN ein, so kann ich den Server per IPv6 Adresse wiederum einwandfrei ansprechen.


    Ich habe mal das Notfallsystem gebootet. Die Netzwerkkarte bekommt dort nur die Standard-IPv4. Wenn ich den dhclient -6 aufrufe, bleibt er beim aquire hängen.


    Ist das ein Zeichen, dass nei Netcup die IPv6 Verteilung nicht funktioniert? Oder gibt es noch andere Möglichkeiten zu überprüfen, warum die Welt meint, dass es meine IPv6 nicht gibt?


    Leider funktioniert IPv6 bei Unity auch nicht so wunderprächtig, und im mobilen Netz habe ich auch immer wieder Aussetzer. Dementsprechend bin ich mir gerade nicht sicher, wer den nun wieder der Schuldige ist...


    Gruß,

    _X_

  • Ich glaube, ich habe ein ähnliches Problem. Ich habe in den Netzwerkeinstellungen meiner beiden Server am Wochenende neue Domains eingetragen und die Server sind bis jetzt nicht zu erreichen. Es kam zwar ein Hinweis, dass der Eintrag bis zu 48 Stunden dauern kann aber die auch schon lange rum.

    Die Hotline habe ich angerufen, aber sie scheint kein Interesse zu haben mir zu helfen. Sie sagte, von Ihrer Seite aus ist alles OK es müsse an den Servereinstellungen oder an I+n+w+x liegen. Ich habe bei dem einen Server verschiedene Images von Netcup ausprobiert, die alle das gleiche Problem aufweisen, damit kann es ja schonmal nicht an "meinen" Servereinstellungen liegen. An I+n+w+x liegt es mit Sicherheit auch nicht. Da habe ich über 20 Domains gebucht, die alle auf verschiedene Server verweisen und nur die bei Netcup funktionieren nicht. Der Support am Telefon war unter aller Kanone. Er zielte von der ersten Minute nur darauf ab, mich schnell wieder los zu werden. Man hat schon die Zuständigkeit abgewimmelt, bevor ich mein Problem überhaupt richtig schildern konnte. Schwach.

  • Hay,

    Ich habe in den Netzwerkeinstellungen meiner beiden Server am Wochenende neue Domains eingetragen und die Server sind bis jetzt nicht zu erreichen.


    zunächst einmal haben xplod und jlaatz zwei komplett unterschiedliche Dinge... aber sowas von unteschiedlich :)

    Ist das ein Zeichen, dass nei Netcup die IPv6 Verteilung nicht funktioniert? Oder gibt es noch andere Möglichkeiten zu überprüfen, warum die Welt meint, dass es meine IPv6 nicht gibt?


    IPv6 solltest Du auf dem Server statisch konfigurieren, damit fallen eine Vielzahl von Problemen weg:

    https://www.netcup-wiki.de/wik…sse_konfigurieren#IPv6%7C


    Ich glaube, ich habe ein ähnliches Problem.

    Nicht mal ansatzweise.


    Ich habe in den Netzwerkeinstellungen meiner beiden Server am Wochenende neue Domains eingetragen und die Server sind bis jetzt nicht zu erreichen.

    Man trägt in die Netzwerkeinstellen eines Servers keine Domains ein (maximal einen Hostnamen).


    Was Du meinst, ist ganz bestimmt der DNS - und dann stimmt auch der Bezug auf die 48h. Da helfen auch keine neuen Images weiter


    (Es sei denn, Du betreibst einen eigenen DSN. Anhand Deiner Formulierungen glaube ich das aber nicht. Dann nutzt Du den Netcup-DNS im CCP. Wenn nicht, bitte hier detaillierter ausführen).


    Du solltest einfach mal Deine DNS-Einstellunge posten, dann kann man Dir sicher weiterhelfen. Doch bei der Art, wie Du das Problem schilderst (und verschiedene Sachen durcheinanderwürfelst), macht es einem sehr schwer zu erkenne, welches eigentlich Deine Frage ist - insofern habe ich mildes Verständnis für einen Supportmitarbeiter, der mit einem dickem "Hä???" über dem Kopf zugehört hat. Freilich muss ein guter Support dann die richtigen Fragen stellen um aus dem "Hä?" ein "Ha!" zu machen und da sehe ich hier eher das Versäumnis.


    CU, Peter

  • Jedes ping6 oder traceroute6 arbeitet der Server ohne Probleme ab, (ipv6.google.com z.B.)

    Problematisch wird's, wenn ich mich auf den Server verbinden will: Dann sagt mir leider jedes Tool "Netzwerk nicht erreichbar".

    1. Wie CmdrXay schon schrieb, statisches Konfigurieren der IPv6 Adressen, des Präfix und des Gateways wird helfen.

    2. Wenn Du zwar nach draussen ping6en kannst, aber von draussen mit obiger Fehlermeldung nicht zu Deinem Server kommst, dann hat Dein Server höchstwahrscheinlich eine falsche IPv6-Adresse als Quelladresse eingetragen, oder es funktioniert NDP nicht ganz so, wie es soll. Hast Du bereits statische Adressen eingetragen, könnte es ein simpler Typo sein. (warum Du trotzdem pingen kannst, liegt wohl am linklokalen Gateway fe80::1 oder an der ULA).

    3. 2. war ein Blick in meine Kristallkugel, die mir aber sonst nichts über Deine Voraussetzungen und Gegebenheiten erzählt.

    ░▒▓Blog: https://grundsoli.de/▓▒░

    ░▒▓Netcup-Gutscheine: https://hosting-groupie.de/▓▒░

    ░▒▓Educom Invites: http://bit.ly/3792TX9▓▒░

  • IPv6 solltest Du auf dem Server statisch konfigurieren, damit fallen eine Vielzahl von Problemen weg:

    Alle IP-Adressen (je eine V4 und V6) sind statisch konfiguriert.

    Beim Server war eine IPv6 Address-Range von 64Bit enthalten, diese gehört auch zu Netcup (2a03:4000::x)


    Im SCP habe ich die Adresse gelöscht und neu angelegt, aber das hat scheinbar nichts gebracht.

    Im SCP ist als gateway fe80::1 angegeben, diese habe ich so übernommen. Wenn ich eine IPv6 IP traceroute ist 2a03:4000:23::2 der erste Hop.


    Ein Traceroute auf ipv6.google.com wird komplett aufgelöst. Ein traceroute auf meine Fritzbox hingegen nicht...

    Auch meine Fritzbox kann ipv6.google.com auflösen (allerdings mit anderer IP). Die Verbindung zu meinem Server klappt aber auch nicht.

    Bei einem traceroute von meinem PC auf meinen Server sehe ich nichts, was ansatzweise nach Netcup aussieht (dafür sehr viele Sternchen)...


    Über https://www.subnetonline.com/p…ools/online-ipv6-ping.php wiederum kann ich meinen Server erreichen.

    Es sieht also so aus, als ob Deutschlandweit irgendwo eine Vermittlungsstelle abgebrannt wäre...


    Ich habe gerade spaßeshalber mal einen DNS-Lookup für Netcup gemacht, und auch deren IPv6 (2a03:4000:0:0:0:0:0:e013) kann nicht angepingt werden...

    Hat niemand von euch das gleiche Problem? Hab ich meine IPv6-Rechnung nicht bezahlt :heul:

  • Im SCP habe ich die Adresse gelöscht und neu angelegt, aber das hat scheinbar nichts gebracht.

    Du meinst, Du hast im SCP den Reverse-DNS-Eintrag gelöscht?!

    Etwas anderes (außer geroutete Präfices und Failover-Prefices) kann man wohl nicht löschen.


    2. Fritzbox - hat Dein Provider daheim natives IPv6 oder verwendest Du einen Tunnelbroker oder 6to4? Dann würde ich dort einmal zu debuggen beginnen - wegen asymmetrischer Routen am dortigen Anycast-Gateway.

    ░▒▓Blog: https://grundsoli.de/▓▒░

    ░▒▓Netcup-Gutscheine: https://hosting-groupie.de/▓▒░

    ░▒▓Educom Invites: http://bit.ly/3792TX9▓▒░

  • Du meinst, Du hast den Reverse-DNS-Eintrag gelöscht?!

    Ja, genau das. Ansonsten sehe ich nur die 64Bit Range der IP, und kann nichts anderes mehr einstellen...

    Es sah erst so aus, als ob die Netcup Router nicht wüssen, was sie mit meiner IPv6-Range anfangen sollten...

  • Ja, genau das. Ansonsten sehe ich nur die 64Bit Range der IP, und kann nichts anderes mehr einstellen...

    Der Reverse Eintrag (ip6.arpa) hat nichts, aber schon gar nichts mit dem Routing zu tun.

    Das im SCP angezeigte IPv6-Prefix ist nicht durch Dich selbst änderbar.


    Sind weitere Zuteilungen vorhanden (gebuchte zusätzliche Präfices, Failover-Subnets?)

    ░▒▓Blog: https://grundsoli.de/▓▒░

    ░▒▓Netcup-Gutscheine: https://hosting-groupie.de/▓▒░

    ░▒▓Educom Invites: http://bit.ly/3792TX9▓▒░

  • Der Reverse Eintrag (ip6.arpa) hat nichts, aber schon gar nichts mit dem Routing zu tun.

    Das im SCP angezeigte IPv6-Prefix ist nicht durch Dich selbst änderbar.


    Sind weitere Zuteilungen vorhanden (gebuchte zusätzliche Präfices, Failover-Subnets?)

    Nein, keine weiteren Zuteilungen...


    Erstaunlicherweise hatte ich gerade wieder einen Connect über IPv6 aus dem 1+1 Netz. Somit scheint irgendwie Unitymedia Probleme zu haben. Aber warum bin ich der einzige, der das bemerkt?

  • Probier einmal via https://lg.netcup.net/ zu debuggen -> dann an den Support. Vielleicht gibt's ja wirklich ein Routingproblem. Ohne konkrete Infos kann ich leider als Aussenstehender auch nicht helfen.

    ░▒▓Blog: https://grundsoli.de/▓▒░

    ░▒▓Netcup-Gutscheine: https://hosting-groupie.de/▓▒░

    ░▒▓Educom Invites: http://bit.ly/3792TX9▓▒░

  • Beim Server war eine IPv6 Address-Range von 64Bit enthalten

    Dass IPv6 Adressen 128 Bit breit sind, schenke ich mir mal.

    Die 64 Bit auf die du abzielst, sind wahrscheinlich die Subnetzmaske.


    Im SCP ist als gateway fe80::1 angegeben, diese habe ich so übernommen. Wenn ich eine IPv6 IP traceroute ist 2a03:4000:23::2 der erste Hop.

    Das ist Absicht und so gewollt.


    So, jetzt brauchen wir hier Informationen:


    - Welches Betriebssystem / Distribution benutzt du?

    - Wie sieht deine Netzkonfiguration aus?

    - Was ist die Ausgabe von ip a?

    - Gibt es Firewallbeschränkungen für ICMP? Sind DROP Policies aktiv?

  • Dass IPv6 Adressen 128 Bit breit sind, schenke ich mir mal. Die 64 Bit auf die du abzielst, sind wahrscheinlich die Subnetzmaske.

    Meinetwegen. Ich meinte den mir zugewiesenen Adressbereich...


    Betriebssystem: Ubuntu 16.04 LTS

    Netzwerk-Konfig ens3 (Treiber steht im SCP auf virtio, Komplett statische IP-Adressen (kein DHCP))

    ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether (mac) brd ff:ff:ff:ff:ff:ff

    inet (ipv4)/22 brd 185.228.139.255 scope global ens3

    valid_lft forever preferred_lft forever

    inet 10.1.1.1/24 brd 10.1.1.255 scope global ens3:1

    valid_lft forever preferred_lft forever

    inet6 (ipv6)/64 scope global

    valid_lft forever preferred_lft forever

    inet6 fe80::3845:5dff:fe8c:b529/64 scope link

    valid_lft forever preferred_lft forever


    ens3:1 wird für einen Zugriff von Windows über einen VPN Tunnel benötigt...

    ip6tables hat die Default-Policy DROP, ICMP echo-request und echo-reply sind explizit freigegeben.

    Bei Teamspeak z.B. sind die gleichen Ports für IPv4 und IPv6 freigegeben, und über IPv4 kann ich mich verbinden, IPv6 klappt nicht.


    Lustigerweise gibt es Leute, die sich über IPv6 verbinden können (z.B. über 1+1). Das Netcup-Lookingglas kann per ping6 normal auf den Server zugreifen...


    Es sieht so aus, als ob irgendeiner der großen Routing-Dienstleister meinen Adressbereich nicht auflösen möchte/kann. Aber ich wüsste nicht, wen man diesbezüglich fragen bzw. eine Störung melden könnte...

  • ens3:1 könntest Du Dir eventuell schenken, wenn Windows das auch auf dem Loopback-Interface akzeptiert. Es sollte an sich nichts ausmachen, aber das Interface hat dieselbe Broadcast-Domain wie ens3 und die private IP hat dort IMO nichts verloren. Freilich kannst Du auch das Gratis cloud VLAN dazubuchen und dessen Interface verwenden. Das ist aber nicht das Hauptthema.


    Die Vorgehensweise mit ICMPv6 solltest Du überdenken. Echo request und echo reply allein genügen nicht für eine funktionierende Neighbor Discovery. https://de.wikipedia.org/wiki/Neighbor_Discovery_Protocol

    Wie gesagt NDP ersetzt ARP in IPv6 und ist Voraussetzung, dass IPv6 überhaupt routen kann. Wenn Dir ip -6 n oder ip -6 n s lauter „incomplete“ Werte ausspuckt, ist das ein sicheres Indiz dafür, dass Du zuviel blockst. Neben Typ 128 und 129 sollten schon auch zumindest Typ 135 und 136 zugelassen sein. Typ 2 ist bei abweichenden MTUs unentbehrlich - ist nur die Frage, ob der Rechner auch als Router fungiert - VPN deutet darauf hin.

    ░▒▓Blog: https://grundsoli.de/▓▒░

    ░▒▓Netcup-Gutscheine: https://hosting-groupie.de/▓▒░

    ░▒▓Educom Invites: http://bit.ly/3792TX9▓▒░

  • ens3:1 könntest Du Dir eventuell schenken, wenn Windows das auch auf dem Loopback-Interface akzeptiert. Es sollte an sich nichts ausmachen, aber das Interface hat dieselbe Broadcast-Domain wie ens3 und die private IP hat dort IMO nichts verloren. Freilich kannst Du auch das Gratis cloud VLAN dazubuchen und dessen Interface verwenden. Das ist aber nicht das Hauptthema.

    Leider nein. Windows mit IKEv2 hat trotz Tunnel die seltsame Eigenschaft, den Datenverkehr zu dem VPN-Server nicht zu verschlüsseln. Quasi alles, was direkt an die Server-IP geht, geht in Klartext raus. Somit muss es leider eine IP geben, auf die der Server hört, und die in jedem Fall durch das VPN geroutet wird...


    eripek wrote:

    Die Vorgehensweise mit ICMPv6 solltest Du überdenken. Echo request und echo reply allein genügen nicht für eine funktionierende Neighbor Discovery. https://de.wikipedia.org/wiki/Neighbor_Discovery_Protocol

    Wie gesagt NDP ersetzt ARP in IPv6 und ist Voraussetzung, dass IPv6 überhaupt routen kann. Wenn Dir ip -6 n oder ip -6 n s lauter „incomplete“ Werte ausspuckt, ist das ein sicheres Indiz dafür, dass Du zuviel blockst. Neben Typ 128 und 129 sollten schon auch zumindest Typ 135 und 136 zugelassen sein. Typ 2 ist bei abweichenden MTUs unentbehrlich - ist nur die Frage, ob der Rechner auch als Router fungiert - VPN deutet darauf hin.

    Ich habe jetzt spaßeshalber alle ICMP Pakete erlaubt, das ändert auch nichts.

    Kann es denn überhaupt eine Fehlkonfiguration sein, wenn z.B. http://ipv6-test.com und https://lg.netcup.net/ die IPv6 richtig auflösen können?


    Mein Server löst z.B auch netcup.de zu "2a03:4000:e013::" auf, mein Rechner zuhause hingegen kann diese IPv6 nicht auflösen...
    Also sieht es so aus, als ob Unitymedia Probleme mit allem hat, was aus dem Netcup Bereich kommt, aber warum bin ich der einzige, dem das auffällt? Kann das mal jemand, der auch bei Unitymedia Kunde ist, verifizieren?

  • Bin auch bei Unitymedia und habe keine Probleme mit IPv6. Wenn ich wieder zu hause bin kann ich deinen Server ja mal anpingen.

    ChestSort: Automatische Kistensortierung in Minecraft - www.chestsort.de


    www.raucher-werden.de - www.serioese-alternative.de - www.jeff-media.de

  • Das ist alles sehr seltsam. Das scheint irgendwas mit 6to4 zu tun zu haben (nutzt meine Fritzbox)...


    Nochmal die Kurzform:

    - Meine Fritzbox kann meinen Server nicht per IPv6 erreichen (auch netcup.de nicht)

    - Mein Server kann meine Fritzbox per IPv6 nicht erreichen (kenne leider keine weitere 6to4 Adresse

    - Meine Fritzbox erreicht allerdings ipv6.google.com

    - Über http://www.ipv6now.com.au/pingme.php kann ich meine Fritzbox und den Server erreichen


    Somit scheint Netcup nicht an dem 6to4 Tunnel "angeschlossen" zu sein, den Unitymedia verwendet. Ich frage heute mal nach, ob ich eine native IPv6 Adresse bekommen kann... Hat jemand noch andere Vorschläge?

  • Das ist alles sehr seltsam. Das scheint irgendwas mit 6to4 zu tun zu haben (nutzt meine Fritzbox)...

    Jetzt beginnt es Sinn zu ergeben: 6to4 benützt als Gateway per Anycast angekündigte IPv4-Server. Dadurch kann es sein, dass v6 Pakete den Weg zurück zum „richtigen“ Gateway nicht finden. Das ergibt genau so einen Blackhole-Effekt, wie Du ihn beschreibst.


    Wäre 6in4, wie es he.net und die anderen noch verbliebenen Tunnelbroker anbieten, eventuell eine Lösung? Dort bekommst Du pro Tunnel einen Prefix, der an ein spezifisches Gateway statisch geroutet wird, womit solche Asymmetrien in aller Regel nicht auftreten können.

    ░▒▓Blog: https://grundsoli.de/▓▒░

    ░▒▓Netcup-Gutscheine: https://hosting-groupie.de/▓▒░

    ░▒▓Educom Invites: http://bit.ly/3792TX9▓▒░


  • Wäre 6in4, wie es he.net und die anderen noch verbliebenen Tunnelbroker anbieten, eventuell eine Lösung? Dort bekommst Du pro Tunnel einen Prefix, der an ein spezifisches Gateway statisch geroutet wird, womit solche Asymmetrien in aller Regel nicht auftreten können.

    Das Problem ist, dass viele Unitymedia Kunden genau dieses Problem mit meinem Server haben.

    Die Leute mit DSL-Lite haben eine native IPv6 Adresse und müssen IPv6 nutzen, da die IPv4-Tunnel massiv Probleme verursachen.

    Meinereiner mit einer nativen IPv4 Adresse hingegen könnte IPv4 bevorzugen, muss es aber verwenden, da die Cloud-Dienste aufgrund der IP-Knappheit immer mehr auf IPv6 setzen werden...


    Das ist doch zum Mäusemelken... 20 Jahre IPv6, und die Provider kriegen es immer noch nicht flächendeckend fehlerfrei hin???

  • Mäusemelken hin oder her - haben diejenigen mit nativem IPv6 auch diese Probleme oder treten die Probleme vermehrt nur bei 6to4 auf?

    6to4 ist eben 6to4 gegen eine Anycast-Adresse (dynamisch), während 6in4 ein spezifisches Providergateway nützt. Die Fritzbox müsste alle diese Varianten, wie eben auch DS-Lite unterstützen.


    BTW: 6to4 mag praktisch sein, weil es etwa in der Fritzbox quasi „auf Knopfdruck“ funktioniert - oder auch nicht, aber 6to4 Anycast gilt seit https://tools.ietf.org/html/rfc7526 als deprecated. Als Workaround wird RFC6555 genannt (Happy Eyeballs - als Fallback).


    Debugging: ein tracepath / traceroute zu 192.88.99.1 sollte offenbaren, wer Dein Relay tatsächlich betreibt. Dort kannst Du das Routingproblem melden - in meinem Fall führt das Anycast etwa zu Cz.net, wie ein Whois auf den vorletzten Hop offenbart. Denen würde ich dann -in meinem Beispiel- je ein tracepath (wegen der MTU) oder MTR in beide Richtungen (IPv6 only) schicken.

    ░▒▓Blog: https://grundsoli.de/▓▒░

    ░▒▓Netcup-Gutscheine: https://hosting-groupie.de/▓▒░

    ░▒▓Educom Invites: http://bit.ly/3792TX9▓▒░