Запирањето на услугата го отстранува интерфејсот дури и со поставено persist-tun. Тоа е опцијата што работи како документирано, а не дефект. Опцијата опишува една патека на рестартирање во процес што работи, и systemctl stop не е таа патека.

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

Двата ресурса и рестартот на кој му припаѓаат

OpenVPN го сигнализира сопствениот рестарт во две вообичаени ситуации. Експлицитно SIGUSR1 го прави тоа, а ping-restart предизвикан од мртов партнер го прави истото. Двете го оставаат процесот жив и повторно го извршуваат поставувањето на врската, и токму таму опциите го заслужуваат своето место.

EventTUN/TAP deviceKey and auth filesAddresses and routesup/down hooks
Soft reset, from SIGUSR1 or from a ping-restart the daemon sends itselfsurvives only with persist-tunsurvive only with persist-keysurvive with the device, otherwise rebuiltrun again only when restart hooks are enabled
Configuration reload, SIGHUPrecreatedre-read from diskrebuilt once the device returnsrun again
Service stoplostre-read at the next startremovedrun at the next start

Само редот на мекиот рестарт е она што овие две опции го менуваат, а работата што ја прескокнуваат е скапиот дел на зафатена врска. Повторното отворање на уред ги крши адресите и рутите прикачени на него, а нивното повторно градење може да исфрли пакети што биле на пат кога започнал рестартот. Запирањето ги уништува истите објекти без никаква опција да ги зачува.

Зошто овие опции воопшто постојат

Зацврстен OpenVPN сервер обично започнува како root, ги отвора своите клучеви и уредот, потоа преминува на корисник без привилегии. По тој премин некои операции едноставно исчезнуваат. Читањето клучна датотека со режим 0600, создавањето мрежен интерфејс или менувањето рути може да бидат одбиени.

Без persist опциите, партнер што молчи доволно долго за да предизвика ping-restart би ги принудил токму тие операции. Повторното поврзување би пропаднало иако ништо во конфигурацијата не се сменило. Процесот би изгледал како да умира без причина, а дневникот би покажал грешка со дозволи наместо мрежна грешка.

Со нив, мекиот рестарт повторно го користи тоа што привилегираната фаза веќе го добила. Нема магија и процесот не преживува ништо. Набавката на ресурси едноставно се одложува.

Читајте ја првата грешка, не последната

Кога рестартот не успева, читајте ја првата грешка наместо последната. Заштитен клуч, auth датотека, ioctl на интерфејс и надворешна кука се четири различни ресурси. Задржувањето на еден не кажува ништо за пристапот до другите. Кука што повикува алатка за огнена брана сѐ уште ги бара привилегиите што таа алатка ги бара.

Куките имаат свој прекинувач. Прирачникот на OpenVPN ги поврзува persist опциите со up-restart, кој одлучува дали скриптите up и down повторно ќе се извршат по рестарт. Затоа интерфејс што останал подигнат не ви кажува ништо за тоа дали вашата resolver интеграција се освежила.

# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'

# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0

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

Задржаниот интерфејс не е kill switch

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

Третирајте ги двете барања одделно. Задржувањето на објектот на тунелот меѓу повторни поврзувања е погодност за демонот. Блокирањето на излезот кога тунелот е исклучен е политика на огнена брана со свои правила и свој тест. Нивното мешање дава конфигурација што изгледа одбранбено, а се однесува како повторно поврзување со најдобар напор.

Именувајте го настанот пред да го дијагностицирате. Мекиот рестарт, неуспешниот обид за поврзување и запирањето на услугата се три настани со три однесувања, и само првиот е она што овие опции го опишуваат.

Поврзани статии