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 отговор или отдалечен партньор е готов.

Същото разсъждение изключва обичайните алтернативи. Запис за автоматично стартиране на работен плот чака потребителска сесия, която на сървър може никога да не се отвори, а отложена команда cron добавя изминало време, без да назовава ресурса, на чието появяване е разчитала. И двете могат да изглеждат успешни с месеци и после да се провалят при единственото зареждане, което има значение.

Проверете свързването след студено зареждане

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

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

Разширяването на слушателя променя кой може да го достигне, затова съчетайте тази промяна с политиката на защитната стена, която е трябвало да го ограничава. Услуга, която стартира надеждно на всеки интерфейс, не е решила първоначалния проблем; тя е преместила проблема към ръба на мрежата.