ServerAliveInterval SSH lewat VPN: ujung mana yang mengirim probe?

Sebagian besar saran menjaga sesi SSH tetap hidup berhenti pada «tambahkan ServerAliveInterval 30» dan meninggalkan bagian yang berguna. Kata kuncinya adalah pengatur waktu di sisi klien yang hanya aktif saat kanal sepi, ia menghitung probe tanpa jawaban, bukan detik, dan ia tinggal di berkas tempat nilai pertama yang cocok menang. Salah pada ketiga sifat itu dan sesi VPN yang sehat tetap putus, sementara sesi mati malah menggantung.

Kedua arah milik daemon yang berbeda

ServerAliveInterval dibaca oleh klien ssh Anda. ClientAliveInterval dibaca oleh sshd di sisi jauh dan memeriksa ke arah sebaliknya, dari server ke klien. Keduanya bukan alias dan tidak bekerja sama, jadi menyetel yang satu tidak berpengaruh pada perilaku ujung lainnya. Mencampuradukkan keduanya adalah alasan biasa sebuah perbaikan tampak berhasil di satu host dan tidak di host berikutnya.

Keduanya menerima nol. Pada nol klien tidak mengirim apa pun, dan di sisi server ClientAliveCountMax bernilai nol mematikan pemutusan yang seharusnya menyusul pemeriksaan tanpa jawaban.

Apa yang dibuktikan probe dan apa yang tidak

Setelah interval yang dikonfigurasi lewat tanpa data datang dari server, klien mengirim permintaan kecil melalui kanal terenkripsi yang ada dan menunggu balasan. ServerAliveCountMax menetapkan berapa banyak yang boleh tetap tanpa jawaban sebelum sesi diputus. Dengan interval 60 dan hitungan 3 klien menyerah setelah sekitar tiga menit hening, dan angka itu adalah sifat konfigurasi Anda, bukan standar jaringan. Biarkan interval pada nilai bawaannya 0 dan tidak ada probe yang pernah dikirim, itulah sebabnya klien standar bisa duduk di koneksi mati tanpa batas.

Karena pertukaran berjalan di dalam transport SSH, balasan membuktikan bahwa proses SSH di ujung lain masih membaca dan menulis. Itu tidak mengatakan apa pun tentang program yang Anda jalankan di dalam sesi tersebut: klien basis data, port yang diteruskan, atau skrip berjalan lama bisa macet sementara transport dengan senang hati menjawab probe.

TCPKeepAlive adalah mekanisme terpisah satu lapis lebih rendah. Kernel yang menanganinya, ia tidak terenkripsi, dan ujung yang daemon SSH-nya macet masih bisa memenuhinya. Karena itu probe pada tingkat SSH adalah sinyal yang lebih bermakna ketika Anda peduli pada sesi, bukan pada soket.

Urutan menentukan nilai mana yang bertahan

OpenSSH menerapkan nilai pertama yang diperolehnya untuk setiap parameter, jadi blok Host yang spesifik harus muncul sebelum blok mana pun yang lebih luas yang juga cocok. Letakkan nilai bawaan dengan kartu liar di bagian bawah berkas, bukan di atas, dan ingat bahwa blok Match di bawahnya tidak dapat menimpa nilai yang sudah ditetapkan. Referensi konfigurasi klien OpenSSH menyatakan aturan nilai pertama secara langsung, dan itu layak dibaca sekali sebelum menata ulang konfigurasi bersama.

Opsi baris perintah menang atas berkas, yang membuat percobaan sementara menjadi murah:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

Untuk melihat apa yang sebenarnya diselesaikan klien, bukan apa yang Anda kira telah tulis, minta ia membuang konfigurasi efektif. Keluarannya memuat nilai gabungan untuk nama host itu dan merupakan cara tercepat menangkap blok sebelumnya yang nyasar:

ssh -G office-shell | grep -i alive

Apa yang dilakukan keepalive lewat terowongan

Lalu lintas berkala mencegah pemetaan NAT atau firewall stateful kedaluwarsa, yang merupakan manfaat nyata pada VPN yang gateway-nya membuang aliran diam setelah beberapa menit. Probe yang datang setiap 60 detik menyegarkan pemetaan itu tanpa membawa data aplikasi.

Mereka tidak dapat membangun ulang jalur yang telah hilang. Saat antarmuka terowongan lenyap, probe gagal seperti hal lainnya, dan sesi berakhir begitu hitungan habis. Deteksi hidup dan pemulihan jalur adalah masalah berbeda, dan hanya yang pertama dapat dikonfigurasi di ssh_config. Yang sebenarnya dibeli interval dan hitungan adalah seberapa cepat klien menyadarinya, dan itulah bagian yang dialami pengguna sebagai macet.

Koneksi bermultipleks menambah kerutan. Saat ControlMaster dipakai, probe menjadi milik koneksi induk, dan sesi baru di atas induk yang ada mewarisi apa pun yang dinegosiasikan induk itu. Jika induk mux macet, membuka jendela lain tidak akan menguji jalur lagi.

Memastikan pengaturan dari ujung ke ujung

Di server, buang konfigurasi daemon yang efektif alih-alih membaca berkas dan menebak include mana yang menang:

sshd -T | grep -i clientalive

Lalu amati sesi nyata dengan keluaran debug diaktifkan. Klien mencetak baris batas waktu saat hitungan habis, dan stempel waktu di sekitarnya menunjukkan apakah keheningan berlangsung terus atau probe tidak pernah dikirim sama sekali. Sesi yang mati tanpa lalu lintas probe biasanya menyimpan kata kunci di blok yang tidak pernah cocok.

Dua pemeriksaan layak ditambahkan untuk host apa pun yang hanya Anda capai lewat terowongan: pastikan interval yang diselesaikan adalah yang Anda maksud, dan pastikan interval itu dikalikan hitungan lebih pendek daripada batas diam di gateway VPN. Bila angka kedua lebih besar, gateway diam-diam membuang aliran lebih dulu dan probe SSH tidak pernah mendapat kesempatan melaporkan apa pun.