DNS на OpenVPN остава след 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. Ако второто спиране почисти, по-ранният проблем е бил принудителният изход, а не конфигурацията.