Az openfortivpn folyton felülírja a DNS-t? Találja meg a valódi gazdát

Kövesse a kapcsolatot attól a pillanattól, amikor feljön: a kliens hitelesít, a pppd tárgyal, aztán valami DNS-beállításokat ír az operációs rendszerbe. Ha csak annyit tud, hogy a VPN megváltoztatta a feloldóját, még nem tudja, melyik szakasz tette ezt. Kettő közülük képes rá, és a dokumentált pppd-integrációt használó kliensen elég közel futnak egymáshoz ahhoz, hogy egyetlen szereplőnek tűnjenek. Az író megnevezése az első lépés; a helyettes kiválasztása a második, és ez külön döntés a maga hibaformáival.

Az alábbi sorrend a klienst kifelé követi: mit változtatott a kapcsolat, melyik kapcsoló melyik írót némítja el, kinek kellene átvennie, és hogyan erősíthető meg, hogy az eredmény túléli az újracsatlakozást. Minden szakasz más nyomot hagy, és a nyom az, ami megmondja, valóban megtörtént-e az átadás.

Kezdje azzal, mit változtatott meg valójában a kapcsolat

Csatlakozzon egyszer a szokásos parancsával, és hasonlítsa össze a feloldást előtte és utána. Egy systemd-resolved-et futtató Linux-gazdagépen a resolvectl status kapcsolatonként kiírja a DNS-kiszolgálókat és a keresési tartományokat, és az új tun vagy ppp kapcsolat saját kiszolgálókkal a kliensoldali frissítés ujjlenyomata. macOS-en a scutil --dns a feloldó konfigurációját abban a sorrendben mutatja, ahogy az alkalmazások konzultálják.

Hasonlítsa össze ezt azzal a fájllal, amelyről azt várta, hogy megváltozik. A kapcsolathoz kötött bejegyzés a kapcsolatonkénti nézetben és az újraírt /etc/resolv.conf két különböző eredmény, és a második lehet egy szimbolikus hivatkozás, amelyet teljesen más kezel. Jegyezze fel a feloldó címét, a keresési tartományokat és az interfész nevét ugyanabban a pillanatban; bármelyikük változása más íróra mutat. E bázisvonal nélkül minden későbbi javítás találgatás arról, hogy három komponens közül melyik mozdult el.

A két kapcsoló és az író, amelyet mindegyik elnémít

Az openfortivpn dokumentál egy opciótöredéket, amely kikapcsolja mindkét írót, amelyet vezérelni tud, és minden kapcsolónak van egy teljesen kiírt megfelelője, amelyet a kézikönyv ugyanazon beállításként kezel.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns megakadályozza, hogy a kliens alkalmazza az átjárótól tanult DNS-kiszolgálókat, míg --pppd-no-peerdns megakadályozza, hogy a pppd a partner DNS-ét a rendszerbe tolja. Az upstream kézikönyve figyelmeztet, hogy a PPP-n keresztüli DNS-frissítések versenyezhetnek a kliens saját DNS-frissítéseivel, ezért mindkét kapcsoló a töredékbe tartozik, ahelyett hogy bármelyiket elegendőnek tekintenék.

Egyik kapcsoló sem nevez meg tartalék feloldót, és egyik sem akadályozza meg a hálózatkezelőt, a DHCP-klienst vagy egy külön VPN-integrációt abban, hogy utána feloldást írjon. Két író elnémítása nyitva hagyja a mezőt, nem birtokolva. Ha egy harmadik komponens már kezeli a DNS-t, a töredék semmit sem változtat, amit megfigyelhet; ha semmi sem kezeli, épp most távolította el a privát névfeloldás egyetlen forrását. Ez csak akkor érvényes elrendezés, ha a helyettes gazdát először választották ki és önállóan tesztelték.

Válassza ki a gazdát, mielőtt bármit kikapcsolna

Először döntse el, ki válaszol a munkanév-kérdésekre, mert ez a választás mindent korlátoz, ami utána jön. A meglévő feloldó megtartása azt jelenti, hogy a privát zónának már elérhetőnek kell lennie onnan, ahol a kliens ül, és az irodán belüli privát feloldónak olyan útvonalra van szüksége, amely túléli az alagút feljövését. Minden kérdés egyetlen belső szolgáltatáshoz küldése egy harmadik irányelv élesebb hibaformával: amikor az a szolgáltatás elérhetetlen, a nyilvános nevek a privátokkal együtt hibáznak.

Az útvonal-tulajdon szándékosan külön marad. Az útvonalopciók nem kötelezőek azért, mert megváltoztatta a DNS-t, és az útvonaltelepítés kikapcsolása helyettes telepítése nélkül elérhetetlenné teheti az épp kiválasztott feloldót. Ellenőrizze az útválasztási táblázatot kifejezetten a feloldó címére, ne csak arra az alkalmazás-alhálózatra, amelyet véletlenül tesztelt.

Kapcsolatonként ellenőrizze a feloldást, ne fájlonként

Egyetlen /etc/resolv.conf nem leltára annak, amit az alkalmazások valóban használnak egy hatókörölt vagy tartományonkénti feloldású gazdagépen, ezért úgy olvassa a feloldó állapotát, ahogy a platform feltárja.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

Kérdezzen meg egy privát nevet és egy nyilvános nevet, amint a kapcsolat feljött, és jegyezze fel, melyik kapcsolat válaszolt mindegyikre. Ahol a VPN-kapcsolat tartományonkénti keresési listát hordoz, egy privát név helyesen oldódhat fel, miközben egy nyilvános név még mindig a helyi feloldóhoz megy, és ez a szétválás a működő tervezés, nem hiba. Ha a privát lekérdezés meghiúsul, vizsgálja meg a feloldóhoz vezető útvonalat, mielőtt újra hozzányúl a DNS-hez; ha sikerül, miközben egy alkalmazás továbbra is hibázik, az alkalmazás talán a saját gyorsítótárazott vagy külön beállított feloldóját olvassa.

Csatlakozzon újra, és erősítse meg a leválasztott állapotot

Vegye le a kapcsolatot, és ismételje meg mindkét lekérdezést. Amit a kiválasztott gazda telepített, azt neki kell eltávolítania vagy visszaállítania, nem hagyhatja hátra az a kliens, amelyet elnémított. Az alagutat túlélő elavult kapcsolatonkénti bejegyzés továbbra is privát lekérdezéseket küld egy már elérhetetlen címre.

Aztán csatlakozzon újra, és olvassa el ismét ugyanazt a három értéket: a feloldó címe, a keresési tartományok, az interfész.

Ha megfelelnek a feljegyzett irányelvnek, az átadás teljes, és a VPN-kliens már nem egyike az íróknak. Ha egy érték néhány másodperccel a kapcsolat feljövetele után visszacsúszik, valami más még konfigurációt alkalmaz, és a következő lépés annak a komponensnek az azonosítása, nem egy újabb jelző hozzáadása. A kívánt végállapot eseménytelen: egy gazda, egy dokumentált irányelv, és egy leválasztott gazdagép, amely pontosan úgy old fel, mint az alagút létezése előtt.