Aktualisiert ein Hostname der Pi-Gateway statische Routen von selbst?

Ein DNS-Name für deine Pi-Gateway schreibt einen installierten nächsten Hop nie um. Sieh, was der Kernel speichert und wer die Route aktualisieren muss.

Eine statische Route auf einen Gateway-Namen zu zeigen wirkt so, als müsste sie eine Adressänderung überstehen, und das tut sie nicht. Der Name lebt im DNS, während die Route als numerischer nächster Hop in der Routingtabelle des Clients sitzt. Wenn die Pi auf eine andere Adresse umzieht, schickt jeder Verbraucher, der den alten Hop schon installiert hat, weiter Verkehr an dieselbe Nummer. Kein Resolver ist mit der Weiterleitungstabelle verbunden, also schreibt nichts diesen Eintrag für dich um.

Die DNS-Antwort und die Route sind verschiedene Objekte

Sagen wir, deine Pi antwortet auf vpn-gw.lan und leitet 10.44.0.0/16 in einen Tunnel. Clients in 192.168.30.0/24 erreichen sie über eine statische Route. Als die Adresse der Pi von 192.168.30.4 auf 192.168.30.11 wechselte, folgte der Record innerhalb seiner TTL, die Routen nicht.

Die beiden Ansichten widersprechen sich auf eine Weise, die leicht zu übersehen ist, weil beide plausibel wirken, wenn man sie getrennt abfragt:

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

Nur die erste Zeile entscheidet, wohin Pakete gehen. Die zweite Zeile beantwortet eine Frage, die der Kernel nie gestellt hat. Ein Record mit mehreren A-Records wird auch keine Failover-Richtlinie, denn jede Adresse muss auf diesem Segment weiterhin ein brauchbarer nächster Hop sein.

Was nach dem Ende des Befehls in der Tabelle bleibt

Eine Linux-Route hält zwei Dinge fest, die hier zählen: den nächsten Hop als Protokolladresse und die Ausgangsschnittstelle als Indexnummer. Die rtnetlink-Routenattribute benennen dieses erste Feld RTA_GATEWAY, und es enthält Bytes. Sobald der Eintrag steht, ist keine TTL daran gebunden, und kein Hintergrund-Lookup frischt ihn auf.

Deshalb kann ip route add 10.44.0.0/16 via vpn-gw.lan funktionieren zu scheinen. Das Werkzeug löst den Namen auf, während der Befehl läuft, schreibt die resultierende Adresse und vergisst den Namen völlig. Führe danach ip route show 10.44.0.0/16 aus, und du bekommst eine wörtliche Adresse zurück.

Dieses Verhalten lohnt sich zu kennen, bevor du den Tunnel beschuldigst.

Werkzeuge, die einen Namen für dich auflösen, und wann

Manche Router und Firewalls akzeptieren tatsächlich Hostnamen in einem Routen- oder Gateway-Feld. Entscheidend ist, wann die Auflösung stattfindet. Löst das Gerät den Namen nur auf, während du die Konfiguration anwendest, ist der gespeicherte Eintrag genauso statisch wie eine getippte Adresse, und eine spätere Adressänderung braucht ein weiteres Anwenden. Dass das Feld einen Namen akzeptiert, sagt dir nichts über die Aktualisierung.

Verwaltete Umgebungen teilen die Arbeit meist auf. Eine DHCP-Reservierung oder ein statisches Lease hält die Pi auf einer Adresse, und der DNS-Record folgt einfach dem Lease. Nichts muss ein bewegliches Ziel verfolgen, weil das Ziel sich nicht bewegt.

Ein überwachter Updater ist das andere legitime Muster, und er braucht einen Eigentümer.

Nagel die Adresse fest oder starte den Updater selbst

Für ein kleines LAN ist eine Reservierung auf dem DHCP-Server die billigste Lösung. Wähle eine Adresse außerhalb des dynamischen Pools, binde sie an die MAC-Adresse der Pi und bestätige sie mit ip -4 addr show dev eth0 nach der nächsten Lease-Erneuerung. Dann richte den nächsten Hop der Clients einmal auf diese Adresse. Jetzt hast du ein stabiles Gateway und einen Record, der es beschreibt, und das ist die Reihenfolge, in der die Beziehung tatsächlich funktioniert.

Wenn die Pi wirklich umziehen muss, halte die Routenreparatur an einer Stelle, statt jeden Client von Hand zu bearbeiten. Ein kurzes Skript, das auflöst, vergleicht und ersetzt, reicht, um den Schritt wiederholbar zu machen:

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

Der letzte Befehl ist der Abnahmetest, denn er druckt das Gateway, das der Kernel tatsächlich benutzt. Ist die gedruckte Adresse noch die alte, lief das Skript im falschen Netzwerk-Namespace oder hatte keine Berechtigung, und die DNS-Seite ist irrelevant.

Prüfe auch den Rückweg. Die Pi muss wissen, wie sie das Client-Subnetz erreicht, und ihre Firewall muss den Tunnelverkehr zulassen. Eine Standardroute, die den Mismatch zudecken soll, verbirgt meist die echte Lücke und bricht eine Woche später etwas anderes.

Ähnliche Artikel