SSH pēc pārstartēšanas neklausās: VPN adrese ierodas vēlu

Iestatīšanas laikā jūs piesaistāt SSH tuneļa adresei, tas darbojas, un pēc nākamās pārstartēšanas neviens nevar pieteikties, kamēr kāds manuāli nepārstartē pakalpojumu. Akreditācijas dati nav problēma. Dēmons lūdza kodolam adresi, kas vēl neeksistēja, piesaiste neizdevās, un ziņojums aizripoja garām sāknēšanas žurnālā. Tas, kas izskatās pēc autentifikācijas problēmas, ir startēšanas secības problēma.

Ko piesaistes kļūda patiesībā saka

Klausošais socket ir jāizveido adresē, kas tajā brīdī eksistē. Kad VPN saskarne parādās vēlāk, dēmonam, kas konfigurēts piesaistīties tikai tuneļa adresei, nav kam pievienoties. Konfigurācija paliek sintaktiski derīga; vide vienkārši nebija gatava. Pakalpojums, kas darbojas kopš manuālas palaišanas, nekad neiet cauri sāknēšanas ceļam, tāpēc kļūme parādās tikai nākamajā pārstartēšanā. Salīdziniet neizdevušās piesaistes laika zīmogu ar adreses piešķiršanas laika zīmogu, un secība kļūs acīmredzama.

Konfigurācijas derīgums un gatavība izpildes laikā ir atsevišķas īpašības. Pārbaudiet abas, jo viena no tām neizdodas, neko nepasakot.

Kurš process pārvalda portu

Dēmons ne vienmēr ir komponente, kas izveido klausītāju. Socket aktivizācija pārvieto šo atbildību uz vienību, un tad dēmona pārstartēšana neko nemaina.

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

Socket saraksts parāda, kurš process tur portu un kādā adresē, bet vienības izdruka parāda, vai socket vienība vispār eksistē. Kad aktivizācija ir spēkā, adrese pieder socket vienībai un dēmona fails nav autoritatīvs. Lasiet sāknēšanas žurnālu, lai atrastu īsto piesaistes kļūdu, nevis seciniet to no simptoma. Trūkstoša socket vienība vienkārši nozīmē klasisko izkārtojumu, kurā dēmons piesaistās tieši.

Padariet gatavību skaidru, nevis miegu

Fiksēta aizkave ir minējums, kas ātru aparatūru un lēnus tīklus traktē vienādi. Tā vietā izsakiet atkarību: gaidiet adresi, tad startējiet.

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

Pievienojiet ExecStartPre komandu, kas atkārtojas, līdz adrese parādās, vai sakārtojiet vienību pēc konkrētā tīkla mērķa, kuram pieder saskarne. Abas pieejas ieraksta atkarību vietā, kur nākamais administrators to var izlasīt. Cilpai ir vajadzīgs taimauts, citādi neizdevies VPN atstāj vienību, kas karājas, nevis ziņo par kļūmi. Pēc tam apstipriniet, ka dēmons piesaista tuneļa adresi, kamēr parastā saskarne paliek jūsu filtra noteikumu pārvaldībā.

Pārbaudiet tīru startēšanu un atkārtotu savienojumu

Manuāla pārstartēšana pēc tam, kad viss ir tiešsaistē, neko nepierāda par sāknēšanas secību. Pārstartējiet mašīnu ar tuneli, kas konfigurēts celties automātiski, un novērojiet, vai klausītājs parādās bez iejaukšanās.

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

Pēc tam nometiet un atjaunojiet tuneli, jo atkārtots savienojums var mainīt adresi, un cieti kodēta piesaiste tam nesekos. Testēšanas laikā saglabājiet ārpusjoslas atkopšanas ceļu, lai slikta secības maiņa nevarētu jūs izslēgt no resursdatora.

Veiksmes kritērijs ir klausītājs, kas parādās saskaņā ar savu dokumentēto atkarību, nevis tas, kuru kāds atcerējās pārstartēt.