SSH Tidak Mendengar Selepas But Semula: Alamat VPN Datang Lewat

Anda mengikat SSH pada alamat terowong semasa persediaan, ia berfungsi, dan selepas but semula seterusnya tiada siapa boleh log masuk sehingga seseorang memulakan semula perkhidmatan secara manual. Bukti kelayakan bukan masalahnya. Daemon meminta alamat daripada kernel yang belum wujud, ikatan gagal, dan mesej itu berlalu dalam log but. Apa yang kelihatan seperti masalah pengesahan sebenarnya masalah susunan permulaan.

Apa sebenarnya yang dikatakan ralat ikatan

Soket pendengar mesti dicipta pada alamat yang wujud pada saat itu. Apabila antara muka VPN muncul kemudian, daemon yang dikonfigurasikan untuk mengikat hanya pada alamat terowong tiada apa-apa untuk dilekatkan. Konfigurasi kekal sah dari segi sintaksis; persekitaran itu semata-mata belum sedia. Perkhidmatan yang berjalan sejak permulaan manual tidak pernah melalui laluan but, sebab itulah kesalahan hanya muncul pada permulaan semula seterusnya. Bandingkan cap masa kegagalan ikatan dengan cap masa pemberian alamat, dan susunannya menjadi jelas.

Kesahihan konfigurasi dan kesediaan masa jalan ialah sifat berasingan. Uji kedua-duanya, kerana salah satunya gagal tanpa berkata apa-apa.

Proses mana yang memiliki port

Daemon bukan selalu komponen yang mencipta pendengar. Pengaktifan soket memindahkan tanggungjawab itu kepada unit, dan kemudian memulakan semula daemon tidak mengubah apa-apa.

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

Senarai soket menunjukkan proses mana yang memegang port dan pada alamat mana, manakala dump unit menunjukkan sama ada unit soket wujud. Apabila pengaktifan berperanan, alamat itu milik unit soket dan fail daemon bukan autoritatif. Baca log but untuk ralat ikatan sebenar daripada menyimpulkannya daripada gejala. Ketiadaan unit soket hanya bermaksud susunan klasik, di mana daemon mengikat secara langsung.

Jadikan kesediaan eksplisit, bukan tidur

Kelewatan tetap ialah tekaan yang melayan perkakasan pantas dan rangkaian perlahan secara sama. Nyatakan kebergantungan sebaliknya: tunggu alamat, kemudian mula.

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

Tambahkan arahan ExecStartPre yang berulang sehingga alamat muncul, atau susun unit selepas sasaran rangkaian khusus yang memiliki antara muka. Kedua-dua pendekatan merekodkan kebergantungan di tempat yang boleh dibaca oleh pentadbir seterusnya. Gelung memerlukan had masa, jika tidak VPN yang gagal meninggalkan unit yang tergantung daripada melaporkan kesalahan. Kemudian sahkan bahawa daemon mengikat alamat terowong manakala antara muka biasa kekal di bawah peraturan penapis anda.

Uji but bersih dan sambungan semula

Permulaan semula manual selepas semuanya dalam talian tidak membuktikan apa-apa tentang susunan but. But semula mesin dengan terowong dikonfigurasikan untuk naik secara automatik dan perhatikan sama ada pendengar muncul tanpa campur tangan.

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

Kemudian lepaskan dan wujudkan semula terowong, kerana sambungan semula boleh mengubah alamat dan ikatan berkod keras tidak akan mengikutinya. Kekalkan laluan pemulihan di luar jalur semasa ujian, supaya perubahan susunan yang buruk tidak mengunci anda keluar daripada hos.

Kriteria kejayaan ialah pendengar yang muncul di bawah kebergantungannya yang didokumenkan, bukan yang seseorang ingat untuk dimulakan semula.