OpenVPN: локалното поврзување не успева при подигање — да се чека или да се обиде повторно

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

Двете се подобри од фиксно спиење, кое ниту чека нешто ниту известува што чекало.

Што всушност бара опцијата local

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

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

Чекање на адресата наспроти повторно поврзување

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

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

Зошто network-online.target не е доволен

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

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

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

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

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

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