Koja veza odgovara: ruting domene za DNS split-tunnel VPN-a
Zadana ruta i DNS ruting domena su različite postavke. Dodajte sufiks kompanije s tildom, pa pitajte resolvectl koja je veza stvarno odgovorila.
Zadržite obično pregledanje na lokalnoj vezi dok se imena kompanije razrješavaju preko DNS servera koji tunel pruža. Isključivanje zadane rute VPN-a daje vam prvu polovinu, a drugu ostavlja neizgrađenom. Slijedi postavka koja nedostaje, interpunkcija koja mijenja njeno značenje i jedina komanda koja pokazuje koja je veza stvarno odgovorila. NetworkManager i systemd-resolved se podrazumijevaju kroz cijeli tekst, jer taj par je mjesto gdje zabuna obično počinje.
Prvi korak: odvojite rutu od razrješivača
ipv4.never-default odgovara na pitanje usmjeravanja i sprječava NetworkManager da ovu vezu instalira kao put za sav IPv4 saobraćaj. DNS ruting domena odgovara na drugo pitanje: koji imenski serveri 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 kompanije i da njen razrješivač odgovara na imena kompanije, a sve ostalo ostaje na miru.
Postavite samo svojstvo rute i interna imena padaju, obično s istekom vremena koji izgleda kao pokvaren tunel. Postavite samo domenu i tiho ste dodali sufiks za pretragu svakom kratkom imenu na mašini. Obje greške šalju tiket na VPN server, 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 kompanije je internal.example, a razrješivač tunela je već dostupan. Prvo pročitajte trenutne vrijednosti, jer komande 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 yesZamijenite svojim imenom veze i sufiksom, jer su gornje vrijednosti ilustrativne. Znak plus je važniji nego što izgleda: s njim se vrijednost dodaje postojećoj listi, 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 pasus ispod opisuje šta 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 servere ove veze i sufiks se ne dodaje kratkim imenima. Uklonite tildu i isti string 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 servere i domene svake veze, pa pokrenite resolvectl query host.internal.example za stvarno interno ime koje smijete pitati. Druga komanda je jedini direktan dokaz da ruting domena radi svoj posao, jer imenuje vezu koja je odgovorila. Sam popis statusa dokazuje konfiguraciju; upit dokazuje razrješavanje.
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 liste domena prije nego dirnete DNS server 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 kompanije.
Ako VPN veza uopće ne navodi DNS server, klijent ga nikad nije registrirao. Ruting domena bez servera iza sebe pada drugačije od nedostajuće domene, pa prvo popravite registraciju.
Četvrti korak: kada se ime razrješava, ali usluga ne radi
Ispravan odgovor dokazuje samo da je razrješavanje 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 ponovo okrivite DNS. Zatim provjerite dostupnost na portu usluge, jer dijeljenje datoteka ili imenička usluga pada na razrješavanju, 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 ponovo provjerava DNS koji je već bio ispravan.
Samba izmjena koja kruži uz ovo pitanje tiče se sloja pristupa, ne DNS izbora. Primijeniti je na kvar razrješavanja imena jeste kako mali problem dobije drugi.
Peti korak: ne zamjenjujte razrješivač da popravite nedostajuću domenu
Savjet koji prepisuje datoteku razrješivača ili instalira drugi upravitelj razrješ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 razrješavanje imena na mašini prije nego ga zamijenite, jer na radnoj površini s NetworkManagerom i systemd-resolvedom to vlasništvo je već definirano. Borba s tim je kako radna postavka postaje nešto što niko ne može reproducirati.
Redoslijed rada: potvrdite da tunel pruža razrješivač, dodajte domenu samo za usmjeravanje, ponovo se povežite preko kontrola profila, provjerite vezu koja odgovara, pa testirajte uslugu na njenom portu. Taj slijed ostavlja rezultat koji možete predati sljedećoj osobi bez drugog intervjua.