post-mortem debugowania sieci

VPS tracił sieć.
Tailscale był niewinny.

Historia o tym, jak timeout DHCPv6 wyłączał cały interfejs — i jak to naprawiliśmy.

interfejs
ens3
stan przed
failed
stan po
active
// co się działo
objaw

Tailscale: „network is down" — VPS znika z Tailnet

Maszyna regularnie wypadała z sieci Tailscale. Na pierwszy rzut oka wyglądało to jak problem z samym Tailscale. Był to jednak tylko symptom czegoś głębszego.

diagnoza

Brak domyślnej trasy na ens3

Po czasie interfejs ens3 tracił domyślną trasę — internet przestawał działać.

bash ip route # brak trasy domyślnej → ping 1.1.1.1 nie działa

Ręczny DHCP przywracał internet natychmiast, co wskazywało na problem z konfiguracją sieci — nie z Tailscale:

bash sudo dhclient -v ens3
przyczyna

Usługa networking w stanie failed — winowajca DHCPv6

Serwis blokował się przy podnoszeniu ens3. Winowajca ukrywał się w pliku konfiguracji cloud-init:

interfaces iface ens3 inet6 dhcp # ↑ serwer czekał na DHCPv6, którego nie było # timeout blokował całe networking — razem z IPv4

Usługa networking nie startowała poprawnie, bo czekała na DHCPv6 — a razem z nią padał cały interfejs, włącznie z trasą IPv4.

naprawa ✓

Wykomentowanie linii DHCPv6

  • Otwieramy plik konfiguracji:
    bash sudo nano /etc/network/interfaces.d/50-cloud-init
  • Komentujemy winowajcę:
    diff iface ens3 inet6 dhcp # iface ens3 inet6 dhcp
  • Restartujemy usługę sieciową:
    bash sudo systemctl restart networking
networking: active — sieć startuje poprawnie, Tailscale przestaje znikać