openfortivpn inaendelea kuandika juu DNS? Pata mmiliki halisi

Fuata muunganisho tangu wakati unapoinuka: mteja anajithibitisha, pppd inajadiliana, kisha kitu kinaandika mipangilio ya DNS kwenye mfumo wa uendeshaji. Ikiwa unajua tu kwamba VPN ilibadilisha kitatuzi chako, bado hujui ni hatua ipi kati ya hizo ilifanya hivyo. Mbili kati yao zinaweza, na kwa mteja anayetumia muunganiko wa pppd ulioandikwa hufanya kazi karibu vya kutosha kuonekana kama mwigizaji mmoja. Kutaja mwandishi ni hatua ya kwanza; kuchagua mbadala wake ni ya pili, na huo ni uamuzi tofauti na mbinu zake za kushindwa.

Mfululizo hapa chini unafuata mteja kuelekea nje: muunganisho ulibadilisha nini, swichi ipi inanyamazisha mwandishi yupi, nani anapaswa kuchukua jukumu, na jinsi ya kuthibitisha kwamba matokeo yanastahimili kuunganishwa upya. Kila hatua huacha alama tofauti, na alama hiyo ndiyo inayokuambia kama uhamishaji ulifanyika kweli.

Anza na kile muunganisho ulibadilisha kwa kweli

Unganisha mara moja kwa amri yako ya kawaida na linganisha utatuzi kabla na baada. Kwenye mwenyeji wa Linux anayeendesha systemd-resolved, resolvectl status huchapisha seva za DNS na vikoa vya utafutaji kwa kila kiungo, na kiungo kipya cha tun au ppp kinachobeba seva zake mwenyewe ni alama ya vidole ya usasishaji kutoka upande wa mteja. Kwenye macOS, scutil --dns huonyesha usanidi wa kitatuzi kwa mpangilio ambao programu huzishauri.

Linganisha hilo na faili uliyotarajia lingebadilika. Kuingia kwa kiungo kwenye mwonekano kwa kila kiungo na /etc/resolv.conf iliyoandikwa upya ni matokeo mawili tofauti, na la pili linaweza kuwa kiungo cha ishara kinachosimamiwa kabisa na kitu kingine. Andika anwani ya kitatuzi, vikoa vya utafutaji na jina la kiolesura kwa wakati mmoja; mabadiliko katika lolote kati yao yanaelekeza kwa mwandishi tofauti. Bila msingi huo, kila marekebisho ya baadaye ni dhana kuhusu sehemu ipi kati ya tatu iliyohama.

Swichi mbili na mwandishi ambaye kila moja inamnyamazisha

openfortivpn huandika kipande cha chaguo kinachozima waandishi wote wawili ambayo inaweza kudhibiti, na kila swichi ina kifani kilichoandikwa kikamilifu ambacho mwongozo huchukulia kama mpangilio huo huo.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns huzuia mteja kutumia seva za DNS alizojifunza kutoka lango, wakati --pppd-no-peerdns huzuia pppd kusukuma DNS ya mwenzake kwenye mfumo. Mwongozo wa upstream unaonya kwamba masasisho ya DNS kupitia PPP yanaweza kushindana na masasisho ya DNS ya mteja mwenyewe, ndiyo sababu swichi zote mbili zinapaswa kuwa kwenye kipande badala ya moja yao kuchukuliwa kuwa ya kutosha.

Hakuna swichi inayotaja kitatuzi mbadala, na hakuna inayozuia msimamizi wa mtandao, mteja wa DHCP au muunganiko tofauti wa VPN kuandika utatuzi baadaye. Kunyamazisha waandishi wawili kunaacha uwanja wazi badala ya umilikiwa. Ikiwa sehemu ya tatu tayari inasimamia DNS, kipande hakibadilishi chochote unachoweza kuona; ikiwa hakuna kinachoisimamia, umeondoa chanzo pekee cha utatuzi wa majina ya faragha. Huu ni mpangilio halali tu wakati mmiliki mbadala alichaguliwa kwanza na kujaribiwa peke yake.

Chagua mmiliki kabla ya kuzima kitu chochote

Kwanza amua nani anajibu maswali ya majina ya kazi, kwa sababu chaguo hilo huzuia kila kitu kinachofuata. Kuweka kitatuzi kilichopo kunamaanisha eneo la faragha lazima liwe tayari kufikiwa kutoka popote mteja alipo, na kitatuzi cha faragha ndani ya ofisi kinahitaji njia inayostahimili tunnel kupanda. Kutuma kila swali kwa huduma moja ya ndani ni sera ya tatu yenye hali ya kushindwa kali zaidi: huduma hiyo isipofikiwa, majina ya umma hushindwa pamoja na ya faragha.

Umiliki wa njia unabaki tofauti kwa makusudi. Chaguo za njia hazihitajiki kwa sababu ulibadilisha DNS, na kuzima usanikishaji wa njia bila kusanikisha mbadala kunaweza kufanya kitatuzi ulichokichagua hivi punde kisiweze kufikiwa. Angalia jedwali la uelekezaji hasa kwa anwani ya kitatuzi, sio tu kwa subneti ya programu uliyojaribu kwa bahati.

Angalia utatuzi kwa kila kiungo, sio kwa kila faili

/etc/resolv.conf moja si orodha ya kile programu hutumia kwa kweli kwenye mwenyeji mwenye utatuzi uliopunguzwa au kwa kila kikoa, kwa hiyo soma hali ya kitatuzi jinsi jukwaa linavyoifichua.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

Uliza jina moja la faragha na jina moja la umma mara muunganisho unapoinuka, na andika ni kiungo kipi kilijibu kila moja. Pale kiungo cha VPN kinapobeba orodha ya utafutaji kwa kila kikoa, jina la faragha linaweza kutatuliwa kwa usahihi wakati jina la umma bado linaenda kwa kitatuzi cha ndani, na mgawanyiko huo ni muundo unaofanya kazi sio hitilafu. Ikiwa swali la faragha linashindwa, kagua njia kuelekea kitatuzi kabla ya kugusa DNS tena; ikiwa linafanikiwa wakati programu bado inashindwa, programu inaweza kuwa inasoma kitatuzi chake kilichohifadhiwa au kilichosanidiwa kando.

Unganisha upya na uthibitishe hali ya kukatwa

Shusha muunganisho na urudie maswali yote mawili. Kile mmiliki aliyechaguliwa alisanikisha anapaswa kuondolewa au kurejeshwa na mmiliki huyo, sio kuachwa na mteja uliyemnyamazisha. Kuingia kwa kila kiungo lililopitwa na wakati linalostahimili tunnel linaendelea kutuma maswali ya faragha kwa anwani isiyoweza kufikiwa tena.

Kisha unganisha upya na soma maadili hayo matatu tena: anwani ya kitatuzi, vikoa vya utafutaji, kiolesura.

Ikiwa yanalingana na sera uliyoandika, uhamishaji umekamilika na mteja wa VPN hayuko tena miongoni mwa waandishi. Ikiwa thamani inarudi nyuma sekunde chache baada ya kiungo kupanda, kitu kingine bado kinatumia usanidi, na hatua inayofuata ni kutambua sehemu hiyo badala ya kuongeza bendera nyingine. Hali ya mwisho unayotaka haina matukio: mmiliki mmoja, sera moja iliyoandikwa, na mwenyeji aliyekatwa anayetatua kwa usahihi kama ilivyokuwa kabla tunnel haijakuwepo.