VPN resursdatoru nosaukumi neizdodas, IP adreses darbojas: kur meklēt

Jūs varat atvērt koplietojumu pēc adreses, un tas pats koplietojums pēc nosaukuma neizdodas, kas nozīmē, ka tunelis pārvieto paketes, bet nosaukumu slānis ne. Šis viens novērojums ietaupa apkārtceļu caur ugunsmūra un maršrutu izmaiņām. Nosaukumiem vajag galotni, risinātāju un ceļu vaicājumam, un VPN klients var instalēt maršrutu, neinstalējot nevienu no tiem. Izpildiet četras pārbaudes zemāk secībā un apstājieties pie pirmās, kas salūzt.

Nosaukums uzdod jautājumu, ko adrese neuzdod

Adrese ir galamērķis, ko steks var izmantot uzreiz. Īsais nosaukums ir jautājums, kas jāpaplašina ar galotni, jānosūta risinātājam un uz to jāatbild kaut kam, kas pazīst zonu. Tunelis, kas instalē maršrutus, bet ne risinātāju, atstāj pirmo strādājošu un otro salauztu. Tāpēc simptoms izskatās tik konsekvents ļoti atšķirīgos VPN produktos.

Strādājiet no adreses uz āru: vispirms pilnais nosaukums, tad kailais resursdatora nosaukums, un atzīmējiet, kurš no trim strādā. Modelis jums pasaka, kuru slāni pārbaudīt pirms vienas konfigurācijas ekrāna atvēršanas. Minēt maršrutus, kad FQDN tiek atrisināts, ir veltīgs darbs.

Lasiet risinātāju, ko tunelis patiešām instalēja

Pajautājiet operētājsistēmai kurš risinātājs apstrādā iekšējās zonas vaicājumus, nevis kuru reklamē VPN klienta saskarne. Serveris, kas uzspiež publisku risinātāju bez iekšējās zonas, rada tieši šo neveiksmi, un tā ir konfigurācijas kļūda, nevis maršrutēšanas bojājums.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Domēnam pievienotā Windows klientā nosaukumtelpas maršrutēšanas politika izlemj, kuri vaicājumi dodas pie kura risinātāja, un VPN adaptera paša DNS iestatījumi parādās adaptera detaļās. Lasiet spēkā esošo politiku, nevis profilu, jo kešatmiņā saglabāta politika var pārdzīvot to instalējušo savienojumu. Ja risinātājs atbild uz pilno nosaukumu, bet ne uz īso, problēma jau ir pārvietojusies uz galotņu sarakstu.

Get-DnsClientNrptPolicy
ipconfig /all

Apstājieties, ja iekšējā zona tiek atrisināta caur pareizo serveri. Risinātājs nav jūsu problēma.

Galotnes izskaidro īsos nosaukumus, kas neizdodas

Vienas etiķetes nosaukums tiek paplašināts ar savienojuma galotņu sarakstu pirms vaicājuma nosūtīšanas. Ja VPN nepiegādā iekšējo galotni, fileserver nekad nekļūst par fileserver.corp.example, un vaicājums iziet kā nosaukums, ko nepazīst neviens publisks risinātājs. Galotnes uzspiešana vai pilna nosaukuma ierakstīšana pārbauda hipotēzi, neko nemainot serverī.

nslookup fileserver.corp.example
ping -a 192.168.50.20

Linux sistēmā risinātāja pakalpojums saista DNS serveri ar saiti un maršrutēšanas domēnu kopu, tāpēc uzspiests serveris, kas nav saistīts ar tuneļa saiti, uzvedas tā, it kā tā nebūtu. Pārbaudiet statusu pa saitēm, nevis stub failu, kas var norādīt tikai uz vietējo risinātāju. Tāda pati šķelšanās redzama arī pretējā virzienā: meklēšanas domēns, kas pastāv, bet nav piemērots tuneļa saskarnei, rada īso nosaukumu neveiksmes, kas izskatās nejaušas.

Ja galotnes pievienošana to salabo, atlikušais darbs ir piegādāt šo galotni caur VPN profilu, nevis prasīt katram lietotājam to ierakstīt.

NetBIOS un WINS ir cits mehānisms

Vecais SMB joprojām var meklēt kailu nosaukumu ar NetBIOS nosaukumu pakalpojumu, kas atbild apraides ceļā vai caur WINS serveri. Apraide paliek vienā apraides domēnā un apstājas pie pirmā maršrutētāja, tāpēc nevar šķērsot tuneli; WINS darbojas tāpēc, ka klientam ir unicast adrese, ar ko reģistrēties un ko vaicāt. Tāpēc VPN, kas pārvieto tikai IP, joprojām var atbalstīt vecos nosaukumus, ja WINS ir konfigurēts un sasniedzams.

nbtstat -n
nbtstat -R

Mūsdienu SMB paļaujieties uz DNS un pilno nosaukumu, un veco ceļu aizdodiet pensijā. Ja tas tiešām ir vecs, nodrošiniet WINS vai aizstājiet lietojumprogrammu; vidusceļš ir atbalsta rinda, kas nekad neiztukšojas.

Gājiens beidzas, kad varat pateikt, kurš slānis sabojājās: risinātājs, galotne vai vecā atklāšana. Pierakstiet atbildējušo risinātāju un strādājušo nosaukuma formu, jo nākamais cilvēks sāks no tā paša simptoma.