Kas vajad koduse VPN-serveri jaoks dünaamilist DNS-i?

Dünaamiline DNS parandab nime, mitte sissepääsutee. Kolm kontrolli otsustavad, kas hostinimi on koduse VPN-serveri jaoks piisav või on sissepääsutee katki.

Enamik koduse VPN-i tõrkeid, mille kohta minult küsitakse, ei ole DNS-i tõrked, ja ometi ostetakse kõigepealt dünaamilise DNS-i tellimus. Enne millegi seadistamist otsusta, kas hostinimi on see osa, mis on tegelikult katki. Uuendaja kirjutab kirje üle, kui sinu teenusepakkuja antud aadress liigub; see ei saa avada porti, läbida operaatori NAT-i ega panna töötavat WireGuard-seanssi märkama, et selle lõpp-punkt muutus. Kolm tingimust otsustavad, kas dünaamiline DNS on kogu lahendus või ainult üks selle rida.

Esimene tingimus: sinu aadress tõesti liigub

Elukoha-aadressid liiguvad tavalistel põhjustel: modem sünkroniseerub uuesti pärast voolukatkestust, teenusepakkuja tasakaalustab basseini ümber, pika katkestuse järel saabub uus rendileping. Mõnel liinil liiguvad need ka harva, ja ma olen näinud sama aadressi aasta vastu pidavat; äriplaanid sisaldavad sageli staatilist. Kui kaheteistkümne kuu jooksul pole midagi muutunud, on üks käsitsi muudetav A-kirje üks deemon vähem elus hoida.

Mõõda, mitte oleta. Loe ruuteri olekulehelt WAN-aadress ja võrdle seda sellega, mida näeb välismaailm. Käivita see LAN-is asuvast masinast:

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

Kui kaks väärtust erinevad, tõlgib midagi sinu ruuteri ees ja ükski hostinime uuendus ei paranda seda. Aadress vahemikus 100.64.0.0/10 on operaatoritasandi NAT-i jagatud vahemik, ja see on tavaline põhjus, miks õigesti uuendatud nimi väljast ikka aegub.

Teine tingimus: kliendid otsivad nime uuesti

Lühike TTL on see osa, mille inimesed vahele jätavad. Rekursiivsed resolverid austavad kirje TTL-i, kuid kliendipinud puhverdavad eraldi ja juba püsti olev tunnel ei lahenda midagi uuesti. Sea kirje silumise ajal 60-300 sekundile; see lühendab akent, kus serveeritakse vananenud vastust, ega migreeri ühendatud seanssi.

OpenVPN lahendab uuesti rea remote vpn.example.net 1194 igal taasühendusel, ja resolv-retry infinite sunnib seda uuesti proovima, selle asemel et väljuda, kui otsing ebaõnnestub. Serveris laseb float loodud seansil järgida partnerit, mille lähteaadress muutus. WireGuard on otsesem: wg-quick up lahendab Endpoint konfiguratsiooni rakendamisel ja klient lahendab selle uuesti, kui ta tunneli uuesti üles ehitab, nii et vana aadressi vastu veel õnnestuv kätlus õnnestub edasi, kuni see peatub.

See erinevus kujundab plaani. Kui kliendid ühenduvad nõudmisel, maksab aadressimuutus ühe taasühenduse. Kui nad hoiavad seanssi päevi lahti, oota, et tunnel sureb järgmisel kätlusel, ja pane klient uuesti proovima, selle asemel et eeldada, et see püsib.

Kolmas tingimus: sissepääsutee on endiselt avatud

Dünaamiline DNS muudab ainult seda, kuhu nimi osutab, ja ei midagi muud. Ruuteri pordisuunamine, VPN-hostija tulemüürireegel ja teenusepakkuja luba sissetulevatele pakettidele peavad kõik olemas olema, enne kui kirjel on tähtsust. Jälgi, mida suunamine sihib: kui see on kinnitatud WAN-aadressi, mitte liidese külge, katkeb aadressimuutusel suunamine vaikselt ja süü langeb kirjele.

Testi väljast. Telefon mobiilsel andmesidel, Wi-Fi väljas, on odavaim aus test; sülearvuti samas LAN-is ei ole. Kui nimi laheneb sinu avalikuks aadressiks ja ruuteril pole NAT-loopbacki, ebaõnnestub sisemine test, kuigi kirje on täiesti õige, ja see saadab enamiku inimesi muutma kirjet, mis ei olnud kunagi vale.

Mida käivitada, kui kõik kolm kehtivad

ddclient on väikese hostija jaoks kõige vähem üllatav uuendaja. Minimaalne konfiguratsioon avaldab aadressi, mida teenusepakkuja näeb, mis väldib topelt-NAT-i vea:

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äivita seda systemd-taimerist iga paari minuti järel, mitte shell-tsüklist, ja logi teenusepakkuja vastust, selle asemel et eeldada õnnestumist. Kohtle mandaati nagu võtit, sest see otsustab, kuhu iga klient saadetakse: kasuta piiratud uuendusluba, mitte konto parooli, hoia faili režiimil 0600 ja saada uuendused üle HTTPS-i.

Kontrolli enne, kui kohustud

Üks päring ütleb sulle, mida näeb ülejäänud maailm, ja trükib TTL-i, mida pead pärast muudatust ootama:

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

Võrdle seda aadressi ruuteri WAN-aadressiga. Kui need kattuvad, teeb nimi oma tööd ja see, mis ikka ebaõnnestub, on sissetulev kättesaadavus, võti või klient, kes pole uuesti lahendanud. Kui need erinevad, avaldab uuendaja vale liidese, sageli seetõttu, et see töötas ruuteri taga VPN-hostijal, mitte ruuteril endal.

Hoia tagasipööramine, mis võtab minuti: pane kirja viimane töötav aadress ja eelmine TTL, et saaksid mõlemad käsitsi avaldada, kui teenusepakkujal on halb pärastlõuna.

Kui vastus on ei

Kui esimene või kolmas tingimus ei täitu, muutub otsus, mitte konfiguratsioon. Operaatori NAT-i taga on sinu praktilised valikud paluda teenusepakkujalt avalikku aadressi, viia sissepääsupunkt väikesele stabiilse aadressiga VPS-ile, või kasutada ülekattet, mis hoiab oma kohtumispaika. Kui aadress on staatiline, jäta uuendaja vahele: üks A-kirje, üks AAAA-kirje, kui kasutad IPv6-te, sama pordisuunamine.

Kui aadress muutub klientide ühendatuks jäämise ajal, elab aus parandus kliendis: taasühendusloogika ja korduskatse intervall, mitte kiirem uuendaja. Teine teenusepakkuja ainult peidab intervalli.

Enne edasi liikumist kinnita neli asja järjekorras:

  • Aadress, mille uuendaja avaldab, kattub ruuteri WAN-aadressiga.
  • Kirje TTL on piisavalt lühike, et muudatus paistaks minutite jooksul.
  • Pordisuunamine on seotud liidesega, mitte fikseeritud aadressiga.
  • Üks päris klient on viimasest muudatusest saati uuesti ühendunud ja liiklust läbi lasknud.

Kui kõik neli kehtivad, jäta seadistus rahule; sinu järgmine tõrge on võti või tulemüürireegel, mitte nimetamise probleem. Kui mõni ei täitu, paranda see rida enne, kui lisad veel ühe liikuva osa. RFC 2136 kirjeldab uuendusmehhanismi ennast, kui tahad näha, mida deemon juhtmele paneb.

Seotud artiklid