Nabibigo ang mga hostname ng VPN, gumagana ang mga IP address: saan titingin

Mabubuksan mo ang share sa pamamagitan ng address at ang parehong share sa pamamagitan ng pangalan ay nabibigo, na nangangahulugang dinadala ng tunnel ang mga packet at hindi ang antas ng mga pangalan. Ang nag-iisang obserbasyong iyon ay nakakatipid ng ligoy sa mga pagbabago sa firewall at ruta. Kailangan ng mga pangalan ang isang suffix, isang resolver at isang landas para sa query, at ang isang VPN client ay makakapag-install ng ruta nang hindi nag-i-install ng alinman sa mga iyon. Dumaan sa apat na pagsusuri sa ibaba nang sunod-sunod at huminto sa unang masisira.

Nagtanong ang pangalan ng hindi itinatanong ng address

Ang address ay isang destinasyon na magagamit agad ng stack. Ang maikling pangalan ay isang tanong na kailangang palawakin ng suffix, ipadala sa isang resolver at sagutin ng isang bagay na nakakaalam ng zone. Ang isang tunnel na nag-i-install ng ruta ngunit walang resolver ay nag-iiwan sa una na gumagana at sa pangalawa na sira. Iyon ang dahilan kung bakit ang sintomas ay mukhang napakakonsistente sa mga produktong VPN na napakakaiba.

Magtrabaho palabas mula sa address: una ang buong pangalan, pagkatapos ang hubad na hostname, at itala kung alin sa tatlo ang gumagana. Sinasabi ng pattern kung aling antas ang susuriin bago ka magbukas ng kahit isang screen ng configuration. Ang manghula ng ruta kapag nagre-resolve ang FQDN ay nasayang na pagsisikap.

Basahin ang resolver na aktwal na in-install ng tunnel

Tanungin ang operating system kung aling resolver ang humahawak ng mga query para sa panloob na zone, hindi kung alin ang inaanunsyo ng interface ng VPN client. Ang isang server na nagtutulak ng pampublikong resolver na walang panloob na zone ay gumagawa ng eksaktong kabiguang ito, at ito ay error sa configuration at hindi sira sa routing.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Sa isang Windows client na kabilang sa domain, ang patakaran sa routing ng namespace ang nagpapasya kung aling mga query ang pupunta sa aling resolver, at ang sariling DNS settings ng VPN adapter ay lumilitaw sa mga detalye ng adapter. Basahin ang epektibong patakaran at hindi ang profile, dahil ang naka-cache na patakaran ay maaaring mabuhay nang mas matagal kaysa sa koneksyong nag-install nito. Kung ang resolver ay sumasagot sa buong pangalan at hindi sa maikling pangalan, ang problema ay lumipat na sa listahan ng suffix.

Get-DnsClientNrptPolicy
ipconfig /all

Huminto kung ang panloob na zone ay nare-resolve sa pamamagitan ng tamang server. Ang resolver ay hindi ang iyong problema.

Ipinapaliwanag ng mga suffix ang mga maikling pangalan na nabibigo

Ang pangalang may iisang label ay pinalalawak ng listahan ng suffix ng koneksyon bago ipadala ang query. Kung hindi inihahatid ng VPN ang panloob na suffix, ang fileserver ay hindi kailanman nagiging fileserver.corp.example, at ang query ay lumalabas bilang isang pangalan na wala sa mga pampublikong resolver ang nakakaalam. Ang pagtulak ng suffix, o pag-type ng buong pangalan, ay sumusubok sa hypothesis nang walang binabago sa server.

nslookup fileserver.corp.example
ping -a 192.168.50.20

Sa Linux, ang serbisyo ng resolver ay nag-uugnay ng isang DNS server sa isang link at sa isang hanay ng mga routing domain, kaya ang itinulak na server na hindi nauugnay sa link ng tunnel ay kumikilos na parang wala ito. Suriin ang katayuan bawat link at hindi ang stub file, na maaaring tumuturo lamang sa lokal na resolver. Ang parehong paghahati ay lumilitaw sa kabilang direksyon: ang isang search domain na naroroon ngunit hindi inilalapat sa interface ng tunnel ay gumagawa ng mga kabiguan sa maikling pangalan na mukhang random.

Kung ang pagdaragdag ng suffix ay nag-aayos nito, ang natitirang gawain ay ihatid ang suffix na iyon sa pamamagitan ng profile ng VPN sa halip na hilingin sa bawat user na i-type ito.

Ang NetBIOS at WINS ay ibang mekanismo

Ang lumang SMB ay makakahanap pa rin ng hubad na pangalan sa serbisyo ng pangalan ng NetBIOS, na sumasagot sa broadcast o sa pamamagitan ng isang WINS server. Ang broadcast ay nananatili sa loob ng isang broadcast domain at humihinto sa unang router, kaya hindi ito makakatawid sa isang tunnel; gumagana ang WINS dahil ang client ay may unicast address na rerehistruhan at tatanungin. Iyon ang dahilan kung bakit ang isang VPN na nagdadala lamang ng IP ay makakasuporta pa rin ng mga lumang pangalan kapag ang WINS ay naka-configure at maaabot.

nbtstat -n
nbtstat -R

Para sa modernong SMB, umasa sa DNS at sa buong pangalan, at iretiro ang lumang landas. Kung talagang luma ito, magbigay ng WINS o palitan ang application; ang gitnang daan ay isang pila ng suporta na hindi kailanman nauubos.

Nagtatapos ang paglalakbay kapag masasabi mo kung aling antas ang nabigo: resolver, suffix o lumang pagtuklas. Itala ang resolver na sumagot at ang anyo ng pangalan na gumana, dahil ang susunod na tao ay magsisimula sa parehong sintomas.