Menjalankan klien VPN melalui SSH? Sematkan dahulu laluan anda sendiri

Anda masuk melalui SSH ke hos binaan, jalankan klien VPN di atasnya, dan sesi berhenti menjawab. Tiada apa yang ranap, dan tiada apa yang kelihatan salah dikonfigurasikan dalam erti kata yang jelas. Klien memasang laluan lalai, jadi balasan ke stesen kerja anda kini keluar melalui terowong, di mana alamat stesen kerja anda tidak boleh dilalukan. Bahagian yang menarik ialah hasil ini boleh dijangka, dan pembetulannya ialah satu laluan yang ditulis sebelum klien bermula. Andaikan pelayan dengan satu kad rangkaian, get laluan 192.0.2.254, dan pentadbir yang menyambung dari 203.0.113.9.

Catat laluan sebelum anda bermula

ip route show default menamakan get laluan dan antara muka semasa, manakala ip route get 203.0.113.9 menunjukkan antara muka dan alamat sumber yang akan digunakan oleh kernel untuk sesi anda. Simpan kedua-dua output. Selepas terowong naik, kedua-dua arahan itu sepatutnya masih menerangkan laluan fizikal, dan jika ia menerangkan terowong pula, sesi itu sudah hidup atas masa pinjaman.

Sambungan yang telah terbentuk itulah yang penting, jadi jangan sahkan hanya dengan log masuk baharu. Sesi baharu mungkin berjaya sebentar melalui keadaan yang tidak lagi dimiliki sesi lama.

Sematkan alamat dalam konfigurasi klien itu sendiri

Laluan yang ditambah dengan tangan hilang selepas but semula dan bersaing dengan kemas kini jadual klien itu sendiri, jadi letakkan pengecualian di tempat jadual diurus. Di bawah OpenVPN kata kunci net_gateway diselesaikan kepada get laluan yang wujud sebelum terowong, jadi route 203.0.113.9 255.255.255.255 net_gateway menyimpan tepat satu alamat di luarnya. WireGuard memerlukan pendekatan berbeza kerana wg-quick mengurus laluan sendiri: tetapkan Table = off dan tambah pengecualian dalam PostUp, dengan PostDown sepadan yang mengeluarkannya. Kedua-dua bentuk menyatakan niat yang sama, dan kedua-duanya mengehadkan pengecualian kepada satu alamat dan bukannya melemahkan terowong untuk semua.

Untuk IPv6 idea yang sama mengambil awalan satu hos, dan kes pengangkutan terbungkus wajar diingat: jika sambungan luar terowong itu sendiri berada pada alamat tetap, alamat itu mesti kekal di luar terowong yang dibawanya, jika tidak klien melalukan pengangkutannya sendiri ke dalam dirinya.

Atau keluarkan jadual utama daripada persamaan

Apabila beberapa perkhidmatan pada hos mesti mengekalkan laluan biasa mereka, berhenti menyunting jadual utama dan berikan klien jadualnya sendiri. Ruang nama rangkaian dengan pasangan veth melakukannya dengan bersih: laluan lalai klien berada dalam tindanan lain dan hanya proses yang dimulakan di dalamnya menggunakan terowong. Penghalaan dasar mencapai tempat yang serupa untuk satu destinasi, dengan menghantar trafik yang sepadan ke jadual khusus yang lalainya masih menghala ke get laluan fizikal. Mana-mana pendekatan meninggalkan jadual utama hos tanpa laluan lalai baharu, dan sifat itulah yang memastikan SSH terus menjawab.

Kedua-duanya lebih banyak jentera daripada satu laluan hos, dan kedua-duanya berbaloi apabila lebih daripada satu perkara pada mesin itu perlu bertahan melalui terowong.

Anggapkan penyematan boleh gagal

Laluan yang dikunci kepada alamat awam semasa anda rosak pada saat penyedia anda menetapkannya semula. Pelayan jauh kemudian memerlukan laluan yang tidak bergantung pada alamat itu: konsol, antara muka pengurusan kedua, atau hos lompat yang kekal di luar terowong.

Dua langkah perlindungan mengambil masa sepuluh minit. Pemantau yang menghentikan klien jika log masuk pengesahan tidak muncul dalam beberapa minit menukar kuncian menjadi kelewatan, dan sesi SSH kedua yang dibiarkan terbuka semasa perubahan membuktikan pengecualian berfungsi ketika terowong naik. Keepalive sahaja tidak membantu di sini, kerana laluan itu sudah hilang dan bukan melahu; ia hanya menjadikan kematian lebih mudah disedari.

Sahkan dalam urutan yang penting

Sambungkan terowong, pastikan laluan ke alamat anda masih keluar melalui get laluan fizikal, kemudian buka sesi baharu. Jika sesi baharu berjaya dan sesi lama tetap mati, puncanya ialah penjejakan sambungan atau firewall berkeadaan dan bukan penghalaan, yang merupakan pembetulan berbeza.

Tulis alamat yang disematkan dan arahan yang membuktikannya dalam rekod perubahan. Orang seterusnya yang menjalankan klien pada hos itu akan memerlukan kedua-duanya, dan alamat itu mungkin sudah berubah menjelang itu.