Koja veza odgovara: ruting domene za DNS split-tunnel VPN-a

Zadržite uobičajeno pregledavanje na lokalnoj vezi dok se imena tvrtke razlučuju preko DNS poslužitelja koji tunel osigurava. Isključivanje zadane rute VPN-a daje vam prvu polovicu, a drugu ostavlja neizgrađenom. Slijedi postavka koja nedostaje, interpunkcija koja mijenja njezino značenje i jedina naredba koja pokazuje koja je veza stvarno odgovorila. NetworkManager i systemd-resolved podrazumijevaju se kroz cijeli tekst jer je taj par mjesto gdje zbrka obično počinje.

Prvi korak: odvojite rutu od razlučivača

ipv4.never-default odgovara na pitanje usmjeravanja i sprječava NetworkManager da ovu vezu instalira kao put za sav IPv4 promet. DNS ruting domena odgovara na drugo pitanje: koja imenska poslužitelja koje veze primaju upit za odgovarajući sufiks. Nijedno ne podrazumijeva drugo, a profil može godinama nositi jedno dok mu drugo nedostaje. Samo ruta znači da tunel nosi podmreže tvrtke i da njezin razlučivač odgovara na imena tvrtke, dok sve ostalo ostaje na miru.

Postavite samo svojstvo rute i interna imena padaju, obično s istekom vremena koji zvuči kao pokvaren tunel. Postavite samo domenu i tiho ste dodali sufiks za pretragu svakom kratkom imenu na stroju. Obje pogreške šalju zahtjev na VPN poslužitelj, koji rijetko je dio koji je pogrešan.

Drugi korak: dodajte domenu samo za usmjeravanje u profil

Pretpostavite da se veza zove corp-vpn, sufiks tvrtke je internal.example, a razlučivač tunela već je dostupan. Prvo pročitajte trenutne vrijednosti jer naredbe ispod mijenjaju svojstva koja već mogu imati unose.

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

Zamijenite svojim imenom veze i sufiksom jer su gornje vrijednosti ilustrativne. Znak plus važniji je nego što izgleda: s njim se vrijednost dodaje postojećem popisu, a bez njega svojstvo se zamjenjuje i nepovezane domene nestaju iz profila koji je jučer radio. Tilda mijenja ponašanje, a ne stil, i odlomak ispod opisuje što ona bira. Zadržite čitanje prije pisanja da vas oblik zamjene nikad ne iznenadi.

Vodeća tilda označava domenu samo za usmjeravanje pa odgovarajući upiti idu na poslužitelje ove veze i sufiks se ne dodaje kratkim imenima. Uklonite tildu i isti niz postaje i sufiks za pretragu, što je drugačiji ishod koji ljudi rijetko žele. Obje postavke iznad su IPv4 pa dual-stack profil treba ipv6.never-default i istu ruting domenu u ipv6.dns-search, inače IPv6 strana nastavlja koristiti zadanu rutu i interna imena tamo padaju.

Treći korak: pitajte resolvectl koja je veza odgovorila

Pokrenite resolvectl status i pročitajte DNS poslužitelje i domene svake veze, zatim pokrenite resolvectl query host.internal.example za stvarno interno ime koje smijete upitati. Druga naredba jedini je izravan dokaz da ruting domena radi svoj posao jer imenuje vezu koja je odgovorila. Sam popis statusa dokazuje konfiguraciju; upit dokazuje razlučivanje.

systemd-resolved bira najbolje odgovarajuću ruting domenu pa specifičnija domena na drugoj vezi ipak može pobijediti u utrci. Ako upit dođe s veze koju niste očekivali, pročitajte popise domena prije nego dirnete DNS poslužitelj VPN-a. Korijenska domena ~. odgovara svemu, a ako već postoji, vaša specifična domena ipak pobjeđuje za svoja imena dok veza odgovara na mnogo više nego što ste tražili. Uklonite ili suzite taj korijenski unos kada je namjera bila samo imena tvrtke.

Ako VPN veza uopće ne navodi DNS poslužitelj, klijent ga nikad nije registrirao. Ruting domena bez poslužitelja iza sebe pada drugačije od nedostajuće domene pa prvo popravite registraciju.

Četvrti korak: kada se ime razluči, ali usluga ne radi

Ispravan odgovor dokazuje samo da je razlučivanje uspjelo, a aplikaciji i dalje treba ruta do adrese koju je dobila. Ta ruta mora preživjeti podijeljenu zadanu rutu koju ste upravo postavili pa je provjerite prije nego ponovno okrivite DNS. Zatim provjerite dostupnost na portu usluge jer dijeljenje datoteka ili imenička usluga pada na razlučivanju, usmjeravanju ili autentifikaciji i u svakom slučaju daje vrlo slične poruke. Držite ta tri sloja odvojeno kada izvještavate rezultat, inače sljedeća osoba ponovno provjerava DNS koji je već bio ispravan.

Samba promjena koja kruži uz ovo pitanje tiče se sloja pristupa, ne DNS izbora. Primijeniti je na kvar razlučivanja imena jest kako mali problem dobije drugi.

Peti korak: ne zamjenjujte razlučivač da popravite nedostajuću domenu

Savjet koji prepisuje datoteku razlučivača ili instalira drugi upravitelj razlučivača rješava drugi problem. To su promjene sistemske integracije s vlastitim načinima kvara i nijedna od njih ne dodaje ruting domenu koja nikad nije konfigurirana. Utvrdite koji komponent posjeduje razlučivanje imena na stroju prije nego ga zamijenite jer je na radnoj površini s NetworkManagerom i systemd-resolvedom to vlasništvo već definirano. Borba s tim je kako radna postavka postaje nešto što nitko ne može reproducirati.

Redoslijed rada: potvrdite da tunel pruža razlučivač, dodajte domenu samo za usmjeravanje, ponovno se povežite preko kontrola profila, provjerite vezu koja odgovara pa testirajte uslugu na njezinu portu. Taj slijed ostavlja rezultat koji možete predati sljedećoj osobi bez drugog razgovora.