Aling link ang sumasagot: mga routing domain para sa DNS ng split-tunnel VPN

Panatilihin ang ordinaryong pag-browse sa lokal na link habang nare-resolve ang mga pangalan ng kumpanya sa pamamagitan ng DNS server na ibinibigay ng tunnel. Ang pagpatay sa default route ng VPN ay nagbibigay sa iyo ng unang kalahati at iniiwan ang pangalawa na hindi pa natatayo. Sumusunod ang kulang na setting, ang bantas na nagbabago ng kahulugan nito, at ang nag-iisang command na nagpapakita kung aling link ang tunay na sumagot. Ipinapalagay ang NetworkManager at systemd-resolved sa buong teksto, dahil doon karaniwang nagsisimula ang kalituhan.

Unang hakbang: paghiwalayin ang ruta sa resolver

Ang ipv4.never-default ay sumasagot sa tanong ng routing at pumipigil sa NetworkManager na i-install ang koneksyong ito bilang daan para sa lahat ng trapikong IPv4. Ang isang DNS routing domain ay sumasagot sa ibang tanong: aling mga nameserver ng aling link ang tumatanggap ng query para sa tugmang suffix. Wala sa kanila ang nagsasama ng isa, at ang isang profile ay maaaring magdala ng isa nang maraming taon habang kulang ang isa. Ruta lamang ay nangangahulugang dinadala ng tunnel ang mga subnet ng kumpanya at sinasagot ng resolver nito ang mga pangalan ng kumpanya, habang ang lahat ng iba ay hinahayaang tahimik.

Itakda lamang ang property ng ruta at mabibigo ang mga panloob na pangalan, kadalasan may timeout na parang sirang tunnel. Itakda lamang ang domain at tahimik mong naidagdag ang search suffix sa bawat maikling pangalan sa makina. Parehong pagkakamali ay nagpapadala ng ticket sa VPN server, na bihirang ang bahaging mali.

Ikalawang hakbang: magdagdag ng routing-only domain sa profile

Ipagpalagay na ang koneksyon ay tinatawag na corp-vpn, ang suffix ng kumpanya ay internal.example, at ang resolver ng tunnel ay naaabot na. Basahin muna ang kasalukuyang mga halaga, dahil binabago ng mga command sa ibaba ang mga property na maaaring may entry na.

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

Palitan ng sarili mong pangalan ng koneksyon at suffix, dahil ang mga halaga sa itaas ay halimbawa lamang. Mas mahalaga ang plus sign kaysa sa hitsura nito: kasama nito, ang halaga ay idinaragdag sa umiiral na listahan, samantalang kung wala ito, ang property ay pinapalitan at nawawala ang mga hindi kaugnay na domain mula sa profile na gumana kahapon. Binabago ng tilde ang pag-uugali hindi ang estilo, at ipinapaliwanag ng talata sa ibaba kung ano ang pinipili nito. Panatilihin ang pagbasa bago ang pagsulat, upang hindi ka mabigla ng anyo ng pagpapalit.

Ang nangungunang tilde ay nagmamarka ng routing-only domain, kaya ang mga tugmang query ay pumupunta sa mga server ng link na ito at hindi idinadagdag ang suffix sa maiikling pangalan. Alisin ang tilde at ang parehong string ay magiging search suffix din, isang ibang resulta na bihirang sinasadya ng mga tao. Parehong setting sa itaas ay IPv4, kaya ang dual-stack na profile ay nangangailangan ng ipv6.never-default at ng parehong routing domain sa ipv6.dns-search, kung hindi ay patuloy na gagamitin ng panig IPv6 ang default route at mabibigo ang mga panloob na pangalan doon.

Ikatlong hakbang: tanungin ang resolvectl kung aling link ang sumagot

Patakbuhin ang resolvectl status at basahin ang mga DNS server at domain ng bawat link, pagkatapos patakbuhin ang resolvectl query host.internal.example laban sa isang tunay na panloob na pangalan na pinapayagan kang tanungin. Ang ikalawang command ang nag-iisang direktang ebidensya na ginagawa ng routing domain ang trabaho nito, dahil pinangalanan nito ang link na sumagot. Ang listahan ng status lamang ay nagpapatunay ng konfigurasyon; ang query ay nagpapatunay ng resolution.

Pinipili ng systemd-resolved ang pinakatugmang routing domain, kaya ang mas tiyak na domain sa ibang link ay maaari pa ring manalo sa karera. Kung bumalik ang query mula sa link na hindi mo inaasahan, basahin ang mga listahan ng domain bago hawakan ang DNS server ng VPN. Ang root domain na ~. ay tumutugma sa lahat, at kung naroon na, ang iyong tiyak na domain ay nananalo pa rin para sa sarili nitong mga pangalan habang ang link ay sumasagot ng higit pa sa hiniling mo. Alisin o paliitin ang root entry na iyon kapag ang layunin ay mga pangalan ng kumpanya lamang.

Kung ang VPN link ay hindi naglilista ng anumang DNS server, hindi kailanman nagrehistro ang client ng isa. Ang routing domain na walang server sa likod ay nabibigo nang iba kaysa sa nawawalang domain, kaya ayusin muna ang rehistro.

Ikaapat na hakbang: kapag nag-resolve ang pangalan ngunit hindi ang serbisyo

Ang tamang sagot ay nagpapatunay lamang na gumana ang resolution, at kailangan pa rin ng aplikasyon ng ruta patungo sa address na natanggap nito. Ang rutang iyon ay dapat mabuhay sa split default na kakalikha mo lang, kaya suriin ito bago sisihin muli ang DNS. Pagkatapos suriin ang abot ng serbisyo sa port nito, dahil ang file sharing o directory service ay nabibigo sa resolution, routing o authentication at nagbibigay ng halos magkatulad na mensahe sa bawat kaso. Panatilihing hiwalay ang tatlong layer na iyon kapag iniuulat ang resulta, kung hindi ay muling sinusuri ng susunod na tao ang DNS na tama na.

Ang pagbabago sa Samba na umiikot sa tabi ng tanong na ito ay tungkol sa access layer, hindi sa pagpili ng DNS. Ang paglapat nito sa pagkabigo ng resolution ng pangalan ay kung paano nakakakuha ng pangalawa ang maliit na problema.

Ikalimang hakbang: huwag palitan ang resolver para ayusin ang nawawalang domain

Ang payong nagsusulat sa ibabaw ng file ng resolver o nag-i-install ng ibang tagapamahala ng resolver ay nilulutas ang ibang problema. Mga pagbabago iyon sa integrasyon ng system na may sariling paraan ng pagkabigo, at wala sa kanila ang nagdadagdag ng routing domain na hindi kailanman na-configure. Tukuyin kung aling component ang may-ari ng resolution ng pangalan sa makina bago palitan ito, dahil sa desktop ng NetworkManager na may systemd-resolved ay natukoy na ang pagmamay-ari na iyon. Ang pakikipaglaban dito ang paraan kung paano nagiging isang bagay na hindi maaaring muling gawin ng sinuman ang gumaganang setup.

Pagkakasunod-sunod ng trabaho: tiyakin na nagbibigay ng resolver ang tunnel, idagdag ang routing-only domain, muling kumonekta sa pamamagitan ng mga kontrol ng profile, i-verify ang link na sumasagot, pagkatapos subukan ang serbisyo sa port nito. Ang pagkakasunod-sunod na iyon ay nag-iiwan ng resultang maaari mong ipasa sa susunod na tao nang walang ikalawang panayam.