Laptap yako hutatua intranet.corp kupitia handaki huku gitlab.com ikiendelea kwenda kwa kitatuzi cha mtoa huduma, na hii ni mpangilio unaofanya kazi kama ulivyoundwa. Maamuzi mawili tofauti yaliuunda: kanuni ya kulinganisha jina ilichagua kitatuzi, na njia ilirudisha jibu. Vunja moja yao na kivinjari kinaonyesha hitilafu inayofanana kutoka nje. Ripoti nyingi za DNS iliyogawanywa zinaeleza hitilafu ya pili huku zikinukuu ushahidi kuhusu ya kwanza.

Nusu mbili zinaishi mahali tofauti na kwa kawaida hueditwa na watu tofauti. Moja ni sera ya DNS iliyounganishwa na wasifu wa VPN, nyingine ni njia ambayo handaki huiweka au kuizuia. Utatuzi wa matatizo unasimama pale ambapo hakuna anayebaini ni nusu ipi iliyohama kwa kweli.

Maamuzi mawili yaliyofichwa katika ombi moja

Nusu ya jina ni kitu cha sera, si njia. Katika Windows ni sera ya utatuzi wa majina kwenye wasifu wa VPN; kwenye majukwaa ya Apple ni seti ya vikoa vinavyolingana kwenye kitu cha mipangilio ya DNS; katika Linux ni kikoa cha uelekezaji, mstari wa kitatuzi kilichogawanywa au mpangilio wa swichi ya huduma ya majina. Nusu ya njia ni uelekezaji wa kawaida, uliowekwa na handaki au kwa mkono, na haijui jina la mwenyeji ni nini. Wasifu unaoruhusu kiambishi huamua tu nani anajibu; kamwe haifanyi jibu lifikike.

Jaribio la haraka la dalili huzitenganisha: badilisha jina kwa anwani. Ikiwa anwani inafanya kazi, njia ni sahihi na kanuni si sahihi. Ikiwa anwani pia inashindikana, kanuni inaweza kuwa sahihi na njia ikawa haipo.

Jinsi kila jukwaa linavyoeleza kanuni hiyo hiyo ya jina

Nia ni moja na majina ya sehemu hayafanani. Mfano ulionakiliwa kutoka kwa mteja mmoja hadi mwingine huchanganuliwa kwa usafi na kamwe haulingani. Maumbo matatu yanaonekana hivi:

PlatformWhere the rule livesWhat usually breaks
Windowsname-resolution policy on the VPN profileprecedence against the interface suffix list
Apple platformsmatch domains on the DNS settings objectdomains attached to the wrong extension
Linuxrouting domain, split resolver, nsswitch orderthe suffix written the wrong way round

Kikoa cha kulinganisha au cha uelekezaji ni jaribio la kiambishi, kwa hiyo intranet.corp hufunika git.intranet.corp na haifuniki corp.intranet, na kuipindua ndilo kosa la kawaida zaidi katika mpangilio wote. Windows hubeba ramani kama sera ya utatuzi wa majina iliyounganishwa na wasifu, ikiwa na mpangilio wake wa kipaumbele dhidi ya orodha yoyote ya viambishi ambayo kiolesura kilikuwa nayo. Majukwaa ya Apple huunganisha vikoa vinavyolingana na kitu cha mipangilio ya DNS cha kiendelezi cha mtandao, na mfumo huitumia kwa kila kitatuzi kilichowekewa mipaka. Hakuna moja ya maumbo haya ni njia, na hakuna linaloweza kufanya anwani isiyofikika ifikike. Marejeo ya sera ya utatuzi wa majina ya Windows yanaorodhesha majina ya sehemu na kanuni za kipaumbele kwa jukwaa hilo, na si zile zinazotumiwa na nyaraka za Apple au systemd.

Jibu sahihi bado linahitaji njia

Jibu la kitatuzi ni anwani tu, na programu bado inapaswa kuifikia. Muundo wa handaki lililogawanywa mara nyingi husukuma 10.20.0.0/16 na kuzuia njia chaguo-msingi, kwa hiyo jina la ndani hutatuliwa na muunganisho kisha huning'inia. Kesi iliyo kinyume ni ya kawaida vile vile: njia ipo, kitatuzi cha umma hujibu jina la faragha kwa NXDOMAIN, na hitilafu husajiliwa kama tatizo la uelekezaji. Kupima njia kwanza kunakuacha ukitazama njia kwa jina ambalo halikuwa likitatuliwa kamwe.

Pia kuna lango la tatu ambalo hakuna nusu inalofunika. ACL kwenye lango, kanuni ya firewall au sera ya upande wa mteja zinaweza kuangusha muunganisho baada ya maamuzi yote mawili kuwa sahihi. Jina linapotatuliwa, njia ipo na muunganisho bado unaisha muda, acha kupima DNS.

Kupima majina na njia kwa mpangilio maalum

Chagua mpangilio na uushikilie, la sivyo utafukuza hatua iliyoshindikana mwisho. Tatua jina kamili la ndani lililoandikwa, thibitisha kwamba jibu ni anwani ambayo jedwali la uelekezaji linaweza kuibeba, kisha rudia kwa jina la umma ili kuthibitisha handaki halikukamata kila kitu. Kwenye mwenyeji wa systemd swali na kikoa cha uelekezaji cha kitatuzi viko umbali wa amri moja:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Mteja wa Windows huuliza maswali hayo mawili kwa cmdlet tofauti. La pili huripoti kiolesura ambacho mfumo ungetumia kwa kweli:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Ikiwa utafutaji unarudisha anwani na ukaguzi wa njia unataja kiolesura cha kimwili, kanuni ya jina ilifanya kazi na njia haikufanya. Ikiwa jina fupi linashindikana huku jina kamili likitatuliwa, orodha ya viambishi ndiyo isiyo sahihi, si kitatuzi.

Mahali ulinganisho kwa kawaida unakosea

Kosa la kwanza ni kumuuliza kitatuzi cha umma kisichohusiana kuhusu jina la faragha na kusoma kukataliwa kama ushahidi kuhusu VPN. La pili ni kudhani kuwa utafutaji wa umma unaofanya kazi unathibitisha njia ya kitatuzi cha handaki. La tatu ni kuchukulia uhandaki uliogawanywa na DNS iliyogawanywa kama uamuzi mmoja wa muundo, wakati usambazaji unaweza kuwa sahihi katika moja na umevunjika katika nyingine. Kila kosa hutoa hitimisho la uhakika kutoka jaribio ambalo halikuwahi kufanya mazoezi ya sehemu inayolalamikiwa.

Kivinjari kilicho na DNS yake salama kinaweza pia kupita kanuni ya mfumo, kwa hiyo kushindikana kwa kivinjari kimoja huku kingine kikifanikiwa si ukinzani. Linganisha kitatuzi kilichojibu, si kivinjari kilicholalamika.

Mara nusu zote mbili zinapoonekana, swali lililobaki ni la sera na si la kiufundi: ni nafasi zipi za majina zina mali ya shirika, nani anamiliki kila jibu, na zipi kati yao zinapaswa kuondoka kwenye mashine kabisa. Andika hilo kando ya wasifu, kwa sababu mtu anayefuata kugusa kanuni atalihitaji.

Makala zinazohusiana