Brauchen Sie dynamisches DNS für einen Heim-VPN-Server?

Dynamisches DNS repariert den Namen, nicht den Weg hinein. Drei Prüfungen entscheiden, ob ein Hostname für einen Heim-VPN-Server reicht oder ob die Route hinein kaputt ist.

Die meisten Heim-VPN-Fehler, nach denen man mich fragt, sind keine DNS-Fehler, und trotzdem kaufen die Leute zuerst ein dynamisches DNS-Abo. Bevor Sie irgendetwas konfigurieren, entscheiden Sie, ob der Hostname der Teil ist, der wirklich kaputt ist. Ein Updater schreibt einen Eintrag neu, wenn sich die Adresse verschiebt, die Ihnen Ihr Provider gegeben hat; er kann keinen Port öffnen, kein Carrier-NAT durchstoßen und keine laufende WireGuard-Sitzung dazu bringen, zu bemerken, dass sich ihr Endpunkt geändert hat. Drei Bedingungen entscheiden, ob dynamisches DNS die ganze Lösung ist oder nur eine Zeile davon.

Bedingung eins: Ihre Adresse verschiebt sich tatsächlich

Wohnadressen verschieben sich aus unspektakulären Gründen: Das Modem synchronisiert nach einem Stromausfall neu, der Provider gleicht einen Pool aus, ein neues Lease kommt nach einem längeren Ausfall. Auf manchen Leitungen verschieben sie sich auch selten, und ich habe dieselbe Adresse ein Jahr überleben sehen; Business-Tarife enthalten oft eine statische. Wenn sich in zwölf Monaten nichts geändert hat, ist ein einzelner A-Eintrag, den Sie von Hand bearbeiten, ein Daemon weniger, den Sie am Leben halten müssen.

Messen Sie statt zu raten. Lesen Sie die WAN-Adresse auf der Statusseite des Routers und vergleichen Sie sie mit dem, was die Außenwelt sieht. Führen Sie das von einem Rechner im LAN aus:

curl -fsS https://api.ipify.org; echo

Wenn sich die beiden Werte unterscheiden, übersetzt etwas vor Ihrem Router, und kein Hostname-Update behebt das. Eine Adresse innerhalb von 100.64.0.0/10 ist der geteilte Bereich für Carrier-Grade-NAT, und das ist der übliche Grund, warum ein korrekt aktualisierter Name von außen trotzdem in einen Timeout läuft.

Bedingung zwei: Clients lösen den Namen erneut auf

Die kurze TTL ist der Teil, den Leute überspringen. Rekursive Resolver halten sich an die TTL des Eintrags, aber Client-Stacks cachen getrennt, und ein Tunnel, der schon steht, löst nichts erneut auf. Stellen Sie den Eintrag beim Debuggen auf 60-300 Sekunden; das verkürzt das Fenster, in dem eine veraltete Antwort ausgeliefert wird, und es migriert keine verbundene Sitzung.

OpenVPN löst die Zeile remote vpn.example.net 1194 bei jedem erneuten Verbinden neu auf, und resolv-retry infinite lässt es weiter versuchen, statt zu beenden, wenn die Auflösung fehlschlägt. Auf dem Server float erlaubt einer bestehenden Sitzung, einem Peer zu folgen, dessen Quelladresse sich geändert hat. WireGuard ist direkter: wg-quick up löst den Endpoint beim Anwenden der Konfiguration auf, und der Client löst ihn erneut auf, wenn er den Tunnel neu aufbaut, sodass ein Handshake, der gegen die alte Adresse noch gelingt, weiter gelingt, bis er aufhört.

Dieser Unterschied prägt den Plan. Wenn Clients bei Bedarf verbinden, kostet eine Adressänderung eine Neuverbindung. Wenn sie eine Sitzung tagelang offen halten, rechnen Sie damit, dass der Tunnel beim nächsten Handshake stirbt, und lassen Sie den Client erneut versuchen, statt anzunehmen, dass er oben bleibt.

Bedingung drei: der eingehende Weg ist noch offen

Dynamisches DNS ändert nur, wohin der Name zeigt, und sonst nichts. Die Portweiterleitung am Router, die Firewall-Regel auf dem VPN-Host und die Erlaubnis eingehender Pakete durch den Provider müssen alle existieren, bevor der Eintrag zählt. Achten Sie darauf, worauf die Weiterleitung zielt: Ist sie an eine WAN-Adresse statt an das Interface gebunden, bricht eine Adressänderung die Weiterleitung stillschweigend, und der Eintrag bekommt die Schuld.

