Nabigo ang mga panloob na pangalan sa VPN habang maayos na lumulutas ang mga pampublikong site

Isang user ang nag-uulat na hindi lumulutas ang hostname ng intranet sa VPN. Ang ikalawang ulat, mula sa parehong laptop, ay nagsasabing ang pagsubok sa pagtagas ay nagpapakita pa rin ng mga query na sinasagot ng lokal na resolver. Mukha silang isang problema ngunit dalawa, may magkaibang ebidensya, at ang karaniwang ayos para sa una ay nagpapalala sa pangalawa. Paghiwalayin sila bago hawakan ang anumang setting.

Dalawang sintomas na hindi isang sira

Ang hindi paglutas ng panloob na pangalan ay nangangahulugang napunta ang tanong sa lugar na walang sagot para dito. Ang paglabas ng mga query sa tunnel ay nangangahulugang napunta ang tanong sa maling lugar kahit may sagot. Kabaligtaran ang mga ito: isa ay nawawalang sagot, ang isa ay sobrang destinasyon.

Ang bitag ay ang pagdaragdag ng resolver ng opisina sa lahat ng lugar ay nag-aayos sa una at ginagarantiyahan ang pangalawa. Ang pagdaragdag ng pampublikong resolver sa lahat ng lugar ay kabaligtaran ang ginagawa.

Isulat ang dalawang obserbasyon na may tatak ng oras, pagkatapos ay dumaan sa apat na pagsusuri sa ibaba nang sunod-sunod.

Aling resolver ng adapter ang nakakakuha ng tanong

Sa Windows, pinipili ng DNS client ang mga server ayon sa pagkakasunod-sunod ng pagkakabigkis ng adapter, at ang tunnel adapter ay hindi awtomatikong nauuna. Buksan ang detalyadong setting ng adapter at ilipat ang koneksyon sa malayuang pag-access sa itaas ng pisikal na adapter, pagkatapos ay kumonekta muli upang gumana ang pagbabago sa bagong sesyon.

Ang pagkakasunod-sunod ng pagkakabigkis ay unang kalahati lamang. Kailangan ding malaman ng client kung aling mga pangalan ang kabilang sa adapter na iyon, at tanong iyon ng suffix hindi ng pagkakasunod-sunod.

Ilagay ang ipconfig /all ng gumaganang makina sa tabi ng sa laptop, parehong kinuha habang nakaupo ang tunnel. Ipapakita ng gumaganang makina ang DNS suffix na partikular sa koneksyon sa adapter ng opisina nito, at maaaring wala itong ipakita sa tunnel ng laptop. Ipinapaliwanag ng pagkakaibang iyon ang buong klase ng mga ulat na "naroon mismo ang server at nabigo pa rin ang pangalan", dahil kung walang suffix ang maikling pangalan ay hindi kailanman nabubuo sa zone na pinaglilingkuran ng resolver ng opisina.

Kailangan ng maikling pangalan ang suffix bago ang ruta

Ang pag-type ng hindi kwalipikadong hostname ay hinihiling sa resolver na hulaan ang isang domain. Ang hula ay nagmumula sa listahan ng suffix na nakakabit sa koneksyon, at kung walang laman ang listahang iyon, lalabas ang query bilang isang label na walang pribadong zone na tutugma.

Kopyahin ang suffix ng gumaganang makina sa IPv4 properties ng VPN adapter sa DNS tab, pagkatapos ay kumonekta muli. Sa Linux ang katumbas ay ang search domain sa tunnel link, na inilalantad ng systemd-resolved bawat link sa halip na pangkalahatan.

Panatilihing hiwalay ang dalawang setting sa iyong mga tala. Binabago ng suffix kung ano ang tinatanong; binabago ng address ng resolver kung sino ang tinatanong. Ang pag-aayos ng isa habang mali ang isa ay nagbubunga ng resulta na parang random.

Tanungin nang direkta ang resolver, pagkatapos ang pangalan

Isang direktang query sa resolver ng opisina ang naghihiwalay ng problema sa pangalan mula sa problema sa ruta, dahil nilalampasan nito nang buo ang pagpili ng resolver ng client.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Hinihiling ng unang command sa isang partikular na server ang isang ganap na kwalipikadong pangalan. Kung sumagot ito, maayos ang resolver at ang ruta patungo rito at nasa pagpili o suffix ang sira. Kung nag-timeout, mali o hindi maabot ang address at ang problema ay routing hindi DNS. Ipinapakita ng ikalawang command ang nangyayari sa maikling pangalan, at ang ikatlo ay naglilimbag ng resolver configuration bawat link sa isang systemd host.

Mag-ingat sa mga wildcard na sagot, na ibinabalik ng ilang network para sa mga hindi kilalang pangalan. Ang sagot na mukhang makatwiran ay hindi patunay na ang sinadyang server ang sumagot, kaya ihambing ang ibinalik na address sa aktwal na ginagamit ng panloob na serbisyo. Kung ang address ay sa isang pahinang paradahan o proxy, sumagot ang resolver ngunit hindi kailanman sa iyo ang sagot. Ang pagkakaibang iyon ay nagtitipid ng isang oras sa paghabol sa tunnel na gumagana pala sa buong panahon.

Sa Linux, isang VPN client na nagsusulat muli ng /etc/resolv.conf ang pumapalit sa mga lokal na resolver nang buo. Inilalantad ng vpnc ang DNSUpdate no upang pigilan iyon, at ang systemd-resolved ay maaaring mag-ruta lamang ng mga nakalistang domain patungo sa tunnel link. Pinapanatili ng dalawang paraan ang mga pampublikong pangalan sa lokal na resolver habang ipinapadala ang panloob na pangalan sa opisina.

Ang leak ay patakaran, hindi kahon ng tsek

Ang paglutas ng pangalan ay isang pagpapalitan ng UDP sa port 53, kaya ang tunnel na nagdadala ng trapikong pang-web ngunit hindi UDP ay iniiwan ang query sa pisikal na ruta. Patunayan ito sa pamamagitan ng pag-capture sa pisikal na NIC habang nilulutas ang isang pampublikong pangalan. Ang query na nakikita sa interface na iyon sa nababasang anyo ay nangangahulugang hindi ito dinadala ng tunnel.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Kung lumitaw ang query sa interface na iyon sa nababasang anyo, hindi ito dinadala ng tunnel. Ang pag-aayos ay isang patakaran na nagpapahintulot sa port 53 lamang patungo sa resolver na itinulak ng VPN at nagtatapon sa ibang destinasyon, kasama ang configuration ng client na hindi tahimik na itinatapon ang itinulak na opsyon.

Ang huling bahagi ay mas mahalaga kaysa sa tila. Simulan ang OpenVPN nang may route-nopull at mawawala ang itinulak na DNS option kasama ng mga ruta, maliban kung palawakin ang filter ng paghila upang panatilihin ito. at isang client na binabalewala ang dhcp-option DNS ay patuloy na gagamit ng dati nitong gamit. Anumang pagbabago sa panig ng server ay nangangailangan ng bagong sesyon upang magkabisa, dahil ang listahan ng resolver ay inihahatid kapag umangat ang tunnel at ang lumang sesyon ay patuloy na nagpapakita ng lumang estado.

Itala kung aling sira ang aktwal na naobserbahan bago isara ang ticket. Ang nawawalang panloob na sagot at ang query na tumakas sa tunnel ay nangangailangan ng magkaibang pag-aayos, at ang pagbabago ng suffix na nag-aayos sa una ay maaaring tahimik na magpalala sa pangalawa. Ang susunod na kukuha ng ticket ay magtitiwala sa label, kaya gawing tumpak ang label.