Ar jums reikia dinaminio DNS namų VPN serveriui?

Dinaminis DNS sutvarko vardą, o ne įėjimo kelią. Trys patikros nusprendžia, ar hosto vardo pakanka namų VPN serveriui, ar įėjimo maršrutas sulaužytas.

Dauguma namų VPN gedimų, apie kuriuos manęs klausia, nėra DNS gedimai, ir vis tiek žmonės pirmiausia nusiperka dinaminio DNS prenumeratą. Prieš ką nors konfigūruodami, nuspręskite, ar hosto vardas yra ta dalis, kuri tikrai sulaužyta. Atnaujintuvas perrašo įrašą, kai paslaugų teikėjo duotas adresas pasislenka; jis negali atidaryti prievado, prasiskverbti pro operatoriaus NAT ar priversti veikiančią WireGuard sesiją pastebėti, kad pasikeitė jos galinis taškas. Trys sąlygos nusprendžia, ar dinaminis DNS yra visas sprendimas, ar tik viena jo eilutė.

Pirma sąlyga: jūsų adresas tikrai keičiasi

Gyvenamieji adresai keičiasi dėl įprastų priežasčių: modemas sinchronizuojasi iš naujo po elektros nutrūkimo, teikėjas perskirsto telkinį, po ilgo sutrikimo ateina nauja nuoma. Kai kuriose linijose jie keičiasi ir retai, o aš mačiau tą patį adresą išsilaikant metus; verslo planuose dažnai būna statinis. Jei per dvylika mėnesių niekas nepasikeitė, vienas ranka redaguojamas A įrašas yra vienu daemonu mažiau, kurį reikia palaikyti.

Išmatuokite, o ne spėliokite. Perskaitykite WAN adresą maršrutizatoriaus būsenos puslapyje ir palyginkite jį su tuo, ką mato išorinis pasaulis. Paleiskite tai iš LAN kompiuterio:

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

Jei dvi reikšmės skiriasi, kažkas verčia prieš jūsų maršrutizatorių, ir joks hosto vardo atnaujinimas to nesutvarkys. Adresas 100.64.0.0/10 ribose yra bendras operatoriaus lygio NAT diapazonas, ir tai yra įprasta priežastis, kodėl teisingai atnaujintas vardas vis tiek baigiasi skirtuoju laiku iš išorės.

Antra sąlyga: klientai vėl ieško vardo

Trumpas TTL yra ta dalis, kurią žmonės praleidžia. Rekursyvūs sprendėjai gerbia įrašo TTL, bet klientų krūvos kaupia podėlyje atskirai, o jau pakeltas tunelis nieko iš naujo neišsprendžia. Derinimo metu nustatykite įrašą 60-300 sekundžių; tai sutrumpina langą, kai patiekiamas pasenęs atsakymas, ir neperkelia prijungtos sesijos.

OpenVPN kaskart prisijungdamas iš naujo išsprendžia eilutę remote vpn.example.net 1194 , ir resolv-retry infinite verčia jį bandyti dar kartą, o ne išeiti, kai paieška nepavyksta. Serveryje float leidžia nusistovėjusiai sesijai sekti partnerį, kurio šaltinio adresas pasikeitė. WireGuard yra tiesesnis: wg-quick up taikant konfigūraciją išsprendžia Endpoint galinį tašką, o klientas jį vėl išsprendžia, kai atkuria tunelį, todėl rankos paspaudimas, kuris vis dar pavyksta senuoju adresu, pavyksta tol, kol sustoja.

Šis skirtumas formuoja planą. Jei klientai jungiasi pagal poreikį, adreso pasikeitimas kainuoja vieną prisijungimą. Jei jie laiko sesiją atidarytą dienomis, tikėkitės, kad tunelis mirs per kitą rankos paspaudimą, ir priverskite klientą bandyti dar kartą, o ne manyti, kad jis išlieka.

Trečia sąlyga: įėjimo kelias vis dar atidarytas

