Anda menyambung terowong, menjalankan ip route, dan get laluan lalai asal masih di situ. Fikiran seterusnya ialah klien gagal mengambil alih laluan, jadi anda memadam laluan lalai secara manual dan kehilangan sambungan sepenuhnya. Entri itu sepatutnya kekal. Dengan redirect-gateway def1, OpenVPN memasang dua laluan yang lebih khusus yang mengatasi laluan lalai biasa dan bukannya menggantikannya. Get laluan lama kekal dan berhenti membawa trafik yang anda uji.

Apa yang def1 sebenarnya lakukan

Bendera itu menambah 0.0.0.0/1 dan 128.0.0.0/1, kedua-duanya menghala ke terowong. 0.0.0.0/1 meliputi setiap alamat yang oktet pertamanya 0 hingga 127, dan 128.0.0.0/1 meliputi 128 hingga 255, jadi setiap destinasi IPv4 mempunyai padanan yang lebih khusus daripada laluan lalai lama. Panjang awalan, bukan metrik, menentukan laluan mana yang menang.

Membiarkan laluan lalai asal di tempatnya adalah disengajakan. Klien tidak perlu mengingati apa yang digantikannya, dan ia tidak menulis semula laluan yang membawa sambungannya sendiri ke pelayan VPN. Semasa memutuskan sambungan ia mengalih keluar dua separuh laluan itu dan jadual kembali seperti asalnya.

Mengapa /1 dan bukan /0

Penghalaan memilih awalan padanan terpanjang, bukan metrik terendah, jadi /1 mengalahkan /0 apa pun yang dikatakan metrik laluan lalai. Kedua-dua bahagian wujud kerana satu /1 hanya meliputi separuh ruang; apabila hanya 0.0.0.0/1 hadir, segala-galanya dari 128.0.0.0 ke atas masih mengikut laluan lalai lama, yang menghasilkan gejala mengelirukan apabila sesetengah laman berfungsi dan yang lain tidak.

Menaikkan atau menurunkan metrik laluan lalai lama tidak mengubah apa-apa, dan laluan lalai dengan metrik lebih rendah pada antara muka lain juga tidak mencuri trafik. Panjang awalan yang menentukan dahulu, dan hanya awalan yang sama kembali kepada metrik.

Baca jadual penghalaan sebenar

Hos yang bersambung boleh menunjukkan ketiga-tiga entri sekali gus, dengan terowong membawa kedua-dua bahagian dan get laluan asal masih tersenarai. Alamat-alamat itu contoh dan bukan konfigurasi untuk disalin, kerana nama antara muka, topologi terowong dan laluan tambahan berbeza mengikut platform dan klien.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

Yang penting ialah hubungannya: dua bahagian khusus di atas satu laluan lalai umum. Baris get laluan lama kekal kerana tiada apa yang menggantikannya.

Semak laluan mana yang benar-benar diambil oleh paket

Laluan yang lebih khusus masih boleh menang: laluan untuk julat peribadi, subrangkaian setempat atau alamat pelayan VPN itu sendiri lebih panjang daripada /1. Terowong memerlukan laluan luar ke pelayannya, dan menghantar sambungan itu kembali ke dalam terowong akan memutuskannya serta-merta. Di Linux tanyakan kernel dan bukannya membaca jadual dengan mata: ip route get dengan destinasi yang anda minati mencetak laluan yang dipilih, antara muka dan sumber. Jika penghalaan berasaskan dasar dikonfigurasikan, periksa juga peraturannya, kerana peraturan boleh memilih jadual lain sebelum jadual utama dirujuk.

Jika hanya sebahagian IPv4 berkelakuan salah, pastikan kedua-dua bahagian dipasang dan kemudian cari pengecualian yang sepadan dengan destinasi yang gagal. Memadam laluan lalai lama bukan penyelesaian, dan ia mengalih keluar laluan yang diperlukan klien untuk membongkar terowong dengan bersih.

Apa yang def1 tidak liputi

Dua entri IPv4 tidak mengatakan apa-apa tentang IPv6: hos dengan sambungan IPv6 terus menggunakan laluan lalainya sendiri sehingga sesuatu mengubah hala keluarga itu secara berasingan, itulah sebabnya pada rangkaian dwi-tindanan sebahagian trafik kelihatan memintas terowong. Klien dan pengurus rangkaian lain melaksanakan penghalaan terowong penuh secara berbeza, dan jadual mereka tidak akan sepadan. Tingkah laku def1 yang diterangkan di sini milik bendera OpenVPN yang didokumenkan, bukan setiap VPN pada mesin itu.

Suis pembunuh menjawab soalan lain: apa yang mesin lakukan apabila terowong tumbang. Keutamaan laluan menentukan ke mana trafik pergi semasa terowong aktif; ia tidak menentukan apa yang dilakukan oleh tembok api selepas itu. Urutan kerja: baca jadual, pastikan kedua-dua bahagian wujud, jalankan ip route get untuk destinasi yang gagal, periksa peraturan dasar, kemudian lihat IPv6 secara berasingan. Biarkan laluan lalai lama di tempatnya.

Artikel berkaitan