LAN-i hostinimi ei toimi VPN-i kaudu: järelliide, mDNS või tsoon?
Lühinimi võib toetuda otsingujärelliitele, .local-nimi multicastile ja ettevõtte nimi privaatsele tsoonile. Ainult marsruut ei paku mingit nimesideteenust.
Seadme kõrval vastab printer lühinimele ja failiserver hüüdnimele. Tunnelist läbi aeguvad mõlemad nimed, samal ajal kui nende aadressid ikka töötavad. Marsruut teeb oma tööd; nime tee, mis need lühinimed tööle pani, ei ületanud kunagi tunnelit. Seda käitumist tekitavad kolm mehhanismi ja igaüks neist vajab erinevat parandust.
Alustage selle kindlakstegemisest, millisest mehhanismist nimi sõltub.
Kolm erinevalt käituvat nimeliiki
Ühe sildiga nimi nagu fileserver toetub tavaliselt DNS-i otsingujärelliitele, mille resolver lisab. See järelliide tuleb sageli koos kohaliku DHCP-rendiga, nii et VPN-ilt adresseerimist saaval kaugkliendil pole põhjust seda teada. Marsruudi lisamine ei too järelliidet kohale. Lühinimi lihtsalt lakkab nimena olemast, kuigi selle taga olev aadress on kättesaadav.
.local lõppev nimi lahendatakse tavaliselt kohalikul lingil multicast-DNS-iga, nagu RFC 6762 kirjeldab. Multicast ei ületa marsruuditud tunnelit, kui miski ei silla ega vahenda seda tahtlikult, nii et nimi lakkab lahendamast hetkel, mil segmenti lahkusite.
Täielikult kvalifitseeritud ettevõtte nimi kuulub sisemisele tsoonile, mida teenindavad organisatsiooni resolverid. See toimib kaugelt, kui VPN lükkab need resolverid edasi ja klient on seadistatud neid kasutama. Ja localhost on RFC 6761 järgi eriotstarbeline: see viitab masinale teie ees, mitte kunagi kaugteenusele.
Lugege resolverit enne marsruudi muutmist
Küsige, milline nimeserver vastas ja milline järelliide lisati. Sama päring erinevate resolverite kaudu annab erinevaid vastuseid ja see erinevus on tõend, mida vajate.
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
Kui täielikult kvalifitseeritud päring laheneb, aga lühike mitte, on viga järelliites, mitte serveris. Kui kumbki ei lahene ja aadress töötab, ei kasuta klient sisemist resolverit üldse. Võrrelge resolverite loendit sellega, mida VPN peaks edasi lükkama, sest klient, kes hoiab iga päringu jaoks oma kohalikku resolverit, ei näe sisemist tsooni kunagi.
Tooge õige nimi kliendini
Küsige administraatorilt dokumenteeritud kaugjuurdepääsu nime, täielikult, ja kasutage seda profiilis järelliidete oletamise asemel. Kui juurutus toetab split DNS-i, seadistage sisemine domeen sisemiste serverite poolt lahendatavaks, samal ajal kui kõik muu säilitab kohaliku resolveri. Lükake otsingudomeen VPN-i konfiguratsiooni kaudu edasi seal, kus klient seda toetab.
Kontrollige tulemust kliendil, mitte lüüsil. Serveril rakendatud seade, mis ei jõua kunagi kliendini, ei muuda midagi.
Hoidke sertifikaadi identiteet puutumatuna
Aadressipõhine test, mis eirab sertifikaadi viga, tõestab ainult seda, et pesa avati. Teenuse sertifikaat on välja antud nimele ja klient jätkab erinevuse tagasilükkamist mõjuval põhjusel. Kui sertifikaat loetleb ainult sisemise nime, kasutage seda nime ja parandage lahendamine, või hankige sertifikaat, mis katab aadressi, mida kavatsete kasutada.
Kirjutage üles nimi, resolver ja järelliide, mis andsid edukas ühenduse. See kirje säästab järgmist inimest aadressipõhise möödasõidu kordamisest, mis varjab tegelikku probleemi.