Imena gostiteljev VPN ne uspejo, naslovi IP delujejo: kam pogledati

Deljeno mapo lahko odprete z naslovom, ista mapa z imenom pa ne uspe, kar pomeni, da tunel prenaša pakete, plast imen pa ne. To eno opažanje prihrani obvoz skozi spremembe požarnega zidu in poti. Imena potrebujejo pripono, razreševalnik in pot za poizvedbo, odjemalec VPN pa lahko namesti pot, ne da bi namestil karkoli od tega. Pojdite skozi štiri preverjanja spodaj po vrsti in ustavite se pri prvem, ki se zlomi.

Ime postavi vprašanje, ki ga naslov ne postavi

Naslov je cilj, ki ga sklad lahko uporabi takoj. Kratko ime je vprašanje, ki ga je treba razširiti s pripono, poslati razreševalniku in nanj mora odgovoriti nekaj, kar pozna cono. Tunel, ki namesti poti, ne pa razreševalnika, pusti prvo delujoče in drugo pokvarjeno. Zato je simptom videti tako dosleden pri zelo različnih izdelkih VPN.

Delajte od naslova navzven: najprej polno ime, nato golo ime gostitelja, in zabeležite, katero od treh deluje. Vzorec vam pove, katero plast pregledati, preden odprete en sam zaslon nastavitev. Ugibanje poti, ko se FQDN razreši, je izgubljeno delo.

Preberite razreševalnik, ki ga je tunel res namestil

Vprašajte operacijski sistem kateri razreševalnik obravnava poizvedbe za notranjo cono, ne katerega oglašuje vmesnik odjemalca VPN. Strežnik, ki vsili javni razreševalnik brez notranje cone, povzroči natanko to napako, in to je napaka v konfiguraciji, ne okvara usmerjanja.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Na odjemalcu Windows, pridruženem domeni, pravilo usmerjanja imenskega prostora odloča, katere poizvedbe gredo h kateremu razreševalniku, lastne nastavitve DNS adapterja VPN pa se pojavijo v podrobnostih adapterja. Berite veljavno pravilo, ne profil, ker lahko predpomnjeno pravilo preživi povezavo, ki ga je namestilo. Če razreševalnik odgovori na polno ime in ne na kratko, se je težava že preselila na seznam pripon.

Get-DnsClientNrptPolicy
ipconfig /all

Ustavite se, če se notranja cona razreši prek pravega strežnika. Razreševalnik ni vaša težava.

Pripone pojasnjujejo kratka imena, ki ne uspejo

Ime z eno oznako se pred pošiljanjem poizvedbe razširi s seznamom pripon povezave. Če VPN ne dostavi notranje pripone, fileserver nikoli ne postane fileserver.corp.example, poizvedba pa gre ven kot ime, ki ga ne pozna noben javni razreševalnik. Vsiljenje pripone ali vnos polnega imena preizkusi hipotezo, ne da bi karkoli spremenilo na strežniku.

nslookup fileserver.corp.example
ping -a 192.168.50.20

V Linuxu storitev razreševalnika veže strežnik DNS na povezavo in na množico usmerjevalnih domen, zato se vsiljeni strežnik, ki ni povezan s povezavo tunela, obnaša, kot da ga ni. Preverite stanje po povezavi, ne datoteke stub, ki lahko kaže samo na krajevni razreševalnik. Ista delitev se pojavi tudi v drugi smeri: iskalna domena, ki obstaja, a ni uporabljena na vmesniku tunela, povzroča napake kratkih imen, ki so videti naključne.

Če dodajanje pripone to popravi, je preostalo delo dostaviti to pripono prek profila VPN, namesto da bi od vsakega uporabnika zahtevali, da jo vnese.

NetBIOS in WINS sta drug mehanizem

Starejši SMB še vedno lahko poišče golo ime s storitvijo imen NetBIOS, ki odgovarja z oddajanjem ali prek strežnika WINS. Oddajanje ostane v eni oddajni domeni in se ustavi na prvem usmerjevalniku, zato ne more prečkati tunela; WINS deluje, ker ima odjemalec enonaslovni naslov, na katerem se registrira in ki ga sprašuje. Zato lahko VPN, ki prenaša samo IP, še vedno podpira stara imena, ko je WINS konfiguriran in dosegljiv.

nbtstat -n
nbtstat -R

Za sodobni SMB se zanesite na DNS in polno ime ter staro pot upokojite. Če je res star, zagotovite WINS ali zamenjajte aplikacijo; srednja pot je čakalna vrsta podpore, ki se nikoli ne izprazni.

Sprehod se konča, ko lahko rečete, katera plast je odpovedala: razreševalnik, pripona ali staro odkrivanje. Zapišite razreševalnik, ki je odgovoril, in obliko imena, ki je delovala, ker bo naslednja oseba začela pri istem simptomu.