Netcup VPS & Root Server Netzwerk-Troubleshooting: AS197540 MTR, IPv6 fe80::1, MTU & VNC-Recovery

Wenn ein Tippfehler in /etc/netplan/, eine fehlerhafte Änderung an der sshd_config oder eine zu restriktive ufw/nftables-Regel Ihren SSH-Zugang kappt, installieren Sie den Server keinesfalls vorschnell neu. Das Server Control Panel (SCP) von Netcup bietet zwei hardwarenahe Rettungswege, die völlig unabhängig vom Netzwerk-Stack Ihres Gast-Betriebssystems funktionieren.

Innerhalb der chroot-Umgebung des Netcup-Rescue-Systems haben Sie vollen Zugriff auf die Binärdateien und Systemprotokolle Ihrer regulären Installation. Über journalctl -b -1 -u systemd-networkd lesen Sie exakt die Fehlermeldungen des fehlgeschlagenen vorherigen Bootvorgangs aus, während sshd -t Ihre /etc/ssh/sshd_config inklusive aller Drop-in-Dateien vor dem erneuten Starten auf Tippfehler prüft:

• ▪ SCP-Reiter „Screen“ (HTML5-VNC-Konsole): Verbindet sich direkt mit der emulierten QEMU-VGA-Grafikkarte und der PS/2-Tastatur Ihrer laufenden KVM-Instanz. Sofern für Ihren Root- oder Sudo-Benutzer ein lokales Konsolenpasswort vergeben ist, können Sie sich direkt auf tty1 einloggen, ip -br link prüfen oder die Firewall deaktivieren (sudo ufw disable).
• ▪ SCP-Reiter „Media / Rescue System“ (Live-Debian-Netboot): Falls Sie die lokale Passwortanmeldung deaktiviert haben oder der Gast-Kernel nicht mehr bootet (initramfs), aktivieren Sie im SCP das Rescue System. Es startet Ihre VM in ein sauberes Debian-Live-RAM-System mit aktiver Netzwerkanbindung und zeigt im SCP ein temporäres Root-SSH-Passwort an, sodass Sie /dev/vda1 einhängen und jede Datei per chroot reparieren können.

# 1. Nach Aktivierung des Rescue Systems im SCP und SSH-Login als root:
lsblk -f

# 2. Primäre Linux-Root-Partition einhängen (typischerweise /dev/vda1 oder /dev/vda2)
mkdir -p /mnt/sysroot
mount /dev/vda1 /mnt/sysroot

# 3. Falls eine separate /boot- oder /boot/efi-Partition existiert, diese ebenfalls einhängen:
# mount /dev/vda15 /mnt/sysroot/boot/efi

# 4. Virtuelle Kernel-Dateisysteme per Bind-Mount einbinden und in die chroot-Umgebung wechseln
for dir in /dev /dev/pts /proc /sys /run; do
  mount --bind "$dir" "/mnt/sysroot$dir"
done
chroot /mnt/sysroot /bin/bash

# 5. Innerhalb von chroot: Logs prüfen, /etc/netplan oder /etc/ssh/sshd_config korrigieren oder ufw deaktivieren
journalctl -b -1 -u systemd-networkd --no-pager
sshd -t
ufw disable

# 6. chroot sauber verlassen, Dateisysteme aushängen und Rescue System im SCP beenden
exit
umount -R /mnt/sysroot
sync

NAME    FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
vda
├─vda1  ext4   1.0         8b14c9a2-41e0-4d91-9b1a-7c30e192a401  192.4G    18% /mnt/sysroot

Zwei Netcup-spezifische Layer-2/Layer-3-Fallstricke sind für über 75 % aller Netzwerkausfälle nach einem Reboot sowie für abbrechende IPv6-Verbindungen verantwortlich:

Erstens: Beim Upgrade von Debian (11 -> 12) oder Ubuntu (22.04 -> 24.04) benennt systemd-udevd (Predictable Network Interface Names) den virtuellen virtio-net-Adapter häufig von eth0 in ens3 (oder enp0s3) um. Ist in /etc/netplan/01-netcfg.yaml fest eth0: ohne MAC-Adressen-Abgleich eingetragen, schlägt die Netzwerkeinrichtung beim Reboot fehl.

