SSH Tidak Mendengarkan Setelah Reboot: Alamat VPN Datang Terlambat

Anda mengikat SSH ke alamat tunnel saat penyiapan, berhasil, dan setelah reboot berikutnya tidak ada yang bisa masuk sampai seseorang menjalankan ulang layanan secara manual. Kredensial bukan masalahnya. Daemon meminta alamat ke kernel yang belum ada, bind gagal, dan pesannya terlewat di log boot. Yang terlihat seperti masalah autentikasi sebenarnya masalah urutan penyalaan.

Apa sebenarnya yang dikatakan kesalahan bind

Socket pendengar harus dibuat pada alamat yang ada pada saat itu. Ketika antarmuka VPN muncul belakangan, daemon yang dikonfigurasi hanya untuk mengikat ke alamat tunnel tidak punya apa pun untuk ditempeli. Konfigurasi tetap valid secara sintaksis; lingkungannya saja yang belum siap. Layanan yang berjalan sejak start manual tidak pernah melewati jalur boot, itulah sebabnya kesalahan hanya muncul pada restart berikutnya. Bandingkan stempel waktu kegagalan bind dengan stempel waktu pemberian alamat, dan urutannya menjadi jelas.

Validitas konfigurasi dan kesiapan waktu jalan adalah sifat yang berbeda. Uji keduanya, karena salah satunya gagal tanpa mengatakan apa pun.

Proses mana yang memiliki port

Daemon tidak selalu menjadi komponen yang membuat listener. Aktivasi socket memindahkan tanggung jawab itu ke unit, dan menjalankan ulang daemon kemudian tidak mengubah apa pun.

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

Daftar socket menunjukkan proses mana yang memegang port dan pada alamat mana, sedangkan dump unit menunjukkan apakah unit socket ada sama sekali. Saat aktivasi berperan, alamat menjadi milik unit socket dan berkas daemon bukan acuan. Baca log boot untuk kesalahan bind yang sebenarnya alih-alih menyimpulkannya dari gejala. Tidak adanya unit socket berarti pengaturan klasik, tempat daemon mengikat langsung.

Buat kesiapan eksplisit, bukan tidur

Penundaan tetap adalah tebakan yang memperlakukan perangkat keras cepat dan jaringan lambat secara sama. Nyatakan dependensinya: tunggu alamatnya, lalu mulai.

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

Tambahkan perintah ExecStartPre yang berulang sampai alamat muncul, atau urutkan unit setelah target jaringan tertentu yang memiliki antarmuka. Kedua pendekatan mencatat dependensi di tempat yang bisa dibaca administrator berikutnya. Perulangan perlu batas waktu, atau VPN yang gagal meninggalkan unit yang menggantung alih-alih melaporkan kesalahan. Lalu pastikan daemon mengikat alamat tunnel sementara antarmuka biasa tetap diatur oleh aturan filter Anda.

Uji boot bersih dan sambungan ulang

Restart manual setelah semuanya daring tidak membuktikan apa pun tentang urutan boot. Reboot mesin dengan tunnel dikonfigurasi untuk naik otomatis dan amati apakah listener muncul tanpa campur tangan.

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

Lalu jatuhkan dan bangun kembali tunnel, karena koneksi ulang dapat mengubah alamat dan pengikatan yang dikodekan keras tidak akan mengikutinya. Pertahankan jalur pemulihan di luar jalur selama pengujian, agar perubahan urutan yang buruk tidak mengunci Anda keluar dari host.

Kriteria keberhasilan adalah listener yang muncul di bawah dependensi terdokumentasinya, bukan yang seseorang ingat untuk di-restart.