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'

Затым скіньце і зноў усталюйце тунель, бо перападключэнне можа змяніць адрас, і жорстка запраграмаваная прывязка не пойдзе за ім. Трымайце пазапалосны шлях аднаўлення падчас тэставання, каб дрэннае змяненне парадку не адрэзала вам доступ да хоста.

Крытэр поспеху — слухач, які з'яўляецца пад сваёй дакументаванай залежнасцю, а не той, які хтосьці ўспомніў перазапусціць.