Tunnel penuh membunuh sesi SSH Anda: patok rute pulang

Jalankan klien OpenVPN di mesin tempat Anda bekerja melalui SSH, dan di tengah perintah sesi membeku. Tunnel melaporkan terhubung, host dapat mencapai internet melaluinya, dan ketukan tombol Anda tetap datang sementara tidak ada yang kembali. Yang berubah bukan tunnel: itu jalur pulang bagi paket yang dialamatkan kepada Anda, yang kini cocok dengan rute default baru dan masuk ke tunnel yang tidak akan dipakai gateway jauh untuk mencapai meja Anda.

Apa yang sebenarnya dipasang redirect-gateway

Dalam bentuk def1 redirect-gateway ia menambahkan 0.0.0.0/1 dan 128.0.0.0/1 alih-alih menimpa rute default. Kedua separuh itu mencakup seluruh ruang alamat sementara keduanya tetap merupakan prefiks yang lebih panjang daripada 0.0.0.0/0, sehingga tujuan mana pun tanpa kecocokan yang lebih spesifik kini masuk ke tunnel. Itulah mekanisme yang perlu dipegang, karena setiap perbaikan di bawah bekerja dengan memasang kecocokan yang lebih spesifik.

Alamat administrasi Anda adalah salah satu tujuan itu.

Server VPN meneruskan lalu lintas kliennya menuju internet. Ia tidak punya rute untuk alamat publik tempat Anda menyambung, dan tidak punya alasan memperlakukan paket itu sebagai sesuatu selain lalu lintas yang datang dari klien, jadi ia membuangnya. Sementara itu permintaan yang Anda kirim tetap sampai ke host, dan itulah sebabnya sesi tampak hidup hanya dari satu sisi.

ip route show table main | head -n 20
ip route get 198.51.100.23

Temukan alamat sumber Anda dan jalur sebelum tunnel

Di server, daftar koneksi SSH yang terbentuk dan catat alamat peer asalnya. Alamat itulah yang harus dicakup rute pulang Anda, dan tidak selalu seperti yang Anda duga: host lompat, gateway NAT, atau penerjemah operator dapat menggantinya dengan sumber lain.

Lalu temukan gateway fisik dan antarmuka yang membawa lalu lintas sebelum tunnel dimulai. Dalam def1 susunan itu rute default masih ada di bawah setengah-default, jadi informasinya tersedia, meski membaca tabel rute yang panjang dengan mata mengundang kesalahan.

Catat kedua nilai dan nama antarmuka bersama-sama, karena rute yang akan Anda tambahkan membutuhkan ketiganya. Jika host memakai aturan perutean berbasis kebijakan untuk memilih uplink-nya, rute biasa mungkin tidak dipertimbangkan sama sekali, dan kemungkinan itu mengubah perbaikannya.

Patok rute host yang mengungguli setengah-default

Rute /32 lebih panjang daripada kedua setengah-default, sehingga balasan ke alamat Anda memilihnya alih-alih tunnel. Lompatan berikutnya adalah gateway sebelum tunnel dan perangkatnya adalah antarmuka fisik, yang menjaga paket pada jalur yang dipakainya sebelum tunnel ada.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Verifikasi dengan pencarian, bukan dengan memeriksa tabel: jawabannya harus menyebut eth0 dan gateway, tidak pernah tun0.

OpenVPN sudah menambahkan rute host ke alamat server VPN itu sendiri dengan alasan yang sama, jadi polanya sudah dikenal dan alamat administrasi hanyalah satu pengecualian lagi. Jangan pakai route-nopull untuk memperbaiki ini, karena ia membuang rute terdorong yang dibutuhkan tunnel, termasuk jaringan jauh dan opsi DNS.

Buat agar bertahan melewati penyambungan ulang

Rute yang ditambahkan dengan tangan hilang ketika klien menyambung ulang dan memasang rutenya sendiri, yang mengubah perbaikan menjadi gangguan berulang. Kaitkan perintah itu pada sesuatu yang berjalan setelah rute dipasang.

Baik skrip route-up maupun kait pre-up manajer jaringan berfungsi, dan pemeriksaan yang andal adalah menyambung ulang lalu melakukan pencarian yang sama.

Di Windows padanannya adalah rute persisten yang ditambahkan dengan -p, yang bertahan melewati reboot tetapi tetap harus menunjuk gateway yang benar setelah perubahan jaringan. Apa pun platformnya, tulis alasannya di samping rute: administrator berikutnya perlu tahu bahwa rute itu ada untuk melindungi sesi manajemen, bukan karena desain jaringan menuntutnya.

Ketika rute yang dipatok masih belum cukup

Penyaringan jalur balik dapat membuang paket yang tiba di satu antarmuka dan keluar lewat antarmuka lain, dan itulah tepatnya yang dibuat rute yang dipatok. Periksa nilai rp_filter yang efektif sebelum menonaktifkan apa pun secara global, dan utamakan memperbaiki asimetrinya daripada mematikan pemeriksaannya. Pengaturan per antarmuka yang berlaku, dan mode loose sering hanya mencatat asimetri alih-alih membuang paket. Baca keduanya sebelum menyimpulkan bahwa penyaringnya yang salah.

Host dengan perutean berbasis kebijakan membutuhkan aturan selain rute, karena basis aturan memilih tabel sebelum rute di dalamnya dipertimbangkan. Rute di tabel main tidak terlihat oleh aliran yang cocok dengan aturan yang menunjuk ke tabel lain. Baca aturannya sebelum menambahkan apa pun ke main. Jika sebuah aturan sudah mencakup lalu lintas manajemen, pengecualiannya justru masuk ke tabel aturan itu.

Biarkan konsol di luar jalur tetap terbuka selama Anda menguji, dan periksa ulang dari login kedua sebelum memutus yang sedang Anda pakai. Rute yang mengirim lalu lintas manajemen Anda sendiri ke tunnel memotong koneksi yang sedang Anda perbaiki. Untuk masuk lagi berarti konsol serial atau boot penyelamat, yang merupakan pertukaran buruk karena melewatkan satu langkah verifikasi.