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'

Затим оборите и поново успоставите тунел, јер поновно повезивање може да промени адресу и тврдо кодирано повезивање неће је следити. Држите ванпојасни пут опоравка током тестирања, да вас лоша промена редоследа не закључа изван хоста.

Критеријум успеха је слушалац који се појављује под својом документованом зависношћу, а не онај који се неко сетио да рестартује.