SSH neklauso po perkrovimo: VPN adresas vėluoja

Nustatydami SSH susiejate jį su tunelio adresu, tai veikia, o po kito perkrovimo niekas negali prisijungti, kol kas nors rankiniu būdu nepaleidžia paslaugos iš naujo. Kredencialai nėra problema. Demonas paprašė branduolio adreso, kurio dar nebuvo, susiejimas nepavyko, o pranešimas praėjo pro akis paleidimo žurnale. Tai, kas atrodo kaip autentifikavimo problema, yra paleidimo tvarkos problema.

Ką susiejimo klaida iš tikrųjų sako

Klausantis socket turi būti sukurtas adresu, kuris tuo metu egzistuoja. Kai VPN sąsaja pasirodo vėliau, demonas, sukonfigūruotas sietis tik su tunelio adresu, neturi prie ko prisitvirtinti. Konfigūracija išlieka sintaksiškai galiojanti; tiesiog aplinka nebuvo pasirengusi. Paslauga, veikianti nuo rankinio paleidimo, niekada nepereina paleidimo kelio, todėl gedimas pasirodo tik per kitą perkrovimą. Palyginkite nepavykusio susiejimo laiko žymą su adreso priskyrimo laiko žyma, ir tvarka taps akivaizdi.

Konfigūracijos galiojimas ir pasirengimas veikimo metu yra atskiros savybės. Išbandykite abi, nes viena jų nepavyksta nieko nesakiusi.

Kuris procesas valdo prievadą

Demonas ne visada yra komponentas, kuris sukuria klausytoją. Socket aktyvavimas perkelia tą atsakomybę į unit, ir tada demono paleidimas iš naujo nieko nekeičia.

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

Socket sąrašas rodo, kuris procesas laiko prievadą ir kokiu adresu, o unit išvestis rodo, ar socket unit apskritai egzistuoja. Kai aktyvavimas veikia, adresas priklauso socket unit ir demono failas nėra autoritetingas. Skaitykite paleidimo žurnalą, ieškodami tikrosios susiejimo klaidos, o ne spręskite iš simptomo. Trūkstamas socket unit tiesiog reiškia klasikinį išdėstymą, kai demonas jungiasi tiesiogiai.

Padarykite pasirengimą aiškų, o ne miegą

Fiksuotas uždelsimas yra spėjimas, kuris greitą aparatinę įrangą ir lėtus tinklus traktuoja vienodai. Verčiau išreikškite priklausomybę: palaukite adreso, tada paleiskite.

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

Pridėkite ExecStartPre komandą, kuri kartojasi, kol adresas pasirodo, arba surikiuokite unit po konkretaus tinklo tikslo, kuriam priklauso sąsaja. Abu metodai įrašo priklausomybę ten, kur kitas administratorius galės perskaityti. Ciklas turi turėti laiko limitą, kitaip nepavykęs VPN palieka unit, kuris pakimba, o ne praneša apie gedimą. Tada patvirtinkite, kad demonas susieja tunelio adresą, o įprasta sąsaja lieka jūsų filtravimo taisyklių valdoma.

Išbandykite švarų paleidimą ir prisijungimą iš naujo

Rankinis paleidimas iš naujo, kai viskas prisijungta, nieko neįrodo apie paleidimo tvarką. Perkraukite mašiną su tuneliu, sukonfigūruotu kilti automatiškai, ir stebėkite, ar klausytojas pasirodo be įsikišimo.

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

Tada numeskite ir vėl sujunkite tunelį, nes pakartotinis prisijungimas gali pakeisti adresą, o kietai užkoduotas susiejimas jo nepaseks. Testuodami palaikykite atsarginį atkūrimo kelią, kad blogas tvarkos pakeitimas neužrakintų jūsų nuo hosto.

Sėkmės kriterijus yra klausytojas, kuris pasirodo pagal savo dokumentuotą priklausomybę, o ne tas, kurį kas nors prisiminė paleisti iš naujo.