SSH ei kuuntele uudelleenkäynnistyksen jälkeen: VPN-osoite saapuu myöhässä

Sidot SSH:n asennuksen aikana tunnelin osoitteeseen, se toimii, ja seuraavan uudelleenkäynnistyksen jälkeen kukaan ei voi kirjautua sisään ennen kuin joku käynnistää palvelun uudelleen käsin. Tunnistetiedot eivät ole ongelma. Daemon pyysi ytimeltä osoitetta, jota ei vielä ollut, sidonta epäonnistui ja viesti vierähti ohi käynnistyslokiin. Se, mikä näyttää todennusongelmalta, on käynnistysjärjestyksen ongelma.

Mitä sidontavirhe oikeastaan sanoo

Kuunteleva socket on luotava osoitteeseen, joka on olemassa sillä hetkellä. Kun VPN-liittymä ilmestyy myöhemmin, daemonilla, joka on määritetty sitoutumaan vain tunnelin osoitteeseen, ei ole mitään mihin tarttua. Kokoonpano pysyy syntaktisesti kelvollisena; ympäristö ei yksinkertaisesti ollut valmis. Palvelu, joka on ollut käynnissä manuaalisesta käynnistyksestä lähtien, ei koskaan kulje käynnistyspolkua, minkä vuoksi vika ilmenee vasta seuraavalla uudelleenkäynnistyksellä. Vertaa epäonnistuneen sidonnan aikaleimaa osoitteen antamisen aikaleimaan, ja järjestys tulee ilmeiseksi.

Kokoonpanon kelvollisuus ja ajonaikainen valmius ovat erillisiä ominaisuuksia. Testaa molemmat, koska toinen niistä epäonnistuu sanomatta mitään.

Mikä prosessi omistaa portin

Daemon ei aina ole se komponentti, joka luo kuuntelijan. Socket-aktivointi siirtää vastuun unitille, eikä daemonin uudelleenkäynnistys silloin muuta mitään.

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

Socket-luettelo näyttää, mikä prosessi pitää porttia ja millä osoitteella, kun taas unitin tuloste näyttää, onko socket-unittia ylipäätään olemassa. Kun aktivointi on pelissä, osoite kuuluu socket-unitille eikä daemonin tiedosto ole ratkaiseva. Lue käynnistyslokista todellinen sidontavirhe sen sijaan, että päättelet sen oireesta. Puuttuva socket-unitti tarkoittaa yksinkertaisesti klassista järjestelyä, jossa daemon sitoutuu suoraan.

Tee valmiudesta eksplisiittinen, älä unta

Kiinteä viive on arvaus, joka kohtelee nopeaa laitteistoa ja hitaita verkkoja samalla tavalla. Ilmaise sen sijaan riippuvuus: odota osoitetta ja käynnistä sitten.

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

Lisää ExecStartPre-komento, joka toistuu, kunnes osoite ilmestyy, tai järjestä unit sen tietyn verkkokohteen jälkeen, jolle liittymä kuuluu. Molemmat lähestymistavat tallentavat riippuvuuden paikkaan, josta seuraava ylläpitäjä voi lukea sen. Silmukka tarvitsee aikakatkaisun, muuten epäonnistunut VPN jättää unitin, joka roikkuu sen sijaan, että raportoisi viasta. Vahvista sitten, että daemon sitoo tunnelin osoitteen, kun tavallinen liittymä pysyy suodatinsääntöjesi hallinnassa.

Testaa puhdas käynnistys ja uudelleenyhdistäminen

Manuaalinen uudelleenkäynnistys sen jälkeen, kun kaikki on verkossa, ei todista mitään käynnistysjärjestyksestä. Käynnistä kone uudelleen niin, että tunneli on määritetty nousemaan automaattisesti, ja seuraa, ilmestyykö kuuntelija ilman väliintuloa.

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

Pudota sitten tunneli ja palauta se, koska uudelleenyhdistäminen voi muuttaa osoitetta eikä kovakoodattu sidonta seuraa sitä. Pidä testauksen aikana kaistanulkoinen palautusreitti, jotta huono järjestysmuutos ei voi lukita sinua ulos isännästä.

Onnistumiskriteeri on kuuntelija, joka ilmestyy dokumentoidun riippuvuutensa alle, ei se, jonka joku muisti käynnistää uudelleen.