LAN-gastiga nomo malsukcesas tra VPN: sufikso, mDNS aŭ zono?

Apud la aparato, la presilo respondas al mallonga nomo kaj la dosier-servilo al kromnomo. Tra la tunelo, ambaŭ nomoj finiĝas per tempolimo, dum iliaj adresoj ankoraŭ funkcias. La vojo faras sian laboron; la nomvojo, kiu funkciigis tiujn mallongajn nomojn, neniam transiris la tunelon. Tri mekanismoj kaŭzas tiun konduton, kaj ĉiu bezonas malsaman korekton.

Komencu identigante, de kiu mekanismo la nomo dependas.

Tri specoj de nomoj, kiuj kondutas malsame

Nomo kun unu etikedo kiel fileserver kutime dependas de DNS-serĉa sufikso aldonita de la solvilo. Tiu sufikso ofte venas kun la loka DHCP-prunto, do fora kliento, kiu ricevas adresadon de la VPN, havas neniun kialon scii ĝin. Aldoni vojon ne liveras la sufikon. La mallonga nomo simple ĉesas ekzisti kiel nomo, kvankam la adreso malantaŭ ĝi estas atingebla.

Nomo finiĝanta per .local kutime estas solvata per multelsenda DNS sur la loka ligilo, kiel priskribas RFC 6762. Multelsendo ne transiras enkursigitan tunelon, krom se io intence pontas aŭ prokuras ĝin, do la nomo ĉesas solviĝi en la momento, kiam vi forlasas la segmenton.

Plene kvalifikita firmaa nomo apartenas al interna zono servata de la solviloj de la organizo. Tiu funkcias fore, kiam la VPN puŝas tiujn solvilojn kaj la kliento estas agordita uzi ilin. Kaj localhost estas special-uzada laŭ RFC 6761: ĝi rilatas al la maŝino antaŭ vi, neniam al fora servo.

Legu la solvilon antaŭ ol ŝanĝi la vojon

Demandu, kiu noma servilo respondis kaj kiu sufikso estis aldonita. La sama demando tra malsamaj solviloj donas malsamajn respondojn, kaj tiu diferenco estas la pruvo, kiun vi bezonas.

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

Se la plene kvalifikita demando solviĝas sed la mallonga ne, la paneo estas en la sufikso, ne en la servilo. Se neniu solviĝas kaj la adreso funkcias, la kliento tute ne uzas la internan solvilon. Komparu la solvilan liston kun tio, kion la VPN devus puŝi, ĉar kliento, kiu konservas sian lokan solvilon por ĉiu demando, neniam vidos la internan zonon.

Alportu la ĝustan nomon al la kliento

Petu de la administranto la dokumentitan foran alirnomon, plene, kaj uzu ĝin en la profilo anstataŭ diveni sufiksojn. Se la starigo subtenas split DNS, agordu la internan domajnon por esti solvata de la internaj serviloj, dum ĉio alia konservas la lokan solvilon. Puŝu la serĉan domajnon tra la VPN-agordo tie, kie la kliento subtenas ĝin.

Kontrolu la rezulton sur la kliento, ne sur la pordego. Agordo aplikita sur la servilo, kiu neniam atingas la klienton, ŝanĝas nenion.

Konservu la identecon de la atestilo netuŝita

Testo bazita sur adreso, kiu ignoras la atestilan eraron, pruvas nur, ke la ingo malfermiĝis. La serva atestilo estas eldonita por nomo, kaj la kliento daŭre rifuzos la malkongruon kun bona kialo. Se la atestilo listigas nur la internan nomon, uzu tiun nomon kaj riparu la solvadon, aŭ akiru atestilon, kiu kovras la adreson, kiun vi intencas uzi.

Notu la nomon, la solvilon kaj la sufikon, kiuj rezultigis sukcesan konekton. Tiu noto ŝparas al la sekva persono ripeti la adres-bazitan provizoran solvon, kiu kaŝas la veran problemon.