VPN-gastigantnomoj malsukcesas, IP-adresoj funkcias: kie serĉi

Vi povas malfermi la kunhavon per adreso, kaj la sama kunhavo per nomo malsukcesas, kio signifas, ke la tunelo portas pakaĵojn kaj la nomtavolo ne. Tiu unu observo ŝparas ĉirkaŭvojon tra ŝanĝoj de fajroŝirmilo kaj itineroj. Nomoj bezonas sufikson, solvanton kaj vojon por la peto, kaj VPN-kliento povas instali itineron sen instali iun ajn el ili. Trapasu la kvar kontrolojn sube laŭorde kaj haltu ĉe la unua, kiu rompiĝas.

Nomo starigas demandon, kiun adreso ne starigas

Adreso estas celo, kiun la stako povas uzi tuj. Mallonga nomo estas demando, kiun oni devas ampleksigi per sufikso, sendi al solvanto kaj respondi per io, kio konas la zonon. Tunelo, kiu instalas itinerojn sed neniun solvanton, lasas la unuan funkcii kaj la duan rompita. Tial la simptomo aspektas tiel konsekvenca tra tre diversaj VPN-produktoj.

Laboru eksteren de la adreso: unue la plena nomo, poste la nuda gastigantnomo, kaj notu, kiu el la tri funkcias. La ŝablono diras al vi, kiun tavolon kontroli antaŭ ol malfermi eĉ unu agordan ekranon. Diveni itinerojn, kiam la FQDN solviĝas, estas vana laboro.

Legu la solvanton, kiun la tunelo efektive instalis

Demandu la operaciumon kiu solvanto pritraktas petojn por la interna zono, ne kiun anoncas la interfaco de la VPN-kliento. Servilo, kiu altrudas publikan solvanton sen interna zono, produktas ĝuste ĉi tiun malsukceson, kaj ĝi estas agorda eraro, ne itinera difekto.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Ĉe Windows-kliento aliĝinta al domajno, la itinera politiko de la nomspaco decidas, kiuj petoj iras al kiu solvanto, kaj la propraj DNS-agordoj de la VPN-adaptilo aperas en la adaptilaj detaloj. Legu la efektivan politikon, ne la profilon, ĉar kaŝmemorita politiko povas postvivi la konekton, kiu ĝin instalis. Se la solvanto respondas al la plena nomo kaj ne al la mallonga, la problemo jam moviĝis al la listo de sufiksoj.

Get-DnsClientNrptPolicy
ipconfig /all

Haltu, se la interna zono solviĝas tra la ĝusta servilo. La solvanto ne estas via problemo.

Sufiksoj klarigas mallongajn nomojn, kiuj malsukcesas

Nomo kun unu etikedo ampleksiĝas per la sufiksa listo de la konekto antaŭ ol la peto estas sendita. Se la VPN ne liveras la internan sufikson, fileserver neniam fariĝas fileserver.corp.example, kaj la peto eliras kiel nomo, kiun neniu publika solvanto konas. Altrudi la sufikson, aŭ tajpi la plenan nomon, testas la hipotezon sen ŝanĝi ion ajn sur la servilo.

nslookup fileserver.corp.example
ping -a 192.168.50.20

En Linux la solvanta servo ligas DNS-servilon al ligilo kaj al aro de itineroj domajnoj, do altrudita servilo, kiu ne estas asociita kun la ligilo de la tunelo, kondutas kvazaŭ ĝi ne estus tie. Kontrolu la staton laŭ ligilo anstataŭ la stub-dosieron, kiu eble montras nur al la loka solvanto. La sama disiĝo aperas en la alia direkto: serĉa domajno, kiu ĉeestas sed ne estas aplikata al la tunela interfaco, produktas mallongnomajn malsukcesojn, kiuj aspektas hazardaj.

Se aldoni la sufikson solvas ĝin, la restanta laboro estas liveri tiun sufikson tra la VPN-profilon anstataŭ peti ĉiun uzanton tajpi ĝin.

NetBIOS kaj WINS estas alia mekanismo

Malnova SMB ankoraŭ povas serĉi nudan nomon per la NetBIOS-noma servo, kiu respondas per dissendo aŭ tra WINS-servilo. Dissendo restas en unu dissenda domajno kaj haltas ĉe la unua enkursigilo, do ĝi ne povas atingi trans tunelon; WINS funkcias ĉar la kliento havas unuĉelan adreson, ĉe kiu registriĝi kaj demandi. Tial VPN, kiu portas nur IP, ankoraŭ povas subteni malnovajn nomojn, kiam WINS estas agordita kaj atingebla.

nbtstat -n
nbtstat -R

Por moderna SMB, fidu la DNS kaj la plenan nomon, kaj pensiigu la malnovan vojon. Se ĝi vere estas malnova, provizu WINS aŭ anstataŭigu la aplikaĵon; la mezo estas subtena vico, kiu neniam malpleniĝas.

La promenado finiĝas, kiam vi povas diri, kiu tavolo malsukcesis: solvanto, sufikso aŭ malnova malkovro. Notu la solvanton, kiu respondis, kaj la nomformon, kiu funkciis, ĉar la sekva persono komencos de la sama simptomo.