Melyik kapcsolat válaszol: útválasztási tartományok split-tunnel VPN DNS-hez

Tartsa a szokásos böngészést a helyi kapcsolaton, miközben a cég nevei a tunel által biztosított DNS-kiszolgálón keresztül oldódnak fel. A VPN alapértelmezett útvonalának kikapcsolása az első felét adja, a másodikat építetlenül hagyja. A következő a hiányzó beállítás, a jelentését megváltoztató írásjel, és az az egyetlen parancs, amely megmutatja, melyik kapcsolat válaszolt valójában. A NetworkManager és a systemd-resolved végig feltételezett, mert a zavar általában ezen a páron kezdődik.

Első lépés: válassza szét az útvonalat a feloldótól

Az ipv4.never-default útválasztási kérdésre válaszol, és megakadályozza, hogy a NetworkManager ezt a kapcsolatot az összes IPv4-forgalom útjaként telepítse. A DNS útválasztási tartomány más kérdésre válaszol: melyik kapcsolat névkiszolgálói kapják az egyező utótagra vonatkozó lekérdezést. Egyik sem jelenti a másikat, és egy profil évekig hordozhatja az egyiket, miközben a másik hiányzik. Csak útvonal azt jelenti, hogy a tunel a cég alhálózatait viszi, és feloldója a cég neveire válaszol, minden más érintetlen marad.

Állítsa be csak az útvonal tulajdonságát, és a belső nevek meghiúsulnak, általában egy időtúllépéssel, amely törött tunelnek hangzik. Állítsa be csak a tartományt, és csendben keresési utótagot adott a gépen minden rövid névhez. Mindkét hiba a VPN-kiszolgálóhoz küldi a jegyet, amely ritkán a hibás rész.

Második lépés: adjon hozzá csak-útválasztási tartományt a profilhoz

Tegyük fel, hogy a kapcsolat neve corp-vpn, a cég utótagja internal.example, és a tunel feloldója már elérhető. Először olvassa ki a jelenlegi értékeket, mert az alábbi parancsok olyan tulajdonságokat módosítanak, amelyekben már lehetnek bejegyzések.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Helyettesítse a saját kapcsolatnevével és utótagjával, mert a fenti értékek szemléltetők. A pluszjel fontosabb, mint látszik: vele az érték a meglévő listához fűződik, nélküle a tulajdonság lecserélődik, és a tegnap működő profilból eltűnnek a nem kapcsolódó tartományok. A tilde viselkedést változtat, nem stílust, és az alábbi bekezdés leírja, mit választ. Tartsa az olvasást az írás előtt, hogy a csereforma soha ne lepje meg.

A kezdő tilde csak-útválasztási tartományt jelöl, így az egyező lekérdezések ennek a kapcsolatnak a kiszolgálóira mennek, és az utótag nem fűződik a rövid nevekhez. Vegye le a tildét, és ugyanaz a karakterlánc keresési utótaggá is válik, ami más eredmény, és az emberek ritkán ezt akarják. A fenti két beállítás IPv4, ezért a kettős verem profilnak ipv6.never-default-ra és ugyanarra az útválasztási tartományra van szüksége az ipv6.dns-search-ben, különben az IPv6 oldal tovább használja az alapértelmezett útvonalat, és ott a belső nevek meghiúsulnak.

Harmadik lépés: kérdezze meg a resolvectl-t, melyik kapcsolat válaszolt

Futtassa a resolvectl status parancsot, és olvassa ki minden kapcsolat DNS-kiszolgálóit és tartományait, majd futtassa a resolvectl query host.internal.example parancsot egy valódi belső névre, amelyet szabad kérdeznie. A második parancs az egyetlen közvetlen bizonyíték arra, hogy az útválasztási tartomány teszi a dolgát, mert megnevezi a válaszoló kapcsolatot. Az állapotlista önmagában a konfigurációt bizonyítja; a lekérdezés a feloldást.

A systemd-resolved a legjobban illeszkedő útválasztási tartományt választja, ezért egy másik kapcsolat konkrétabb tartománya még nyerhet a versenyben. Ha a lekérdezés nem várt kapcsolatról jön vissza, olvassa el a tartománylistákat, mielőtt a VPN DNS-kiszolgálójához nyúl. A ~. gyökértartomány mindenre illeszkedik, és ha már jelen van, a konkrét tartománya továbbra is nyer a saját neveihez, miközben a kapcsolat sokkal többre válaszol, mint amit kért. Távolítsa el vagy szűkítse ezt a gyökérbejegyzést, ha a szándék csak a cég nevei voltak.

Ha a VPN-kapcsolat egyáltalán nem sorol fel DNS-kiszolgálót, a kliens soha nem regisztrált egyet. A mögötte kiszolgáló nélküli útválasztási tartomány másképpen hiúsul meg, mint a hiányzó tartomány, ezért először a regisztrációt javítsa.

Negyedik lépés: amikor a név feloldódik, de a szolgáltatás nem

A helyes válasz csak azt bizonyítja, hogy a feloldás működött, és az alkalmazásnak még mindig útvonalra van szüksége a kapott címhez. Ennek az útvonalnak túl kell élnie az imént beállított osztott alapértelmezett útvonalat, ezért ellenőrizze, mielőtt újra a DNS-t hibáztatja. Utána ellenőrizze az elérhetőséget a szolgáltatás portján, mert a fájlmegosztás vagy a címtárszolgáltatás a feloldásnál, az útválasztásnál vagy a hitelesítésnél hiúsul meg, és minden esetben nagyon hasonló üzeneteket ad. Tartsa ezt a három réteget külön, amikor az eredményt jelenti, különben a következő ember újra ellenőrzi a DNS-t, amely már helyes volt.

A Samba-változás, amely e kérdés mellett kering, a hozzáférési réteget érinti, nem a DNS-választást. Egy névfeloldási hibára alkalmazni az a mód, ahogy egy kis probléma másodikat kap.

Ötödik lépés: ne cserélje le a feloldót egy hiányzó tartomány javításához

Az a tanács, amely felülírja a feloldó fájlját vagy másik feloldókezelőt telepít, más problémát old meg. Ezek rendszerintegrációs változások saját hibamódokkal, és egyik sem ad hozzá olyan útválasztási tartományt, amely soha nem volt beállítva. Állapítsa meg, melyik összetevő birtokolja a névfeloldást a gépen, mielőtt lecseréli, mert a NetworkManager asztali környezetben a systemd-resolveddel ez a tulajdonjog már meg van határozva. Ez ellen harcolni az a mód, ahogy egy működő beállítás olyasmivé válik, amit senki nem tud megismételni.

A munka sorrendje: erősítse meg, hogy a tunel biztosít feloldót, adja hozzá a csak-útválasztási tartományt, csatlakozzon újra a profil vezérlőin keresztül, ellenőrizze a válaszoló kapcsolatot, majd tesztelje a szolgáltatást a portján. Ez a sorrend olyan eredményt hagy, amelyet második beszélgetés nélkül átadhat a következő embernek.