Nabibigo ang hostname ng LAN sa VPN: suffix, mDNS o zone?

Sa tabi ng aparato, sumasagot ang printer sa maikling pangalan at ang file server sa palayaw. Sa pamamagitan ng tunnel, parehong nag-expire ang mga pangalan habang gumagana pa rin ang kanilang mga address. Ginagawa ng ruta ang trabaho nito; ang daan ng pagpapangalan na nagpagana sa maiikling pangalang iyon ay hindi kailanman tumawid sa tunnel. Tatlong mekanismo ang gumagawa ng ganoong ugali, at bawat isa ay nangangailangan ng ibang pagwawasto.

Magsimula sa pagtukoy kung aling mekanismo nakadepende ang pangalan.

Tatlong uri ng pangalan na kumikilos nang iba

Ang isang pangalang may isang label tulad ng fileserver ay karaniwang umaasa sa suffix ng paghahanap na DNS na idinadagdag ng resolver. Madalas na kasama ng lokal na DHCP lease ang suffix na iyon, kaya ang malayong client na kumukuha ng addressing mula sa VPN ay walang dahilan para malaman ito. Ang pagdaragdag ng ruta ay hindi naghahatid ng suffix. Ang maikling pangalan ay tumitigil na lamang na umiral bilang pangalan, kahit na ang address sa likod nito ay maabot.

Ang pangalang nagtatapos sa .local ay karaniwang nire-resolve ng multicast DNS sa lokal na link, gaya ng inilalarawan ng RFC 6762. Ang multicast ay hindi tumatawid sa rutadong tunnel maliban kung may sadyang nag-bridge o nag-proxy nito, kaya tumitigil ang pag-resolve ng pangalan sa sandaling umalis ka sa segment.

Ang ganap na kwalipikadong pangalan ng kumpanya ay kabilang sa panloob na zone na pinaglilingkuran ng mga resolver ng organisasyon. Gumagana iyon nang malayuan kapag itinutulak ng VPN ang mga resolver na iyon at ang client ay naka-configure na gamitin ang mga ito. At ang localhost ay espesyal na paggamit ayon sa RFC 6761: tumutukoy ito sa makina sa harap mo, hindi kailanman sa malayong serbisyo.

Basahin ang resolver bago baguhin ang ruta

Itanong kung aling name server ang sumagot at anong suffix ang idinagdag. Ang parehong query sa iba't ibang resolver ay nagbibigay ng iba't ibang sagot, at ang pagkakaibang iyon ang ebidensyang kailangan mo.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

Kung na-resolve ang ganap na kwalipikadong query ngunit hindi ang maikli, ang sira ay nasa suffix, hindi sa server. Kung wala sa dalawa ang na-resolve at gumagana ang address, hindi talaga ginagamit ng client ang panloob na resolver. Ihambing ang listahan ng resolver sa dapat itulak ng VPN, dahil ang client na nagpapanatili ng lokal na resolver para sa bawat query ay hindi kailanman makikita ang panloob na zone.

Dalhin ang tamang pangalan sa client

Hilingin sa administrator ang dokumentadong pangalan ng malayuang pag-access, nang buo, at gamitin ito sa profile sa halip na hulaan ang mga suffix. Kung sinusuportahan ng deployment ang split DNS, i-configure ang panloob na domain na ma-resolve ng mga panloob na server habang ang lahat ng iba ay nagpapanatili ng lokal na resolver. Itulak ang domain ng paghahanap sa pamamagitan ng configuration ng VPN kung saan sinusuportahan ito ng client.

I-verify ang resulta sa client sa halip na sa gateway. Ang setting na inilapat sa server at hindi kailanman umabot sa client ay walang binabago.

Panatilihing buo ang pagkakakilanlan ng sertipiko

Ang pagsubok na nakabatay sa address na hindi pinapansin ang error ng sertipiko ay nagpapatunay lamang na bumukas ang socket. Ang sertipiko ng serbisyo ay inilalabas para sa isang pangalan, at patuloy na tatanggihan ng client ang pagkakaiba nang may mabuting dahilan. Kung ang sertipiko ay naglilista lamang ng panloob na pangalan, gamitin ang pangalang iyon at ayusin ang pag-resolve, o kumuha ng sertipikong sumasaklaw sa address na balak mong gamitin.

Itala ang pangalan, resolver, at suffix na nagbigay ng matagumpay na koneksyon. Ang talaang iyon ay nagliligtas sa susunod na tao mula sa pag-uulit ng workaround na nakabatay sa address na nagtatago ng tunay na problema.