SSH Putus di VPN Setiap Menit? Bukan Keepalive Penyebabnya

SSH terhubung, berfungsi sekitar satu menit, lalu membeku pada interval yang kurang lebih sama setiap kali. Penjelasan umumnya adalah timeout diam, jadi orang menurunkan MTU dan menyetel keepalive klien. Tautan WireGuard yang saya kerjakan sudah melewati semua itu: MTU terowongan lebih kecil, pengaturan client-alive, keepalive terowongan yang dikonfigurasi. Putusnya berlanjut tanpa perubahan. Penyebabnya ternyata rute LAN asimetris, dan polanya layak dikenali karena mengalahkan setiap perbaikan berbasis timer.

Keepalive membuktikan host Anda masih bersedia mengirim. Ia tidak dapat membuat perangkat yang menyimpan status melihat balasan yang tidak pernah melewatinya.

Mitos: keepalive memperbaiki putus yang senyap

Keepalive SSH ada untuk satu tugas: mencegah sesuatu yang menghitung kesunyian membersihkan sesi yang menganggur. Itu mereka lakukan dengan baik. Mereka tidak mengatasi perangkat berstatus yang melihat paket pertama di satu arah lalu tidak pernah melihat balasannya, karena tidak ada yang dikirim klien mengubah antarmuka mana yang dipakai balasan.

Mengubah MTU adalah perbaikan populer lainnya, dan ia punya mode kegagalan yang sama. Menurunkan MTU membantu fragmentasi dan masalah MTU jalur, dan tidak melakukan apa pun pada rute. Jika timer dan MTU Anda sudah wajar dan putusnya masih pada interval berulang, interval itu memberi tahu Anda tentang timeout di suatu tempat, bukan tentang ukuran paket. Catat intervalnya dan bandingkan dengan timeout status pada setiap perangkat di jalur.

Petunjuknya adalah keteraturan disertai sesi yang tetap bisa dipakai di dalam interval itu. Timeout diam menyerang saat tidak ada yang terjadi; yang ini menyerang saat Anda mengetik.

Apa yang sebenarnya dilakukan gateway tambahan

Letakkan laptop dan gateway VPN di LAN yang sama, dengan firewall LAN terpisah sebagai gateway default. Laptop mengirim lalu lintas menuju VPN ke firewall, firewall meneruskannya ke gateway, dan balasan gateway kembali langsung melintasi LAN ke laptop. Kaki kedua itu tidak pernah melewati firewall, jadi tabel statusnya menyimpan setengah koneksi.

Alamat di bawah ini mencerminkan susunan tersebut:

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

Pengalihan dan penanganan status kemudian mengubah handshake yang berfungsi menjadi koneksi yang mati belakangan, bukan seketika. Penundaan itu adalah entri status yang menua atau pemeriksaan yang lebih ketat gagal, itulah sebabnya intervalnya tampak begitu mekanis.

Tidak ada dari ini yang muncul di konfigurasi klien, itulah sebabnya pencariannya biasanya dimulai di berkas yang salah.

Pilih satu jalur yang disengaja

Untuk susunan di atas, merutekan subnet jarak jauh langsung ke gateway VPN menghilangkan setengah koneksi:

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 berikutnya harus dapat dijangkau di LAN Anda, prefiksnya harus jaringan jarak jauh yang dimaksud, dan perintah kedua menunjukkan hasilnya sebelum Anda mengandalkannya. Jika gateway tidak ada di subnet Anda, rute ini bukan perbaikan yang Anda inginkan.

Jika firewall dimaksudkan untuk mengawasi lalu lintas antar sistem itu, merutekan di sekitarnya adalah desain yang salah. Sebaliknya, buat kedua arah melewati batas dan konfigurasikan rute di tiap sisi agar jalur kembali cocok. Tujuannya satu jalur yang disengaja, bukan pemeriksaan status yang lebih sedikit.

catatan tentang perutean asimetris dari Netgate menjelaskan asimetri tingkat antarmuka yang sama dan masalah status yang ditimbulkannya, jadi bacalah sebelum Anda melonggarkan penanganan status secara global. Pemutusan berwaktu yang menyerupai kasus ini bukan bukti dengan sendirinya. Perlakukan artikel itu sebagai deskripsi satu mode kegagalan, lalu buktikan jaringan Anda sendiri cocok dengannya sebelum mengubah kebijakan status global.

Uji dari kedua ujung

Baca rute laptop menuju tujuan dan rute tujuan kembali menuju laptop; itu dua keputusan terpisah dan mungkin hanya satu yang salah. Ping yang berhasil dari gateway itu sendiri dapat menyembunyikan masalah sepenuhnya, karena berasal dari mesin yang jalurnya sudah benar. Anda memerlukan kedua arah sebagaimana dilihat kedua ujung sesi yang sebenarnya.

Setelah perbaikan, buka lagi SSH dan tahan sesi terbuka jauh melewati interval yang dulu gagal. Lalu jadikan rute permanen dalam konfigurasi jaringan yang disetujui, karena perintah sekali jalan bukan rencana reboot dan masalahnya akan kembali saat reboot berikutnya dengan misteri baru.

Kapan asimetri tidak masalah

Perutean asimetris normal di banyak jaringan dan tidak rusak menurut definisi. Ia menjadi masalah ketika pelacakan status, penerjemahan, atau kebijakan bergantung pada melihat jalur yang tidak mereka lihat, dan masing-masing punya obat berbeda. Periksa apa yang sebenarnya dibutuhkan perangkat tengah sebelum merancang ulang di sekitarnya.

Jawaban yang tahan lama menyebutkan dua jalur, perangkat yang perlu melihat keduanya, dan rute yang membuatnya demikian. Jika Anda tidak dapat menyebutkan perangkatnya, Anda belum menemukan penyebabnya.