Zweitens: Netcup routet Ihr dediziertes /64-IPv6-Subnetz (z. B. 2a03:4000:xx:xxxx::/64) über die Hypervisor-Bridge mithilfe der statischen Link-Local-Router-Adresse fe80::1. Wenn Sie sich auf SLAAC (accept-ra: true) verlassen, anstatt eine statische fe80::1-Route mit on-link: true zu definieren, funktioniert IPv6 nach dem Booten einige Minuten lang und bricht dann lautlos ab, sobald die Lifetime des initialen Router Advertisements abläuft.

# 1. Exakten Interface-Namen (eth0 vs. ens3), Status (UP/DOWN) und MAC-Adresse prüfen
ip -br link show

# 2. Gebundene IPv4- und IPv6-Adressen anzeigen
ip -br addr show

# 3. IPv4- und IPv6-Routing-Tabellen sowie fe80::1 Neighbor-Erreichbarkeit prüfen
ip -4 route show
ip -6 route show
ip -6 neigh show dev "$(ip -4 route show default | awk '{print $5; exit}')"

eth0             UP             52:54:00:4a:8b:1c <BROADCAST,MULTICAST,UP,LOWER_UP>
default via fe80::1 dev eth0 proto static metric 1024 onlink pref medium
fe80::1 lladdr aa:bb:cc:dd:ee:ff router REACHABLE

network:
  version: 2
  renderer: networkd
  ethernets:
    primary_nic:
      match:
        macaddress: "52:54:00:4a:8b:1c"
      set-name: "eth0"
      dhcp4: true
      dhcp6: false
      accept-ra: false
      addresses:
        - "2a03:4000:61:a1b2::1/64"
      routes:
        - to: "::/0"
          via: "fe80::1"
          on-link: true
      nameservers:
        addresses:
          - 46.38.225.230
          - 46.38.252.230
          - 2a03:4000:0:1::e1e6
          - 1.1.1.1

Netcup betreibt das autonome System AS197540 (netcup GmbH) mit direktem Peering an großen europäischen und internationalen Internetknoten (darunter DE-CIX Frankfurt, VIX Wien, AMS-IX Amsterdam) sowie Upstream-Transit-Carriern (wie Anexia AS42473, Telia/Arelion AS1299, NTT AS2914 und Cogent AS174).

Bei der Untersuchung von vermutetem Paketverlust oder hohen Latenzen zwischen Ihrem Netcup-Server und einem Client-ISP reicht ein einseitiger ping oder traceroute nicht aus, da BGP-Routing im Internet häufig asymmetrisch verläuft. Der Hinweg (Egress von Netcup Nürnberg über DE-CIX zum Endkunden) nimmt oft einen völlig anderen Carrier-Pfad als der Rückweg (Ingress vom ISP des Endkunden zurück zu AS197540). Erstellen Sie daher immer einen Bericht über 100 Pakete mittels mtr -rwzc 100 in beide Richtungen (vom Server zur Client-IP und vom Client zur Server-IP).

sudo apt update && sudo apt install -y mtr-tiny

# 1. 100-Pakete IPv4-MTR-Bericht mit ASN-Auflösung (-z) und ungekürzten Hostnamen (-w) erstellen
mtr -rwzc 100 -4 1.1.1.1

# 2. 100-Pakete IPv6-MTR-Bericht erstellen, um die IPv6-Transit-Qualität zu prüfen
mtr -rwzc 100 -6 2606:4700:4700::1111

# 3. Falls ICMP auf Zwischen-Routern gedrosselt wird, TCP-SYN-MTR auf Port 443 ausführen
sudo mtr -rwzc 50 -T -P 443 1.1.1.1

Start: 2026-11-04T20:50:12+0000
HOST: netcup-rs1000-nue                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS197540 gw-nue1.netcup.net                 0.0%   100    0.3   0.4   0.2   1.8   0.2
  2. AS197540 core-nue-fra.netcup.net            0.0%   100    2.6   2.7   2.5   4.9   0.3
  3. AS???    de-cix.fra.cloudflare.com          0.0%   100    2.9   3.0   2.8   6.1   0.4
  4. AS13335  one.one.one.one                    0.0%   100    2.8   2.9   2.7   3.5   0.1

