Tarvitsetko dynaamisen DNS:n kotiverkon VPN-palvelimelle?

Suurin osa minulta kysytyistä kodin VPN-vioista ei ole DNS-vikoja, ja silti ihmiset ostavat ensin dynaamisen DNS:n tilauksen. Ennen kuin asennat mitään, päätä, onko isäntänimi se osa, joka on oikeasti rikki. Päivittäjä kirjoittaa tietueen uudelleen, kun operaattorisi antama osoite liikkuu; se ei voi avata porttia, läpäistä operaattorin NAT:ia eikä saada käynnissä olevaa WireGuard-istuntoa huomaamaan, että sen päätepiste vaihtui. Kolme ehtoa ratkaisee, onko dynaaminen DNS koko ratkaisu vai vain yksi sen rivi.

Ehto yksi: osoitteesi todella liikkuu

Asuinosoitteet liikkuvat tavallisista syistä: modeemi synkronoituu uudelleen sähkökatkon jälkeen, operaattori tasapainottaa poolia, uusi vuokra saapuu pitkän katkon jälkeen. Joillain linjoilla ne liikkuvat myös harvoin, ja olen nähnyt saman osoitteen kestävän vuoden; yritysliittymiin kuuluu usein kiinteä. Jos kahdessatoista kuussa mikään ei ole muuttunut, yksi käsin muokattava A-tietue on yksi taustaprosessi vähemmän pidettävänä.

Mittaa äläkä arvaa. Lue WAN-osoite reitittimen tilasivulta ja vertaa sitä siihen, mitä ulkomaailma näkee. Aja tämä LAN:in koneelta:

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

Jos kaksi arvoa eroavat, jokin kääntää reitittimesi edessä, eikä mikään isäntänimen päivitys korjaa sitä. Osoite alueella 100.64.0.0/10 on operaattoritason NAT:in jaettu alue, ja se on tavallinen syy siihen, että oikein päivitetty nimi silti aikakatkeaa ulkoa.

Ehto kaksi: asiakkaat katsovat nimen uudelleen

Lyhyt TTL on se osa, jonka ihmiset ohittavat. Rekursiiviset resolverit noudattavat tietueen TTL:ää, mutta asiakasohjelmapinot välimuistittavat erikseen, eikä jo pystyssä oleva tunneli ratkaise mitään uudelleen. Aseta tietue 60-300 sekuntiin vianetsinnän ajaksi; se lyhentää ikkunaa, jossa vanhentunutta vastausta tarjoillaan, eikä se siirrä yhdistettyä istuntoa.

OpenVPN ratkaisee rivin remote vpn.example.net 1194 uudelleen joka kerta yhdistäessään, ja resolv-retry infinite pitää sen yrittämässä uudelleen sen sijaan että se lopettaisi, kun haku epäonnistuu. Palvelimella float sallii vakiintuneen istunnon seurata vertaista, jonka lähdeosoite vaihtui. WireGuard on suorempi: wg-quick up ratkaisee Endpoint konfiguraation käyttöönotossa, ja asiakas ratkaisee sen uudelleen rakentaessaan tunnelin, joten kättely, joka vielä onnistuu vanhaa osoitetta vastaan, jatkaa onnistumistaan kunnes se pysähtyy.

Tämä ero muovaa suunnitelman. Jos asiakkaat yhdistävät pyynnöstä, osoitteen vaihdos maksaa yhden uudelleenyhdistämisen. Jos he pitävät istuntoa auki päiviä, odota tunnelin kuolevan seuraavassa kättelyssä, ja laita asiakas yrittämään uudelleen sen sijaan että olettaisit sen pysyvän pystyssä.

Ehto kolme: sisäänmenoreitti on yhä auki

Dynaaminen DNS muuttaa vain sitä, mihin nimi osoittaa, eikä muuta. Reitittimen portinohjaus, VPN-isäntäkoneen palomuurisääntö ja operaattorin sallinta saapuville paketeille tarvitsevat kaikki olla olemassa ennen kuin tietueella on merkitystä. Katso, mihin ohjaus tähtää: jos se on kiinnitetty WAN-osoitteeseen eikä rajapintaan, osoitteen vaihdos rikkoo ohjauksen äänettömästi ja tietue saa syyn niskoilleen.

