Har du brug for dynamisk DNS til en VPN-server derhjemme?

Dynamisk DNS retter navnet, ikke vejen ind. Tre kontroller afgør, om et værtsnavn er nok til en VPN-server derhjemme, eller om ruten ind er brudt.

De fleste fejl med VPN derhjemme, som folk spørger mig om, er ikke DNS-fejl, og alligevel køber de først et dynamisk DNS-abonnement. Før du konfigurerer noget, så afgør, om værtsnavnet er den del, der faktisk er i stykker. En opdatering omskriver en post, når den adresse, din udbyder gav dig, flytter sig; den kan ikke åbne en port, trænge gennem carrier-NAT eller få en kørende WireGuard-session til at opdage, at dens endpoint er ændret. Tre betingelser afgør, om dynamisk DNS er hele løsningen eller kun én linje af den.

Betingelse et: din adresse flytter sig faktisk

Boligadresser flytter sig af kedelige grunde: modemet synkroniserer igen efter en strømafbrydelse, udbyderen afbalancerer en pulje, en ny leje lander efter et langt udfald. De flytter sig også sjældent på nogle linjer, og jeg har set den samme adresse overleve i et år; erhvervsabonnementer inkluderer ofte en statisk. Hvis intet har ændret sig i tolv måneder, er én A-post, du redigerer i hånden, en dæmon mindre at holde i live.

Mål det i stedet for at gætte. Læs WAN-adressen på routerens statusside, og sammenlign den med det, omverdenen ser. Kør dette fra en maskine på LAN:

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

Hvis de to værdier er forskellige, oversætter noget foran din router, og ingen opdatering af værtsnavnet retter det. En adresse inden for 100.64.0.0/10 er det delte område til carrier-grade NAT, og det er den sædvanlige grund til, at et korrekt opdateret navn stadig timer ud udefra.

Betingelse to: klienter slår navnet op igen

Kort TTL er den del, folk springer over. Rekursive resolvere respekterer postens TTL, men klientstakke cacher separat, og en tunnel, der allerede er oppe, slår intet op igen. Sæt posten til 60-300 sekunder, mens du fejlretter; det forkorter vinduet, hvor et forældet svar udleveres, og det flytter ikke en forbundet session.

OpenVPN slår linjen remote vpn.example.net 1194 op igen, hver gang den genopretter forbindelsen, og resolv-retry infinite får den til at prøve igen i stedet for at afslutte, når opslaget fejler. På serveren float lader en etableret session følge en peer, hvis kildeadresse er ændret. WireGuard er mere ligefrem: wg-quick up slår Endpoint op, når konfigurationen anvendes, og klienten slår den op igen, når den genopbygger tunnelen, så et håndtryk, der stadig lykkes mod den gamle adresse, bliver ved med at lykkes, indtil det stopper.

Den forskel former planen. Hvis klienter forbinder efter behov, koster en adresseændring én genforbindelse. Hvis de holder en session åben i dagevis, så regn med, at tunnelen dør ved næste håndtryk, og få klienten til at prøve igen i stedet for at antage, at den bliver oppe.

Betingelse tre: vejen ind er stadig åben

Dynamisk DNS ændrer, hvor navnet peger, og intet andet. Portforwarding på routeren, firewallreglen på VPN-værten og udbyderens tilladelse af indgående pakker skal alle findes, før posten betyder noget. Se på, hvad forwardingen peger på: hvis den er låst til en WAN-adresse i stedet for til interfacet, brækker en adresseændring forwardingen lydløst, og posten får skylden.

Test udefra. En telefon på mobildata med Wi-Fi slået fra er den billigste ærlige test; en laptop på samme LAN er det ikke. Når navnet opløses til din offentlige adresse, og routeren ikke har NAT-loopback, fejler en indvendig test, mens posten er helt korrekt, og det sender de fleste ud i at redigere en post, der aldrig var forkert.

Hvad du skal køre, når alle tre holder

ddclient er den mindst overraskende opdatering til en lille vært. En minimal konfiguration offentliggør den adresse, udbyderen ser, og det omgår dobbelt-NAT-fejlen:

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 fra en systemd-timer hvert par minutter i stedet for et shell-loop, og log udbyderens svar i stedet for at antage succes. Behandl legitimationsoplysningen som en nøgle, fordi den afgør, hvor hver klient sendes hen: brug et afgrænset opdateringstoken i stedet for en kontoadgangskode, hold filen på mode 0600, og send opdateringer over HTTPS.

Bekræft, før du binder dig

Et opslag fortæller dig, hvad resten af verden ser, og det udskriver den TTL, du skal vente ud efter en ændring:

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

Sammenlign den adresse med routerens WAN-adresse. Hvis de matcher, gør navnet sit arbejde, og det, der stadig fejler, er indgående tilgængelighed, en nøgle eller en klient, der ikke har slået op igen. Hvis de afviger, offentliggør opdateringen det forkerte interface, ofte fordi den kørte på VPN-værten bag routeren i stedet for på routeren selv.

Hav en tilbagerulning, der tager et minut: noter den sidste fungerende adresse og den forrige TTL, så du kan offentliggøre begge i hånden, mens udbyderen har en dårlig eftermiddag.

Når svaret er nej

Hvis betingelse et eller tre fejler, ændres beslutningen i stedet for konfigurationen. Bag carrier-NAT er dine praktiske muligheder at bede udbyderen om en offentlig adresse, at flytte indgangspunktet til en lille VPS med en stabil adresse, eller at bruge et overlay, der holder sit eget mødested. Hvis adressen er statisk, spring opdateringen over: én A-post, én AAAA-post, hvis du kører IPv6, den samme portforwarding.

Hvis adressen ændrer sig, mens klienterne forbliver forbundet, bor den ærlige rettelse i klienten: genforbindelseslogik og et interval for nye forsøg, ikke en hurtigere opdatering. En ekstra udbyder skjuler bare intervallet.

Før du går videre, bekræft fire ting i rækkefølge:

  • Adressen, opdateringen offentliggør, matcher routerens WAN-adresse.
  • Postens TTL er kort nok til, at en ændring viser sig inden for minutter.
  • Portforwardingen er bundet til interfacet, ikke til en fast adresse.
  • Én rigtig klient har genoprettet forbindelsen og sendt trafik siden sidste ændring.

Hvis alle fire holder, så lad opsætningen være; din næste fejl er en nøgle eller en firewallregel og ikke et navneproblem. Hvis nogen fejler, så ret den række, før du tilføjer endnu en bevægelig del. RFC 2136 beskriver selve opdateringsmekanismen, hvis du vil se, hvad dæmonen lægger på tråden.

Relaterede artikler