LAN-värdnamn misslyckas över VPN: suffix, mDNS eller zon?

Bredvid enheten svarar skrivaren på ett kort namn och filservern på ett smeknamn. Genom tunneln löper båda namnen ut medan deras adresser fortfarande fungerar. Rutten gör sitt jobb; namnsökvägen som fick de korta namnen att fungera korsade aldrig tunneln. Tre mekanismer skapar det beteendet, och var och en kräver en annan rättelse.

Börja med att ta reda på vilken mekanism namnet beror på.

Tre slags namn som beter sig olika

Ett namn med en enda etikett som fileserver bygger vanligtvis på ett DNS-söksuffix som resolvern lägger till. Det suffixet kommer ofta med det lokala DHCP-lånet, så en fjärrklient som får adressering från VPN har ingen anledning att känna till det. Att lägga till en rutt levererar inte suffixet. Det korta namnet slutar helt enkelt att existera som namn, även om adressen bakom det är nåbar.

Ett namn som slutar på .local löses vanligtvis via multicast-DNS på den lokala länken, som RFC 6762 beskriver. Multicast korsar inte en routad tunnel om inte något medvetet bryggar eller proxar den, så namnet slutar lösas i samma stund som du lämnar segmentet.

Ett fullt kvalificerat företagsnamn tillhör en intern zon som organisationens resolvrar betjänar. Det fungerar på distans när VPN:n skjuter ut dessa resolvrar och klienten är konfigurerad att använda dem. Och localhost är för särskilt bruk enligt RFC 6761: det syftar på maskinen framför dig, aldrig på en fjärrtjänst.

Läs resolvern innan du ändrar rutten

Fråga vilken namnserver som svarade och vilket suffix som lades till. Samma fråga via olika resolvrar ger olika svar, och den skillnaden är det bevis du behöver.

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

Om den fullt kvalificerade frågan löses men den korta inte, ligger felet i suffixet, inte i servern. Om ingen av dem löses och adressen fungerar använder klienten inte den interna resolvern alls. Jämför resolverlistan med det VPN:n ska skjuta ut, för en klient som behåller sin lokala resolver för varje fråga kommer aldrig att se den interna zonen.

Ta det rätta namnet till klienten

Be administratören om det dokumenterade fjärråtkomstnamnet, fullt ut, och använd det i profilen i stället för att gissa suffix. Om utrullningen stöder split DNS, konfigurera den interna domänen så att den löses av de interna servrarna medan allt annat behåller den lokala resolvern. Skjut ut sökdomänen via VPN-konfigurationen där klienten stöder det.

Verifiera resultatet på klienten i stället för på gatewayen. En inställning som tillämpas på servern och aldrig når klienten ändrar ingenting.

Håll certifikatets identitet intakt

Ett adressbaserat test som ignorerar certifikatfelet bevisar bara att socketen öppnades. Tjänstens certifikat är utfärdat för ett namn, och klienten kommer att fortsätta avvisa avvikelsen med goda skäl. Om certifikatet bara listar det interna namnet, använd det namnet och rätta upplösningen, eller skaffa ett certifikat som täcker den adress du tänker använda.

Notera namnet, resolvern och suffixet som gav en lyckad anslutning. Den noteringen sparar nästa person från att upprepa den adressbaserade kringgången som döljer det egentliga problemet.