LAN kompiuterio vardas neveikia per VPN: priesaga, mDNS ar zona?
Trumpas vardas gali remtis paieškos priesaga, .local vardas – multicast, o įmonės vardas – privačia zona. Vien maršrutas nesuteikia jokios vardų paslaugos.
Prie įrenginio spausdintuvas atsako į trumpą vardą, o failų serveris – į pravardę. Per tunelį abu vardai baigia galioti, nors jų adresai vis dar veikia. Maršrutas atlieka savo darbą; vardų kelias, kuris leido tiems trumpiems vardams veikti, niekada neperžengė tunelio. Trys mechanizmai sukelia šį elgesį, ir kiekvienam reikia kitokios pataisos.
Pradėkite nuo to, kurio mechanizmo vardas priklauso.
Trys vardų rūšys, kurios elgiasi skirtingai
Vienos etiketės vardas, pavyzdžiui, fileserver, paprastai remiasi DNS paieškos priesaga, kurią prideda sprendėjas. Ši priesaga dažnai ateina su vietine DHCP nuoma, todėl nuotolinis klientas, gaunantis adresus iš VPN, neturi priežasties ją žinoti. Maršruto pridėjimas priesagos nepristato. Trumpas vardas tiesiog nustoja egzistuoti kaip vardas, nors adresas už jo pasiekiamas.
Vardas, besibaigiantis .local, paprastai išsprendžiamas multicast DNS vietinėje jungtyje, kaip aprašo RFC 6762. Multicast neperžengia maršrutizuoto tunelio, nebent kažkas jį sąmoningai tiltina ar proxy'ina, todėl vardas nustoja sprendžiamas tą akimirką, kai paliekate segmentą.
Visas įmonės vardas priklauso vidinei zonai, kurią aptarnauja organizacijos sprendėjai. Jis veikia nuotoliniu būdu, kai VPN stumia tuos sprendėjus ir klientas sukonfigūruotas juos naudoti. O localhost pagal RFC 6761 yra specialios paskirties: jis nurodo priešais jus esantį kompiuterį, niekada nuotolinę paslaugą.
Perskaitykite sprendėją prieš keisdami maršrutą
Paklauskite, kuris vardų serveris atsakė ir kokia priesaga buvo pridėta. Ta pati užklausa per skirtingus sprendėjus duoda skirtingus atsakymus, ir tas skirtumas yra jums reikalingas įrodymas.
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
Jei visas užklausos vardas išsprendžiamas, o trumpasis ne, gedimas yra priesagoje, ne serveryje. Jei nė vienas neišsprendžiamas, o adresas veikia, klientas apskritai nenaudoja vidinio sprendėjo. Palyginkite sprendėjų sąrašą su tuo, ką VPN turėtų stumti, nes klientas, kuris kiekvienai užklausai palieka savo vietinį sprendėją, niekada nematys vidinės zonos.
Atneškite tinkamą vardą klientui
Paprašykite administratoriaus dokumentuoto nuotolinės prieigos vardo viso ir naudokite jį profilyje, o ne spėliokite priesagas. Jei diegimas palaiko split DNS, sukonfigūruokite vidinį domeną, kad jį spręstų vidiniai serveriai, o visa kita išlaikytų vietinį sprendėją. Stumkite paieškos domeną per VPN konfigūraciją ten, kur klientas tai palaiko.
Patikrinkite rezultatą kliente, o ne šliuze. Serveryje pritaikytas nustatymas, kuris niekada nepasiekia kliento, nieko nekeičia.
Išsaugokite sertifikato tapatybę
Adresu pagrįstas testas, kuris ignoruoja sertifikato klaidą, įrodo tik tai, kad lizdas atidarytas. Paslaugos sertifikatas išduotas vardui, ir klientas pagrįstai toliau atsisakys neatitikimo. Jei sertifikate nurodytas tik vidinis vardas, naudokite tą vardą ir sutvarkykite sprendimą arba gaukite sertifikatą, apimantį adresą, kurį ketinate naudoti.
Užrašykite vardą, sprendėją ir priesagą, kurie davė sėkmingą ryšį. Šis įrašas sutaupo kitam žmogui laiko nekartoti adresu pagrįsto apėjimo, kuris slepia tikrąją problemą.