SSH po restartu neposlouchá: adresa VPN přichází pozdě

Během nastavení navážete SSH na adresu tunelu, funguje to, a po dalším restartu se nikdo nemůže přihlásit, dokud někdo službu nespustí ručně. Přihlašovací údaje problém nejsou. Démon požádal jádro o adresu, která ještě neexistovala, navázání selhalo a zpráva se v bootovacím logu jen převalila. Co vypadá jako problém s ověřováním, je problém s pořadím při spouštění.

Co chybová zpráva o navázání skutečně říká

Naslouchající socket musí být vytvořen na adrese, která v daném okamžiku existuje. Když se rozhraní VPN objeví později, démon nakonfigurovaný k navázání pouze na adresu tunelu nemá k čemu přilnout. Konfigurace zůstává syntakticky platná; prostředí prostě nebylo připravené. Služba, která běží od ručního spuštění, nikdy neprojde bootovací cestou, a proto se závada projeví až při dalším restartu. Porovnejte časovou značku selhání navázání s časovou značkou přidělení adresy a pořadí bude zřejmé.

Platnost konfigurace a připravenost za běhu jsou oddělené vlastnosti. Otestujte obojí, protože jedno z nich selhává, aniž by cokoli řeklo.

Který proces vlastní port

Démon není vždy komponentou, která vytváří posluchače. Aktivace socketu přesouvá tuto odpovědnost na jednotku, a restart démona pak nic nezmění.

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

Výpis socketů ukazuje, který proces drží port a na jaké adrese, zatímco výpis jednotky ukazuje, zda jednotka socketu vůbec existuje. Když je aktivace ve hře, adresa patří jednotce socketu a soubor démona není směrodatný. Čtěte bootovací log kvůli skutečné chybě navázání, místo abyste ji odvozovali z příznaku. Chybějící jednotka socketu prostě znamená klasické uspořádání, kdy se démon navazuje přímo.

Udělejte připravenost explicitní, ne spánek

Pevné zpoždění je odhad, který zachází s rychlým hardwarem a pomalými sítěmi stejně. Vyjádřete závislost místo toho: počkejte na adresu a pak spusťte.

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

Přidejte příkaz ExecStartPre, který se opakuje, dokud se adresa neobjeví, nebo seřaďte jednotku za konkrétní síťový cíl, kterému rozhraní patří. Oba přístupy zaznamenávají závislost někam, kde si ji další správce může přečíst. Smyčka potřebuje časový limit, jinak selhané VPN zanechá jednotku, která visí, místo aby nahlásila závadu. Potom potvrďte, že démon navazuje adresu tunelu, zatímco běžné rozhraní zůstává podřízeno vašim filtrovacím pravidlům.

Otestujte čisté zavedení a opětovné připojení

Ruční restart poté, co je vše online, o bootovacím pořadí nic nedokazuje. Restartujte stroj s tunelem nastaveným tak, aby se zvedl automaticky, a sledujte, zda se posluchač objeví bez zásahu.

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

Potom tunel shodte a znovu vytvořte, protože opětovné připojení může změnit adresu a pevně zakódované navázání ji nebude následovat. Během testování si udržujte mimopásmovou cestu pro obnovu, aby vás špatná změna pořadí nemohla zamknout mimo hostitele.

Kritériem úspěchu je posluchač, který se objeví pod svou zdokumentovanou závislostí, ne ten, který někdo nezapomněl restartovat.