Cara mengirim satu tujuan IPv4 ke luar terowongan OpenVPN
Satu rute host melalui net_gateway dapat mengirim satu alamat IPv4 ke luar terowongan OpenVPN. Periksa hop berikutnya, cakupan DNS, IPv6, dan pemblokiran klien apa pun.
Sebagian besar penyiapan terowongan penuh mengirim setiap paket melalui VPN, dan redirect-gateway adalah direktif yang membuatnya demikian. Satu tujuan tetap dapat dikecualikan. Menambahkan rute host untuk alamat itu dengan placeholder net_gateway memberi tahu klien untuk mencapainya melalui gateway asli mesin, sementara semua yang lain tetap menggunakan terowongan.
Baris itu tampak tidak berbahaya dan sering memang begitu, tetapi ia hanya menyelesaikan satu pertanyaan: ke mana paket untuk alamat IPv4 yang tepat itu pergi. Ia tidak mengubah DNS, IPv6, kebijakan firewall, atau proses mana yang membuka koneksi, dan masing-masing hal itu dapat menggagalkan pengecualian secara diam-diam.
Apa yang sebenarnya dinamai net_gateway
Entri profil untuk pengecualian itu adalah satu baris: route 198.51.100.77 255.255.255.255 net_gateway. Alamat pertama adalah placeholder dokumentasi untuk tujuan, mask membuatnya menjadi rute satu host, dan token terakhir menamai placeholder gateway. OpenVPN menyelesaikan placeholder gateway saat memasang rute. vpn_gateway berarti gateway terowongan itu sendiri, sisi jauh tautan VPN. net_gateway berarti gateway default yang dimiliki host sebelum VPN mengubah apa pun, yang biasanya merupakan router lokal di jaringan fisik.
Placeholder ketiga, remote_host, merujuk pada alamat server VPN, dan keberadaannya agar terowongan dapat mencapai server melalui jalur fisik. Mencampuradukkan ketiganya adalah alasan paling umum sebuah pengecualian menuju tempat yang salah atau gagal dipasang sama sekali.
Nilai itu dibaca saat menghubungkan, bukan ditulis ke dalam berkas. Jika mesin berpindah ke jaringan lain, gateway sebelum VPN berubah dan rute mengikuti yang baru. Itu biasanya yang Anda inginkan, tetapi itu juga berarti perilaku pengecualian bergantung pada jaringan tempat klien memulai.
Mengapa rute host mengalahkan rute default terowongan
Perutean ditentukan oleh prefiks yang paling spesifik dan cocok. redirect-gateway def1 biasanya tidak menggantikan rute default; ia menambahkan dua bagian, rute untuk separuh bawah ruang alamat dan satu untuk separuh atas, sehingga rute default asli dipertahankan untuk kegunaan lain. Bagian-bagian itu lebih luas daripada satu alamat.
Rute untuk satu alamat dengan mask 255.255.255.255 adalah /32, yang merupakan spesifisitas maksimum yang bisa dicapai IPv4. Saat paket untuk alamat itu dievaluasi, /32 cocok dan menang tanpa memandang rute mana yang dipasang lebih dulu. Itulah mekanisme di balik pengecualian, dan ia bekerja sama di Linux, macOS, dan Windows asalkan rutenya benar-benar ada.
Windows menambahkan dimensi kedua. Saat dua rute sama spesifiknya, yang metriknya lebih rendah menang, dan adaptor VPN dapat membawa metrik antarmuka yang mengubah hasilnya. /32 tetap lebih spesifik daripada kedua bagian, jadi pengecualian biasanya bertahan, tetapi rute usang dari sesi sebelumnya dapat menghasilkan hasil yang membingungkan jika sama spesifiknya.
Apa yang tidak dicakup pengecualian
DNS adalah celah pertama. Klien dapat mendorong pengaturan resolver internal, dan sistem operasi akan terus menggunakannya untuk pencarian. Aplikasi yang menyelesaikan nama sebelum menghubungkan dapat menerima alamat internal untuk layanan yang seharusnya langsung, atau alamat eksternal yang terselesaikan dengan benar tetapi kemudian tersandung pada celah berikutnya.
IPv6 adalah yang kedua. Direktif rute hanya menangani IPv4. Tujuan tumpukan ganda dapat memilih IPv6, yang mengikuti terowongan atau rute default IPv6 host tergantung kebijakan, sehingga pengecualian IPv4 tidak pernah berlaku. Anda memerlukan rute IPv6 yang cocok, atau keputusan sadar untuk menonaktifkan IPv6 bagi klien itu.
Cakupan aplikasi adalah yang ketiga. Aturannya berbasis tujuan, jadi setiap proses yang terhubung ke alamat itu menggunakan jalur langsung, baik itu yang Anda maksud atau bukan. Sebaliknya, sebuah situs web dapat menjawab dari beberapa alamat, jadi mengecualikan satu /32 tidak mengecualikan situs itu. Jika kebutuhan sebenarnya adalah perutean per aplikasi, tabel rute klien Community adalah alat yang salah.
Memeriksa pengecualian tanpa menipu diri sendiri
Mulailah dari rute yang terpasang, bukan dari peramban. Di Linux, tanyakan kepada kernel rute dan hop berikutnya yang akan digunakan untuk alamat tertentu; di Windows, baca tabel rute untuk /32 itu. Pastikan gateway-nya yang fisik, bukan terowongan. Jika entrinya tidak ada, profil tidak diterapkan atau klien tidak memiliki hak istimewa untuk mengubah rute.
Lalu uji dua tujuan. Permintaan ke alamat yang dikecualikan harus keluar melalui antarmuka fisik, dan permintaan ke alamat internal kontrol harus tetap menggunakan terowongan. Menguji hanya alamat yang dikecualikan tidak membuktikan apa pun tentang sisa terowongan, dan menguji situs web publik menguji alamat ke mana situs itu diselesaikan, yang mungkin bukan alamat dalam aturan.
Terakhir, periksa kontrol yang dapat mengesampingkan rute. Kill switch sisi klien atau pengaturan block-outside-dns Windows dapat melarang lalu lintas langsung, yang tampak sebagai koneksi yang gagal meskipun rutenya benar. Jangan nonaktifkan kontrol itu agar pengecualian terlihat berfungsi; jika kebijakan melarang jalur langsung, pengecualian adalah masalah desain bagi pemilik layanan VPN.
Periksa ulang setelah menyambung kembali atau berganti jaringan, karena gateway sebelum VPN dan jalur yang tersedia adalah sifat momen, bukan sifat profil.