OpenVPN DNS останува по SIGKILL: прво проверете го сопственикот

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

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

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

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

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

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

Одлучете кој го поседува резолверот

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

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

VPN управуван од NetworkManager може веќе да ги поседува промените на резолверот. Додавањето втор помошник одозгора создава два сопственици што се натпреваруваат за истата врска, а состојбата на губитникот повторно се појавува при следното повторно поврзување. Ако менаџерот е одговорен, поправете ја поставката во менаџерот, а не во скрипта.

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

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

Ниту една директива не прави куката да се изврши по SIGKILL. Ниту привилегиите не се враќаат со down-pre: ако демонот се спушти до user или group или влезе во chroot, куката работи со пристапот што ѝ го остава тоа. Повикана кука сепак може да не успее да го ажурира резолверот. Референцата за OpenVPN ги покрива сигналите и животниот циклус на повратниот повик.

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

Проверете ја состојбата што навистина останува

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

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

Вратете без да украдете друга врска

Кога поставките по врска се ваши за управување, resolvectl revert го зема името на врската и ја чисти DNS конфигурацијата во време на извршување за тој интерфејс. Тоа е дејство во време на извршување, а не уредување на профил, па постојаната конфигурација на врската останува недопрена. Ако именувате погрешна врска, ќе го избришете DNS-от на тунел што работи, затоа името доаѓа од излезот на статусот.

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