SSH nie nasłuchuje po restarcie: adres VPN przychodzi za późno

Podczas konfiguracji wiążesz SSH z adresem tunelu, wszystko działa, a po następnym restarcie nikt nie może się zalogować, dopóki ktoś ręcznie nie uruchomi usługi ponownie. Poświadczenia nie są problemem. Demon poprosił jądro o adres, który jeszcze nie istniał, wiązanie nie powiodło się, a komunikat przeleciał w logu rozruchu. To, co wygląda na problem uwierzytelniania, jest problemem kolejności uruchamiania.

Co naprawdę mówi błąd wiązania

Gniazdo nasłuchujące musi zostać utworzone na adresie, który istnieje w danej chwili. Gdy interfejs VPN pojawi się później, demon skonfigurowany do wiązania tylko z adresem tunelu nie ma do czego się przyczepić. Konfiguracja pozostaje poprawna składniowo; środowisko po prostu nie było gotowe. Usługa działająca od ręcznego uruchomienia nigdy nie przechodzi ścieżki rozruchu, dlatego usterka pojawia się dopiero przy następnym restarcie. Porównaj znacznik czasu nieudanego wiązania ze znacznikiem czasu przydziału adresu, a kolejność stanie się oczywista.

Poprawność konfiguracji i gotowość w czasie działania to odrębne właściwości. Przetestuj obie, bo jedna z nich zawodzi bez słowa.

Który proces posiada port

Demon nie zawsze jest komponentem, który tworzy nasłuch. Aktywacja gniazda przenosi tę odpowiedzialność na jednostkę, a wtedy restart demona niczego nie zmienia.

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

Lista gniazd pokazuje, który proces trzyma port i na jakim adresie, natomiast zrzut jednostki pokazuje, czy jednostka gniazda w ogóle istnieje. Gdy aktywacja jest w grze, adres należy do jednostki gniazda, a plik demona nie jest miarodajny. Czytaj log rozruchu, szukając prawdziwego błędu wiązania, zamiast wnioskować go z objawu. Brak jednostki gniazda oznacza po prostu klasyczny układ, w którym demon wiąże się bezpośrednio.

Uczyń gotowość jawną, nie snem

Stałe opóźnienie to zgadywanie, które traktuje szybki sprzęt i wolne sieci jednakowo. Zamiast tego wyraź zależność: poczekaj na adres, potem uruchom.

ip -4 addr show dev tun0
systemctl edit ssh.service

Dodaj polecenie ExecStartPre, które powtarza się, aż adres się pojawi, albo uporządkuj jednostkę po konkretnym celu sieciowym, do którego należy interfejs. Oba podejścia zapisują zależność w miejscu, które następny administrator może przeczytać. Pętla potrzebuje limitu czasu, inaczej nieudany VPN zostawia wiszącą jednostkę zamiast zgłosić usterkę. Następnie potwierdź, że demon wiąże adres tunelu, podczas gdy zwykły interfejs pozostaje pod kontrolą twoich reguł filtrowania.

Przetestuj czysty rozruch i ponowne połączenie

Ręczny restart, gdy wszystko jest online, niczego nie dowodzi o kolejności rozruchu. Zrestartuj maszynę z tunelem skonfigurowanym do automatycznego podnoszenia i obserwuj, czy nasłuch pojawia się bez interwencji.

systemctl status ssh.service
ss -ltnp 'sport = :22'

Następnie zerwij i ponownie ustanów tunel, ponieważ ponowne połączenie może zmienić adres, a twardo zakodowane wiązanie za nim nie podąży. Podczas testów utrzymuj pozapasmową ścieżkę odzyskiwania, aby zła zmiana kolejności nie mogła cię zablokować poza hostem.

Kryterium sukcesu to nasłuch, który pojawia się zgodnie z udokumentowaną zależnością, a nie taki, którego ktoś pamiętał, by zrestartować.