SSH harket net nei it opnij starten: it VPN-adres is te let

Jo bine SSH by it ynstellen oan it tunneladres, it wurket, en nei de folgjende opnij start kin nimmen ynlogge oant immen de tsjinst mei de hân opnij start. De oanmeldgegevens binne it probleem net. De daemon frege de kernel om in adres dat noch net bestie, de bining mislearre, en it berjocht rôle foarby yn it opstartloch. Wat as in autentikaasjeprobleem liket, is in probleem mei de opstartfolchoarder.

Wat de biningsflater eins seit

In harkende socket moat makke wurde op in adres dat op dat momint bestiet. As de VPN-ynterface letter opkomt, hat in daemon dy't ynsteld is om allinnich oan it tunneladres te binen neat om oan fêst te meitsjen. De konfiguraasje bliuwt syntaktysk jildich; de omjouwing wie gewoan net klear. In tsjinst dy't sûnt in hânmjittige start rint, giet nea troch it opstartpaad, en dêrom ferskynt de flater pas by de folgjende opnij start. Ferlykje de tiidstimpel fan de mislearre bining mei de tiidstimpel fan de adrestawizing, en de folchoarder wurdt dúdlik.

Konfiguraasjejildigens en klearheid by runtime binne aparte eigenskippen. Test beide, want ien fan harren mislearret sûnder wat te sizzen.

Hokker proses hat de poarte

De daemon is net altyd it ûnderdiel dat de harker makket. Socket-aktivaasje ferpleatst dy ferantwurdlikheid nei in ienheid, en dan feroaret it opnij starten fan de daemon neat.

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

De socketlist lit sjen hokker proses de poarte hâldt en op hokker adres, wylst de ienheidsdump lit sjen oft der wol in socket-ienheid bestiet. As aktivaasje yn it spul is, heart it adres yn de socket-ienheid en is it daemonbestân net gesachhawwend. Lês it opstartloch foar de echte biningsflater ynstee fan dy út it symptoom ôf te lieden. In ûntbrekkende socket-ienheid betsjut gewoan de klassike regeling, wêrby't de daemon direkt bint.

Meitsje klearheid eksplisyt, net in sliep

In fêste fertraging is in gissing dy't flugge hardware en stadige netwurken itselde behannelet. Utterje ynstee de ôfhinklikheid: wachtsje op it adres, start dan.

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

Foegje in ExecStartPre-opdracht ta dy't werhellet oant it adres ferskynt, of oarderje de ienheid nei it spesifike netwurkdoel dat de ynterface hat. Beide oanpakken lizze de ôfhinklikheid fêst earne wêr't de folgjende behearder it lêze kin. De lus hat in time-out nedich, oars lit in mislearre VPN in ienheid hingjen ynstee fan in flater te melden. Befêstigje dan dat de daemon it tunneladres bint wylst de gewoane ynterface ûnder jo filterregels bliuwt.

Test in skjinne opstart en in werferbining

In hânmjittige opnij start nei't alles online is, bewiist neat oer de opstartfolchoarder. Start de masine opnij mei de tunnel ynsteld om automatysk op te kommen en sjoch oft de harker sûnder yngripen ferskynt.

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

Lit dan de tunnel falle en meitsje him wer oan, want in werferbining kin it adres feroarje en in hurdcodet bining sil it net folgje. Hâld by it testen in bûtenbânsk herstelpaad, sadat in minne folchoarderferoaring jo net bûten de host slute kin.

It súkseskriterium is in harker dy't ûnder syn dokumintearre ôfhinklikheid ferskynt, net ien dy't immen betocht om opnij te starten.