Trenger du dynamisk DNS for en VPN-server hjemme?

De fleste VPN-feil hjemme som folk spør meg om, er ikke DNS-feil, og likevel kjøper de først et dynamisk DNS-abonnement. Før du konfigurerer noe, avgjør om vertsnavnet er den delen som faktisk er ødelagt. En oppdaterer skriver om en post når adressen leverandøren ga deg flytter seg; den kan ikke åpne en port, trenge gjennom operatørens NAT eller få en kjørende WireGuard-økt til å merke at endepunktet er endret. Tre betingelser avgjør om dynamisk DNS er hele løsningen eller bare én linje av den.

Betingelse én: adressen din flytter seg faktisk

Bostedsadresser flytter seg av kjedelige grunner: modemet synkroniserer på nytt etter et strømbrudd, leverandøren balanserer om en pool, en ny leie kommer etter et langt avbrudd. På noen linjer flytter de seg også sjelden, og jeg har sett samme adresse overleve et år; bedriftsavtaler inkluderer ofte en statisk. Hvis ingenting har endret seg på tolv måneder, er én A-post du redigerer for hånd, en daemon mindre å holde i live.

Mål det i stedet for å gjette. Les WAN-adressen på ruternes statusside, og sammenlign den med det omverdenen ser. Kjør dette fra en maskin på LAN-et:

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

Hvis de to verdiene er forskjellige, oversetter noe foran ruteren din, og ingen vertsnavnoppdatering retter det. En adresse innenfor 100.64.0.0/10 er det delte området for carrier-grade NAT, og det er den vanlige grunnen til at et korrekt oppdatert navn fortsatt timer ut utenfra.

Betingelse to: klientene slår opp navnet igjen

Kort TTL er den delen folk hopper over. Rekursive resolvere respekterer postens TTL, men klientstakker cacher separat, og en tunnel som allerede er oppe, slår ikke opp noe på nytt. Sett posten til 60-300 sekunder mens du feilsøker; det forkorter vinduet der et utdatert svar serveres, og det flytter ikke en tilkoblet økt.

OpenVPN slår opp linjen remote vpn.example.net 1194 på nytt hver gang den kobler til igjen, og resolv-retry infinite får den til å prøve på nytt i stedet for å avslutte når oppslaget feiler. På serveren lar float en etablert økt følge en peer hvis kildeadresse er endret. WireGuard er mer direkte: wg-quick up slår opp Endpoint når konfigurasjonen brukes, og klienten slår den opp igjen når den bygger tunnelen på nytt, så et håndtrykk som fortsatt lykkes mot den gamle adressen, fortsetter å lykkes til det stopper.

Den forskjellen former planen. Hvis klienter kobler til ved behov, koster en adresseendring én gjenoppkobling. Hvis de holder en økt åpen i dagevis, regn med at tunnelen dør ved neste håndtrykk, og få klienten til å prøve på nytt i stedet for å anta at den blir stående.

Betingelse tre: veien inn er fortsatt åpen

Dynamisk DNS endrer bare hvor navnet peker, og ingenting annet. Portvidingen på ruteren, brannmurregelen på VPN-verten og leverandørens tillatelse av innkommende pakker må alle finnes før posten betyr noe. Se på hva vidingen peker på: hvis den er festet til en WAN-adresse i stedet for grensesnittet, bryter en adresseendring vidingen lydløst, og posten får skylden.

Test utenfra. En telefon på mobildata med Wi-Fi av er den billigste ærlige testen; en laptop på samme LAN er det ikke. Når navnet løses til din offentlige adresse og ruteren ikke har NAT-loopback, feiler en innvendig test mens posten er helt korrekt, og det sender de fleste ut i å redigere en post som aldri var feil.

Hva du skal kjøre når alle tre holder

ddclient er den minst overraskende oppdatereren for en liten vert. En minimal konfigurasjon publiserer adressen leverandøren ser, og det omgår dobbel-NAT-feilen:

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

Kjør den fra en systemd-timer hvert par minutter i stedet for en skalløkke, og logg leverandørens svar i stedet for å anta suksess. Behandle legitimasjonen som en nøkkel, fordi den avgjør hvor hver klient sendes: bruk et avgrenset oppdateringstoken i stedet for et kontopassord, hold filen på modus 0600, og send oppdateringer over HTTPS.

Bekreft før du binder deg

Ett oppslag forteller deg hva resten av verden ser, og det skriver ut TTL-en du må vente ut etter en endring:

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

Sammenlign den adressen med ruterens WAN-adresse. Hvis de stemmer, gjør navnet jobben sin, og det som fortsatt feiler, er innkommende tilgjengelighet, en nøkkel eller en klient som ikke har slått opp på nytt. Hvis de er forskjellige, publiserer oppdatereren feil grensesnitt, ofte fordi den kjørte på VPN-verten bak ruteren i stedet for på ruteren selv.

Ha en tilbakerulling som tar ett minutt: noter den siste fungerende adressen og forrige TTL, slik at du kan publisere begge for hånd mens leverandøren har en dårlig ettermiddag.

Når svaret er nei

Hvis betingelse én eller tre feiler, endres beslutningen i stedet for konfigurasjonen. Bak carrier-NAT er dine praktiske muligheter å be leverandøren om en offentlig adresse, flytte inngangspunktet til en liten VPS med stabil adresse, eller bruke et overlegg som holder sitt eget møtested. Hvis adressen er statisk, hopp over oppdatereren: én A-post, én AAAA-post hvis du kjører IPv6, samme portviding.

Hvis adressen endres mens klientene forblir tilkoblet, bor den ærlige rettelsen i klienten: gjenoppkoblingslogikk og et intervall for nye forsøk, ikke en raskere oppdaterer. En ekstra leverandør skjuler bare intervallet.

Før du går videre, bekreft fire ting i rekkefølge:

• Adressen oppdatereren publiserer, samsvarer med ruterens WAN-adresse.
• Postens TTL er kort nok til at en endring vises innen minutter.
• Portvidingen er bundet til grensesnittet, ikke til en fast adresse.
• Én ekte klient har koblet til på nytt og sluppet trafikk gjennom siden forrige endring.

Hvis alle fire holder, la oppsettet være; din neste feil er en nøkkel eller en brannmurregel og ikke et navneproblem. Hvis noen feiler, rett den raden før du legger til enda en bevegelig del. RFC 2136 beskriver selve oppdateringsmekanismen, hvis du vil se hva daemonen legger på ledningen.