Стартирането на OpenVPN преди мрежата да е готова не е отказ

Стартирате клиента при зареждане, unit-ът съобщава, че е активен, а тунелът липсва. Естественият извод е, че услугата не е стартирала, а естествената поправка е да я стартирате отново. И двете са достатъчно често грешни, за да си струва правило: работещ клиент, който повтаря опити, изглежда отвън точно като счупен. Разликата е в това какво прави процесът, а не в състоянието на unit-а.

Мит: стартирала услуга означава работещ тунел

Активният unit доказва, че процесът е стартиран и не е приключил. Той не доказва, че профилът е зареден, сертификатът е приет или отсрещната страна е отговорила. Пакетиран клиент може да стои в цикъл на повторни опити с минути, докато systemd съобщава само успех. Тази разлика между състояние и поведение е целият предмет.

Обратният случай е също толкова чест. Процесът може да е приключил, след като не е успял да прочете ключ, и тогава unit-ът съобщава състояние на отказ, което не казва нищо за причината. И двете състояния се различават само по журнала.

Четете журнала за инстанцията, а не състоянието на unit-а. Редът с причината е в журнала, не в етикета на състоянието.

Мит: настройките за повторни опити покриват всеки отказ

Разрешаването на имена и транспортните повторни опити са отделни контроли с отделни стойности по подразбиране. resolv-retry управлява повторните търсения на отдалечено име на хост и документираната стойност по подразбиране продължава да опитва безкрайно. connect-retry задава интервала между опитите, а connect-retry-max може да ограничи колко пъти се прави опит за всеки отдалечен запис. Проверете кой етап назовава журналът, преди да променяте някоя от тях.

Нищо от това не се отнася за повреден профил, нечетим частен ключ или отказан акаунт. Те се нуждаят от поправка и клиент, който продължава да опитва, не напредва.

Безкрайното повтаряне на опити с неодобрен сертификат не е причина да премахнете проверката. Това е причина да прочетете грешката.

Мит: един стартер е достатъчен, затова добавете още един

Връзка, която вече се управлява от NetworkManager или пакетиран unit, не се нуждае от втори стартер, прикачен към нея. Два процеса, които се състезават за едни и същи маршрути, създават дублирани интерфейси, объркващи журнали и тунел, който трепти по причини, които никой не вижда. Второто копие обикновено идва като заобиколно решение, защото първото е бавно.

Решете кой компонент притежава тунела преди да добавите каквото и да е. След това премахнете другия стартер, вместо да го изключвате и да се надявате.

Собственикът определя и откъде идват повторните опити и идентификационните данни, затова това решение предхожда всяка настройка. Собствеността е първа именно поради тази причина.

Какво наистина се нуждае от подредба

Подредбата може да изчака конфигуриран адрес и това е всичко, което гарантира. network-online.target отлага активирането, докато мениджърът сметне мрежата за готова, а определението за готова зависи от мениджъра. Той не казва нищо за това дали името на VPN се разрешава, дали слушателят отговаря или дали пленен портал е пуснал устройството.

Прочетете инсталирания unit и всички drop-in файлове, преди да добавяте зависимости. Широк After= за всяка мрежова услуга отлага зареждането, без да установява връзката, която всъщност ви трябва.

Подредете зависимостта, която можете да тествате, а всичко останало проверявайте с проверка за готовност. Проверка, която отваря тунела, е по-добра от таймер, който гадае.

Какво се случва, след като тунелът се вдигне за първи път

Зареждането е едно събитие сред много. Каналът за достъп се сменя, сесия на портал изтича, партньорът се рестартира. Разграничавайте вътрешното повторно свързване от изход на процеса, който мениджърът на услуги обработва, защото двете имат различни собственици и оставят различни доказателства.

Интерактивното удостоверяване ограничава необслужваното възстановяване. Фоновият unit не отключва ключодържател на работен плот и не отговаря на MFA заявка, затова следвайте одобрената схема за идентификационни данни за контекста на услугата.

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