Testaa ulkoa. Puhelin mobiilidatalla ja Wi-Fi pois päältä on halvin rehellinen testi; samassa LAN:issa oleva kannettava ei ole. Kun nimi ratkeaa julkiseen osoitteeseesi eikä reitittimessä ole NAT-silmukkaa, sisäinen testi epäonnistuu vaikka tietue on täysin oikein, ja se lähettää useimmat muokkaamaan tietuetta, joka ei koskaan ollut väärin.

Mitä ajaa, kun kaikki kolme pätevät

ddclient on vähiten yllättävä päivittäjä pienelle isäntäkoneelle. Minimaalinen konfiguraatio julkaisee osoitteen, jonka tarjoaja näkee, ja välttää näin kaksois-NAT-virheen:

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

Aja sitä systemd-ajastimesta muutaman minuutin välein shell-silmukan sijaan, ja kirjaa tarjoajan vastaus sen sijaan että olettaisit onnistumisen. Kohtele tunnusta kuin avainta, koska se päättää, minne jokainen asiakas lähetetään: käytä rajattua päivitystunnusta tilin salasanan sijaan, pidä tiedosto tilassa 0600 ja lähetä päivitykset HTTPS:n yli.

Varmista ennen kuin sitoudut

Yksi kysely kertoo, mitä muu maailma näkee, ja tulostaa TTL:n, joka sinun on odotettava muutoksen jälkeen:

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

Vertaa sitä osoitetta reitittimen WAN-osoitteeseen. Jos ne täsmäävät, nimi tekee työnsä ja se mikä yhä epäonnistuu on saapuva tavoitettavuus, avain tai asiakas, joka ei ole ratkaissut uudelleen. Jos ne eroavat, päivittäjä julkaisee väärän rajapinnan, usein siksi että se ajettiin reitittimen takana olevalla VPN-isäntäkoneella eikä itse reitittimellä.

Pidä minuutin palautus valmiina: kirjaa viimeinen toimiva osoite ja edellinen TTL, jotta voit julkaista molemmat käsin tarjoajan huonona iltapäivänä.

Kun vastaus on ei

Jos ehto yksi tai kolme pettää, päätös muuttuu eikä konfiguraatio. Operaattorin NAT:in takana käytännön vaihtoehtosi ovat pyytää operaattorilta julkista osoitetta, siirtää sisäänmenopiste pieneen VPS:ään, jolla on vakaa osoite, tai käyttää päällekkäisverkkoa, joka pitää oman kohtaamispaikkansa. Jos osoite on kiinteä, jätä päivittäjä väliin: yksi A-tietue, yksi AAAA-tietue jos ajat IPv6:tta, sama portinohjaus.

Jos osoite vaihtuu asiakkaiden pysyessä yhdistettyinä, rehellinen korjaus asuu asiakkaassa: uudelleenyhdistämislogiikka ja uusintayrityksen väli, ei nopeampi päivittäjä. Toinen tarjoaja vain piilottaa välin.

Ennen kuin jatkat, vahvista neljä asiaa järjestyksessä:

• Päivittäjän julkaisema osoite täsmää reitittimen WAN-osoitteeseen.
• Tietueen TTL on tarpeeksi lyhyt, jotta muutos näkyy minuuteissa.
• Portinohjaus on sidottu rajapintaan, ei kiinteään osoitteeseen.
• Yksi oikea asiakas on yhdistänyt uudelleen ja välittänyt liikennettä viimeisen muutoksen jälkeen.

Jos kaikki neljä pitävät, jätä asennus rauhaan; seuraava vikasi on avain tai palomuurisääntö eikä nimeämisongelma. Jos jokin pettää, korjaa se rivi ennen kuin lisäät uuden liikkuvan osan. RFC 2136 kuvaa itse päivitysmekanismin, jos haluat nähdä, mitä taustaprosessi lähettää johtoa pitkin.