Heb je dynamische DNS nodig voor een VPN-server thuis?

Dynamische DNS repareert de naam, niet de weg naar binnen. Drie controles bepalen of een hostnaam genoeg is voor een VPN-server thuis of dat de route naar binnen stuk is.

De meeste VPN-storingen thuis waarover mensen mij vragen zijn geen DNS-storingen, en toch kopen ze eerst een dynamisch DNS-abonnement. Voordat je iets configureert, beslis of de hostnaam het deel is dat echt stuk is. Een updater herschrijft een record wanneer het adres dat je provider je gaf verschuift; hij kan geen poort openen, niet door carrier-NAT komen en een lopende WireGuard-sessie niet laten merken dat het eindpunt is veranderd. Drie voorwaarden bepalen of dynamische DNS de hele oplossing is of slechts één regel ervan.

Voorwaarde één: je adres verschuift echt

Woonadressen verschuiven om onopvallende redenen: de modem synchroniseert opnieuw na stroomuitval, de provider herbalanceert een pool, na een lange storing komt een nieuwe lease. Op sommige lijnen verschuiven ze ook zelden, en ik heb hetzelfde adres een jaar zien overleven; zakelijke abonnementen bevatten vaak een statisch adres. Als er in twaalf maanden niets is veranderd, is één A-record dat je met de hand bewerkt een daemon minder om in leven te houden.

Meet het in plaats van te gokken. Lees het WAN-adres op de statuspagina van de router en vergelijk het met wat de buitenwereld ziet. Voer dit uit vanaf een machine op de LAN:

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

Als de twee waarden verschillen, vertaalt er iets vóór je router en geen enkele hostnaam-update lost dat op. Een adres binnen 100.64.0.0/10 is het gedeelde bereik voor carrier-grade NAT, en dat is de gebruikelijke reden dat een correct bijgewerkte naam van buitenaf toch in een time-out loopt.

Voorwaarde twee: clients zoeken de naam opnieuw op

Een korte TTL is het deel dat mensen overslaan. Recursieve resolvers respecteren de TTL van het record, maar clientstacks cachen apart, en een tunnel die al staat, lost niets opnieuw op. Zet het record op 60-300 seconden terwijl je debugt; dat verkort het venster waarin een verouderd antwoord wordt geserveerd, en het migreert geen verbonden sessie.

OpenVPN lost de regel remote vpn.example.net 1194 bij elke herverbinding opnieuw op, en resolv-retry infinite laat het opnieuw proberen in plaats van afsluiten wanneer de opzoeking mislukt. Op de server laat float een gevestigde sessie een peer volgen waarvan het bronadres is veranderd. WireGuard is directer: wg-quick up lost het Endpoint op wanneer de configuratie wordt toegepast, en de client lost het opnieuw op wanneer hij de tunnel opnieuw opbouwt, dus een handshake die nog slaagt tegen het oude adres blijft slagen tot hij stopt.

Dat verschil bepaalt het plan. Als clients op verzoek verbinden, kost een adreswijziging één herverbinding. Als ze een sessie dagen openhouden, verwacht dan dat de tunnel bij de volgende handshake sterft, en laat de client het opnieuw proberen in plaats van aan te nemen dat hij blijft staan.

Voorwaarde drie: de weg naar binnen is nog open

Dynamische DNS verandert alleen waar de naam naar wijst en niets anders. De portforwarding op de router, de firewallregel op de VPN-host en de toestemming van de provider voor inkomende pakketten moeten allemaal bestaan voordat het record iets betekent. Let op waar de forwarding op richt: als die aan een WAN-adres vastzit in plaats van aan de interface, breekt een adreswijziging de forwarding stil en krijgt het record de schuld.

Test van buitenaf. Een telefoon op mobiele data met Wi-Fi uit is de goedkoopste eerlijke test; een laptop op dezelfde LAN is dat niet. Wanneer de naam naar je openbare adres resolveert en de router geen NAT-loopback heeft, faalt een test van binnen terwijl het record volkomen correct is, en dat stuurt de meeste mensen een record bewerken dat nooit fout was.

Wat je draait als alle drie kloppen

ddclient is de minst verrassende updater voor een kleine host. Een minimale configuratie publiceert het adres dat de provider ziet, wat de dubbel-NAT-fout omzeilt:

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

Draai hem vanuit een systemd-timer elke paar minuten in plaats van een shell-lus, en log het antwoord van de provider in plaats van succes aan te nemen. Behandel de inloggegevens als een sleutel, want die bepaalt waar elke client naartoe gaat: gebruik een beperkt updatetoken in plaats van een accountwachtwoord, houd het bestand op modus 0600 en stuur updates over HTTPS.

Verifieer voordat je je vastlegt

Eén opzoeking vertelt je wat de rest van de wereld ziet, en het print de TTL die je na een wijziging moet afwachten:

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

Vergelijk dat adres met het WAN-adres van de router. Als ze overeenkomen, doet de naam zijn werk en wat nog faalt is inkomende bereikbaarheid, een sleutel of een client die niet opnieuw heeft geresolved. Als ze verschillen, publiceert de updater de verkeerde interface, vaak omdat hij op de VPN-host achter de router draaide in plaats van op de router zelf.

Houd een terugdraai-actie van een minuut achter de hand: noteer het laatste werkende adres en de vorige TTL, zodat je beide met de hand kunt publiceren terwijl de provider een slechte middag heeft.

Als het antwoord nee is

Als voorwaarde één of drie faalt, verandert de beslissing in plaats van de configuratie. Achter carrier-NAT zijn je praktische opties de provider om een openbaar adres vragen, het instappunt verplaatsen naar een kleine VPS met een stabiel adres, of een overlay gebruiken die zijn eigen ontmoetingspunt houdt. Als het adres statisch is, sla de updater over: één A-record, één AAAA-record als je IPv6 draait, dezelfde portforwarding.

Als het adres verandert terwijl clients verbonden blijven, woont de eerlijke oplossing in de client: herverbindingslogica en een interval voor nieuwe pogingen, niet een snellere updater. Een tweede provider verbergt alleen het interval.

Voordat je verdergaat, bevestig vier dingen in volgorde:

  • Het adres dat de updater publiceert komt overeen met het WAN-adres van de router.
  • De TTL van het record is kort genoeg dat een wijziging binnen minuten zichtbaar is.
  • De portforwarding is gebonden aan de interface, niet aan een vast adres.
  • Eén echte client heeft sinds de laatste wijziging opnieuw verbonden en verkeer doorgelaten.

Als alle vier kloppen, laat de opzet met rust; je volgende storing is een sleutel of een firewallregel en geen naamprobleem. Als er één faalt, repareer die regel voordat je nog een bewegend onderdeel toevoegt. RFC 2136 beschrijft het updatemechanisme zelf, als je wilt zien wat de daemon op de lijn zet.

Gerelateerde artikelen