Kell dinamikus DNS egy otthoni VPN-kiszolgálóhoz?

A legtöbb otthoni VPN-hiba, amiről kérdeznek, nem DNS-hiba, mégis először dinamikus DNS-előfizetést vásárolnak. Mielőtt bármit beállítana, döntse el, hogy a hosztnév-e az a rész, amely valóban elromlott. A frissítő akkor írja át a rekordot, amikor a szolgáltatója által adott cím elmozdul; nem tud portot nyitni, nem tud átjutni a szolgáltatói NAT-on, és nem tudja rávenni egy futó WireGuard-munkamenetet, hogy észrevegye a végpontja megváltozását. Három feltétel dönti el, hogy a dinamikus DNS a teljes megoldás-e, vagy csak annak egy sora.

Első feltétel: a címe tényleg elmozdul

Az otthoni címek hétköznapi okokból mozdulnak el: a modem újraszinkronizál áramszünet után, a szolgáltató újraoszt egy készletet, hosszú kimaradás után új bérlet érkezik. Egyes vonalakon ritkán is mozdulnak, és láttam ugyanazt a címet egy évig megmaradni; az üzleti csomagok gyakran tartalmaznak statikusat. Ha tizenkét hónap alatt semmi nem változott, egy kézzel szerkesztett A-rekord egy démonnal kevesebb, amit életben kell tartani.

Mérje meg a tippelés helyett. Olvassa le a WAN-címet az útválasztó állapotoldalán, majd hasonlítsa össze azzal, amit a külvilág lát. Futtassa ezt egy LAN-gépről:

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

Ha a két érték eltér, valami fordít az útválasztója előtt, és ezt semmilyen hosztnév-frissítés nem javítja meg. A 100.64.0.0/10-en belüli cím a szolgáltatói szintű NAT közös tartománya, és ez a szokásos oka annak, hogy egy helyesen frissített név kívülről mégis időtúllépésbe fut.

Második feltétel: az ügyfelek újra feloldják a nevet

A rövid TTL az a rész, amit az emberek kihagynak. A rekurzív feloldók tiszteletben tartják a rekord TTL-jét, de az ügyfélvermek külön gyorsítótáraznak, és egy már álló alagút semmit nem old fel újra. Hibakeresés közben állítsa a rekordot 60-300 másodpercre; ez lerövidíti azt az ablakot, amikor elavult választ szolgálnak ki, és nem telepíti át a csatlakozott munkamenetet.

OpenVPN minden újracsatlakozáskor újra feloldja a következőt: remote vpn.example.net 1194 sor, és a resolv-retry infinite minden újrapróbálkozásra kényszeríti ahelyett, hogy kilépne, ha a keresés meghiúsul. A kiszolgálón a float lehetővé teszi, hogy egy létrejött munkamenet kövessen egy partnert, amelynek forráscíme megváltozott. A WireGuard egyenesebb: a wg-quick up a konfiguráció alkalmazásakor feloldja ezt: Endpoint végpontot, és az ügyfél újra feloldja, amikor újraépíti az alagutat, így egy kézfogás, amely még sikeres a régi cím felé, addig sikeres marad, amíg meg nem áll.

Ez a különbség alakítja a tervet. Ha az ügyfelek igény szerint csatlakoznak, egy címváltozás egy újracsatlakozásba kerül. Ha napokig nyitva tartanak egy munkamenetet, számítson rá, hogy az alagút a következő kézfogásnál meghal, és az ügyfelet újrapróbálkozásra késztesse ahelyett, hogy feltételezné, hogy fenn marad.

Harmadik feltétel: a bejárati út még nyitva van

A dinamikus DNS csak azt változtatja meg, hova mutat a név, és semmi mást. Az útválasztón a porttovábbítás, a VPN-gazdagépen a tűzfal-szabály és a szolgáltató engedélye a bejövő csomagokra mindnek léteznie kell, mielőtt a rekord számít. Figyelje, mire irányul a továbbítás: ha WAN-címhez van rögzítve az interfész helyett, egy címváltozás csendben eltöri a továbbítást, és a rekord kapja a hibát.

