Шта persist-tun и persist-key заиста преживљавају у OpenVPN-у
Обе опције покривају меки ресет унутар живог процеса. Не задржавају интерфејс након заустављања и нису политика блокирања саобраћаја.
Заустављање сервиса уклања интерфејс чак и са постављеним persist-tun. То је опција која ради како је документовано, а не квар. Опција описује једну путању рестарта унутар покренутог процеса, а systemctl stop није та путања.
Прочитајте два имена заједно и дизајн постаје јасан. Једно држи дескриптор, друго држи материјал кључа, и обоје постоје због онога што се дешава након одбацивања привилегија.
Два ресурса и ресет којем припадају
OpenVPN сигнализира сопствени рестарт у две уобичајене ситуације. Експлицитни SIGUSR1 то чини, а ping-restart који покрене мртав партнер чини исто. Оба остављају процес живим и поново покрећу подешавање везе, и ту опције заслужују своје место.
| Event | TUN/TAP device | Key and auth files | Addresses and routes | up/down hooks |
|---|---|---|---|---|
Soft reset, from SIGUSR1 or from a ping-restart the daemon sends itself | survives only with persist-tun | survive only with persist-key | survive with the device, otherwise rebuilt | run again only when restart hooks are enabled |
Configuration reload, SIGHUP | recreated | re-read from disk | rebuilt once the device returns | run again |
| Service stop | lost | re-read at the next start | removed | run 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
Ако је захтев да саобраћај никада не изађе изван тунела, задржани уређај то не испоручује. Руте за другу породицу адреса, друга подразумевана рута и случај када процес потпуно изађе остају изван домашаја опције.
Третирајте два захтева одвојено. Задржавање објекта тунела кроз поновна повезивања погодност је за демон. Блокирање излаза када је тунел пао је firewall политика са својим правилима и својим тестом. Мешање тога даје конфигурацију која изгледа одбрамбено, а понаша се као поновно повезивање по најбољој могућности.
Именујте догађај пре него што га дијагностикујете. Меки ресет, неуспели покушај повезивања и заустављање сервиса три су догађаја са три понашања, а само је први оно што ове опције описују.