Testen Sie von außen. Ein Telefon über Mobilfunk mit ausgeschaltetem WLAN ist der billigste ehrliche Test; ein Laptop im selben LAN ist es nicht. Wenn der Name auf Ihre öffentliche Adresse auflöst und der Router kein NAT-Loopback hat, scheitert ein Test von innen, obwohl der Eintrag völlig korrekt ist, und das schickt die meisten Leute los, einen Eintrag zu bearbeiten, der nie falsch war.

Was Sie laufen lassen, wenn alle drei zutreffen

ddclient ist der am wenigsten überraschende Updater für einen kleinen Host. Eine minimale Konfiguration veröffentlicht die Adresse, die der Provider sieht, und umgeht damit den Doppel-NAT-Fehler:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Starten Sie ihn über einen systemd-Timer alle paar Minuten statt in einer Shell-Schleife, und protokollieren Sie die Antwort des Providers, statt Erfolg anzunehmen. Behandeln Sie das Zugangsgeheimnis wie einen Schlüssel, denn es entscheidet, wohin jeder Client geschickt wird: Nehmen Sie ein eingeschränktes Update-Token statt eines Kontopassworts, halten Sie die Datei auf Modus 0600 und senden Sie Updates über HTTPS.

Prüfen Sie, bevor Sie sich festlegen

Eine Abfrage sagt Ihnen, was der Rest der Welt sieht, und sie druckt die TTL aus, die Sie nach einer Änderung abwarten müssen:

dig +noall +answer vpn.example.net @1.1.1.1

Vergleichen Sie diese Adresse mit der WAN-Adresse des Routers. Stimmen sie überein, erfüllt der Name seine Aufgabe, und was weiter scheitert, ist eingehende Erreichbarkeit, ein Schlüssel oder ein Client, der nicht neu aufgelöst hat. Weichen sie ab, veröffentlicht der Updater das falsche Interface, oft weil er auf dem VPN-Host hinter dem Router lief statt auf dem Router selbst.

Halten Sie einen Rückweg bereit, der eine Minute dauert: Notieren Sie die letzte funktionierende Adresse und die vorherige TTL, damit Sie beides von Hand veröffentlichen können, während der Provider einen schlechten Nachmittag hat.

Wenn die Antwort nein lautet

Wenn Bedingung eins oder drei scheitert, ändert sich die Entscheidung, nicht die Konfiguration. Hinter Carrier-NAT sind Ihre praktischen Optionen, den Provider um eine öffentliche Adresse zu bitten, den Einstiegspunkt auf einen kleinen VPS mit stabiler Adresse zu verlegen, oder ein Overlay zu nutzen, das seinen eigenen Treffpunkt hält. Ist die Adresse statisch, überspringen Sie den Updater: ein A-Eintrag, ein AAAA-Eintrag, wenn Sie IPv6 fahren, dieselbe Portweiterleitung.

Wenn sich die Adresse ändert, während Clients verbunden bleiben, wohnt die ehrliche Lösung im Client: Wiederverbindungslogik und ein Wiederholungsintervall, nicht ein schnellerer Updater. Ein zweiter Provider versteckt nur das Intervall.

Bevor Sie weitermachen, bestätigen Sie vier Dinge der Reihe nach:

  • Die Adresse, die der Updater veröffentlicht, stimmt mit der WAN-Adresse des Routers überein.
  • Die TTL des Eintrags ist kurz genug, dass eine Änderung binnen Minuten sichtbar wird.
  • Die Portweiterleitung ist an das Interface gebunden, nicht an eine feste Adresse.
  • Ein echter Client hat seit der letzten Änderung neu verbunden und Daten durchgelassen.

Wenn alle vier zutreffen, lassen Sie das Setup in Ruhe; Ihr nächster Fehler ist ein Schlüssel oder eine Firewall-Regel, kein Namensproblem. Wenn eine scheitert, reparieren Sie diese Zeile, bevor Sie ein weiteres bewegliches Teil hinzufügen. RFC 2136 beschreibt den Aktualisierungsmechanismus selbst, wenn Sie sehen wollen, was der Daemon auf die Leitung legt.

Ähnliche Artikel