SSH po reštarte nepočúva: adresa VPN prichádza neskoro

Počas nastavenia naviažete SSH na adresu tunela, funguje to, a po ďalšom reštarte sa nikto nemôže prihlásiť, kým niekto službu nespustí ručne. Prihlasovacie údaje problém nie sú. Démon požiadal jadro o adresu, ktorá ešte neexistovala, naviazanie zlyhalo a správa sa v bootovacom logu len prevalila. Čo vyzerá ako problém s overovaním, je problém s poradím pri spúšťaní.

Čo chybová správa o naviazaní skutočne hovorí

Počúvajúci socket musí byť vytvorený na adrese, ktorá v danom okamihu existuje. Keď sa rozhranie VPN objaví neskôr, démon nakonfigurovaný na naviazanie iba na adresu tunela nemá k čomu prilnúť. Konfigurácia zostáva syntakticky platná; prostredie jednoducho nebolo pripravené. Služba, ktorá beží od ručného spustenia, nikdy neprejde bootovacou cestou, a preto sa chyba prejaví až pri ďalšom reštarte. Porovnajte časovú značku zlyhaného naviazania s časovou značkou pridelenia adresy a poradie bude zrejmé.

Platnosť konfigurácie a pripravenosť za behu sú oddelené vlastnosti. Otestujte oboje, pretože jedno z nich zlyhá bez toho, aby čokoľvek povedalo.

Ktorý proces vlastní port

Démon nie vždy je komponentom, ktorý vytvára poslucháča. Aktivácia socketu presúva túto zodpovednosť na jednotku, a reštart démona potom nič nezmení.

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

Výpis socketov ukazuje, ktorý proces drží port a na akej adrese, zatiaľ čo výpis jednotky ukazuje, či socketová jednotka vôbec existuje. Keď je aktivácia v hre, adresa patrí socketovej jednotke a súbor démona nie je smerodajný. Čítajte bootovací log kvôli skutočnej chybe naviazania, namiesto toho, aby ste ju odvodzovali z príznaku. Chýbajúca socketová jednotka jednoducho znamená klasické usporiadanie, pri ktorom sa démon naväzuje priamo.

Urobte pripravenosť explicitnou, nie spánkom

Pevné oneskorenie je odhad, ktorý zaobchádza s rýchlym hardvérom a pomalými sieťami rovnako. Vyjadrite namiesto toho závislosť: počkajte na adresu a potom spustite.

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

Pridajte príkaz ExecStartPre, ktorý sa opakuje, kým sa adresa neobjaví, alebo zoraďte jednotku za konkrétny sieťový cieľ, ktorému rozhranie patrí. Oba prístupy zaznamenávajú závislosť niekde, kde si ju ďalší správca môže prečítať. Slučka potrebuje časový limit, inak zlyhané VPN zanechá jednotku, ktorá visí, namiesto toho, aby nahlásila poruchu. Potom potvrďte, že démon naväzuje adresu tunela, kým bežné rozhranie zostáva podriadené vašim filtrovacím pravidlám.

Otestujte čistý štart a opätovné pripojenie

Ručný reštart po tom, čo je všetko online, o bootovacom poradí nič nedokazuje. Reštartujte stroj s tunelom nastaveným tak, aby sa zdvihol automaticky, a sledujte, či sa poslucháč objaví bez zásahu.

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

Potom tunel zhoďte a znova vytvorte, pretože opätovné pripojenie môže zmeniť adresu a pevne zakódované naviazanie ju nebude nasledovať. Počas testovania si udržujte mimopásmovú cestu obnovy, aby vás zlá zmena poradia nemohla zamknúť mimo hostiteľa.

Kritériom úspechu je poslucháč, ktorý sa objaví pod svojou zdokumentovanou závislosťou, nie ten, ktorý niekto nezabudol reštartovať.