VPN-i hostinimed ei toimi, IP-aadressid toimivad: kust otsida

Saate jagatud ressursi avada aadressi järgi, ja sama ressurss nime järgi ei avane, mis tähendab, et tunnel kannab pakette ja nimeruumikiht mitte. See üks tähelepanek säästab ümbersõidu tulemüüri ja marsruutide muudatustest. Nimed vajavad sufiksit, resolverit ja päringu jaoks teed, ning VPN-klient saab marsruudi paigaldada ilma ühtegi neist paigaldamata. Käige allolevad neli kontrolli järjekorras läbi ja peatuge esimesel, mis katkeb.

Nimi küsib küsimust, mida aadress ei küsi

Aadress on sihtkoht, mida virn saab kohe kasutada. Lühinimi on küsimus, mida tuleb laiendada sufiksiga, saata resolverile ja vastata millegi poolt, mis tunneb tsooni. Tunnel, mis paigaldab marsruudid, aga mitte resolverit, jätab esimese tööle ja teise katki. Seetõttu näeb sümptom välja nii järjekindel väga erinevates VPN-toodetes.

Töötage aadressist väljapoole: kõigepealt täisnimi, siis paljas hostinimi, ja pange kirja, milline kolmest töötab. Muster ütleb teile, millist kihti uurida, enne kui avate ühegi seadistusekraani. Marsruutide oletamine, kui FQDN laheneb, on raisatud vaev.

Lugege resolverit, mille tunnel tegelikult paigaldas

Küsige operatsioonisüsteemilt milline resolver töötleb sisemise tsooni päringuid, mitte millist VPN-kliendi liides kuulutab. Server, mis surub peale avaliku resolveri ilma sisemise tsoonita, tekitab täpselt selle tõrke, ja see on seadistusviga, mitte marsruutimise rike.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Domeeniga liidetud Windowsi kliendis otsustab nimeruumi marsruutimispoliitika, millised päringud lähevad millisele resolverile, ja VPN-adapteri enda DNS-seaded ilmuvad adapteri üksikasjadesse. Lugege kehtivat poliitikat, mitte profiili, sest vahemällu jäänud poliitika võib selle paigaldanud ühendusest kauem kesta. Kui resolver vastab täisnimele, aga mitte lühinimele, on probleem juba sufiksi loendisse liikunud.

Get-DnsClientNrptPolicy
ipconfig /all

Peatuge, kui sisemine tsoon laheneb õige serveri kaudu. Resolver ei ole teie probleem.

Sufiksid selgitavad lühinimesid, mis ei toimi

Ühe sildiga nimi laiendatakse ühenduse sufiksi loendiga enne päringu saatmist. Kui VPN ei anna sisemist sufiksit, ei saa fileserver kunagi fileserver.corp.example, ja päring läheb välja nimena, mida ükski avalik resolver ei tunne. Sufiksi pealesurumine või täisnime tipimine kontrollib hüpoteesi ilma serveris midagi muutmata.

nslookup fileserver.corp.example
ping -a 192.168.50.20

Linuxis seob resolveri teenus DNS-serveri lingi ja marsruutimisdomeenide hulgaga, nii et pealesurutud server, mis ei ole tunneli lingiga seotud, käitub nii, nagu teda ei oleks. Kontrollige linkide kaupa olekut, mitte stub-faili, mis võib osutada ainult kohalikule resolverile. Sama lõhe ilmneb ka vastassuunas: otsingudomeen, mis on olemas, aga mida ei rakendata tunneli liidesele, tekitab lühinimede tõrkeid, mis näivad juhuslikena.

Kui sufiksi lisamine selle parandab, jääb üle see sufiks VPN-profiili kaudu kohale toimetada, selle asemel et paluda igal kasutajal seda tipida.

NetBIOS ja WINS on teine mehhanism

Vana SMB suudab paljast nime veel NetBIOS-nimeteenusega otsida, mis vastab edastusega või WINS-serveri kaudu. Edastus jääb ühte edastusdomeeni ja peatub esimesel ruuteril, seega ei saa see tunnelist läbi; WINS töötab, sest kliendil on unicast-aadress, kuhu registreeruda ja millelt küsida. Seetõttu saab ainult IP-d kandev VPN vanu nimesid ikka toetada, kui WINS on seadistatud ja kättesaadav.

nbtstat -n
nbtstat -R

Kaasaegse SMB puhul lootke DNS-ile ja täisnimele ning saatke vana tee pensionile. Kui see on tõesti vana, pakkuge WINS-i või asendage rakendus; kesktee on tugijärjekord, mis ei tühjene kunagi.

Läbivaatus lõpeb, kui saate öelda, milline kiht ebaõnnestus: resolver, sufiks või vana avastus. Pange kirja resolver, mis vastas, ja nimekuju, mis töötas, sest järgmine inimene alustab samast sümptomist.