Tunnel penuh membunuh sesi SSH anda: pin laluan pulang

Mulakan klien OpenVPN pada mesin yang anda gunakan melalui SSH, dan di tengah-tengah arahan sesi membeku. Tunnel melaporkan ia bersambung, hos boleh mencapai internet melaluinya, dan ketukan kekunci anda masih tiba sementara tiada apa yang kembali. Apa yang berubah bukan tunnel: ia ialah laluan pulang bagi paket yang dialamatkan kepada anda, yang kini sepadan dengan laluan lalai baharu dan masuk ke tunnel yang tidak akan digunakan oleh get laluan jauh untuk mencapai meja anda.

Apa yang sebenarnya dipasang oleh redirect-gateway

Dalam bentuk def1 redirect-gateway ia menambah 0.0.0.0/1 dan 128.0.0.0/1 dan bukannya menimpa laluan lalai. Kedua-dua separuh itu meliputi seluruh ruang alamat sementara kedua-duanya kekal sebagai awalan yang lebih panjang daripada 0.0.0.0/0, jadi mana-mana destinasi tanpa padanan yang lebih khusus kini masuk ke tunnel. Itulah mekanisme yang perlu dipegang, kerana setiap pembaikan di bawah berfungsi dengan memasang padanan yang lebih khusus.

Alamat pentadbiran anda ialah salah satu destinasi itu.

Pelayan VPN memajukan trafik pelanggannya ke arah internet. Ia tiada laluan untuk alamat awam yang anda sambung daripadanya, dan tiada sebab untuk menganggap paket itu sebagai sesuatu selain trafik yang datang daripada pelanggan, jadi ia membuangnya. Sementara itu permintaan yang anda hantar tetap sampai ke hos, dan itulah sebabnya sesi kelihatan hidup hanya dari satu sisi.

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

Cari alamat sumber anda dan laluan sebelum tunnel

Di pelayan, senaraikan sambungan SSH yang terbentuk dan catat alamat rakan sebaya dari mana ia datang. Alamat itulah yang perlu diliputi oleh laluan pulang anda, dan ia bukan selalu seperti yang anda sangka: hos lompat, get laluan NAT atau penterjemah pembawa boleh menggantikannya dengan sumber lain.

Kemudian cari get laluan fizikal dan antara muka yang membawa trafik sebelum tunnel bermula. Dalam def1 susunan itu laluan lalai masih hadir di bawah setengah-lalai, jadi maklumatnya tersedia, walaupun membaca jadual laluan yang panjang dengan mata mengundang kesilapan.

Catat kedua-dua nilai dan nama antara muka bersama-sama, kerana laluan yang akan anda tambah memerlukan ketiga-tiganya. Jika hos menggunakan peraturan penghalaan berasaskan dasar untuk memilih pautan atasnya, laluan biasa mungkin tidak dipertimbangkan langsung, dan kemungkinan itu mengubah pembaikan.

Pin laluan hos yang mengatasi setengah-lalai

Satu laluan /32 lebih panjang daripada mana-mana setengah-lalai, jadi balasan ke alamat anda memilihnya berbanding tunnel. Lompatan seterusnya ialah get laluan sebelum tunnel dan perantinya ialah antara muka fizikal, yang mengekalkan paket pada laluan yang digunakannya sebelum tunnel wujud.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Sahkan dengan carian dan bukan dengan memeriksa jadual: jawapannya mesti menyebut eth0 dan get laluan, tidak pernah tun0.

OpenVPN sudah menambah laluan hos ke alamat pelayan VPN itu sendiri atas sebab yang sama, jadi coraknya sudah dikenali dan alamat pentadbiran hanyalah satu lagi pengecualian. Jangan gunakan route-nopull untuk membaiki ini, kerana ia membuang laluan yang ditolak yang diperlukan oleh tunnel, termasuk rangkaian jauh dan pilihan DNS.

Pastikan ia bertahan apabila menyambung semula

Laluan yang ditambah dengan tangan hilang apabila klien menyambung semula dan memasang laluannya sendiri, yang menjadikan pembaikan sebagai gangguan berulang. Kaitkan arahan itu pada sesuatu yang berjalan selepas laluan dipasang.

Sama ada skrip route-up mahupun cangkuk pre-up pengurus rangkaian berfungsi, dan pemeriksaan yang boleh dipercayai ialah menyambung semula diikuti carian yang sama.

Di Windows persamaannya ialah laluan berterusan yang ditambah dengan -p, yang bertahan selepas but semula tetapi masih mesti menunjuk ke get laluan yang betul selepas perubahan rangkaian. Apa pun platformnya, tulis sebabnya di sebelah laluan: pentadbir seterusnya perlu tahu ia wujud untuk melindungi sesi pengurusan, bukan kerana reka bentuk rangkaian menuntutnya.

Apabila laluan yang dipin masih tidak cukup

Penapisan laluan balik boleh membuang paket yang tiba pada satu antara muka dan keluar melalui yang lain, dan itulah tepat apa yang dicipta oleh laluan yang dipin. Periksa nilai rp_filter berkesan sebelum menyahaktifkan apa-apa secara global, dan utamakan membaiki asimetri daripada mematikan pemeriksaan. Tetapan setiap antara muka yang terpakai, dan mod loose selalunya hanya merekod asimetri dan bukannya membuang paket. Baca kedua-duanya sebelum membuat kesimpulan bahawa penapis itu salah anda.

Hos dengan penghalaan berasaskan dasar memerlukan peraturan selain laluan, kerana asas peraturan memilih jadual sebelum laluan di dalamnya dipertimbangkan. Laluan dalam jadual main tidak kelihatan kepada aliran yang sepadan dengan peraturan yang menunjuk ke jadual lain. Baca peraturan sebelum menambah apa-apa ke main. Jika peraturan sudah meliputi trafik pengurusan, pengecualian itu tergolong dalam jadual peraturan tersebut.

Biarkan konsol di luar jalur terbuka semasa anda menguji, dan semak semula dari log masuk kedua sebelum memutuskan yang sedang anda gunakan. Laluan yang menghantar trafik pengurusan anda sendiri ke dalam tunnel memotong sambungan yang anda sedang baiki. Untuk masuk semula kemudian memerlukan konsol bersiri atau but penyelamat, yang merupakan pertukaran yang buruk kerana melangkau satu langkah pengesahan.