SSH ei kuula pärast taaskäivitust: VPN-i aadress jõuab hilja

Seote SSH seadistamise ajal tunneliaadressiga, see töötab, ja pärast järgmist taaskäivitust ei saa keegi sisse logida enne, kui keegi teenuse käsitsi taaskäivitab. Volitused ei ole probleem. Deemon küsis kerneli käest aadressi, mida veel ei olnud, sidumine ebaõnnestus ja teade veeres alglaadimislogis mööda. See, mis näib autentimisprobleemina, on alglaadimise järjekorra probleem.

Mida sidumisviga tegelikult ütleb

Kuulav pesa tuleb luua aadressil, mis sel hetkel olemas on. Kui VPN-liides hiljem ilmub, ei ole ainult tunneliaadressiga siduda seadistatud deemonil millegi külge kinnituda. Konfiguratsioon jääb süntaktiliselt kehtivaks; keskkond lihtsalt ei olnud valmis. Teenus, mis töötab käsitsi käivitamisest saati, ei läbi kunagi alglaadimise teed, mistõttu ilmneb viga alles järgmisel taaskäivitusel. Võrrelge ebaõnnestunud sidumise ajatemplit aadressi määramise ajatempliga ja järjekord muutub ilmseks.

Konfiguratsiooni kehtivus ja tööaegne valmisolek on eraldi omadused. Testige mõlemat, sest üks neist ebaõnnestub midagi ütlemata.

Milline protsess porti omab

Deemon ei ole alati komponent, mis kuulaja loob. Pesaaktiveerimine liigutab selle vastutuse üksusele ja siis ei muuda deemoni taaskäivitamine midagi.

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

Pesade loend näitab, milline protsess porti hoiab ja millisel aadressil, samas kui üksuse väljund näitab, kas pesaüksus üldse olemas on. Kui aktiveerimine on mängus, kuulub aadress pesaüksusele ja deemoni fail ei ole autoriteetne. Lugege alglaadimislogist tegelikku sidumisviga, selle asemel et seda sümptomist tuletada. Puuduv pesaüksus tähendab lihtsalt klassikalist korraldust, kus deemon seob otse.

Tehke valmisolek selgesõnaliseks, mitte uneks

Fikseeritud viivitus on oletus, mis kohtleb kiiret riistvara ja aeglaseid võrke ühtemoodi. Väljendage selle asemel sõltuvust: oodake aadressi, siis käivitage.

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

Lisage ExecStartPre-käsk, mis kordub, kuni aadress ilmub, või järjestage üksus pärast konkreetset võrgusihtmärki, millele liides kuulub. Mõlemad lähenemisviisid registreerivad sõltuvuse kohas, kus järgmine administraator saab seda lugeda. Silmus vajab ajalimiiti, muidu jätab ebaõnnestunud VPN maha üksuse, mis ripub, selle asemel et veast teatada. Seejärel kinnitage, et deemon seob tunneliaadressi, samal ajal kui tavaline liides jääb teie filtrite reeglite alla.

Testige puhast alglaadimist ja taasühendust

Käsitsi taaskäivitamine pärast seda, kui kõik on võrgus, ei tõesta alglaadimise järjekorra kohta midagi. Taaskäivitage masin tunneliga, mis on seadistatud automaatselt üles tulema, ja jälgige, kas kuulaja ilmub sekkumiseta.

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

Seejärel langetage ja taastage tunnel, sest uuesti ühendamine võib aadressi muuta ja kõvasti kodeeritud sidumine ei järgi seda. Hoidke testimise ajal ribavälist taastetee, et halb järjekorra muudatus ei saaks teid hostist välja lukustada.

Edu kriteerium on kuulaja, mis ilmub oma dokumenteeritud sõltuvuse all, mitte see, mille taaskäivitamist keegi mäletas.