Muunganisho upi unajibu: vikoa vya uelekezaji kwa DNS ya VPN yenye handaki lililogawanywa

Weka uvinjari wa kawaida kwenye muunganisho wa ndani wakati majina ya kampuni yanatatuliwa kupitia seva ya DNS ambayo handaki hutoa. Kuzima njia chaguo-msingi ya VPN hukupa nusu ya kwanza na kuacha nusu ya pili bila kujengwa. Kinachofuata ni mpangilio unaokosekana, alama ya uakifishaji inayobadilisha maana yake, na amri moja tu inayoonyesha muunganisho upi ulijibu kwa hakika. NetworkManager na systemd-resolved huchukuliwa kote maandishi, kwa sababu jozi hiyo ndiyo mahali ambapo mkanganyiko kawaida huanza.

Hatua ya kwanza: tenga njia na kitatuzi

ipv4.never-default hujibu swali la uelekezaji na huzuia NetworkManager kusanidi muunganisho huu kama njia ya trafiki yote ya IPv4. Kikoa cha uelekezaji DNS hujibu swali lingine: seva za majina za muunganisho upi hupokea swali kwa kiambishi kinacholingana. Hakuna kinachodokeza kingine, na wasifu unaweza kubeba kimoja kwa miaka huku kingine kikikosekana. Njia pekee humaanisha kuwa handaki hubeba mitandao ndogo ya kampuni na kitatuzi chake hujibu majina ya kampuni, huku kila kitu kingine kikiachwa bila kuguswa.

Weka sifa ya njia pekee na majina ya ndani yatashindwa, kwa kawaida kwa muda wa kusubiri unaosikika kama handaki lililovunjika. Weka kikoa pekee na umeongeza kwa utulivu kiambishi cha utafutaji kwa kila jina fupi kwenye mashine. Makosa yote mawili hutuma tikiti kwa seva ya VPN, ambayo mara chache ndiyo sehemu iliyo makosa.

Hatua ya pili: ongeza kikoa cha uelekezaji pekee kwenye wasifu

Tuseme muunganisho unaitwa corp-vpn, kiambishi cha kampuni ni internal.example, na kitatuzi cha handaki tayari kinaweza kufikiwa. Soma thamani za sasa kwanza, kwa sababu amri hapa chini hubadilisha sifa ambazo huenda zina maingizo tayari.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Badilisha na jina lako la muunganisho na kiambishi chako, kwa sababu thamani zilizo juu ni mifano. Alama ya kujumlisha ni muhimu zaidi kuliko inavyoonekana: nayo thamani huongezwa kwenye orodha iliyopo, na bila hiyo sifa hubadilishwa na vikoa visivyohusiana hupotea kutoka wasifu uliofanya kazi jana. Tilde hubadilisha tabia na si mtindo, na aya hapa chini inaeleza kinachochaguliwa. Weka usomaji kabla ya uandishi, ili umbo la ubadilishaji lisikushangaze kamwe.

Tilde ya mwanzo huashiria kikoa cha uelekezaji pekee, kwa hivyo maswali yanayolingana huenda kwa seva za muunganisho huu na kiambishi hakiunganishwi na majina mafupi. Ondoa tilde na mfuatano huo huo unakuwa pia kiambishi cha utafutaji, matokeo tofauti ambayo watu mara chache hukusudia. Mipangilio yote mawili iliyo juu ni IPv4, kwa hivyo wasifu wa safu mbili unahitaji ipv6.never-default na kikoa hicho cha uelekezaji katika ipv6.dns-search, vinginevyo upande wa IPv6 unaendelea kutumia njia chaguo-msingi na majina ya ndani hushindwa huko.

Hatua ya tatu: muulize resolvectl muunganisho upi ulijibu

Endesha resolvectl status na usome seva za DNS na vikoa vya kila muunganisho, kisha endesha resolvectl query host.internal.example dhidi ya jina halisi la ndani unaloruhusiwa kuuliza. Amri ya pili ni ushahidi pekee wa moja kwa moja kwamba kikoa cha uelekezaji kinafanya kazi yake, kwa sababu hutaja muunganisho uliojibu. Orodha ya hali pekee huthibitisha usanidi; swali huthibitisha utatuzi.

systemd-resolved huchagua kikoa cha uelekezaji kinacholingana zaidi, kwa hivyo kikoa mahususi zaidi kwenye muunganisho mwingine bado kinaweza kushinda mbio. Ikiwa swali linarudi kutoka muunganisho usiokutarajia, soma orodha za vikoa kabla ya kugusa seva ya DNS ya VPN. Kikoa cha mzizi ~. hulingana na kila kitu, na ikiwa tayari kipo kikoa chako mahususi bado kinashinda kwa majina yake huku muunganisho ukijibu mengi zaidi ya uliyoomba. Ondoa au finya ingizo hilo la mzizi wakati lengo lilikuwa majina ya kampuni pekee.

Ikiwa muunganisho wa VPN hauorodheshi seva yoyote ya DNS, mteja hakuwahi kusajili moja. Kikoa cha uelekezaji bila seva nyuma yake hushindwa tofauti na kikoa kinachokosekana, kwa hivyo rekebisha usajili kwanza.

Hatua ya nne: jina linatatuliwa lakini huduma haifanyi kazi

Jibu sahihi huthibitisha tu kwamba utatuzi ulifanya kazi, na programu bado inahitaji njia kuelekea anwani iliyoipokea. Njia hiyo lazima idumu kupitia njia chaguo-msingi iliyogawanywa uliyosanidi sasa, kwa hivyo iangalie kabla ya kulaumu DNS tena. Kisha angalia ufikivu kwenye bandari ya huduma, kwa sababu kushiriki faili au huduma ya saraka hushindwa katika utatuzi, uelekezaji au uthibitishaji na hutoa ujumbe unaofanana sana katika kila kisa. Weka tabaka hizo tatu tofauti unaporipoti matokeo, vinginevyo mtu anayefuata hukagua tena DNS iliyokuwa sahihi tayari.

Mabadiliko ya Samba yanayozunguka pamoja na swali hili yanahusu tabaka la ufikiaji, si uchaguzi wa DNS. Kuyatumia kwa hitilafu ya utatuzi wa majina ndiyo njia ambayo tatizo dogo hupata la pili.

Hatua ya tano: usibadilishe kitatuzi ili kurekebisha kikoa kinachokosekana

Ushauri unaoandika juu ya faili ya kitatuzi au kusakinisha msimamizi mwingine wa kitatuzi hutatua tatizo lingine. Hizo ni mabadiliko ya muunganiko wa mfumo yenye hali zake za kushindwa, na hakuna hata moja inayoongeza kikoa cha uelekezaji ambacho hakikuwahi kusanidiwa. Tambua ni sehemu ipi inayomiliki utatuzi wa majina kwenye mashine kabla ya kuibadilisha, kwa sababu kwenye desktop ya NetworkManager yenye systemd-resolved umiliki huo umeelezwa tayari. Kupigana nao ndiyo njia ambayo usanidi unaofanya kazi unakuwa kitu ambacho hakuna mtu anayeweza kukizalisha tena.

Mpangilio wa kazi: thibitisha kuwa handaki hutoa kitatuzi, ongeza kikoa cha uelekezaji pekee, unganisha tena kupitia vidhibiti vya wasifu, thibitisha muunganisho unaojibu, kisha jaribu huduma kwenye bandari yake. Mpangilio huo huacha matokeo unayoweza kumkabidhi mtu anayefuata bila mahojiano ya pili.