SSH Terputus pada VPN Setiap Minit? Ia Bukan Keepalive

SSH menyambung, berfungsi kira-kira seminit, kemudian membeku pada selang yang hampir sama setiap kali. Penjelasan biasa ialah timeout melahu, jadi orang menurunkan MTU dan menetapkan keepalive klien. Pautan WireGuard yang saya kerjakan sudah melalui semua itu: MTU terowong yang lebih kecil, tetapan client-alive, keepalive terowong yang dikonfigurasikan. Pemutusan terus berterusan tanpa perubahan. Puncanya ialah laluan LAN asimetri, dan corak itu wajar dikenali kerana ia mengalahkan setiap pembaikan berasaskan pemasa.

Keepalive membuktikan hos anda masih bersedia untuk menghantar. Ia tidak boleh membuat peranti yang menyimpan keadaan melihat balasan yang tidak pernah melaluinya.

Mitos: keepalive membaiki pemutusan senyap

Keepalive SSH wujud untuk satu tugas: menghalang sesuatu yang mengira kesenyapan daripada membuang sesi melahu. Itu mereka lakukan dengan baik. Mereka tidak menyelesaikan peranti berkeadaan yang melihat paket pertama dalam satu arah kemudian tidak pernah melihat balasan, kerana tiada apa yang dihantar klien mengubah antara muka mana yang digunakan balasan.

Menukar MTU ialah pembaikan popular yang lain, dan ia mempunyai mod kegagalan yang sama. Menurunkan MTU membantu pemecahan dan masalah MTU laluan, dan ia tidak melakukan apa-apa pada laluan. Jika pemasa dan MTU anda sudah wajar dan pemutusan masih pada selang berulang, selang itu memberitahu anda tentang timeout di suatu tempat, bukan tentang saiz paket. Catat selang itu dan bandingkan dengan timeout keadaan pada setiap peranti dalam laluan.

Petunjuknya ialah keteraturan bersama sesi yang kekal boleh digunakan dalam selang itu. Timeout melahu menyerang apabila tiada apa berlaku; yang ini menyerang semasa anda menaip.

Apa yang gateway tambahan sebenarnya lakukan

Letakkan komputer riba dan gateway VPN pada LAN yang sama, dengan firewall LAN berasingan sebagai gateway lalai. Komputer riba menghantar trafik menuju VPN kepada firewall, firewall memajukannya kepada gateway, dan balasan gateway kembali terus merentasi LAN ke komputer riba. Kaki kedua itu tidak pernah melalui firewall, jadi jadual keadaannya menyimpan separuh sambungan.

Alamat di bawah mencerminkan susunan itu:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

Ubah hala dan pengendalian keadaan kemudian menukar handshake yang berfungsi menjadi sambungan yang mati kemudian, bukan serta-merta. Kelewatan itu ialah entri keadaan yang menua atau pemeriksaan yang lebih ketat gagal, itulah sebabnya selang itu kelihatan begitu mekanikal.

Tiada satu pun daripada ini muncul dalam konfigurasi klien, itulah sebabnya pencariannya biasanya bermula dalam fail yang salah.

Pilih satu laluan yang disengajakan

Untuk susunan di atas, penghalaan subnet jauh terus ke gateway VPN menghapuskan separuh sambungan:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

Itu alamat contoh. Hop seterusnya mesti boleh dicapai pada LAN anda, awalan mesti rangkaian jauh yang dimaksudkan, dan arahan kedua menunjukkan hasilnya sebelum anda bergantung padanya. Jika gateway tiada pada subnet anda, laluan ini bukan pembaikan yang anda mahu.

Jika firewall bertujuan mengawasi trafik antara sistem itu, penghalaan di sekelilingnya ialah reka bentuk yang salah. Sebaliknya, biarkan kedua-dua arah melintasi sempadan dan konfigurasikan laluan pada setiap sisi supaya laluan balik sepadan. Matlamatnya ialah satu laluan yang disengajakan, bukan pemeriksaan keadaan yang kurang.

nota tentang penghalaan asimetri Netgate menerangkan asimetri peringkat antara muka yang sama dan masalah keadaan yang diwujudkannya, jadi bacalah sebelum anda melonggarkan pengendalian keadaan secara global. Pemutusan bermasa yang menyerupai kes ini bukan bukti dengan sendirinya. Anggap artikel itu sebagai huraian satu mod kegagalan, kemudian buktikan rangkaian anda sendiri sepadan dengannya sebelum mengubah dasar keadaan global.

Uji dari kedua-dua hujung

Baca laluan komputer riba ke destinasi dan laluan destinasi kembali ke komputer riba; itu dua keputusan berasingan dan mungkin hanya satu yang salah. Ping yang berjaya dari gateway itu sendiri boleh menyembunyikan masalah sepenuhnya, kerana ia berasal dari mesin yang laluannya sudah betul. Anda memerlukan kedua-dua arah seperti yang dilihat oleh kedua-dua hujung sesi sebenar.

Selepas pembaikan, buka semula SSH dan biarkan sesi terbuka jauh melepasi selang yang dahulu gagal. Kemudian jadikan laluan itu kekal dalam konfigurasi rangkaian yang diluluskan, kerana arahan sekali sahaja bukan pelan but semula dan masalah akan kembali pada but semula seterusnya dengan misteri baharu.

Bila asimetri tidak mengapa

Penghalaan asimetri adalah normal dalam banyak rangkaian dan tidak rosak mengikut definisi. Ia menjadi masalah apabila penjejakan keadaan, terjemahan atau dasar bergantung pada melihat laluan yang tidak mereka lihat, dan setiap daripadanya mempunyai ubat yang berbeza. Semak apa yang sebenarnya diperlukan oleh peranti tengah sebelum mereka bentuk semula di sekelilingnya.

Jawapan tahan lama menamakan dua laluan, peranti yang perlu melihat kedua-duanya, dan laluan yang menjadikannya mungkin. Jika anda tidak boleh menamakan peranti itu, anda belum menemui puncanya.