Kuhariri resolv.conf hakurekebishi DNS baada ya VPN kukatika
Kitatuzi cha handaki kilichokufa kilicho juu ya orodha hugharimu muda mmoja wa kusubiri kwa kila utafutaji. Angalia mmiliki wa faili, rudisha hali ya kiungo na acha kuhariri matokeo yanayotengenezwa.
Unakatisha VPN, ping 1.1.1.1 bado inajibu, na kila utafutaji wa jina huning’inia kabla ukurasa hatimaye kukata tamaa. Kisha cat /etc/resolv.conf unaonyesha seva ya majina ambayo haijawahi kuwepo isipokuwa ndani ya handaki, kwa kawaida ya kwanza kwenye orodha. Kufuta mstari huo kunaonekana kurekebisha kwa dakika kumi hivi, hadi kusimamisha kwa muda, kuzurura kwa Wi-Fi au kuwasha upya kurudishe. Faili uliyohariri si mpangilio; ni taswira ya hali ya kiungo inayomilikiwa na sehemu nyingine.
Kwa nini ingizo moja lililopitwa na wakati hugharimu sekunde kwa kila utafutaji
Kitatuzi cha glibc hupitia orodha ya seva za majina kwa mpangilio na husubiri muda wa kusubiri uishe kabla ya kujaribu inayofuata, na resolv.conf(5) hupunguza orodha hiyo hadi ingizo tatu. Weka kitatuzi cha upande wa handaki kama 10.8.0.1 juu baada ya handaki kuondoka, na kila utafutaji hulipa muda wa kusubiri kabla ya kuanguka kwa seva inayojibu. Ndiyo sababu dalili inaonekana kama muunganisho uliokufa na si kosa la DNS: vivinjari huzuia, hukosa muda na wakati mwingine hutoa anwani iliyohifadhiwa ambayo baadaye inapitwa na wakati.
Hilo pia hueleza kwa nini malalamiko huja kama «intaneti imeharibika». Ping kwa anwani ya IP huthibitisha kuwa kiungo kiko sawa, jambo linalofanya hitilafu ionekane ya programu. Orodha ya vitatuzi ni kitu cha kwanza kusoma na cha mwisho kuhariri.
Hadithi: resolv.conf ni faili ya mipangilio
Uliza njia hiyo ni nini kwa kweli kabla ya kuibadilisha:
ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
Kwenye mwenyeji wa systemd-resolved ni kiungo cha mfano kwa faili ya stub inayoelekeza 127.0.0.53, na seva halisi zinaishi katika hali ya kila kiungo ambayo resolvectl huchapisha. Kwenye mwenyeji wa NetworkManager inaweza kuwa faili ambayo NetworkManager huandika kutoka muunganisho unaotumika. Kwa baadhi ya wateja wa wauzaji ni faili ya kawaida inayoandikwa upya mahali pake wakati wa kuunganisha na, ikiwa huna bahati, kamwe hairejeshwi wakati wa kukatisha. Hizo ni wamiliki watatu tofauti, na kuhariri mbili za kwanza kwa mkono ama hakufanyi kitu au hudumu hadi tukio la mtandao linalofuata.
resolvectl status ni mwonekano unaosema ukweli: seva za DNS kwa kila kiungo, vikoa vya uelekezaji na kama kiungo cha handaki bado kipo. resolvectl query example.com huenda mbali zaidi na kuonyesha ni kiolesura kipi kilijibu. Tumia vyote viwili kabla ya kugusa faili, na kumbuka kwamba kivinjari kilicho na DNS yake salama hupuuza haya yote.
Tafuta mmiliki kabla ya kuhariri chochote
Kwa kawaida sehemu tatu hushindana kwa mpangilio mmoja: systemd-resolved, NetworkManager na kile ambacho mteja wa VPN amesakinisha. Tambua aliye hai kwanza:
systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"
Ikiwa resolved inatumika na kiungo cha mfano kinaelekeza kwenye stub yake, faili ya jumla ni matokeo yanayotengenezwa na uhariri wako ni wa mwonekano tu. Ikiwa NetworkManager inamiliki muunganisho, seva ni za wasifu wa muunganisho, kwa hiyo marekebisho ni mabadiliko ya sifa ya nmcli na si uhariri wa faili. Ikiwa daemon wa mzabuni inaendesha, ni njia yake mwenyewe ya kurejesha tu inayostahimili muunganisho unaofuata.
Safisha hali ya kiungo iliyoachwa na mteja
Mteja aliyeuawa hawezi kuendesha ndoano yake ya kusafisha. SIGKILL haiwezi kunaswa kabisa, wakati SIGINT na SIGTERM zinaweza, kwa hiyo handaki «ililosimama tu» baada ya kuuawa kwa nguvu mara nyingi huacha usajili wa kiolesura na ingizo la kitatuzi vyote mahali pake. Tafuta PID mahususi na utume ishara kwake peke yake:
ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0
Usinyoshe mkono kwa pkill -f vpn au killall vpn kabla ya kusoma orodha kamili ya vinavyolingana. -f hulingana na mstari mzima wa amri, kwa hiyo inaweza kumaliza script ya kufunika, kikao cha kihariri au mchakato usiohusiana ambao njia yake ina mfuatano huo. Kumaliza mchakato usiofaa katikati ya kazi ndiyo njia ambayo tatizo la kitatuzi huja kuwa faili iliyopotea.
resolvectl revert hurudisha usanidi wa DNS wa wakati wa utekelezaji wa kiungo hicho, ambao ni mwembamba kuliko kuwasha upya kitatuzi na mwembamba zaidi kuliko kuhariri faili ya jumla. Ikiwa kiungo cha handaki kimetoweka kabisa, systemctl restart NetworkManager hujenga upya hali ya muunganisho na hiyo ni hatua ambayo nyuzi za chanzo hurudia mara kwa mara. Jihadhari na kidhibiti cha huduma kilicho na Restart=always, kwa sababu kinaweza kumrudisha mteja aliyeuawa na mipangilio yake ya DNS moja kwa moja.
Upande mwingine: DNS iliyosukumwa ambayo haikufika kamwe
Picha ya kioo ya ingizo lililopitwa na wakati ni handaki isiyo na kitatuzi chochote kinachoweza kutumika. Chaguo la DNS kwenye wasifu ni ombi; sehemu inayosimamia muunganisho lazima iikabidhi kwa kitatuzi. Ikiwa kumbukumbu inaonyesha seva ilipokelewa lakini kiungo cha handaki hakibeba mipangilio yoyote ya DNS, kinachokosekana ni muunganisho wa sehemu, si seva.
Jaribu ukabidhaji kwa kuufanya kwa mkono, jambo linalotenganisha «seva ni mbaya» na «hakuna aliyetumia»:
resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.
Kikoa cha uelekezaji kinachonasa kila kitu hutuma kila jina kwa kiungo hicho, ambayo ndiyo inayotakiwa na mteja wa handaki kamili na ambayo DNS iliyogawanywa haipaswi kutumia. Mipangilio hii hutoweka kwenye muunganisho unaofuata. Ili kuifanya kudumu katika NetworkManager, zima DNS ya kiotomatiki, weka seva kwenye muunganisho na uongeze kikoa:
nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."
Kwa handaki ya kampuni inayopaswa kujibu majina ya ndani pekee, orodhesha kanda hizo kwa tilde ya mwanzo badala ya kunasa kila kitu, ili majina ya umma yaendelee kutumia kitatuzi cha ndani.
Suluhisho za muda zinazokuwa usumbufu unaofuata
Kunakili resolv.conf kabla ya kuunganisha na kuirejesha baadaye ni mstari halali katika runbook, na ni suluhisho la muda na si ukarabati. Hushindwa hasa wakati inagharimu, kwa sababu kuanguka au kuwasha upya kwa nguvu hupuuza urejeshaji. Iandike kama suluhisho la muda ili mtu anayefuata asijenge juu yake.
Kuzima systemd-resolved na kuweka seva za umma kwa mkono ni hatua nyingine maarufu. Huifanya kuunganisha na kukatisha kuweza kutabirika na huondoa DNS ya kila kiungo kwa kila mtandao mwingine, jambo linalovunja DNS iliyogawanywa kwa majina ya ndani na kuharibu madhumuni ya handaki iliyokusudiwa kuweka maswali ndani yake. Kusakinisha resolvconf na kufunga seva za umma hugharimu sawa na tabaka la ziada. Chukua yoyote kati yao kama uchunguzi: ikiwa inarejesha kuvinjari, umejifunza kwamba muunganisho wa kitatuzi ndio wenye kosa, si kwamba seva za umma ni sahihi.
Ukarabati wa kudumu ni mmiliki mmoja kwa kila tabaka: amua ni sehemu ipi inamiliki DNS ya kiungo cha handaki na ipi inamiliki chaguo-msingi la jumla, andika hilo na uondoe nyingine kwenye njia. Kisha thibitisha baada ya kukatisha kwa jina ambalo VPN pekee hutatua. Ikiwa jina la faragha bado linajibu, usajili haukuondolewa; ikiwa hakuna kinachotatuliwa, faili inaelekeza kwa seva ambayo haipo tena. Vyote viwili vinaonekana katika resolvectl kabla ya kufungua kivinjari.