Hindi Nakikinig ang SSH Pagkatapos ng Reboot: Nahuhuli ang Address ng VPN

Itinatali mo ang SSH sa address ng tunnel habang nagsesetup, gumagana ito, at pagkatapos ng susunod na reboot walang makakapasok hangga't walang manu-manong nag-restart ng serbisyo. Hindi ang mga kredensyal ang problema. Humingi ang daemon sa kernel ng address na wala pa, nabigo ang pag-bind, at dumaan ang mensahe sa boot log. Ang mukhang problema sa authentication ay problema sa pagkakasunod-sunod ng pagsisimula.

Ano talaga ang sinasabi ng error sa pag-bind

Ang nakikinig na socket ay dapat gawin sa address na umiiral sa sandaling iyon. Kapag lumitaw ang VPN interface mamaya, ang daemon na naka-configure na mag-bind lamang sa address ng tunnel ay walang makapitan. Nananatiling wasto sa sintaks ang configuration; hindi lang handa ang kapaligiran. Ang serbisyong tumatakbo mula sa manu-manong pag-start ay hindi kailanman dumadaan sa boot path, kaya lumilitaw lamang ang depekto sa susunod na restart. Ihambing ang timestamp ng nabigong pag-bind sa timestamp ng pagtatalaga ng address, at magiging malinaw ang pagkakasunod-sunod.

Ang bisa ng configuration at ang kahandaan sa runtime ay magkahiwalay na katangian. Subukan ang pareho, dahil nabigo ang isa nang walang sinasabi.

Aling proseso ang may-ari ng port

Hindi lagi ang daemon ang component na gumagawa ng listener. Inililipat ng socket activation ang responsibilidad na iyon sa isang unit, at wala nang nababago kapag ni-restart ang daemon.

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

Ipinapakita ng socket list kung aling proseso ang humahawak ng port at sa aling address, habang ipinapakita ng unit dump kung may unit socket man. Kapag kasama ang activation, pag-aari ng unit socket ang address at hindi awtoritatibo ang daemon file. Basahin ang boot log para sa tunay na error sa pag-bind sa halip na hulaan ito mula sa sintomas. Ang kawalan ng unit socket ay nangangahulugan lamang ng klasikong kaayusan, kung saan direktang nagbi-bind ang daemon.

Gawing tahasan ang kahandaan, hindi pagtulog

Ang fixed na pagkaantala ay isang hula na pantay na tinatrato ang mabilis na hardware at mabagal na network. Sa halip, ipahayag ang dependency: hintayin ang address, pagkatapos ay magsimula.

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

Magdagdag ng ExecStartPre command na umuulit hanggang lumitaw ang address, o ayusin ang unit pagkatapos ng partikular na network target na nagmamay-ari ng interface. Itinatala ng parehong paraan ang dependency sa lugar na mababasa ng susunod na administrator. Kailangan ng loop ng timeout, kung hindi ay nag-iiwan ang nabigong VPN ng unit na nakabitin sa halip na mag-ulat ng depekto. Pagkatapos, kumpirmahin na ini-bind ng daemon ang address ng tunnel habang ang ordinaryong interface ay nananatili sa ilalim ng iyong mga patakaran sa filter.

Subukan ang malinis na boot at muling pagkonekta

Ang manu-manong restart pagkatapos na online ang lahat ay walang pinapatunayan tungkol sa pagkakasunod-sunod ng boot. I-reboot ang makina na naka-configure ang tunnel na awtomatikong bumangon at obserbahan kung lumilitaw ang listener nang walang interbensyon.

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

Pagkatapos, ihulog at itatag muli ang tunnel, dahil maaaring baguhin ng reconnect ang address at hindi ito susundan ng hard-coded na binding. Panatilihin ang out-of-band na landas sa pagbawi habang nagtetest, para hindi ka mailock out ng masamang pagbabago sa pagkakasunod-sunod mula sa host.

Ang pamantayan ng tagumpay ay listener na lumilitaw sa ilalim ng dokumentadong dependency nito, hindi ang isa na naalala ng isang tao na i-restart.