A ddclient kihirdeti a VPN-kimenetet: javítsuk a felderítési forrást

A DNS-neved most egy VPN-szolgáltató címére oldódik fel, és a frissítési napló teljesen egészségesnek látszik. Ez a kombináció normális. Egy webalapú felderítési próba megkérdez egy külső szolgáltatást, milyen forrást lát, és amikor a kérés teljes alagútú VPN-en keresztül lép ki, a válasz a VPN-kimenet, nem az otthoni WAN-címed. A frissítő elvégezte a dolgát; a munka rossz megfigyelésre irányult.

Erősítsd meg, mit kell elérnie a névnek

Egy bejövő otthoni szolgáltatás nyilvános nevének olyan cím kell, amelyen keresztül a jóváhagyott bejövő kapcsolatok elérik azt a szolgáltatást. Egy megosztott szolgáltatói kimenet kihirdetése nem rendez bejövő továbbítást ott, és semmilyen DNS-konfiguráció nem hozza létre azt a továbbítást. Döntsd el ezt, mielőtt a frissítőhöz nyúlsz, mert ez határozza meg, melyik cím a helyes.

Egy VPN-kliens alagútcímének privát neve másik probléma másik válasszal: a privát DNS-be tartozik, és egyáltalán nem igényel nyilvános felderítési szolgáltatást. A két követelmény összekeverése az, ahogy egy működő konfiguráció elkezd olyan címet kihirdetni, amelyet senki sem kért.

Az interfészcímek értelmezést is igényelnek. Az otthoni router mögötti laptop címe nem a nyilvános WAN-cím, és még a router WAN-címe is lehet szolgáltatói NAT mögött, ahol a kihirdetése nem tud bejövő elérhetőséget adni.

Reprodukáld az értéket, mielőtt bármit módosítanál

Figyeld a két útvonalat külön. Ha az alagút aktív, a próba a kimenetet jelenti; ha az alagút le van kapcsolva, vagy a próba a fizikai interfészhez van kötve, az otthoni címet jelenti: curl --interface eth0 https://ifconfig.me. Ha ez a két válasz eltér, anélkül reprodukáltad a hibát, hogy hozzányúltál volna a frissítőhöz.

Ezután futtasd a klienst olyan módban, amely frissítés nélkül ellenőrzi a konfigurációt, például ddclient -verbose -noexec, és olvasd ki, melyik felderítési módszert választotta. A részletes kimenet megnevezi a módszert és a kapott értéket, és ez az a tény, amelyre bármilyen szerkesztés előtt szükséged van.

Irányítsd a felderítést a választott útvonalra

Ha a névnek az otthoni WAN-címet kell kihirdetnie, a felderítésnek azt a címet kell figyelnie. Három lehetőség működik, durva preferenciasorrendben: hagyd, hogy a router a saját támogatott frissítőjén keresztül hirdessen; használd a ddclient routerállapot-felderítését egy olyan oldal ellen, amelyet a router valóban kiszolgál; vagy tartsd meg a webes próbát, de kösd a fizikai interfészhez, hogy az alagúton kívül lépjen ki.

A routerállapot-útvonalhoz az újabb ddclient-kiadások a usev4 és fwv4 opciócsaládot használják, opcionális kihagyási mintával a környező oldalszöveghez. Nézd meg a telepített verziód README-jét, mert a régebbi kiadások ugyanezt az ötletet use és fw formában írják, és a rossz kiadásból másolt opciónév indításkor elbukik.

Ha megtartod a webes felderítést, ne feledd, hogy a próba útvonalválasztása és a frissítési API-hívás útvonalválasztása külön döntés. A frissítési hívás szállítja a rekordot; a próba dönti el, milyen érték kerül kiszállításra.

Tartsd rendben a titkokat és a verziókat

A router hitelesítő adatai és a szolgáltatói tokenek védett konfigurációs fájlba valók, nem olyan parancssorba, amely a shell-előzményekbe kerül. A részletes nyomok mindkettőt tartalmazhatják, ezért szerkeszd ki őket, mielőtt jegybe illeszted. Az a felderítési módszer, amely hitelesített routeroldal kaparását igényli, azt is megköveteli, hogy ezek a hitelesítő adatok firmware-frissítéseken át működjenek. Ugyanolyan gonddal őrizd, mint a szolgáltatói tokent.

A ddclient README dokumentálja a felderítési megközelítéseket és opcióneveiket. Ne keverd az IPv4- és IPv6-eredményeket egy rekordban, és ne feltételezd, hogy egy kiadásban létező opció egy másikban is létezik.

Ellenőrizd az értéket, majd az elérhetőséget

Hasonlítsd össze a javasolt címet a szándékolt végponttal, mielőtt engedélyezel egy élő frissítést, majd egy engedélyezett frissítés után ellenőrizd a hiteles DNS-t, és számolj a feloldók gyorsítótáraival. Az alacsony TTL rövidíti a várakozást; nem teszi helyessé a rossz értéket.

Csak akkor teszteld a bejövő szolgáltatást független hálózatból, ha a rekord már helyes, és a szükséges tűzfal és továbbítás már jóváhagyott. Egy helyes A-rekord nem bizonyít elérhető szolgáltatást, és egy statikus VPN-bérlet egyszerűsítheti a privát névadást anélkül, hogy megjavítaná a rossz WAN-ra mutató nyilvános gazdagépnevet.