ServerAliveInterval SSH melalui VPN: hujung mana yang menghantar probe?

Kebanyakan nasihat menjaga sesi SSH kekal hidup berhenti pada «tambah ServerAliveInterval 30» dan meninggalkan bahagian yang berguna. Kata kunci ialah pemasa di sebelah klien yang hanya bertindak apabila saluran senyap, ia mengira probe tanpa jawapan dan bukan saat, dan ia tinggal dalam fail yang nilai pertama yang sepadan menang. Tersilap pada ketiga-tiga sifat itu dan sesi VPN yang sihat tetap terputus, manakala sesi mati terus tergantung.

Dua arah itu milik daemon yang berbeza

ServerAliveInterval dibaca oleh klien ssh anda. ClientAliveInterval dibaca oleh sshd di hujung jauh dan menyiasat arah bertentangan, dari pelayan ke klien. Kedua-duanya bukan alias dan tidak bekerjasama, jadi menetapkan satu tidak memberi kesan pada tingkah laku hujung yang lain. Mengelirukan keduanya ialah sebab biasa sesuatu pembetulan kelihatan berjaya pada satu hos dan tidak pada hos berikutnya.

Kedua-duanya menerima sifar. Pada sifar klien tidak menghantar apa-apa, dan di sebelah pelayan ClientAliveCountMax bersifar mematikan pemutusan yang sepatutnya menyusul selepas pemeriksaan tanpa jawapan.

Apa yang dibuktikan probe dan apa yang tidak

Selepas selang yang ditetapkan berlalu tanpa data datang dari pelayan, klien menghantar permintaan kecil melalui saluran tersulit sedia ada dan menunggu jawapan. ServerAliveCountMax menetapkan berapa banyak yang boleh kekal tanpa jawapan sebelum sesi diputuskan. Dengan selang 60 dan kiraan 3 klien mengalah selepas kira-kira tiga minit senyap, dan angka itu ialah sifat konfigurasi anda, bukan piawaian rangkaian. Biarkan selang pada nilai lalainya 0 dan tiada probe akan dihantar, itulah sebabnya klien standard boleh duduk di atas sambungan mati tanpa had.

Kerana pertukaran berlaku di dalam pengangkutan SSH, jawapan membuktikan bahawa proses SSH di hujung sana masih membaca dan menulis. Ia tidak mengatakan apa-apa tentang program yang anda mulakan dalam sesi itu: klien pangkalan data, port yang diposkan atau skrip yang berjalan lama boleh tersekat sementara pengangkutan dengan gembira menjawab probe.

TCPKeepAlive ialah mekanisme berasingan satu lapisan lebih rendah. Kernel mengendalikannya, ia tidak disulitkan, dan hujung yang daemon SSH-nya tersekat masih boleh memenuhinya. Itulah sebabnya probe pada peringkat SSH ialah isyarat yang lebih bermakna apabila anda mengambil berat tentang sesi, bukan soket.

Susunan menentukan nilai mana yang bertahan

OpenSSH menggunakan nilai pertama yang diperolehnya bagi setiap parameter, jadi blok Host tertentu mesti muncul sebelum mana-mana blok lebih luas yang juga akan sepadan. Letakkan nilai lalai dengan kad liar di bahagian bawah fail, bukan di atas, dan ingat bahawa blok Match yang lebih bawah tidak boleh mengatasi nilai yang telah ditetapkan. Rujukan konfigurasi klien OpenSSH menyatakan peraturan nilai pertama secara langsung, dan ia berbaloi dibaca sekali sebelum menyusun semula konfigurasi dikongsi.

Pilihan baris arahan mengalahkan fail, yang menjadikan eksperimen sementara murah:

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

Untuk melihat apa yang sebenarnya diselesaikan oleh klien dan bukan apa yang anda sangka telah tulis, minta ia meluahkan konfigurasi berkesan. Outputnya mengandungi nilai yang digabungkan untuk nama hos itu dan ia ialah cara terpantas menangkap blok terdahulu yang tersasar:

ssh -G office-shell | grep -i alive

Apa yang dilakukan keepalive melalui terowong

Trafik berkala menghalang pemetaan NAT atau tembok api berkeadaan daripada tamat tempoh, yang merupakan faedah sebenar pada VPN yang getnya membuang aliran melahu selepas beberapa minit. Probe yang tiba setiap 60 saat menyegarkan pemetaan itu tanpa membawa apa-apa data aplikasi.

Mereka tidak boleh membina semula laluan yang telah hilang. Apabila antara muka terowong hilang probe gagal seperti segala-galanya, dan sesi berakhir sebaik kiraan habis. Pengesanan hayat dan pemulihan laluan ialah masalah berbeza, dan hanya yang pertama boleh dikonfigurasikan dalam ssh_config. Apa yang sebenarnya dibeli oleh selang dan kiraan ialah betapa cepat klien menyedarinya, dan itulah bahagian yang dialami pengguna sebagai tersekat.

Sambungan bermultipleks menambah kedutan. Apabila ControlMaster digunakan probe milik sambungan induk, dan sesi baharu di atas induk sedia ada mewarisi apa sahaja yang telah dirundingkan induk itu. Jika induk mux tersekat, membuka tetingkap lain tidak akan menguji laluan itu semula.

Mengesahkan tetapan dari hujung ke hujung

Di pelayan, luahkan konfigurasi daemon yang berkesan dan bukan membaca fail serta meneka include mana yang menang:

sshd -T | grep -i clientalive

Kemudian perhatikan sesi sebenar dengan output nyahpepijat dihidupkan. Klien mencetak baris tamat masa apabila kiraan habis, dan cap masa di sekelilingnya menunjukkan sama ada kesenyapan itu berterusan atau probe tidak pernah dihantar langsung. Sesi yang mati tanpa sebarang trafik probe biasanya menyimpan kata kunci dalam blok yang tidak pernah sepadan.

Dua pemeriksaan wajar ditambah bagi mana-mana hos yang hanya anda capai melalui terowong: pastikan selang yang diselesaikan ialah yang anda maksudkan, dan pastikan selang itu didarab dengan kiraan lebih pendek daripada tamat masa melahu pada get VPN. Apabila nombor kedua lebih besar, get itu membuang aliran itu secara senyap terlebih dahulu dan probe SSH tidak pernah berpeluang melaporkan apa-apa.