Treng du dynamisk DNS for ein VPN-server heime?

Dei fleste VPN-feila heime som folk spør meg om, er ikkje DNS-feil, og likevel kjøper dei først eit dynamisk DNS-abonnement. Før du konfigurerer noko, avgjer om vertsnamnet er den delen som faktisk er øydelagd. Ein oppdaterar skriv om ei post når adressa leverandøren gav deg flyttar seg; han kan ikkje opne ein port, trenge gjennom NAT-en til operatøren eller få ei køyrande WireGuard-økt til å merke at endepunktet er endra. Tre vilkår avgjer om dynamisk DNS er heile løysinga eller berre éi linje av henne.

Vilkår éin: adressa di flyttar seg faktisk

Bustadadresser flyttar seg av keisamelege grunnar: modemet synkroniserer på nytt etter eit straumbrot, leverandøren balanserer om ein pool, ei ny leige kjem etter eit langt avbrot. På nokre linjer flyttar dei seg også sjeldan, og eg har sett same adresse overleve eitt år; bedriftsavtalar inneheld ofte ei statisk. Dersom ingenting har endra seg på tolv månader, er éi A-post du redigerer for hand, ein daemon mindre å halde i live.

Mål det i staden for å gjette. Les WAN-adressa på statussida til rutaren, og samanlikn henne med det omverda ser. Køyr dette frå ein maskin på LAN-et:

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

Dersom dei to verdiane er ulike, omset noko framfor rutaren din, og inga vertsnamn-oppdatering rettar det. Ei adresse innanfor 100.64.0.0/10 er det delte området for carrier-grade NAT, og det er den vanlege grunnen til at eit korrekt oppdatert namn framleis går ut på tid utanfrå.

Vilkår to: klientane slår opp namnet på nytt

Kort TTL er den delen folk hoppar over. Rekursive resolvarar respekterer TTL-en til posten, men klientstakkar cachar separat, og ein tunnel som alt står, slår ikkje opp noko på nytt. Set posten til 60-300 sekund medan du feilsøkjer; det forkortar vindauget der eit utdatert svar blir servert, og det flyttar ikkje ei tilkopla økt.

OpenVPN slår opp linja remote vpn.example.net 1194 på nytt kvar gong han koplar til att, og resolv-retry infinite får han til å prøve på nytt i staden for å avslutte når oppslaget feilar. På serveren lèt float ei etablert økt følgje ein peer der kjeldadressa er endra. WireGuard er meir direkte: wg-quick up slår opp Endpoint når konfigurasjonen blir brukt, og klienten slår han opp att når han byggjer tunnelen på nytt, så eit handtrykk som framleis lukkast mot den gamle adressa, held fram med å lukkast til det stoppar.

Den skilnaden formar planen. Dersom klientar koplar til ved behov, kostar ei adresseendring éi attkopling. Dersom dei held ei økt open i dagevis, rekn med at tunnelen døyr ved neste handtrykk, og få klienten til å prøve på nytt i staden for å anta at han blir ståande.

Vilkår tre: vegen inn er framleis open

Dynamisk DNS endrar berre kvar namnet peikar, og ingenting anna. Portvidinga på rutaren, brannmurregelen på VPN-verten og løyvet frå leverandøren til innkommande pakkar må alle finnast før posten tyder noko. Sjå på kva vidinga peikar på: dersom ho er fest til ei WAN-adresse i staden for grensesnittet, bryt ei adresseendring vidinga lydlaust, og posten får skulda.

Test utanfrå. Ein telefon på mobildata med Wi-Fi av er den billegaste ærlege testen; ein laptop på same LAN er det ikkje. Når namnet blir løyst til den offentlege adressa di og rutaren ikkje har NAT-løkk, feilar ein innvendig test medan posten er heilt korrekt, og det sender dei fleste ut i å redigere ein post som aldri var feil.

Kva du skal køyre når alle tre held

ddclient er den minst overraskande oppdateraren for ein liten vert. Ein minimal konfigurasjon publiserer adressa 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

Køyr han frå ein systemd-timar kvart par minutt i staden for ei skalløkkje, og logg svaret frå leverandøren i staden for å anta suksess. Handsame legitimasjonen som ein nøkkel, fordi han avgjer kvar kvar klient blir send: bruk eit avgrensa oppdateringstoken i staden for eit kontopassord, hald fila på modus 0600, og send oppdateringar over HTTPS.

Stadfest før du bind deg

Eitt oppslag fortel deg kva resten av verda ser, og det skriv ut TTL-en du må vente ut etter ei endring:

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

Samanlikn den adressa med WAN-adressa til rutaren. Dersom dei stemmer, gjer namnet jobben sin, og det som framleis feilar, er innkommande tilgjenge, ein nøkkel eller ein klient som ikkje har slått opp på nytt. Dersom dei er ulike, publiserer oppdateraren feil grensesnitt, ofte fordi han køyrde på VPN-verten bak rutaren i staden for på rutaren sjølv.

Hald ei tilbakerulling som tek eitt minutt: noter den siste fungerande adressa og førre TTL, slik at du kan publisere båe for hand medan leverandøren har ein dårleg ettermiddag.

Når svaret er nei

Dersom vilkår éin eller tre feilar, blir avgjerda endra i staden for konfigurasjonen. Bak carrier-NAT er dei praktiske moglegheitene dine å be leverandøren om ei offentleg adresse, flytte inngangspunktet til ein liten VPS med stabil adresse, eller bruke eit overlegg som held sitt eige møtestad. Dersom adressa er statisk, hopp over oppdateraren: éi A-post, éi AAAA-post dersom du køyrer IPv6, same portvidinga.

Dersom adressa blir endra medan klientane blir verande tilkopla, bur den ærlege rettinga i klienten: attkoplingslogikk og eit intervall for nye forsøk, ikkje ein raskare oppdaterar. Ein ekstra leverandør gøymer berre intervallet.

Før du går vidare, stadfest fire ting i rekkjefølgje:

• Adressa oppdateraren publiserer, svarar til WAN-adressa til rutaren.
• TTL-en til posten er kort nok til at ei endring blir synleg innan minutt.
• Portvidinga er bunden til grensesnittet, ikkje til ei fast adresse.
• Éin ekte klient har kopla til på nytt og sleppt trafikk gjennom sidan førre endring.

Dersom alle fire held, lat oppsettet vere; den neste feilen din er ein nøkkel eller ein brannmurregel og ikkje eit namneproblem. Dersom nokon feilar, rett den rada før du legg til endå ein flyttbar del. RFC 2136 skildrar sjølve oppdateringsmekanismen, dersom du vil sjå kva daemonen legg på leidningen.