Server nimmt IPv6 nicht an, aber IPv4 läuft – Was läuft hier schief?

    Liebes Forum, :)

    ich habe da ein Problem mit meiner Webseite. Der Server akzeptiert Verbindungen über IPv4 ohne Probleme, aber wenn ich versuche, über IPv6 drauf zu kommen, bekomme ich die Fehlermeldung:

    curl: (7) Failed to connect to example.com port 443 after 12 ms: Couldn't connect to server


    Was ich bisher geprüft habe:

    • Der Server läuft mit Debian GNU/Linux und Apache.
    • Er hat sowohl IPv4- als auch IPv6-Adressen, aber IPv6-Verbindungen scheinen irgendwie blockiert zu werden.
    • Wenn ich mit curl -4 -I https://example.com eine Anfrage mache, bekomme ich die Antwort mit HTTP/2 200 zurück.
    • Bei curl -6 -I https://example.com kommt aber diese Fehlermeldung.

    Ich habe schon Folgendes gecheckt:

    1. Apache-Konfiguration: Der Webserver ist auf Port 443 für sowohl IPv4 als auch IPv6 konfiguriert.
    2. Firewall: Keine Regeln, die IPv6-Verbindungen blockieren (weder auf dem Server noch im Netzwerk).
    3. DNS: Der AAAA-Record ist korrekt gesetzt.

    Hat jemand von euch eine Idee, warum IPv6 nicht funktioniert oder was ich noch nachschauen könnte?

    Wäre super, wenn ihr helfen könntet! :)

    Zitat von ruut

    Er hat sowohl IPv4- als auch IPv6-Adressen, aber IPv6-Verbindungen scheinen irgendwie blockiert zu werden.

    Auch ausgehend? Stimmt das Routensetup?

    Zitat von ruut

    Bei curl -6 -I https://example.com kommt aber diese Fehlermeldung.

    Und der Client spricht auch einwandfrei IPv6, inkl. Routing?

    Zitat von ruut

    Apache-Konfiguration: Der Webserver ist auf Port 443 für sowohl IPv4 als auch IPv6 konfiguriert.

    Und das bestätigt ein Aufruf von "netstat -tuplen"?

    Zitat von ruut

    DNS: Der AAAA-Record ist korrekt gesetzt.

    Und er wird beim Client auch entsprechend aufgelöst?

    Wenn das alles der Fall ist, solltest du dir mal mit tcpdump anschauen, was den Client verlässt, und was den Server erreicht. Vor allem: Schau dir auch den Rückweg an.

    Hallo,

    hier die Infos. Danke wieder voraus. :)

    IPv6 Ziele anpingen funktioniert.

    # ping6 google.com

    PING google.com (2a00:1450:4001:831::200e) 56 data bytes

    64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=1 ttl=120 time=0.627 ms

    64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=2 ttl=120 time=0.700 ms

    64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=3 ttl=120 time=0.677 ms

    ^C

    --- google.com ping statistics ---

    3 packets transmitted, 3 received, 0% packet loss, time 2012ms

    rtt min/avg/max/mdev = 0.627/0.668/0.700/0.030 ms

    # Netzwerk | Adressen sind maskiert

    # ip a


    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host noprefixroute

    valid_lft forever preferred_lft forever

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

    link/ether **:**:**:**:**:** brd **:**:**:**:**:**

    altname enp0s3

    inet **.**.**.**/24 metric 100 brd **.**.**.** scope global dynamic ens3

    valid_lft 21531712sec preferred_lft 21531712sec

    inet6 **:**:**:**:**:**:**:**/48 scope global

    valid_lft forever preferred_lft forever

    inet6 fe80::***:**:****:****/64 scope link

    valid_lft forever preferred_lft forever

    # Routing

    # ip -6 route

    2***:****:*::/48 dev ens3 proto kernel metric 256 pref medium

    fe80::/64 dev ens3 proto kernel metric 256 pref medium

    default via **:**:**:**:**:**:**:** dev ens3 proto static metric 1024 pref medium

    Genereller Hinweis: Es macht Sinn, die Adressen zu anonymisieren, aber nur soweit es für die Anonymisierung nötig ist. So sind fast alle oben stehenden Angaben wertlos. Man erkennt nicht mal, ob das nun Ausgaben vom Server oder vom Client sind.

    Zitat von ruut

    inet6 **:**:**:**:**:**:**:**/48 scope global

    /48 ist bei Netcup ungewöhnlich. Dort gibt es üblicherweise /64 Netze. Das könnte die Ursache für die Probleme sein, wenn damit die Anfragen aus dem gleichen Netz kommen (z.B. von einem anderen Netcup Rechner).

    Zitat von ruut

    default via **:**:**:**:**:**:**:** dev ens3 proto static metric 1024 pref medium

    Auch das ist für Netcup ungewöhnlich, da dort das Gateway üblicherweise auf fe80::1 liegt. Ist das vom Client?

    Ich empfehle, auch die anderen Fragen zu beantworten.

    Das weitere Ergebnis...

    # sudo tcpdump -i ens3 ip6

    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode

    listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144 bytes