Emri i hostit në LAN dështon përmes VPN: sufiks, mDNS apo zonë?

Pranë pajisjes, printeri përgjigjet ndaj një emri të shkurtër dhe serveri i skedarëve ndaj një pseudonimi. Përmes tunelit, të dy emrat skadojnë ndërsa adresat e tyre vazhdojnë të funksionojnë. Rruga po e bën punën e vet; rruga e emërtimit që i bënte funksionalë ata emra të shkurtër nuk e kaloi kurrë tunelin. Tre mekanizma e prodhojnë këtë sjellje dhe secili kërkon një korrigjim tjetër.

Filloni duke përcaktuar nga cili mekanizëm varet emri.

Tre lloje emrash që sillen ndryshe

Një emër me një etiketë si fileserver zakonisht mbështetet te një sufiks kërkimi DNS që shton zgjidhësi. Ai sufiks shpesh vjen me qiranë lokale DHCP, kështu që një klient në distancë që merr adresim nga VPN nuk ka arsye ta dijë. Shtimi i një rrugë nuk e dërgon sufiks-in. Emri i shkurtër thjesht pushon së ekzistuari si emër, edhe pse adresa pas tij është e kapshme.

Një emër që mbaron me .local zakonisht zgjidhet përmes DNS multicast në lidhjen lokale, siç përshkruan RFC 6762. Multicast nuk e kalon një tunel me rrugëtim, përveç rastit kur diçka e urëzon ose e proxon qëllimisht, prandaj emri pushon së zgjidhuri në momentin që lini segmentin.

Një emër kompanie plotësisht i kualifikuar i përket një zone të brendshme që shërbehet nga zgjidhësit e organizatës. Ai funksionon në distancë kur VPN shtyn ata zgjidhës dhe klienti është konfiguruar t'i përdorë. Ndërsa localhost është përdorim i veçantë sipas RFC 6761: i referohet makinës përpara jush, kurrë një shërbimi në distancë.

Lexoni zgjidhësin para se të ndryshoni rrugën

Pyetni cili server emrash u përgjigj dhe cili sufiks u shtua. E njëjta kërkesë përmes zgjidhësve të ndryshëm jep përgjigje të ndryshme, dhe ai ndryshim është prova që ju nevojitet.

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

Nëse kërkesa plotësisht e kualifikuar zgjidhet, por ajo e shkurtra jo, defekti është te sufiks-i, jo te serveri. Nëse asnjëra nuk zgjidhet dhe adresa funksionon, klienti nuk po e përdor fare zgjidhësin e brendshëm. Krahasoni listën e zgjidhësve me atë që VPN duhet të shtyjë, sepse një klient që mban zgjidhësin e vet lokal për çdo kërkesë nuk do ta shohë kurrë zonën e brendshme.

Sillni emrin e duhur te klienti

Kërkoni nga administratori emrin e dokumentuar të aksesit në distancë, plotësisht, dhe përdoreni në profil në vend që të hamendësoni sufiks-a. Nëse vendosja mbështet split DNS, konfiguroni domenin e brendshëm që të zgjidhet nga serverët e brendshëm ndërsa çdo gjë tjetër mban zgjidhësin lokal. Shtyni domenin e kërkimit përmes konfigurimit të VPN aty ku klienti e mbështet.

Verifikoni rezultatin te klienti, jo te porta. Një konfigurim i aplikuar te serveri që nuk arrin kurrë te klienti nuk ndryshon asgjë.

Ruani identitetin e certifikatës

Një test i bazuar në adresë që injoron gabimin e certifikatës provon vetëm se socket-i u hap. Certifikata e shërbimit lëshohet për një emër, dhe klienti do të vazhdojë ta refuzojë mospërputhjen me të drejtë. Nëse certifikata liston vetëm emrin e brendshëm, përdorni atë emër dhe rregulloni zgjidhjen, ose merrni një certifikatë që mbulon adresën që synoni të përdorni.

Regjistroni emrin, zgjidhësin dhe sufiks-in që dhanë një lidhje të suksesshme. Ai regjistrim i kursen personit tjetër përsëritjen e zgjidhjes së përkohshme të bazuar në adresë që fsheh problemin e vërtetë.