LAN-vertsnamn feilar over VPN: suffiks, mDNS eller sone?
Eit kortnamn kan kvile på eit søkesuffiks, eit .local-namn på multicast og eit firmanamn på ei privat sone. Ei rute åleine gjev inga namneteneste.
Ved sida av eininga svarar skrivaren på eit kortnamn og filtenaren på eit kallenamn. Gjennom tunnelen går begge namna ut medan adressene deira framleis verkar. Ruta gjer jobben sin; namnevegen som fekk desse kortnamna til å verke, kryssa aldri tunnelen. Tre mekanismar skapar denne åtferda, og kvar av dei treng ei anna retting.
Byrj med å finne ut kva mekanisme namnet er avhengig av.
Tre slag namn som oppfører seg ulikt
Eit namn med éi etikett som fileserver kviler vanlegvis på eit DNS-søkesuffiks som resolvaren legg til. Det suffikset kjem ofte med den lokale DHCP-leiga, så ein fjernklient som får adressering frå VPN-en har inga grunn til å kjenne det. Å leggje til ei rute leverer ikkje suffikset. Kortnamnet sluttar rett og slett å vere til som namn, sjølv om adressa bak det er tilgjengeleg.
Eit namn som sluttar på .local blir vanlegvis løyst opp med multicast DNS på den lokale lenkja, slik RFC 6762 skildrar. Multicast kryssar ikkje ein ruta tunnel utan at noko med vilje bruar eller proxyar han, så namnet sluttar å løysast opp i det augneblunken du forlèt segmentet.
Eit fullt kvalifisert firmanamn høyrer til ei intern sone som resolvarane til organisasjonen tener. Det verkar eksternt når VPN-en dyttar desse resolvarane og klienten er konfigurert til å bruke dei. Og localhost er til spesialbruk ifølgje RFC 6761: det viser til maskinen framfor deg, aldri til ein ekstern teneste.
Les resolvaren før du endrar ruta
Spør kva namnetenar som svara og kva suffiks som vart lagt til. Den same spørjinga gjennom ulike resolvarar gjev ulike svar, og den skilnaden er provet du treng.
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
Viss den fullt kvalifiserte spørjinga løyser opp, men den korte ikkje gjer det, ligg feilen i suffikset, ikkje i tenaren. Viss ingen av dei løyser opp og adressa verkar, brukar klienten ikkje den interne resolvaren i det heile. Samanlikn resolvarlista med det VPN-en skal dytte, for ein klient som held på den lokale resolvaren for kvar spørjing, vil aldri sjå den interne sona.
Ta med det rette namnet til klienten
Be administratoren om det dokumenterte fjernnamnet, fullt ut, og bruk det i profilen i staden for å gjette suffiks. Viss utrullinga støttar split DNS, konfigurer det interne domenet til å bli løyst opp av dei interne tenarane medan alt anna held på den lokale resolvaren. Dytt søkedomenet gjennom VPN-konfigurasjonen der klienten støttar det.
Stadfest resultatet på klienten i staden for på gatewayen. Ei innstilling som blir brukt på tenaren og aldri når klienten, endrar ingenting.
Hald identiteten til sertifikatet intakt
Ein adressebasert test som ignorerer sertifikatfeilen provar berre at socketen vart opna. Sertifikatet til tenesta er utstedt for eit namn, og klienten vil halde fram med å avvise avviket med god grunn. Viss sertifikatet berre listar det interne namnet, bruk det namnet og rett opp oppløysinga, eller skaff eit sertifikat som dekkjer adressa du har tenkt å bruke.
Noter namnet, resolvaren og suffikset som gav ei vellukka tilkopling. Den notata sparer neste person for å gjenta den adressebaserte omvegen som skjuler det eigentlege problemet.