LAN-vertsnavn feiler over VPN: suffiks, mDNS eller sone?

Ved siden av enheten svarer skriveren på et kortnavn og filserveren på et kallenavn. Gjennom tunnelen utløper begge navnene mens adressene deres fortsatt virker. Ruten gjør jobben sin; navneveien som fikk disse kortnavnene til å virke, krysset aldri tunnelen. Tre mekanismer skaper denne oppførselen, og hver av dem trenger en annen rettelse.

Begynn med å finne ut hvilken mekanisme navnet er avhengig av.

Tre slags navn som oppfører seg ulikt

Et navn med én etikett som fileserver hviler vanligvis på et DNS-søkesuffiks som resolveren legger til. Det suffikset kommer ofte med den lokale DHCP-leien, så en fjernklient som får adressering fra VPN-en har ingen grunn til å kjenne det. Å legge til en rute leverer ikke suffikset. Kortnavnet slutter rett og slett å eksistere som navn, selv om adressen bak det er tilgjengelig.

Et navn som slutter på .local blir vanligvis slått opp med multicast DNS på den lokale lenken, slik RFC 6762 beskriver. Multicast krysser ikke en rutet tunnel med mindre noe bevisst broer eller proxier den, så navnet slutter å slå opp i det øyeblikket du forlater segmentet.

Et fullt kvalifisert firmanavn tilhører en intern sone som organisasjonens resolvere betjener. Det fungerer eksternt når VPN-en dytter disse resolverne og klienten er konfigurert til å bruke dem. Og localhost er til spesialbruk ifølge RFC 6761: det viser til maskinen foran deg, aldri til en ekstern tjeneste.

Les resolveren før du endrer ruten

Spør hvilken navneserver som svarte og hvilket suffiks som ble lagt til. Den samme spørringen gjennom ulike resolvere gir ulike svar, og den forskjellen er beviset du trenger.

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 fullt kvalifiserte spørringen slår opp, men den korte ikke gjør det, ligger feilen i suffikset, ikke i serveren. Hvis ingen av dem slår opp og adressen virker, bruker klienten ikke den interne resolveren i det hele tatt. Sammenlign resolverlisten med det VPN-en skal dytte, for en klient som beholder sin lokale resolver for hver spørring, vil aldri se den interne sonen.

Ta med det riktige navnet til klienten

Be administratoren om det dokumenterte fjernnavnet, fullt ut, og bruk det i profilen i stedet for å gjette suffikser. Hvis utrullingen støtter split DNS, konfigurer det interne domenet til å bli slått opp av de interne serverne mens alt annet beholder den lokale resolveren. Dytt søkedomenet gjennom VPN-konfigurasjonen der klienten støtter det.

Verifiser resultatet på klienten i stedet for på gatewayen. En innstilling som brukes på serveren og aldri når klienten, endrer ingenting.

Hold sertifikatets identitet intakt

En adressebasert test som ignorerer sertifikatfeilen beviser bare at socketen ble åpnet. Tjenestens sertifikat er utstedt for et navn, og klienten vil fortsette å avvise avviket med god grunn. Hvis sertifikatet bare lister det interne navnet, bruk det navnet og rett opp oppslaget, eller skaff et sertifikat som dekker adressen du har tenkt å bruke.

Noter navnet, resolveren og suffikset som ga en vellykket tilkobling. Den noten sparer neste person for å gjenta den adressebaserte omveien som skjuler det egentlige problemet.