Az SSH nem figyel újraindítás után: a VPN-cím késik

A beállítás során az SSH-t az alagút címéhez köti, működik, és a következő újraindítás után senki sem tud bejelentkezni, amíg valaki kézzel újra nem indítja a szolgáltatást. A hitelesítő adatok nem a probléma. A démon olyan címet kért a kerneltől, amely még nem létezett, a kötés meghiúsult, és az üzenet elsuhant a rendszerindítási naplóban. Ami hitelesítési problémának tűnik, az valójában indítási sorrendprobléma.

Mit mond valójában a kötési hiba

Egy figyelő socketet olyan címen kell létrehozni, amely abban a pillanatban létezik. Amikor a VPN-interfész később megjelenik, a csak az alagútcímhez kötődni beállított démonnak nincs mihez csatlakoznia. A konfiguráció szintaktikailag érvényes marad; a környezet egyszerűen nem volt kész. Egy szolgáltatás, amely kézi indítás óta fut, soha nem járja be az indítási útvonalat, ezért a hiba csak a következő újraindításnál jelenik meg. Hasonlítsa össze a sikertelen kötés időbélyegét a címkiosztás időbélyegével, és a sorrend nyilvánvalóvá válik.

A konfiguráció érvényessége és a futásidejű készenlét külön tulajdonságok. Tesztelje mindkettőt, mert az egyik szótlanul meghiúsul.

Melyik folyamat birtokolja a portot

A démon nem mindig az az összetevő, amely a figyelőt létrehozza. A socket-aktiválás ezt a felelősséget egy egységre helyezi át, és akkor a démon újraindítása semmit sem változtat.

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

A socketlista megmutatja, melyik folyamat tartja a portot és melyik címen, míg az egység kiírása megmutatja, létezik-e egyáltalán socket-egység. Amikor az aktiválás szerepet játszik, a cím a socket-egységhez tartozik, és a démon fájlja nem mérvadó. Olvassa a rendszerindítási naplót a valódi kötési hibáért, ahelyett hogy a tünetből következtetne rá. A hiányzó socket-egység egyszerűen a klasszikus elrendezést jelenti, ahol a démon közvetlenül kötődik.

Tegye készenlétét explicitté, ne alvássá

A fix késleltetés olyan találgatás, amely a gyors hardvert és a lassú hálózatot egyformán kezeli. Fejezze ki inkább a függőséget: várjon a címre, aztán indítson.

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

Adjon hozzá egy ExecStartPre parancsot, amely ismétlődik, amíg a cím meg nem jelenik, vagy rendezze az egységet az interfészt birtokló adott hálózati cél után. Mindkét megközelítés olyan helyen rögzíti a függőséget, ahol a következő rendszergazda elolvashatja. A huroknak időtúllépésre van szüksége, különben egy meghiúsult VPN lefagyott egységet hagy maga után a hiba jelentése helyett. Ezután erősítse meg, hogy a démon az alagút címéhez kötődik, miközben a közönséges interfész a szűrőszabályai alatt marad.

Teszteljen tiszta indítást és újracsatlakozást

A kézi újraindítás, miután minden online, semmit sem bizonyít az indítási sorrendről. Indítsa újra a gépet úgy, hogy az alagút automatikusan feljöjjön, és figyelje, megjelenik-e a figyelő beavatkozás nélkül.

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

Ezután bontsa le és állítsa helyre az alagutat, mert az újracsatlakozás megváltoztathatja a címet, és egy mereven kódolt kötés nem fogja követni. Tesztelés közben tartson fenn sávon kívüli helyreállítási útvonalat, hogy egy rossz sorrendváltozás ne zárhassa ki a gazdagépről.

A siker kritériuma egy figyelő, amely a dokumentált függősége alatt jelenik meg, nem pedig az, amelynek újraindítására valaki emlékezett.