OpenVPN DNS остаје након SIGKILL: прво проверите власника

DNS престаје да разрешава након што се OpenVPN клијент убије, а први порив је преписивање /etc/resolv.conf. Та измена може да поквари исправан resolver док стварно застарело стање седи негде другде. Питање које треба прво решити јесте ко поседује DNS поставке које је тунел инсталирао и да ли је излаз који је прескочио чишћење заиста био важан.

Три услова одлучују поправку: сигнал који је завршио процес, компонента resolver-а која је примила поставке и да ли веза тунела још постоји. Одговорите тим редом и поправка обично следи без дирања глобалне датотеке.

Одлучите какав је излаз наступио

У Community издању OpenVPN, и SIGINT и SIGTERM су захтеви за уредан излаз. SIGKILL не може да се ухвати: не може да се блокира нити обради, па ниједна рутина гашења не добија прилику да се изврши. Обичан Ctrl+C у терминалу у првом плану ствара SIGINT, док надзорник који одустане од чекања обично ескалира на SIGKILL. Разлика је важна јер само други случај гарантује да су куке прескочене.

Рад унутар screen или tmux не мења који сигнал шаље Ctrl+C. Проверите шта је процес заиста примио, а не шта терминал обично ради.

Када тунел покреће сервис или менаџер веза, зауставите ту једну везу кроз њеног власника уместо да убијете pid. Менаџер може поново да подигне процес, остављајући вам нов тунел и збуњујуће стање resolver-а. Самосталном процесу је потребан само обичан захтев за прекид да би се чишћење извршило.

Одлучите ко поседује resolver

systemd-resolved, скрипта у стилу resolvconf и обично преписивање датотеке су три различита власника. Први држи поставке по вези у меморији и одбацује их када интерфејс нестане. Други држи записе који остају док их нешто не уклони. Трећи уписује датотеку и препуста враћање ономе ко ју је уписао.

Идентификујте власника пре него што одаберете наредбу за поправку. Исти симптом има три различита тачна одговора у зависности од тога који је у употреби.

VPN којим управља NetworkManager можда већ поседује промене resolver-а. Додавање другог помоћника поврх тога ствара два власника који се такмиче за исту везу, а стање губитника се враћа при следећем поновном повезивању. Ако је менаџер задужен, поправите поставку у менаџеру, а не у скрипти.

Шта down кука може и не може

Скрипта down се извршава једном након што се TUN/TAP уређај затвори. Додавање down-pre обрће тај редослед и извршава скрипту док уређај још постоји, што захтевају помоћници којима треба жива веза.

Ниједна директива не чини да се кука изврши након SIGKILL. Привилегије се такође не враћају помоћу down-pre: ако се демон спусти на user или group или уђе у chroot, кука ради с оним приступом који јој то остави. Позвана кука ипак може пропустити да ажурира resolver. OpenVPN референца покрива сигнале и животни циклус повратног позива.

Проверите сопствену грешку куке поред излазног статуса процеса. Чишћење које недостаје и чишћење које је пропало изгледају исто у resolver-у, а различито у записима.

Проверите стање које заиста остаје

На систему који користи systemd-resolved, resolvectl status показује која веза још носи VPN DNS сервере или домене рутирања. Та веза може припадати споју ког више нема или другом тунелу који је још подигнут.

Интерфејс који нестане носи са собом своју конфигурацију по вези, па прескочена кука може постојати уз чист DNS. Ако је веза још регистрована и искључиво је поседује заустављени спој, менаџер који је поседује треба да је уклони. Ако је старија скрипта преписала глобалну датотеку resolver-а, тражите уместо тога документовани корак враћања те скрипте.

Опоравите се без отимања друге везе

Када су поставке по вези ваше за управљање, resolvectl revert узима име везе и брише DNS конфигурацију у време извршавања за тај интерфејс. То је радња у време извршавања, а не измена профила, па трајна конфигурација споја остаје нетакнута. Именујте погрешну везу и обрисаћете DNS за тунел који ради, зато име долази из излаза статуса.

Потврдите да је /etc/resolv.conf управљана симболичка веза пре него што је уредите, затим још једном нормално зауставите клијента и поново погледајте DNS. Ако друго заустављање очисти, ранији проблем је био присилни излаз, а не конфигурација.