Het jy dinamiese DNS nodig vir 'n tuis-VPN-bediener?

Die meeste tuis-VPN-foute waaroor mense my vra, is nie DNS-foute nie, en hulle koop tog eers 'n dinamiese DNS-intekening. Voordat jy enigiets opstel, besluit of die hostnaam die deel is wat werklik stukkend is. 'n Opdatering herskryf 'n rekord wanneer die adres wat jou ISP aan jou gegee het, verander; dit kan nie 'n poort oopmaak, deur draer-NAT breek of 'n lewende WireGuard-sessie laat agterkom dat sy eindpunt verander het nie. Drie voorwaardes bepaal of dinamiese DNS die hele oplossing is of net een reël daarvan.

Voorwaarde een: jou adres verander werklik

Woonadresse verander om onopvallende redes: die modem hersinchroniseer ná 'n kragonderbreking, die ISP herverdeel 'n poel, 'n nuwe huurkontrak kom ná 'n lang onderbreking. Op sommige lyne verander hulle ook selde, en ek het gesien hoe dieselfde adres 'n jaar lank bly staan; sakeplanne sluit dikwels 'n statiese adres in. As niks in twaalf maande verander het nie, is 'n enkele A-rekord wat jy met die hand wysig, een daemon minder om aan die lewe te hou.

Meet dit eerder as om te raai. Lees die WAN-adres op die router se statusbladsy en vergelyk dit met wat die wêreld daarbuite sien. Voer dit uit vanaf 'n masjien op die LAN:

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

As die twee waardes verskil, is iets voor jou router besig om te vertaal, en geen hostnaam-opdatering sal dit regmaak nie. 'n Adres binne 100.64.0.0/10 is die gedeelde reeks vir draer-graad NAT, en dit is die gewone rede waarom 'n korrek opgedateerde naam steeds van buite af tyd uitloop.

Voorwaarde twee: kliënte soek die naam weer op

'n Kort TTL is die deel wat mense oorslaan. Rekursiewe oplossers eerbiedig die rekord se TTL, maar kliëntstapels kas apart, en 'n tonnel wat reeds op is, los niks weer op nie. Stel die rekord op 60-300 sekondes terwyl jy ontfout; dit verkort die venster waarin 'n verouderde antwoord bedien word, en dit migreer nie 'n gekoppelde sessie nie.

OpenVPN los die remote vpn.example.net 1194 reël weer op elke keer wat dit herkoppel, en resolv-retry infinite hou dit aan probeer in plaas daarvan om te stop wanneer die naslaan misluk. Op die bediener laat float 'n gevestigde sessie 'n eweknie volg wie se bronadres verander het. WireGuard is botter: wg-quick up los die Endpoint op wanneer die konfigurasie toegepas word, en die kliënt los dit weer op wanneer hy die tonnel herbou, so 'n handdruk wat steeds teen die ou adres slaag, bly slaag totdat dit ophou.

Daardie verskil bepaal die plan. As kliënte op aanvraag koppel, kos 'n adresverandering een herkoppeling. As hulle 'n sessie dae lank oop hou, verwag dat die tonnel by die volgende handdruk doodgaan, en laat die kliënt weer probeer in plaas daarvan om te aanvaar dat dit op bly.

Voorwaarde drie: die inkomende pad is steeds oop

Dinamiese DNS verander net waar die naam wys, en niks anders nie. Die poortaanstuur op die router, die brandmuurreël op die VPN-gasheer en die ISP wat inkomende pakkette toelaat, moet almal bestaan voordat die rekord saak maak. Let op waarheen die aanstuur mik: as dit aan 'n WAN-adres vasgepen is in plaas van aan die koppelvlak, breek 'n adresverandering die aanstuur stil en kry die rekord die skuld.

Toets van buite. 'n Foon op selfoondata met Wi-Fi af is die goedkoopste eerlike toets; 'n skootrekenaar op dieselfde LAN is nie. Wanneer die naam na jou publieke adres oplos en die router het geen NAT-teruglus nie, misluk 'n binne-toets terwyl die rekord heeltemal korrek is, wat die meeste mense wegstuur om 'n rekord te wysig wat nooit verkeerd was nie.

Wat om te hardloop wanneer al drie geld

ddclient is die minste verrassende opdatering vir 'n klein gasheer. 'n Minimale konfigurasie publiseer die adres wat die verskaffer sien, wat die dubbel-NAT-fout vermy:

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

Hardloop dit uit 'n systemd-tydhouer elke paar minute eerder as 'n skel-lus, en teken die verskaffer se antwoord aan eerder as om sukses te aanvaar. Behandel die geloofsbrief soos 'n sleutel, want dit bepaal waarheen elke kliënt gestuur word: gebruik 'n beperkte opdateringstoken eerder as 'n rekeningwagwoord, hou die lêer op modus 0600, en stuur opdaterings oor HTTPS.

Kontroleer voordat jy besluit

Een opsoek vertel jou wat die res van die wêreld sien, en dit druk die TTL wat jy ná 'n verandering moet uitwag:

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

Vergelyk daardie adres met die router se WAN-adres. As hulle ooreenstem, doen die naam sy werk, en wat steeds misluk, is inkomende bereikbaarheid, 'n sleutel of 'n kliënt wat nie weer opgelos het nie. As hulle verskil, publiseer die opdatering die verkeerde koppelvlak, dikwels omdat dit op die VPN-gasheer agter die router geloop het in plaas van op die router self.

Hou 'n terugrol wat 'n minuut neem: noteer die laaste werkende adres en die vorige TTL, sodat jy albei met die hand kan publiseer terwyl die verskaffer 'n slegte middag het.

Wanneer die antwoord nee is

As voorwaarde een of drie misluk, verander die besluit eerder as die konfigurasie. Agter draer-NAT is jou praktiese opsies om die ISP om 'n publieke adres te vra, die toegangspunt na 'n klein VPS met 'n stabiele adres te skuif, of om 'n oorleg te gebruik wat sy eie ontmoetingsplek hou. As die adres staties is, slaan die opdatering oor: een A-rekord, een AAAA-rekord as jy IPv6 hardloop, dieselfde poortaanstuur.

As die adres verander terwyl kliënte gekoppel bly, woon die eerlike oplossing op die kliënt: herkoppelingslogika en 'n herprobeer-interval, nie 'n vinniger opdatering nie. 'n Tweede verskaffer byvoeg versteek net die interval.

Voordat jy verder gaan, bevestig vier dinge in volgorde:

• Die adres wat die opdatering publiseer, stem ooreen met die router se WAN-adres.
• Die rekord se TTL is kort genoeg dat 'n verandering binne minute wys.
• Die poortaanstuur is aan die koppelvlak gebind, nie aan 'n vaste adres nie.
• Een werklike kliënt het weer gekoppel en verkeer deurgelaat sedert die laaste verandering.

As al vier geld, los die opstelling alleen; jou volgende fout is 'n sleutel of 'n brandmuurreël eerder as 'n naamprobleem. As enige misluk, maak daardie ry reg voordat jy nog 'n bewegende deel byvoeg. RFC 2136 beskryf die opdateringsmeganisme self, as jy wil sien wat die daemon op die draad sit.