Jina la mwenyeji la LAN linashindwa kupitia VPN: kiambishi, mDNS au eneo?
Jina fupi linaweza kutegemea kiambishi cha utafutaji, jina la .local linategemea multicast na jina la kampuni linategemea eneo la faragha. Njia peke yake haitoi huduma yoyote ya majina.
Kando ya kifaa, printa hujibu jina fupi na seva ya faili hujibu jina la utani. Kupitia handaki, majina yote mawili yanaisha wakati anwani zao bado zinafanya kazi. Njia inafanya kazi yake; njia ya majina iliyofanya majina hayo mafupi yafanye kazi haikuvuka handaki kamwe. Mbinu tatu huzalisha tabia hiyo, na kila moja inahitaji marekebisho tofauti.
Anza kwa kubaini jina linategemea mbinu gani.
Aina tatu za majina yanayofanya kazi tofauti
Jina la lebo moja kama fileserver kwa kawaida hutegemea kiambishi cha utafutaji cha DNS kinachoongezwa na kisuluhishi. Kiambishi hicho mara nyingi huja na ukodishaji wa DHCP wa ndani, kwa hivyo mteja wa mbali anayepata anwani kutoka VPN hana sababu ya kukijua. Kuongeza njia hakuwasilishi kiambishi. Jina fupi huacha tu kuwepo kama jina, ingawa anwani iliyo nyuma yake inafikiwa.
Jina linaloishia kwa .local kwa kawaida husuluhishwa kwa DNS ya multicast kwenye kiungo cha ndani, kama RFC 6762 inavyoeleza. Multicast haivuki handaki yenye njia isipokuwa kitu kwa makusudi kikiunganisha au kukiweka kama proksi, kwa hivyo jina huacha kusuluhishwa mara tu unapoondoka kwenye sehemu.
Jina la kampuni lililostahiki kikamilifu ni la eneo la ndani linalohudumiwa na visuluhishi vya shirika. Hilo hufanya kazi kwa mbali wakati VPN inasukuma visuluhishi hivyo na mteja amesanidiwa kuvitumia. Na localhost ni la matumizi maalum kulingana na RFC 6761: linarejelea mashine iliyo mbele yako, kamwe si huduma ya mbali.
Soma kisuluhishi kabla ya kubadilisha njia
Uliza ni seva gani ya majina ilijibu na kiambishi kipi kiliongezwa. Swali hilo hilo kupitia visuluhishi tofauti hutoa majibu tofauti, na tofauti hiyo ni ushahidi unaouhitaji.
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
Ikiwa swali lililostahiki kikamilifu linasuluhishwa lakini fupi halisuluhishwi, hitilafu iko kwenye kiambishi, si kwenye seva. Ikiwa hakuna linalosuluhishwa na anwani inafanya kazi, mteja hatumii kisuluhishi cha ndani hata kidogo. Linganisha orodha ya visuluhishi na kile VPN inapaswa kusukuma, kwa sababu mteja anayebakiza kisuluhishi chake cha ndani kwa kila swali hataona eneo la ndani kamwe.
Leta jina sahihi kwa mteja
Omba msimamizi jina lililoandikwa la ufikiaji wa mbali, kikamilifu, na ulitumie kwenye wasifu badala ya kukisia viambishi. Ikiwa usambazaji unasaidia split DNS, sanidi kikoa cha ndani kisuluhishwe na seva za ndani wakati kila kitu kingine kinabaki na kisuluhishi cha ndani. Sukuma kikoa cha utafutaji kupitia usanidi wa VPN pale mteja anaposaidia.
Thibitisha matokeo kwa mteja badala ya kwa lango. Mpangilio unaotumika kwenye seva na haufiki kwa mteja kamwe haubadilishi chochote.
Hifadhi utambulisho wa cheti
Jaribio la msingi wa anwani linalopuuza hitilafu ya cheti linathibitisha tu kwamba soketi ilifunguliwa. Cheti cha huduma hutolewa kwa jina, na mteja ataendelea kukataa kutokubaliana kwa sababu nzuri. Ikiwa cheti kinaorodhesha jina la ndani pekee, tumia jina hilo na urekebishe usuluhishaji, au pata cheti kinachofunika anwani unayokusudia kutumia.
Rekodi jina, kisuluhishi na kiambishi vilivyotoa muunganisho uliofanikiwa. Rekodi hiyo humwokoa mtu anayefuata kurudia suluhisho la muda la msingi wa anwani linaloficha tatizo halisi.