Apa yang sebenarnya ditambahkan bypass-dhcp ke rencana rute OpenVPN

Profil yang membawa redirect-gateway def1 bypass-dhcp menggabungkan penggantian rute IPv4 bawaan dengan satu pengecualian yang sempit. Orang membaca kata terakhir dan mengharapkan solusi umum untuk koneksi seluler, lalu menghabiskan seharian dengan teori DHCP yang tidak pernah didukung flag ini. Setiap bagian melakukan satu hal, dan pengecualiannya jauh lebih kecil daripada reputasinya.

Uraikan flag-flag itu sebelum mengaitkan kegagalan khusus seluler dengan pemberian alamat. Dua bagian dari string itu tidak ada hubungannya satu sama lain.

Dua flag, dua tugas tak berhubungan

Dengan def1, klien menambahkan dua setengah-rute IPv4 bawaan alih-alih mengganti rute bawaan yang sudah ada. 0.0.0.0/1 mencakup separuh bawah ruang alamat dan 128.0.0.0/1 separuh atas, sehingga bersama-sama keduanya mencapai setiap tujuan sementara masing-masing tetap lebih spesifik daripada 0.0.0.0/0. Rute bawaan asli karena itu tetap ada di tabel tanpa memenangkan pencarian tersebut, yang membuat gateway lama tetap terjangkau untuk apa pun yang dirutekan klien secara eksplisit. Ini juga menyisakan dua rute bawaan yang tumpang tindih di tabel, dan itulah sebabnya dump rute bisa tampak lebih aneh daripada yang disiratkan profil.

bypass-dhcp terpisah, dan sama sekali tidak menyentuh rute bawaan. Manual OpenVPN 2.6 mendokumentasikannya sebagai penambahan rute langsung ke server DHCP yang tidak berada di subnet lokal, sehingga lalu lintas sewa keluar di luar tunnel, dan mencatat bahwa perilaku itu diterapkan pada klien Windows dan mungkin tidak tersedia di tempat lain.

Alasan keberadaannya bersifat mekanis. Setelah setengah-rute bawaan menangkap lalu lintas keluar, pembaruan DHCP yang ditujukan ke server di jaringan fisik akan dirutekan ke dalam tunnel kecuali ada sesuatu yang memaku alamat itu ke antarmuka sebenarnya. Flag itu memakunya.

Apa cakupan pengecualian itu sebenarnya

Tabel ilustratif setelah koneksi berhasil menunjukkan bentuknya: dua setengah-rute bawaan melalui tunnel, dan satu rute host untuk server DHCP melalui gateway fisik. Bacalah sebagai bentuk, bukan sebagai alamat Anda sendiri.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

Baris ketiga itu menyebut satu tujuan. Itu bukan pengaturan resolver, bukan izin umum untuk jaringan lokal, dan bukan aturan keluar di server. Ponsel pada penyedia seluler mungkin tidak memiliki server DHCP yang bisa dikenali klien dengan cara ini, dan itulah sebabnya flag tidak mengubah apa pun di sana.

Periksa apa yang benar-benar dipasang klien

Bedakan opsi yang tertulis di profil, opsi yang ditawarkan server, dan rute yang benar-benar diterapkan pemilik koneksi. Klien yang menolak flag tak didukung mungkin mempertahankan sisa konfigurasi, sehingga tunnel tetap naik dan pengecualiannya sekadar tidak ada. Baca log klien itu sendiri dan tabel rute yang dihasilkan alih-alih menganggap baris di berkas sudah berlaku. Tiga dari hal itu bisa benar sekaligus, dan hanya yang terakhir mengubah ke mana paket sebenarnya pergi.

Jaga rute ke endpoint VPN tetap dapat digunakan pada saat yang sama. Pengecualian endpoint itu persyaratan yang berbeda dari pengecualian DHCP, dan tanpanya tunnel dapat menangkap transport yang menjaganya.

Untuk tujuan aplikasi, periksa pencarian efektif dalam konteks tempat ia gagal. Rute lokal yang lebih spesifik, perutean kebijakan, dan pengecualian per aplikasi semuanya mengubah jawabannya, jadi adanya dua setengah-rute bawaan bukan inventaris setiap aliran.

Sisa jalurnya tidak ada di flag ini

Server tetap memerlukan izin untuk meneruskan lalu lintas internet klien dan pengaturan keluar yang dapat mengembalikannya. Tidak ada rute di sisi klien yang menciptakan penerusan atau terjemahan sumber yang hilang di server, dan tidak ada flag yang menggantikan jalur balik yang berfungsi.

Resolusi nama dan IPv6 masing-masing memerlukan kebijakannya sendiri. Penggantian IPv4 tidak mengarahkan resolver ke server di sisi tunnel dan tidak membangun cakupan IPv6, dan klien yang hanya mengalihkan v4 membiarkan jalur v6 tak tersentuh.

Bandingkan satu permintaan tak berbahaya yang disetujui pada jalur akses yang berfungsi dan yang gagal, dengan profil dan tujuan dijaga tetap. Catat apakah perbedaannya ada pada resolusi nama, pembentukan tunnel, pemilihan rute, atau lalu lintas yang diteruskan, dan simpan jawabannya bersama profil. Catatan itulah yang mencegah orang berikutnya menyalahkan DHCP atas masalah yang tidak dapat dijangkau olehnya.