Wenn ein Dienst-Port (wie HTTPS 443, WireGuard 51820/udp oder ein eigener API-Port) von außen nicht erreichbar ist, kommen genau drei Ursachen infrage: Der Dienst lauscht nur auf 127.0.0.1, die Gast-OS-Firewall (ufw/nftables/iptables) verwirft das Paket, oder die Netcup SCP Stateful Firewall blockiert das Paket bereits vor Ihrer VM.

Ein weiterer subtiler Fehler ist ein Path-MTU-Discovery-(PMTUD)-Blackhole: Dabei klappt zwar der TCP-Drei-Wege-Handshake (kleine 60-Byte-SYN-Pakete), aber sobald der Server während des TLS-Handshakes große Zertifikats-Frames (1500 Bytes) über ein gekapseltes VLAN-, PPPoE- oder VPN-Segment sendet, gehen diese kommentarlos verloren. Mit ss -tulnp, tcpdump -ni any und ping -M do grenzen Sie sowohl Firewall-Drops als auch MTU-Engpässe innerhalb weniger Sekunden zweifelsfrei ein:

# 1. Prüfen, ob der Dienst auf 0.0.0.0 / [::] lauscht (und NICHT nur auf 127.0.0.1)
sudo ss -tulnp | grep -E "Local Address|:80 |:443 |:22 "

# 2. Eingehende Pakete direkt am Netzwerk-Interface mitschneiden, während von außen verbunden wird
# -> Zeigt tcpdump NULL eingehende SYN-Pakete: Die Netcup SCP Firewall (vorgeschaltet) blockiert den Port!
# -> Zeigt tcpdump eingehende SYN-Pakete ohne SYN-ACK-Antwort: Lokales UFW / nftables verwirft das Paket!
sudo tcpdump -ni any 'tcp port 443 and (tcp-syn|tcp-ack)!=0' -c 10

# 3. Aktive Gast-Firewall-Regeln prüfen (sowohl UFW/iptables als auch natives nftables)
sudo ufw status verbose
sudo nft list ruleset | head -n 45

# 4. Path-MTU (1472 Payload + 20 IPv4 + 8 ICMP = 1500 Bytes) mit Don't-Fragment-Flag (-M do) testen
ping -4 -M do -s 1472 -c 3 1.1.1.1
ping -6 -M do -s 1452 -c 3 2606:4700:4700::1111

PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1480 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=2.84 ms

Wenn ping 1.1.1.1 mit 0 % Verlust funktioniert, apt update oder curl https://github.com jedoch mit Temporary failure in name resolution abbricht, ist Ihr IP-Routing völlig intakt und lediglich die lokale DNS-Auflösung gestört. Unter Ubuntu 24.04 sollte /etc/resolv.conf ein Symlink auf /run/systemd/resolve/stub-resolv.conf sein.

Wenn Sie einen Mailserver betreiben oder Systembenachrichtigungen versenden, prüfen Sie abschließend, ob Vorwärts- (A/AAAA) und Rückwärtsauflösung (PTR) für IPv4 und IPv6 exakt übereinstimmen (FCrDNS).

# 1. systemd-resolved-Status und aktive Upstream-DNS-Server pro Interface prüfen
resolvectl status

# 2. Direkte DNS-Abfragen gegen die offiziellen rekursiven Netcup-Resolver & Cloudflare testen
dig @46.38.225.230 netcup.com +short
dig @1.1.1.1 ubuntu.com +short

# 3. Falls /etc/resolv.conf überschrieben wurde, den systemd-resolved-Symlink wiederherstellen
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved

# 4. Öffentliche IPv4- und IPv6-Reverse-DNS-(PTR)-Einträge des Servers abfragen
SERVER_IPV4=$(ip -4 addr show "$(ip -4 route show default | awk '{print $5; exit}')" | awk '/inet / {split($2,a,"/"); print a[1]; exit}')
SERVER_IPV6=$(ip -6 addr show "$(ip -4 route show default | awk '{print $5; exit}')" scope global | awk '/inet6 / {split($2,a,"/"); print a[1]; exit}')
echo "IPv4 PTR: $(dig -x "${SERVER_IPV4}" +short @1.1.1.1)"
echo "IPv6 PTR: $(dig -x "${SERVER_IPV6}" +short @1.1.1.1)"

IPv4 PTR: mail.example.com.
IPv6 PTR: mail.example.com.