Tesztelje kívülről. Egy mobilneten lévő telefon kikapcsolt Wi-Fi-vel a legolcsóbb őszinte teszt; egy ugyanazon a LAN-on lévő laptop nem az. Amikor a név a nyilvános címére oldódik fel, és az útválasztónak nincs NAT-hurok, egy belső teszt meghiúsul, miközben a rekord teljesen helyes, és ez a legtöbb embert egy soha nem hibás rekord szerkesztésére küldi.

Mit futtasson, ha mindhárom teljesül

A ddclient a legkevésbé meglepő frissítő egy kis gazdagéphez. Egy minimális konfiguráció közzéteszi azt a címet, amit a szolgáltató lát, és ezzel kikerüli a kettős NAT hibáját:

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

Futtassa systemd-időzítőből néhány percenként shell-hurok helyett, és naplózza a szolgáltató válaszát ahelyett, hogy sikert feltételezne. Kezelje a hitelesítő adatot kulcsként, mert ez dönti el, hová küld minden ügyfelet: használjon korlátozott frissítési tokent fiókjelszó helyett, tartsa a fájlt 0600 módban, és HTTPS-en küldje a frissítéseket.

Ellenőrizze, mielőtt elköteleződik

Egy lekérdezés megmondja, mit lát a világ többi része, és kinyomtatja a TTL-t, amit egy változás után ki kell várni:

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

Hasonlítsa össze ezt a címet az útválasztó WAN-címével. Ha egyeznek, a név végzi a dolgát, és ami még meghiúsul, az bejövő elérhetőség, egy kulcs vagy egy ügyfél, amely nem oldott fel újra. Ha eltérnek, a frissítő a rossz interfészt teszi közzé, gyakran azért, mert az útválasztó mögötti VPN-gazdagépen futott, nem magán az útválasztón.

Tartson készleten egy perc alatt elvégezhető visszaállítást: jegyezze fel az utolsó működő címet és az előző TTL-t, hogy mindkettőt kézzel tegye közzé, miközben a szolgáltatónak rossz délutánja van.

Amikor a válasz nem

Ha az első vagy a harmadik feltétel meghiúsul, a döntés változik, nem a konfiguráció. Szolgáltatói NAT mögött a gyakorlati lehetőségei: nyilvános címet kérni a szolgáltatótól, a belépési pontot stabil című kis VPS-re helyezni, vagy olyan átfedő réteget használni, amely saját találkozót tart. Ha a cím statikus, hagyja ki a frissítőt: egy A-rekord, egy AAAA-rekord, ha IPv6-ot futtat, ugyanaz a porttovábbítás.

Ha a cím akkor változik meg, amikor az ügyfelek csatlakozva maradnak, az őszinte javítás az ügyfélben él: újracsatlakozási logika és újrapróbálkozási időköz, nem gyorsabb frissítő. Egy második szolgáltató csak elrejti az időközt.

Mielőtt továbblép, sorrendben erősítsen meg négy dolgot:

• A frissítő által közzétett cím megegyezik az útválasztó WAN-címével.
• A rekord TTL-je elég rövid ahhoz, hogy egy változás perceken belül megjelenjen.
• A porttovábbítás az interfészhez van kötve, nem fix címhez.
• Egy valódi ügyfél újracsatlakozott és átvitt forgalmat az utolsó változás óta.

Ha mind a négy teljesül, hagyja békén a beállítást; a következő hibája egy kulcs vagy egy tűzfal-szabály lesz, nem névfeloldási probléma. Ha valamelyik meghiúsul, javítsa azt a sort, mielőtt újabb mozgó alkatrészt ad hozzá. RFC 2136 magát a frissítési mechanizmust írja le, ha látni akarja, mit tesz a démon a vezetékre.