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'

Затем сбросьте и заново установите туннель, потому что переподключение может изменить адрес, и жёстко закодированная привязка за ним не последует. Во время тестирования держите резервный путь восстановления вне полосы, чтобы неудачное изменение порядка не заперло вас вне хоста.

Критерий успеха — слушатель, появляющийся в соответствии с задокументированной зависимостью, а не тот, который кто-то вспомнил перезапустить.