Cara menghantar satu destinasi IPv4 ke luar terowong OpenVPN

Kebanyakan persediaan terowong penuh menghantar setiap paket melalui VPN, dan redirect-gateway ialah arahan yang menjadikannya mungkin. Satu destinasi tunggal masih boleh dikecualikan. Menambah laluan hos untuk alamat itu dengan pemegang tempat net_gateway memberitahu klien untuk mencapainya melalui get laluan asal mesin, manakala segala-galanya terus menggunakan terowong.

Baris itu kelihatan tidak berbahaya dan selalunya begitu, tetapi ia hanya menyelesaikan satu soalan: ke mana paket untuk alamat IPv4 yang tepat itu pergi. Ia tidak mengubah DNS, IPv6, dasar tembok api atau proses mana yang membuka sambungan, dan setiap satunya boleh menggagalkan pengecualian secara senyap.

Apa sebenarnya yang dinamakan net_gateway

Entri profil untuk pengecualian itu ialah satu baris: route 198.51.100.77 255.255.255.255 net_gateway. Alamat pertama ialah pemegang tempat dokumentasi untuk destinasi, topeng menjadikannya laluan hos tunggal, dan token terakhir menamakan pemegang tempat get laluan. OpenVPN menyelesaikan pemegang tempat get laluan apabila ia memasang laluan. vpn_gateway bermaksud get laluan terowong itu sendiri, sisi jauh pautan VPN. net_gateway bermaksud get laluan lalai yang dimiliki hos sebelum VPN mengubah apa-apa, yang biasanya merupakan penghala tempatan pada rangkaian fizikal.

Pemegang tempat ketiga, remote_host, merujuk kepada alamat pelayan VPN, dan ia wujud supaya terowong boleh mencapai pelayan melalui laluan fizikal. Mengelirukan ketiga-tiganya ialah sebab paling biasa sesuatu pengecualian pergi ke tempat yang salah atau gagal dipasang sama sekali.

Nilai itu dibaca semasa menyambung, bukan ditulis ke dalam fail. Jika mesin berpindah ke rangkaian lain, get laluan sebelum VPN berubah dan laluan mengikut yang baharu. Itu biasanya yang anda mahu, tetapi ia juga bermakna tingkah laku pengecualian bergantung pada rangkaian tempat klien bermula.

Mengapa laluan hos mengalahkan laluan lalai terowong

Penghalaan ditentukan oleh awalan sepadan yang paling spesifik. redirect-gateway def1 biasanya tidak menggantikan laluan lalai; ia menambah dua separuh, satu laluan untuk separuh bawah ruang alamat dan satu untuk separuh atas, jadi laluan lalai asal dikekalkan untuk kegunaan lain. Separuh itu lebih luas daripada satu alamat.

Laluan untuk satu alamat dengan topeng 255.255.255.255 ialah /32, iaitu spesifisiti maksimum yang boleh dicapai oleh IPv4. Apabila paket untuk alamat itu dinilai, /32 sepadan dan menang tanpa mengira laluan mana yang dipasang dahulu. Itulah mekanisme di sebalik pengecualian, dan ia berfungsi sama pada Linux, macOS dan Windows selagi laluan itu benar-benar wujud.

Windows menambah dimensi kedua. Apabila dua laluan sama spesifik, yang mempunyai metrik lebih rendah menang, dan penyesuai VPN boleh membawa metrik antara muka yang mengubah hasilnya. /32 masih lebih spesifik daripada kedua-dua separuh, jadi pengecualian biasanya bertahan, tetapi laluan lapuk daripada sesi terdahulu boleh menghasilkan keputusan mengelirukan jika ia sama spesifik.

Apa yang tidak diliputi oleh pengecualian

DNS ialah jurang pertama. Klien boleh menolak tetapan penyelesai dalaman, dan sistem pengendalian akan terus menggunakannya untuk carian. Aplikasi yang menyelesaikan nama sebelum menyambung boleh menerima alamat dalaman untuk perkhidmatan yang sepatutnya pergi terus, atau alamat luaran yang diselesaikan dengan betul tetapi kemudian tersadung pada jurang seterusnya.

IPv6 ialah yang kedua. Arahan laluan hanya mengendalikan IPv4. Destinasi dwi-timbunan mungkin mengutamakan IPv6, yang mengikut terowong atau laluan lalai IPv6 hos bergantung pada dasar, jadi pengecualian IPv4 tidak pernah berkuat kuasa. Anda memerlukan laluan IPv6 yang sepadan, atau keputusan sengaja untuk melumpuhkan IPv6 bagi klien itu.

Skop aplikasi ialah yang ketiga. Peraturan itu berdasarkan destinasi, jadi setiap proses yang menyambung ke alamat itu menggunakan laluan langsung, sama ada itulah yang anda maksudkan atau tidak. Sebaliknya, tapak web boleh menjawab dari beberapa alamat, jadi mengecualikan satu /32 tidak mengecualikan tapak itu. Jika keperluan sebenar ialah penghalaan mengikut aplikasi, jadual laluan klien Community ialah alat yang salah.

Menyemak pengecualian tanpa menipu diri sendiri

Mulakan dengan laluan yang dipasang, bukan pelayar. Pada Linux, tanya kernel laluan dan hop seterusnya yang akan digunakan untuk alamat tertentu; pada Windows, baca jadual laluan untuk /32 itu. Sahkan get laluan itu yang fizikal dan bukan terowong. Jika entri tiada, profil tidak digunakan atau klien tidak mempunyai keistimewaan untuk menukar laluan.

Kemudian uji dua destinasi. Permintaan ke alamat yang dikecualikan sepatutnya keluar melalui antara muka fizikal, dan permintaan ke alamat dalaman kawalan sepatutnya masih menggunakan terowong. Menguji hanya alamat yang dikecualikan tidak membuktikan apa-apa tentang baki terowong, dan menguji tapak web awam menguji alamat yang tapak itu selesaikan, yang mungkin bukan alamat dalam peraturan.

Akhir sekali, semak kawalan yang boleh mengatasi laluan. Kill switch sebelah klien atau tetapan block-outside-dns Windows boleh melarang trafik langsung, yang kelihatan sebagai sambungan yang gagal walaupun laluan itu betul. Jangan matikan kawalan itu untuk membuat pengecualian kelihatan berfungsi; jika dasar melarang laluan langsung, pengecualian ialah masalah reka bentuk bagi pemilik perkhidmatan VPN.

Semak semula selepas menyambung semula atau menukar rangkaian, kerana get laluan sebelum VPN dan laluan yang tersedia ialah sifat saat itu, bukan sifat profil.