Hallo zusammen,
ich melde hier ein wiederkehrendes Problem mit der IPv6-Erreichbarkeit meines VS2-free Servers, da mein gebuchter Tarif laut Support keinen kostenpflichtigen E-Mail-/Telefon-Support beinhaltet. Kontodaten (Kundennummer, Vertragsnummer) sende ich zur Verifizierung per PN, um sie hier nicht öffentlich zu posten.
Server: `srv****.blue.kundencontroller.de`
IPv6: `2a02:180:6:1::2**`
Symptome:
- Server über IPv6 nicht erreichbar (SSH-Timeout, Cloudflare Tunnel zeigt "offline").
- Web-Reset über das Kundencenter behebt das Problem nicht.
- Globale Erreichbarkeitstests zeigen während der Störung Nichterreichbarkeit von praktisch allen getesteten Standorten weltweit.
Bisheriger Verlauf:
- Erste Störung: [20.09]
- Behoben am 22.09., nachdem ich über das Kundencenter eine komplette Neuinstallation des Betriebssystems durchgeführt habe (Konnektivität kehrte unmittelbar danach zurück).
- Zweite, aktuell andauernde Störung: seit dem 23.09.
Technische Diagnose (erste Störung):
Ich habe einen anderen EUserv-Kunden gebeten, per mtr von seinem eigenen EUserv-Server aus (also innerhalb Ihres Netzwerks, ohne externen Transit) sowohl seine eigene Adresse als auch meine anzupingen, zum direkten Vergleich:
- Zu seinem eigenen Server: vollständig erfolgreich, 0% Paketverlust am letzten Hop.
- Zu meinem Server: identischer Pfad durch Ihr Netzwerk bis zum Knoten `2a02:180:6:9::5`, danach Abbruch mit "no route to host".
Zusätzlich habe ich externe Traces von zwei unabhängigen Netzwerken durchgeführt (Oracle Cloud, Hetzner) — beide liefen über komplett unterschiedliche Upstream-Pfade (einmal via Tata/AS6453, einmal via HE/Zayo/AS6939), liefen aber exakt am selben internen Knoten (`2a02:180:6:9::5`) zusammen, bevor sie fehlschlugen. Das deutet stark auf einen fehlenden oder veralteten Routing-/Neighbor-Table-Eintrag für meine spezifische IP-Adresse hin, nicht auf ein externes Transit- oder Peering-Problem.
Aktuelle Situation (23.09.) — vermutlich größeres Problem:
Die Störung ist nach nur ca. 24 Stunden erneut aufgetreten, was darauf hindeutet, dass die Ursache beim letzten Mal nicht vollständig behoben wurde. Zusätzlich beobachte ich heute:
1. Ein befreundeter EUserv-Kunde kann sich ebenfalls nicht per SSH auf seinen eigenen Server verbinden — das Problem scheint also nicht auf meinen Account beschränkt zu sein.
2. support.euserv.com selbst liefert ein fehlerhaftes SSL-Zertifikat (Port 80 funktioniert, Port 443 nicht): Der Browser zeigt `ERR_CERT_COMMON_NAME_INVALID`. Das ausgelieferte Zertifikat ist für `euserv.de` / `*.euserv.de` ausgestellt (Let's Encrypt, ausgestellt am 04.09.2026, gültig bis 04.12.2026 — also nicht abgelaufen), wird aber für die Domain `euserv.com` ausgeliefert. Das deutet für mich auf ein Fehlkonfigurationsproblem im Bereich SNI-Routing / Load-Balancer / Zertifikatszuordnung hin — nicht auf ein abgelaufenes Zertifikat.
Angesichts dieser gleichzeitig auftretenden Probleme (mein Server, der Server eines anderen Kunden, und die eigene Support-Website) vermute ich, dass es sich heute um ein größeres, netzwerk- oder infrastrukturweites Problem handelt und nicht um ein isoliertes Problem meines Accounts.
Könnte sich bitte jemand aus dem Netzwerk-Team die Routing-/Neighbor-Table-Einträge in der Nähe von `2a02:180:6:9::5` ansehen? Vollständige mtr-Ausgaben und weitere Traces stelle ich gerne auf Anfrage zur Verfügung.
Vielen Dank für Ihre Zeit,
Mitsu