SSH не слухає після перезавантаження: адреса VPN приходить пізно

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

Що насправді каже помилка прив'язки

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

Коректність конфігурації та готовність під час роботи — різні властивості. Перевірте обидві, бо одна з них відмовляє мовчки.

Який процес володіє портом

Демон не завжди є тим компонентом, що створює слухач. Активація сокета передає цю відповідальність юніту, і тоді перезапуск демона нічого не змінює.

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

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

Зробіть готовність явною, а не сном

Фіксована затримка — це здогад, який однаково поводиться зі швидким обладнанням і повільними мережами. Натомість висловіть залежність: дочекайтеся адреси, потім запускайте.

ip -4 addr show dev tun0
systemctl edit ssh.service

Додайте команду ExecStartPre, яка повторюється, доки не з'явиться адреса, або впорядкуйте юніт після конкретної мережевої цілі, якій належить інтерфейс. Обидва підходи фіксують залежність там, де наступний адміністратор зможе її прочитати. Циклу потрібен тайм-аут, інакше невдалий VPN залишить юніт, що зависає, замість повідомлення про збій. Потім переконайтеся, що демон прив'язує адресу тунелю, а звичайний інтерфейс залишається під керуванням ваших правил фільтрації.

Перевірте чисте завантаження та повторне підключення

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

systemctl status ssh.service
ss -ltnp 'sport = :22'

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

Критерій успіху — слухач, що з'являється відповідно до задокументованої залежності, а не той, який хтось згадав перезапустити.