DNS ya OpenVPN inabaki baada ya SIGKILL: kagua mmiliki kwanza

DNS huacha kutatua baada ya mteja wa OpenVPN kuuawa, na mzuka wa kwanza ni kuandika upya /etc/resolv.conf. Badiliko hilo linaweza kuvunja kitatuzi kinachofanya kazi ilhali hali halisi ya zamani iko mahali pengine. Swali la kwanza la kuamuliwa ni nani anamiliki mipangilio ya DNS iliyowekwa na handaki, na kama kutoka kulikoruka usafishaji kuliwa na maana kweli.

Masharti matatu huamua ukarabati: ishara iliyomaliza mchakato, sehemu ya kitatuzi iliyopokea mipangilio, na kama kiungo cha handaki bado kipo. Jibu kwa mpangilio huo na marekebisho kwa kawaida huja bila kugusa faili la jumla.

Amua ni aina gani ya kutoka ilitokea

Katika toleo la Community la OpenVPN, SIGINT na SIGTERM zote ni maombi ya kutoka kwa utulivu. SIGKILL haiwezi kunaswa: haiwezi kuzuiwa wala kushughulikiwa, kwa hivyo hakuna utaratibu wa kuzima unaopata nafasi ya kukimbia. Ctrl+C ya kawaida kwenye terminal ya mbele huzalisha SIGINT, ilhali msimamizi anayeacha kusubiri kwa kawaida hupanda hadi SIGKILL. Tofauti ni muhimu kwa sababu ni kesi ya pili pekee inayohakikisha ndoano zilirukwa.

Kuendesha ndani ya screen au tmux hakubadilishi ishara ambayo Ctrl+C hutuma. Kagua kile mchakato ulipokea kweli, sio kile terminal hufanya kwa kawaida.

Wakati huduma au msimamizi wa miunganisho anaendesha handaki, simamisha muunganisho huo mmoja kupitia mmiliki wake badala ya kuua pid. Msimamizi anaweza kuinua mchakato tena, na ukabaki na handaki mpya na hali ya kitatuzi iliyochanganyika. Mchakato wa kujitegemea unahitaji tu ombi la kawaida la kusimamisha ili usafishaji uende.

Amua nani anamiliki kitatuzi

systemd-resolved, script ya mtindo wa resolvconf na uandikaji upya wa faili rahisi ni wamiliki watatu tofauti. Wa kwanza huweka mipangilio kwa kila kiungo kwenye kumbukumbu na kuiacha wakati kiolesura kinapotea. Wa pili huweka kumbukumbu zinazodumu hadi kitu kuziondoe. Wa tatu huandika faili na kuacha urejeshaji kwa aliyeandika.

Tambua mmiliki kabla ya kuchagua amri ya ukarabati. Dalili hiyo hiyo ina majibu matatu sahihi tofauti kulingana na lipi linalotumika.

VPN inayosimamiwa na NetworkManager inaweza kuwa tayari inamiliki mabadiliko ya kitatuzi. Kuongeza msaidizi wa pili juu yake huunda wamiliki wawili wanaoshindania kiungo kimoja, na hali ya aliyeshindwa inaonekana tena kwenye muunganisho ujao. Ikiwa msimamizi anahusika, rekebisha mpangilio kwenye msimamizi na sio kwenye script.

Ndoano ya down inaweza na haiwezi kufanya nini

Script ya down hukimbia mara moja baada ya kifaa cha TUN/TAP kufungwa. Kuongeza down-pre hugeuza mpangilio huo na kuendesha script wakati kifaa bado kipo, jambo ambalo wasaidizi wanaohitaji kiungo hai hulihitaji.

Hakuna maagizo yanayofanya ndoano ikimbie baada ya SIGKILL. Haki pia hazirejeshwi na down-pre: ikiwa daemon inashuka hadi user au group au inaingia chroot, ndoano hukimbia kwa ufikiaji unaoachwa na hilo. Ndoano iliyoitwa bado inaweza kushindwa kusasisha kitatuzi. Rejeleo la OpenVPN linashughulikia ishara na mzunguko wa maisha wa mwitiko.

Kagua hitilafu ya ndoano yenyewe kando ya hali ya kutoka ya mchakato. Usafishaji unaokosekana na usafishaji ulioshindwa huonekana sawa kwenye kitatuzi na tofauti kwenye kumbukumbu.

Kagua hali iliyobaki kweli

Kwenye mfumo unaotumia systemd-resolved, resolvectl status huonyesha ni kiungo gani bado kinabeba seva za DNS za VPN au vikoa vya uelekezaji. Kiungo hicho kinaweza kuwa cha muunganisho ulioondoka, au handaki lingine ambalo bado liko juu.

Kiolesura kinachopotea hubeba usanidi wake kwa kila kiungo, kwa hivyo ndoano iliyorukwa inaweza kuishi pamoja na DNS safi. Ikiwa kiungo bado kimesajiliwa na kinamilikiwa pekee na muunganisho uliosimamishwa, msimamizi mmiliki anapaswa kukiondoa. Ikiwa script ya zamani iliandika upya faili la kitatuzi la jumla, tafuta badala yake hatua ya urejeshaji iliyoandikwa ya script hiyo.

Rejesha bila kuiba kiungo kingine

Wakati mipangilio kwa kila kiungo ni jukumu lako kusimamia, resolvectl revert huchukua jina la kiungo na kufuta usanidi wa DNS wa wakati wa utekelezaji kwa kiolesura hicho. Ni tendo la wakati wa utekelezaji na sio uhariri wa wasifu, kwa hivyo usanidi endelevu wa muunganisho unabaki bila kuguswa. Ukitaja kiungo kibaya utafuta DNS ya handaki linalofanya kazi, ndiyo sababu jina linatoka kwenye matokeo ya hali.

Kabla ya kuhariri thibitisha kwamba /etc/resolv.conf ni kiungo cha mfano kinachosimamiwa, kisha simamisha mteja kawaida mara moja zaidi na uangalie DNS tena. Ikiwa kusimamisha kwa pili kunasafisha, tatizo la awali lilikuwa kutoka kwa kulazimishwa na sio usanidi.