Behöver du dynamisk DNS för en VPN-server hemma?

Dynamisk DNS lagar namnet, inte vägen in. Tre kontroller avgör om ett värdnamn räcker för en VPN-server hemma eller om vägen in är trasig.

De flesta VPN-fel hemma som folk frågar mig om är inte DNS-fel, och ändå köper de först en prenumeration på dynamisk DNS. Innan du konfigurerar något, avgör om värdnamnet är den del som faktiskt är trasig. En uppdaterare skriver om en post när adressen som leverantören gav dig flyttar sig; den kan inte öppna en port, tränga igenom operatörens NAT eller få en pågående WireGuard-session att märka att dess slutpunkt har ändrats. Tre villkor avgör om dynamisk DNS är hela lösningen eller bara en rad av den.

Villkor ett: din adress flyttar sig faktiskt

Bostadsadresser flyttar sig av tråkiga skäl: modemet synkroniserar om efter ett strömavbrott, leverantören balanserar om en pool, en ny lease kommer efter ett långt avbrott. På vissa linjer flyttar de sig också sällan, och jag har sett samma adress överleva ett år; företagsabonnemang innehåller ofta en statisk. Om inget har ändrats på tolv månader är en enda A-post som du redigerar för hand en daemon mindre att hålla vid liv.

Mät det i stället för att gissa. Läs WAN-adressen på routerns statussida och jämför med vad omvärlden ser. Kör detta från en maskin på LAN:

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

Om de två värdena skiljer sig översätter något framför din router, och ingen värdnamnsuppdatering rättar det. En adress inom 100.64.0.0/10 är det delade intervallet för carrier-grade NAT, och det är den vanliga orsaken till att ett korrekt uppdaterat namn ändå tidsutlöper utifrån.

Villkor två: klienterna slår upp namnet igen

Kort TTL är den del folk hoppar över. Rekursiva resolvrar respekterar postens TTL, men klientstackar cachar separat, och en tunnel som redan är uppe slår inte upp något igen. Sätt posten till 60-300 sekunder medan du felsöker; det förkortar fönstret där ett inaktuellt svar serveras, och det flyttar inte en ansluten session.

OpenVPN slår upp raden remote vpn.example.net 1194 igen vid varje återanslutning, och resolv-retry infinite får den att försöka igen i stället för att avsluta när uppslaget misslyckas. På servern låter float en etablerad session följa en peer vars källadress har ändrats. WireGuard är mer direkt: wg-quick up slår upp Endpoint när konfigurationen tillämpas, och klienten slår upp den igen när den bygger om tunneln, så ett handskak som fortfarande lyckas mot den gamla adressen fortsätter att lyckas tills det stannar.

Den skillnaden formar planen. Om klienter ansluter vid behov kostar en adressändring en återanslutning. Om de håller en session öppen i dagar, räkna med att tunneln dör vid nästa handskak, och låt klienten försöka igen i stället för att anta att den står kvar.

Villkor tre: vägen in är fortfarande öppen

Dynamisk DNS ändrar bara vart namnet pekar och inget annat. Portvidarebefordran på routern, brandväggsregeln på VPN-värden och leverantörens tillåtelse av inkommande paket måste alla finnas innan posten betyder något. Titta på vad vidarebefordran riktar sig mot: om den är fäst vid en WAN-adress i stället för gränssnittet bryter en adressändring vidarebefordran tyst, och posten får skulden.

Testa utifrån. En telefon på mobildata med Wi-Fi avstängt är det billigaste ärliga testet; en laptop på samma LAN är det inte. När namnet slås upp till din publika adress och routern saknar NAT-loopback misslyckas ett test inifrån medan posten är helt korrekt, och det skickar de flesta att redigera en post som aldrig var fel.

Vad du ska köra när alla tre håller

ddclient är den minst överraskande uppdateraren för en liten värd. En minimal konfiguration publicerar adressen som leverantören ser, vilket kringgår dubbel-NAT-felet:

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

Kör den från en systemd-timer varje par minuter i stället för en skalloop, och logga leverantörens svar i stället för att anta framgång. Behandla uppgiften som en nyckel, för den avgör vart varje klient skickas: använd en begränsad uppdateringstoken i stället för ett kontolösenord, håll filen på läge 0600 och skicka uppdateringar över HTTPS.

Verifiera innan du binder dig

Ett uppslag säger vad resten av världen ser, och det skriver ut TTL:en du måste vänta ut efter en ändring:

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

Jämför den adressen med routerns WAN-adress. Om de stämmer gör namnet sitt jobb, och det som fortfarande misslyckas är ingående nåbarhet, en nyckel eller en klient som inte slagit upp igen. Om de skiljer sig publicerar uppdateraren fel gränssnitt, ofta för att den körde på VPN-värden bakom routern i stället för på routern själv.

Ha en återställning som tar en minut: notera den senast fungerande adressen och föregående TTL, så att du kan publicera båda för hand medan leverantören har en dålig eftermiddag.

När svaret är nej

Om villkor ett eller tre fallerar ändras beslutet, inte konfigurationen. Bakom carrier-NAT är dina praktiska alternativ att be leverantören om en publik adress, flytta ingångspunkten till en liten VPS med stabil adress, eller använda ett överlägg som håller sin egen mötesplats. Om adressen är statisk, hoppa över uppdateraren: en A-post, en AAAA-post om du kör IPv6, samma portvidarebefordran.

Om adressen ändras medan klienterna förblir anslutna bor den ärliga rättelsen i klienten: återanslutningslogik och ett intervall för nya försök, inte en snabbare uppdaterare. En extra leverantör döljer bara intervallet.

Innan du går vidare, bekräfta fyra saker i ordning:

  • Adressen som uppdateraren publicerar stämmer med routerns WAN-adress.
  • Postens TTL är kort nog att en ändring syns inom minuter.
  • Portvidarebefordran är bunden till gränssnittet, inte till en fast adress.
  • En riktig klient har återanslutit och släppt igenom trafik sedan den senaste ändringen.

Om alla fyra håller, lämna uppsättningen i fred; ditt nästa fel är en nyckel eller en brandväggsregel och inte ett namnproblem. Om någon fallerar, rätta den raden innan du lägger till ännu en rörlig del. RFC 2136 beskriver själva uppdateringsmekanismen, om du vill se vad daemonen lägger på tråden.

Relaterade artiklar