Dinaminis DNS keičia tik tai, kur rodo vardas, ir nieko daugiau. Prievado peradresavimas maršrutizatoriuje, ugniasienės taisyklė VPN hoste ir teikėjo leidimas įeinantiems paketams turi egzistuoti prieš įrašui įgyjant reikšmę. Atkreipkite dėmesį, į ką nukreiptas peradresavimas: jei jis pritvirtintas prie WAN adreso, o ne prie sąsajos, adreso pasikeitimas tyliai sugadina peradresavimą ir įrašas gauna kaltę.

Išbandykite iš išorės. Telefonas mobiliaisiais duomenimis su išjungtu Wi-Fi yra pigiausias sąžiningas bandymas; nešiojamas kompiuteris tame pačiame LAN – ne. Kai vardas išsprendžiamas į jūsų viešą adresą, o maršrutizatorius neturi NAT kilpos, vidinis bandymas nepavyksta, nors įrašas visiškai teisingas, ir tai nusiunčia daugumą taisyti įrašo, kuris niekada nebuvo klaidingas.

Ką paleisti, kai visos trys galioja

ddclient yra mažiausiai stebinantis atnaujintuvas mažam hostui. Minimali konfigūracija paskelbia adresą, kurį mato teikėjas, ir taip apeina dvigubo NAT klaidą:

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

Paleiskite jį iš systemd laikmačio kas kelias minutes, o ne iš shell ciklo, ir registruokite teikėjo atsakymą, o ne manykite, kad pavyko. Su prisijungimo duomenimis elkitės kaip su raktu, nes jie nusprendžia, kur siunčiamas kiekvienas klientas: naudokite apribotą atnaujinimo žetoną, o ne paskyros slaptažodį, laikykite failą 0600 režimu ir siųskite atnaujinimus per HTTPS.

Patikrinkite prieš įsipareigodami

Viena užklausa pasako, ką mato likęs pasaulis, ir išspausdina TTL, kurio turite palaukti po pakeitimo:

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

Palyginkite tą adresą su maršrutizatoriaus WAN adresu. Jei jie sutampa, vardas atlieka savo darbą, o tai, kas dar nepavyksta, yra įeinantis pasiekiamumas, raktas arba klientas, kuris neišsprendė iš naujo. Jei skiriasi, atnaujintuvas skelbia netinkamą sąsają, dažnai todėl, kad veikė VPN hoste už maršrutizatoriaus, o ne pačiame maršrutizatoriuje.

Turėkite vienos minutės atsukimą: užsirašykite paskutinį veikusį adresą ir ankstesnį TTL, kad abu galėtumėte paskelbti ranka, kol teikėjui bloga popietė.

Kai atsakymas yra ne

Jei pirma arba trečia sąlyga nepavyksta, keičiasi sprendimas, o ne konfigūracija. Už operatoriaus NAT praktinės galimybės yra paprašyti teikėjo viešo adreso, perkelti įėjimo tašką į mažą VPS su stabiliu adresu, arba naudoti perdangą, kuri palaiko savo susitikimą. Jei adresas statinis, praleiskite atnaujintuvą: vienas A įrašas, vienas AAAA įrašas, jei naudojate IPv6, tas pats prievado peradresavimas.

Jei adresas keičiasi klientams liekant prisijungusiems, sąžiningas pataisymas gyvena kliente: prisijungimo logika ir pakartojimo intervalas, o ne greitesnis atnaujintuvas. Antras teikėjas tik paslepia intervalą.

Prieš tęsdami patvirtinkite keturis dalykus iš eilės:

  • Adresas, kurį skelbia atnaujintuvas, sutampa su maršrutizatoriaus WAN adresu.
  • Įrašo TTL pakankamai trumpas, kad pakeitimas pasirodytų per kelias minutes.
  • Prievado peradresavimas susietas su sąsaja, o ne su fiksuotu adresu.
  • Vienas tikras klientas po paskutinio pakeitimo prisijungė iš naujo ir praleido srautą.

Jei visi keturi galioja, palikite sąranką ramybėje; jūsų kitas gedimas yra raktas arba ugniasienės taisyklė, o ne vardų problema. Jei kuris nors nepavyksta, sutaisykite tą eilutę prieš pridėdami dar vieną judančią dalį. RFC 2136 aprašo patį atnaujinimo mechanizmą, jei norite pamatyti, ką daemonas deda į laidą.

Susiję straipsniai