DNS-ja e OpenVPN mbetet pas SIGKILL: kontrolloni fillimisht pronarin

DNS-ja ndalon së zgjidhuri pasi një klient OpenVPN vritet, dhe instinkti i parë është të rishkruhet /etc/resolv.conf. Ai ndryshim mund të prishë një resolutor që punon, ndërsa gjendja e vërtetë e vjetëruar ndodhet diku tjetër. Pyetja që duhet zgjidhur fillimisht është kush zotëron cilësimet DNS që instaloi tuneli, dhe nëse dalja që anashkaloi pastrimin kishte vërtet rëndësi.

Tre kushte vendosin riparimin: sinjali që përfundoi procesin, komponenti i resolutorit që mori cilësimet dhe nëse lidhja e tunelit ekziston ende. Përgjigjuni në atë rend dhe korrigjimi zakonisht vjen pa prekur një skedar global.

Vendosni çfarë lloj daljeje ndodhi

Në botimin Community të OpenVPN, si SIGINT ashtu edhe SIGTERM janë kërkesa për dalje të rregullt. SIGKILL nuk mund të kapet: nuk mund të bllokohet ose trajtohet, kështu që asnjë rutinë mbylljeje nuk merr shansin të ekzekutohet. Një Ctrl+C normal në një terminal në plan të parë gjeneron SIGINT, ndërsa një mbikëqyrës që heq dorë nga pritja zakonisht përshkallëzohet në SIGKILL. Diferenca ka rëndësi sepse vetëm rasti i dytë garanton që grepat u anashkaluan.

Ekzekutimi brenda screen ose tmux nuk ndryshon çfarë sinjali dërgon Ctrl+C. Kontrolloni çfarë mori vërtet procesi, jo çfarë bën zakonisht terminali.

Kur një shërbim ose menaxher lidhjesh ekzekuton tunelin, ndaloni pikërisht atë lidhje përmes pronarit të saj në vend që të vrisni pid-in. Një menaxher mund ta ngrejë përsëri procesin, duke ju lënë një tunel të ri dhe një gjendje konfuze të resolutorit. Një proces i pavarur ka nevojë vetëm për një kërkesë normale përfundimi që pastrimi të ekzekutohet.

Vendosni kush zotëron resolutorin

systemd-resolved, një skript në stilin resolvconf dhe një rishkrim i thjeshtë skedari janë tre pronarë të ndryshëm. I pari i mban cilësimet për lidhje në memorie dhe i hedh ato kur ndërfaqja zhduket. I dyti mban regjistrime që vazhdojnë derisa diçka t'i heqë. I treti shkruan një skedar dhe ia lë rikthimin atij që e shkroi.

Identifikoni pronarin përpara se të zgjidhni një komandë riparimi. I njëjti simptom ka tre përgjigje të sakta të ndryshme, në varësi të asaj që përdoret.

Një VPN i menaxhuar nga NetworkManager mund t'i zotërojë tashmë ndryshimet e resolutorit. Shtimi i një ndihmësi të dytë sipër krijon dy pronarë që konkurrojnë për të njëjtën lidhje, dhe gjendja e humbësit rishfaqet në rilidhjen tjetër. Nëse një menaxher është përgjegjës, rregulloni cilësimin në menaxher dhe jo në një skript.

Çfarë mund dhe çfarë nuk mund të bëjë grepi down

Skripti down ekzekutohet një herë pasi pajisja TUN/TAP është mbyllur. Shtimi i down-pre e përmbys atë rend dhe ekzekuton skriptin ndërsa pajisja ekziston ende, gjë që kërkojnë ndihmësit që kanë nevojë për lidhjen e gjallë.

Asnjëra direktivë nuk bën që një grep të ekzekutohet pas SIGKILL. Privilegjet gjithashtu nuk rikthehen nga down-pre: nëse daemoni zbret në një user ose group ose hyn në një chroot, grepi ekzekutohet me aksesin që kjo i lë. Një grep i thirrur mund të dështojë gjithsesi në përditësimin e resolutorit. Referenca e OpenVPN mbulon sinjalet dhe ciklin e jetës së kthimit të thirrjes.

Kontrolloni gabimin e vetë grepit pranë statusit të daljes së procesit. Pastrimi që mungon dhe pastrimi i dështuar duken njësoj në resolutor dhe ndryshe në regjistra.

Kontrolloni gjendjen që mbetet vërtet

Në një sistem që përdor systemd-resolved, resolvectl status tregon cila lidhje ende mbart serverat DNS të VPN-së ose domenet e rrugëzimit. Ajo lidhje mund t'i përkasë një lidhjeje që është zhdukur, ose një tuneli tjetër që është ende lart.

Një ndërfaqe që zhduket merr me vete konfigurimin e saj për lidhje, kështu që një grep i anashkaluar mund të bashkëjetojë me DNS të pastër. Nëse lidhja është ende e regjistruar dhe zotërohet ekskluzivisht nga lidhja e ndalur, menaxheri pronar duhet ta heqë atë. Nëse një skript më i vjetër ka rishkruar një skedar global të resolutorit, kërkoni në vend të kësaj hapin e dokumentuar të rikthimit të atij skripti.

Rikthejuni pa vjedhur një lidhje tjetër

Kur cilësimet për lidhje janë përgjegjësia juaj, resolvectl revert merr emrin e lidhjes dhe pastron konfigurimin DNS në kohë ekzekutimi për atë ndërfaqe. Është veprim në kohë ekzekutimi dhe jo redaktim profili, kështu që konfigurimi i vazhdueshëm i lidhjes mbetet i paprekur. Nëse emërtoni lidhjen e gabuar, pastroni DNS-në e një tuneli që punon, prandaj emri vjen nga dalja e statusit.

Konfirmoni që /etc/resolv.conf është një lidhje simbolike e menaxhuar përpara se ta redaktoni, pastaj ndaloni klientin normalisht edhe një herë dhe shikoni përsëri DNS-në. Nëse ndalimi i dytë pastron, problemi i mëparshëm ishte dalja e detyruar dhe jo konfigurimi.