Ime hosta na LAN-u ne radi preko VPN-a: sufiks, mDNS ili zona?
Kratko ime može se osloniti na sufiks pretrage, ime .local na multicast, a ime kompanije na privatnu zonu. Sama ruta ne pruža nikakvu uslugu imenovanja.
Pored uređaja, pisač odgovara na kratko ime, a datotečni poslužitelj na nadimak. Kroz tunel oba imena isteku, dok njihove adrese i dalje rade. Ruta radi svoj posao; put imenovanja koji je ta kratka imena činio funkcionalnim nikada nije prešao tunel. Tri mehanizma proizvode takvo ponašanje i svaki od njih traži drugačiju ispravku.
Počnite tako što ćete utvrditi o kojem mehanizmu ime zavisi.
Tri vrste imena koja se ponašaju različito
Ime s jednom oznakom kao što je fileserver obično se oslanja na DNS sufiks pretrage koji dodaje resolver. Taj sufiks često dolazi uz lokalni DHCP zakup, pa udaljeni klijent koji adresiranje dobija od VPN-a nema razloga da ga zna. Dodavanje rute ne dostavlja sufiks. Kratko ime jednostavno prestaje postojati kao ime, iako je adresa iza njega dostupna.
Ime koje završava na .local obično se rješava putem multicast DNS-a na lokalnoj vezi, kako opisuje RFC 6762. Multicast ne prelazi rutiranim tunelom osim ako ga nešto namjerno ne premosni ili proksira, pa ime prestaje da se rješava u trenutku kada napustite segment.
Potpuno kvalifikovano ime kompanije pripada internoj zoni koju opslužuju resolveri organizacije. Ono radi na daljinu kada VPN potisne te resolvere i klijent je konfigurisan da ih koristi. A localhost je posebne namjene prema RFC 6761: odnosi se na mašinu ispred vas, nikada na udaljenu uslugu.
Pročitajte resolver prije nego što promijenite rutu
Pitajte koji je imenski server odgovorio i koji je sufiks dodan. Isti upit kroz različite resolvere daje različite odgovore, a ta razlika je dokaz koji vam treba.
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
Ako se potpuno kvalifikovani upit rješava, a kratki ne, kvar je u sufiksu, ne u serveru. Ako se nijedan ne rješava, a adresa radi, klijent uopšte ne koristi interni resolver. Uporedite listu resolvera s onim što VPN treba da potisne, jer klijent koji čuva svoj lokalni resolver za svaki upit nikada neće vidjeti internu zonu.
Donesite pravo ime klijentu
Zatražite od administratora dokumentovano ime za daljinski pristup, u cjelini, i koristite ga u profilu umjesto pogađanja sufiksa. Ako implementacija podržava split DNS, konfigurišite da internu domenu rješavaju interni serveri, dok sve ostalo zadržava lokalni resolver. Potisnite domenu pretrage kroz VPN konfiguraciju tamo gdje je klijent podržava.
Provjerite rezultat na klijentu, a ne na gatewayu. Postavka primijenjena na serveru koja nikada ne stigne do klijenta ne mijenja ništa.
Sačuvajte identitet certifikata netaknutim
Test zasnovan na adresi koji ignorira grešku certifikata dokazuje samo da se socket otvorio. Certifikat usluge izdat je za ime i klijent će s pravom nastaviti odbijati neslaganje. Ako certifikat navodi samo interno ime, koristite to ime i popravite rješavanje, ili nabavite certifikat koji pokriva adresu koju namjeravate koristiti.
Zabilježite ime, resolver i sufiks koji su dali uspješnu vezu. Taj zapis štedi sljedeću osobu od ponavljanja zaobilaznog rješenja zasnovanog na adresi koje skriva pravi problem.