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'

Потоа спуштете го и повторно воспоставете го тунелот, бидејќи повторното поврзување може да ја смени адресата и цврсто кодираното врзување нема да ја следи. За време на тестирањето одржувајте вонпојасен пат за враќање, за да не ве заклучи лоша промена на редоследот од домаќинот.

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