Неуспешно локално повезивање OpenVPN при покретању: чекање или поновни покушај

За OpenVPN сервер који се не покрене при подизању система нуде се два решења: сачекати адресу или пустити сервис да покушава док повезивање не успе. Оба решавају исти симптом, али се различито понашају у случају неуспеха. Чекање кодира одређени предуслов и гласно пада када га нема; понављање покушаја крије предуслов и наставља да покушава. Које од њих припада вашој јединици зависи од тога да ли је адреса пројектована зависност или случајност тајминга.

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

Шта опција local заправо захтева

local именује адресу на коју демон везује свој сокет, а повезивање на адресу која још не постоји одмах пада са грешком о затраженој адреси. Када опције нема, демон слуша на свим адресама, због чега исти профил ради на машини чији интерфејс још није подигнут: слуша свуда уместо на једној адреси коју сте навели. Та разлика је цео отказ и остаје невидљива до поновног подизања.

Захтев није да је интерфејс подигнут у неком општем смислу. Адреса мора бити додељена правом интерфејсу у тренутку повезивања и мора бити основни интерфејс, а не тунел који би исти демон направио касније. Провера извршена неколико минута после пријаве не доказује ништа о редоследу подизања.

Чекање адресе наспрам поновног покушаја повезивања

Чекање значи ExecStartPre који испитује док се адреса не појави, са ограниченим бројем покушаја и ненултим излазом када време истекне. Понављање значи пустити главни процес да падне и затражити од менаџера сервиса да га поново покрене, на пример Restart=on-failure са RestartSec=5. Прво пријављује недостајући предуслов као неуспешну јединицу, док друго то пријављује као низ поновљених покретања који се на крају заустави; у журналу је бучније, али преживљава адресу која стигне касно из разлога које не можете предвидети.

Преферирајте чекање када је адреса пројектована зависност, а понављање покушаја када се адреса обично појави, али њено време варира. Комбинација оба је разумна: ограничено чекање покрива уобичајен случај, а политика поновног покретања изузетак. Ни једно не би требало да ради заувек, јер јединица која покушава неограничено крије погрешну конфигурацију уместо да је пријави.

Зашто network-online.target није довољан

network-online.target обећава тачно оно што активна имплементација мреже подразумева под online, и ништа више. Са systemd-networkd, systemd-networkd-wait-online одлучује када је тај циљ достигнут, а његово подразумевано схватање online стања може бити испуњено пре него што ваша конкретна адреса постоји. Под NetworkManager-ом, сервис wait-online примењује сопствена правила. Редослед после циља је добар темељ, а не гаранција да су једна адреса, DNS одговор или удаљени peer спремни.

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

Проверите повезивање после хладног подизања

Проверите правим хладним подизањем, а не поновним покретањем сервиса, јер поновно покретање наслеђује адресу коју је редослед подизања морао да створи. После подизања, ss -lntp или ss -lunp показује локалну адресу на коју се сваки слушалац стварно повезао, а journalctl -b -u openvpn-server@server показује да ли је први покушај пао. Упоредите повезану адресу са оном у профилу, па поновите поређење после поновног повезивања мреже.

Ако профилу никада није била потребна фиксна адреса, уклањање local је легитимно поједностављење, али нека то буде безбедносна одлука, а не дијагностичка навика.

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