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'

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

Критерият за успех е слушател, който се появява под документираната си зависимост, а не такъв, който някой е запомнил да рестартира.