LAN-gasheername misluk oor VPN: agtervoegsel, mDNS of sone?

Langs die toestel antwoord die drukker op ’n kort naam en die lêerbediener op ’n bynaam. Deur die tonnel hou albei name op om te werk terwyl hulle adresse steeds werk. Die roete doen sy werk; die naamroete wat daardie kort name laat werk het, het nooit die tonnel oorgesteek nie. Drie meganismes veroorsaak daardie gedrag, en elkeen verg ’n ander regstelling.

Begin deur vas te stel van watter meganisme die naam afhang.

Drie soorte name wat anders optree

’n Naam met ’n enkele etiket soos fileserver maak gewoonlik staat op ’n DNS-soekagtervoegsel wat die resolver byvoeg. Daardie agtervoegsel kom dikwels saam met die plaaslike DHCP-leas, so ’n afgeleë kliënt wat adressering van die VPN kry, het geen rede om dit te ken nie. Om ’n roete by te voeg lewer nie die agtervoegsel nie. Die kort naam hou eenvoudig op om as naam te bestaan, selfs al is die adres agter hom bereikbaar.

’n Naam wat op .local eindig, word gewoonlik op die plaaslike skakel deur multicast-DNS opgelos, soos RFC 6762 beskryf. Multicast steek nie ’n gerouteerde tonnel oor nie, tensy iets dit doelbewus oorbrug of volmag gee om dit te verteenwoordig, so die naam hou op oplos die oomblik wanneer jy die segment verlaat.

’n Ten volle gekwalifiseerde maatskappynaam behoort aan ’n interne sone wat deur die organisasie se resolvers bedien word. Daardie een werk op afstand wanneer die VPN daardie resolvers stoot en die kliënt gekonfigureer is om hulle te gebruik. En localhost is volgens RFC 6761 vir spesiale gebruik: dit verwys na die masjien voor jou, nooit na ’n afgeleë diens nie.

Lees die resolver voordat jy die roete verander

Vra watter naambediener geantwoord het en watter agtervoegsel bygevoeg is. Dieselfde navraag deur verskillende resolvers gee verskillende antwoorde, en daardie verskil is die bewys wat jy nodig het.

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

As die ten volle gekwalifiseerde navraag oplos maar die kort een nie, is die fout ’n agtervoegsel, nie ’n bediener nie. As nie een oplos nie en die adres werk, gebruik die kliënt glad nie die interne resolver nie. Vergelyk die resolverlys met wat die VPN veronderstel is om te stoot, want ’n kliënt wat sy plaaslike resolver vir elke navraag behou, sal nooit die interne sone sien nie.

Bring die regte naam na die kliënt

Vra die administrateur vir die gedokumenteerde naam vir afstandtoegang, volledig, en gebruik dit in die profiel in plaas daarvan om agtervoegsels te raai. As die ontplooiing split-DNS ondersteun, konfigureer die interne domein om deur die interne bedieners opgelos te word terwyl alles anders die plaaslike resolver behou. Stoot die soekdomein deur die VPN-konfigurasie waar die kliënt dit ondersteun.

Verifieer die resultaat op die kliënt eerder as op die gateway. ’n Instelling wat op die bediener toegepas word en nooit die kliënt bereik nie, verander niks.

Hou die sertifikaatidentiteit ongeskonde

’n Adresgebaseerde toets wat die sertifikaatfout ignoreer, bewys net dat die sokket oopgemaak het. Die dienssertifikaat word vir ’n naam uitgereik, en die kliënt sal die wanverhouding met goeie rede bly weier. As die sertifikaat net die interne naam lys, gebruik daardie naam en maak die resolusie reg, of kry ’n sertifikaat wat die adres dek wat jy van plan is om te gebruik.

Teken die naam, die resolver en die agtervoegsel aan wat ’n suksesvolle verbinding opgelewer het. Daardie rekord spaar die volgende persoon daarvan om die adresgebaseerde omweg te herhaal wat die werklike probleem verberg.