Access Server втратив прив’язку після перейменування мережевого інтерфейсу: виправте ключі

Ви перейменували мережевий інтерфейс або відновили машину, чий адаптер повернувся під іншим ім’ям, і тепер демон OpenVPN Access Server не запускається. Веб-інтерфейс може ще відповідати або ні, залежно від того, який компонент був прив’язаний до старого імені. Служба не пошкоджена, конфігурація не втрачена; одне налаштування досі вказує на інтерфейс, якого хост уже не має.

Рефлекс — перевстановити, повторно ініціалізувати або редагувати базу даних, доки помилка не зникне. Кожне з цього — зміна більша за саму несправність, а останнє може стерти користувачів, права й залежності, заради яких сервер варто було відновлювати. Це проблема прив’язки, і вона має назване рішення.

Що насправді каже симптом

Демон, який не може прив’язатися, зазвичай повідомляє про це у власному журналі: адреса недоступна або інтерфейсу немає. Повідомлення конкретне: воно називає адресу, яку демон спробував; порівняйте її з ip -br addr на хості, щоб зрозуміти, чи інтерфейс перейменовано, видалено або піднято без старої адреси.

Тримайте авторизовану консоль відновлення відкритою весь час. Якщо прив’язка, яку ви збираєтеся змінити, несе вашу єдину адміністративну сесію, ви відрізали собі шлях назад. Локальна консоль, друга адреса керування або задокументований позасмуговий шлях роблять зміну зворотною.

Запитайте конфігурацію перед її редагуванням

Access Server показує свою конфігурацію через власний CLI. Задокументований вигляд:

sacli ConfigQuery

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

Цей вивід — вигляд конфігурації сервера, а не повна резервна копія. Властивості користувачів і груп запитуються окремо, тож чиста прив’язка не відновлює ідентичності, а відновлена ідентичність не виправляє слухача. Зафіксуйте обидва як два окремі артефакти.

Визначте, який слухач зламаний

Access Server запускає більше одного слухача. Демони OpenVPN несуть трафік тунелю, веб-служба — портал адміністрування й клієнтів, а інші компоненти можуть мати власні порти. Невдалий запит браузера не каже, який із них відмовив, як і номер порту в повідомленні про помилку.

Ключі прив’язки демона задокументовані для кожного демона, і в офіційному посібнику значення — ідентифікатор інтерфейсу, хоча імена ключів закінчуються на ip_address. Прочитайте це речення двічі. Посібник також припускає, що демони UDP і TCP ділять один інтерфейс, тому виправлення лише одного ключа — частковий ремонт.

Змініть назване налаштування, а не відповідні рядки

Посібник документує ConfigPut для конкретних ключів, як-от vpn.daemon.0.server.ip_address і vpn.daemon.0.listen.ip_address. Використовуйте власний метод продукту з іменем ключа й новим значенням, у синтаксисі, задокументованому для вашої версії, і змінюйте лише ключі того слухача, який ви діагностували.

Чого робити не слід — шукати в базі даних усі рядки, значення яких дорівнює старому імені інтерфейсу, і замінювати їх усі. Це припускає, що старе ім’я траплялося лише в налаштуваннях слухача, чого схема не обіцяє. Це також робить зміну неможливою для перевірки.

Варто відкинути ще дві спокуси. Відновлення типового значення, що слухає на всіх інтерфейсах, — рішення про розкриття, а не виправлення правопису; задумана локальна прив’язка, опублікований шлях і фільтрування перед ним мають узгоджуватися з цим вибором. Повторна ініціалізація конфігурації перейменовує проблему замість її вирішення, бо свіже встановлення відкидає саме тих користувачів і права, які працювали до перейменування.

Застосуйте й доведіть, що шлях працює

Після виправлення значення застосуйте його через задокументований життєвий цикл продукту ( життєвий цикл ). Посібник використовує sacli start після встановлення ключів; це не повне перезавантаження хоста й не скидання бази даних.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

Перевірте слухача, потім установіть одне авторизоване з’єднання VPN, досягніть одного приватного ресурсу й відкрийте адміністративну сторінку очікуваним шляхом. Збережіть наявні права й відкликання; відновлення, яке їх скидає, виправило прив’язку й втратило розгортання. Робота завершена, коли та сама служба працює на призначеному інтерфейсі.