Kuri sąsaja atsako: maršrutizavimo domenai split-tunnel VPN DNS

Įprastą naršymą palikite vietinėje sąsajoje, o įmonės vardai tebūna sprendžiami per DNS serverį, kurį pateikia tunelis. Išjungus numatytąjį VPN maršrutą gaunate pirmąją pusę, o antroji lieka nesukurta. Toliau pateikiamas trūkstamas nustatymas, skyrybos ženklas, keičiantis jo reikšmę, ir vienintelė komanda, parodanti, kuri sąsaja iš tikrųjų atsakė. Visame tekste daroma prielaida, kad naudojami NetworkManager ir systemd-resolved, nes būtent ši pora dažniausiai tampa sumaišties pradžia.

Pirmas žingsnis: atskirkite maršrutą nuo sprendiklio

ipv4.never-default atsako į maršrutizavimo klausimą ir neleidžia NetworkManager įdiegti šio ryšio kaip viso IPv4 srauto kelio. DNS maršrutizavimo domenas atsako į kitą klausimą: kurios sąsajos vardų serveriai gauna užklausą dėl atitinkančios priesagos. Nė vienas neimplikuoja kito, o profilis gali metų metus turėti vieną, kai trūksta kito. Tik maršrutas reiškia, kad tunelis neša įmonės potinklius ir jo sprendiklis atsako į įmonės vardus, o visa kita paliekama ramybėje.

Nustatykite tik maršruto savybę ir vidiniai vardai nepavyksta, dažniausiai su laiko limitu, kuris skamba kaip sulaužytas tunelis. Nustatykite tik domeną ir tyliai pridėjote paieškos priesagą prie kiekvieno trumpo vardo mašinoje. Abi klaidos siunčia bilietą į VPN serverį, kuris retai būna neteisinga dalis.

Antras žingsnis: pridėkite tik-maršrutizavimo domeną prie profilio

Tarkime, ryšys vadinasi corp-vpn, įmonės priesaga yra internal.example, o tunelio sprendiklis jau pasiekiamas. Pirmiausia perskaitykite dabartines reikšmes, nes žemiau esančios komandos keičia savybes, kurios jau gali turėti įrašų.

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

Pakeiskite savo ryšio vardu ir priesaga, nes aukščiau pateiktos reikšmės iliustracinės. Pliuso ženklas svarbesnis, nei atrodo: su juo reikšmė pridedama prie esamo sąrašo, o be jo savybė pakeičiama ir nesusiję domenai dingsta iš profilio, kuris vakar veikė. Tildė keičia elgesį, o ne stilių, ir žemiau esanti pastraipa paaiškina, ką ji pasirenka. Laikykitės skaitymo prieš rašymą, kad pakeitimo forma niekada nenustebintų.

Pradinė tildė žymi tik-maršrutizavimo domeną, todėl atitinkančios užklausos eina į šios sąsajos serverius, o priesaga nepridedama prie trumpų vardų. Pašalinkite tildę ir ta pati eilutė taip pat tampa paieškos priesaga, o tai kitas rezultatas, kurio žmonės retai nori. Abu aukščiau esantys nustatymai yra IPv4, todėl dvigubo kamino profiliui reikia ipv6.never-default ir to paties maršrutizavimo domeno ipv6.dns-search, kitaip IPv6 pusė toliau naudoja numatytąjį maršrutą, ir vidiniai vardai ten nepavyksta.

Trečias žingsnis: paklauskite resolvectl, kuri sąsaja atsakė

Paleiskite resolvectl status ir perskaitykite kiekvienos sąsajos DNS serverius ir domenus, tada paleiskite resolvectl query host.internal.example su tikru vidiniu vardu, kurį jums leidžiama užklausti. Antroji komanda yra vienintelis tiesioginis įrodymas, kad maršrutizavimo domenas atlieka savo darbą, nes ji įvardija sąsają, kuri atsakė. Vien statuso sąrašas įrodo konfigūraciją; užklausa įrodo sprendimą.

systemd-resolved pasirenka geriausiai atitinkantį maršrutizavimo domeną, todėl konkretesnis domenas kitoje sąsajoje vis tiek gali laimėti lenktynes. Jei užklausa grįžta iš sąsajos, kurios nesitikėjote, perskaitykite domenų sąrašus prieš liesdami VPN DNS serverį. Šakninis domenas ~. atitinka viską, o jei jis jau yra, jūsų konkretus domenas vis tiek laimi savo vardams, kol sąsaja atsako daug daugiau, nei prašėte. Pašalinkite arba susiaurinkite tą šakninį įrašą, kai tikslas buvo tik įmonės vardai.

Jei VPN sąsaja visiškai nenurodo DNS serverio, klientas jo niekada neužregistravo. Maršrutizavimo domenas be serverio už jo nepavyksta kitaip nei trūkstamas domenas, todėl pirmiausia sutvarkykite registraciją.

Ketvirtas žingsnis: kai vardas išsprendžiamas, o paslauga ne

Teisingas atsakymas įrodo tik tai, kad sprendimas veikė, o programai vis dar reikia maršruto į gautą adresą. Tas maršrutas turi išgyventi ką tik sukonfigūruotą padalytą numatytąjį maršrutą, todėl patikrinkite jį prieš vėl kaltindami DNS. Tada patikrinkite pasiekiamumą paslaugos prievade, nes failų bendrinimas ar katalogų paslauga nepavyksta sprendžiant, maršrutizuojant ar autentifikuojant ir kiekvienu atveju pateikia labai panašius pranešimus. Laikykite šiuos tris sluoksnius atskirai, kai pranešate rezultatą, kitaip kitas žmogus iš naujo tikrina DNS, kuris jau buvo teisingas.

Samba pakeitimas, kuris sukasi šalia šio klausimo, liečia prieigos sluoksnį, o ne DNS pasirinkimą. Jo taikymas vardų sprendimo gedimui yra būdas, kuriuo maža problema įgyja antrą.

Penktas žingsnis: nekeiskite sprendiklio, kad pataisytumėte trūkstamą domeną

Patarimas, kuris perrašo sprendiklio failą arba įdiegia kitą sprendiklio tvarkyklę, sprendžia kitą problemą. Tai sistemos integracijos pakeitimai su savais gedimų režimais, ir nė vienas jų neprideda maršrutizavimo domeno, kuris niekada nebuvo sukonfigūruotas. Nustatykite, kuris komponentas valdo vardų sprendimą mašinoje, prieš jį keisdami, nes NetworkManager darbalaukyje su systemd-resolved ta nuosavybė jau apibrėžta. Kova su ja yra būdas, kuriuo veikianti sąranka tampa kažkuo, ko niekas negali atkartoti.

Darbo tvarka: patvirtinkite, kad tunelis teikia sprendiklį, pridėkite tik-maršrutizavimo domeną, prisijunkite iš naujo per profilio valdiklius, patikrinkite atsakančią sąsają, tada išbandykite paslaugą jos prievade. Ši seka palieka rezultatą, kurį galite perduoti kitam žmogui be antro pokalbio.