Værtsnavn på LAN fejler over VPN: suffiks, mDNS eller zone?
Et kort navn kan afhænge af et søgesuffiks, et .local-navn af multicast og et virksomhedsnavn af en privat zone. En rute alene leverer ingen navnetjeneste.
Ved siden af enheden svarer printeren på et kort navn, og filserveren svarer på et kælenavn. Gennem tunnelen udløber begge navne, mens deres adresser stadig virker. Ruten gør sit arbejde; den navnevej, der fik de korte navne til at virke, krydsede aldrig tunnelen. Tre mekanismer skaber den adfærd, og hver af dem kræver en anden rettelse.
Begynd med at afgøre, hvilken mekanisme navnet afhænger af.
Tre slags navne, der opfører sig forskelligt
Et navn med en enkelt etiket som fileserver hviler normalt på et DNS-søgesuffiks, som resolveren tilføjer. Det suffiks kommer ofte med den lokale DHCP-leje, så en fjernklient, der får adressering fra VPN'en, har ingen grund til at kende det. At tilføje en rute leverer ikke suffikset. Det korte navn holder simpelthen op med at eksistere som navn, selv om adressen bag det er tilgængelig.
Et navn, der ender på .local, bliver normalt slået op via multicast DNS på det lokale net, som RFC 6762 beskriver. Multicast krydser ikke en routet tunnel, medmindre noget bevidst broer eller proxier den, så navnet holder op med at slå op i det øjeblik, du forlader segmentet.
Et fuldt kvalificeret virksomhedsnavn hører til en intern zone, der betjenes af organisationens resolvere. Det virker eksternt, når VPN'en skubber de resolvere ud og klienten er konfigureret til at bruge dem. Og localhost er til særligt brug ifølge RFC 6761: det henviser til maskinen foran dig, aldrig til en ekstern tjeneste.
Læs resolveren, før du ændrer ruten
Spørg, hvilken navneserver der svarede, og hvilket suffiks der blev tilføjet. Den samme forespørgsel gennem forskellige resolvere giver forskellige svar, og den forskel er det bevis, du har brug for.
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
Hvis den fuldt kvalificerede forespørgsel slår op, men den korte ikke, ligger fejlen i suffikset, ikke i serveren. Hvis ingen af dem slår op, og adressen virker, bruger klienten slet ikke den interne resolver. Sammenlign resolverlisten med det, VPN'en skal skubbe ud, for en klient, der beholder sin lokale resolver til hver forespørgsel, vil aldrig se den interne zone.
Bring det rigtige navn til klienten
Bed administratoren om det dokumenterede fjernadgangsnavn, fuldt ud, og brug det i profilen i stedet for at gætte suffikser. Hvis udrulningen understøtter split DNS, skal du konfigurere det interne domæne til at blive slået op af de interne servere, mens alt andet beholder den lokale resolver. Skub søgedomænet gennem VPN-konfigurationen, hvor klienten understøtter det.
Kontroller resultatet på klienten i stedet for på gatewayen. En indstilling, der anvendes på serveren og aldrig når klienten, ændrer intet.
Hold certifikatets identitet intakt
En adressebaseret test, der ignorerer certifikatfejlen, beviser kun, at socket'en blev åbnet. Tjenestens certifikat er udstedt til et navn, og klienten vil fortsat afvise uoverensstemmelsen med god grund. Hvis certifikatet kun viser det interne navn, så brug det navn og ret opløsningen, eller skaff et certifikat, der dækker den adresse, du har tænkt dig at bruge.
Noter navnet, resolveren og suffikset, som gav en vellykket forbindelse. Den note sparer den næste person for at gentage den adressebaserede omvej, som skjuler det egentlige problem.