Apa yang sebenarnya dicegah route-nopull OpenVPN dari dorongan server

Anda menaruh route-nopull di profil klien agar terowongan tidak menelan rute default Anda, dan sekarang subnet kantor tidak terjangkau sementara klien masih menyatakan terhubung. Kedua pengamatan itu benar, dan tidak ada yang gagal. Flag tersebut memberi tahu klien untuk melewati rute dan entri DHCP yang didorong server, sebuah instruksi yang lebih sempit daripada yang diharapkan kebanyakan orang saat menambahkannya. Yang tersisa adalah terowongan yang berfungsi tanpa pendapat tentang tujuan mana yang harus memakainya.

Celah itulah seluruh keputusan yang dibahas artikel ini. Entah server yang menjelaskan jaringan, atau klien, dan flag tersebut menyerahkan tugas itu kepada klien tanpa mengerjakan apa pun untuk Anda.

Apa yang dimatikan flag saat terhubung

Klien OpenVPN yang menarik biasanya menerima paket dari server setelah autentikasi: rute, pengalihan gateway default, server DNS, dan beberapa direktif penyetelan. Dengan route-nopull berlaku, klien tetap menerima sesi, tetap memverifikasi sertifikat, tetap menegosiasikan cipher dan keepalive, dan tetap menaikkan antarmuka. Yang dibuangnya adalah penerapan baris route yang didorong dan baris dhcp-option yang didorong, termasuk DNS.

Kebingungan berasal dari indikator hijau di samping aplikasi yang mati. Terowongannya ada; pemetaan tujuan ke terowongan itu tidak ada. Tidak ada yang membedakan «terhubung dan merutekan» dari «terhubung dan pasif» di panel status klien, karena dari sudut pandang terowongan keduanya adalah keadaan yang sama.

Mengapa terowongan yang hidup tetap bisa tidak merutekan apa pun

Antarmuka muncul dengan alamatnya sendiri dan, pada tautan titik-ke-titik, sering tidak ada yang lebih spesifik daripada rute host ke rekan. Subnet privat baru bisa dijangkau ketika suatu rute menunjuk ke antarmuka itu dengan prefiks yang benar, dan dengan pendorongan dimatikan rute tersebut tidak pernah datang. Profil yang diunduh juga biasanya tidak bisa membantu, karena ditulis dengan asumsi server akan memasok persis informasi ini. Itulah sebabnya antarmuka bisa tampak sehat sementara subnet tetap gelap.

Membaca profil karena itu membuktikan sangat sedikit. Bacalah keadaan yang berjalan, di mesin yang terhubung:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Alamat tanpa rute subnet di perintah kedua adalah tanda tangan masalah ini. Perintah ketiga lalu menjawab pertanyaan yang benar-benar dipedulikan pengguna, karena melaporkan antarmuka yang akan dipilih kernel untuk tujuan tertentu alih-alih daftar yang Anda harap dipakai. Jika ia menjawab lewat tautan fisik Anda, terowongan sama sekali tidak ada di jalur.

Resolusi nama gagal karena alasan yang terkait, bukan alasan terpisah. Entri dhcp-option DNS yang didorong dilewati oleh flag yang sama, sehingga kueri untuk host internal pergi ke resolver mana pun yang disediakan jaringan lokal. Resolver itu tidak punya zona untuk kantor, jadi kueri gagal atau mengembalikan jawaban publik, dan kegagalan itu tampak seperti masalah server padahal masalah konfigurasi klien. Menguji alamat sebelum nama adalah yang memisahkan keduanya.

Memilih antara flag dan penyaring prefiks

Kedua opsi memecahkan bentuk berbeda dari keluhan yang sama, dan pilihan yang buruklah yang menghasilkan keadaan terhubung-tetapi-tak-berguna. Satu mengganti kebijakan yang didorong sepenuhnya, sedangkan yang lain menyuntingnya per prefiks. Tabel memberi versi singkatnya, dan paragraf sesudahnya mencakup bagian yang mengejutkan orang.

pull-filter adalah pencocok prefiks dengan tiga kata kerja, jadi ia bisa menerima keluarga baris, mengabaikannya diam-diam, atau menolak koneksi sepenuhnya ketika suatu prefiks muncul. Perilaku terakhir itulah yang perlu diketahui: aturan penolakan mengubah perbedaan kebijakan menjadi handshake yang gagal alih-alih penghilangan yang tenang. Manual OpenVPN 2.6 mencantumkan prefiks yang diterima dan semantik persis tiap kata kerja.

Jalan tengah yang umum adalah menolak hanya redirect-gateway dan membiarkan rute kantor serta DNS datang sebagaimana dimaksud. Itu menjaga pendorongan tetap bekerja untuk bagian yang server pahami lebih baik daripada Anda, sekaligus mencegah satu-satunya baris yang akan mengambil alih rute default Anda.

Menambahkan rute dan resolver secara manual

Jika Anda mempertahankan flag, profil harus mengatakan apa yang akan dikatakan server. Direktif route di sisi klien diterapkan setelah koneksi terbentuk, jadi ia bekerja bersama flag alih-alih diblokir olehnya. Taruh di profil, bukan di baris perintah interaktif, atau sambungan ulang berikutnya tidak akan mereproduksi keadaan yang berfungsi.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

Baris DNS berada di posisi yang canggung: ini direktif sisi klien, tetapi sebagian klien hanya menerapkannya lewat integrasi DNS platform, yang bisa menimpanya saat tautan berubah. Pada host systemd, menyetel resolver langsung di antarmuka terowongan lebih dapat diprediksi daripada berharap klien memenangkan persaingan prioritas:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Domain perutean sama pentingnya dengan alamat. Tanpanya, kueri untuk nama publik juga bisa dikirim ke resolver internal, dan resolver internal mana pun yang menolak rekursi akan mematahkan penjelajahan sementara zona privat tetap bekerja. Dengannya, hanya nama di bawah sufiks itu yang dirutekan ke resolver terowongan dan sisanya mengikuti tautan fisik.

Memeriksa hasilnya: alamat, nama, dan jalur luar

Tiga uji memisahkan kemungkinan kegagalan. Ambil alamat privat lewat IP, lalu host yang sama lewat nama, lalu situs publik biasa. IP yang bekerja dengan nama yang gagal menunjuk ke resolver; IP yang gagal dengan nama yang bekerja menunjuk ke perutean; keduanya gagal biasanya berarti terowongan tidak ada di jalur.

Lalu lihat ke luar, bukan ke dalam. Rute titik akhir terowongan itu sendiri harus bertahan terhadap perubahan, dan setiap kegagalan pemblokiran harus dibatasi ke terowongan tanpa menangkap titik akhir. Klien yang terus menjelajah setelah terowongan jatuh adalah masalah kebijakan, bukan perutean, dan itu tidak akan muncul di salah satu dari tiga uji di atas.

Tuliskan daftar akhir di dokumentasi profil: rutenya, resolver, domain, dan alasan masing-masing ada. Sambungan ulang yang mereproduksi tabel yang sama adalah satu-satunya bukti bahwa kebijakan lokal lengkap. Jika aplikasi masih gagal dengan terowongan menyala dan ketiga uji lulus, tempat berikutnya untuk melihat adalah kelas masalah terhubung-tetapi-luring, bukan sertifikat yang sudah diverifikasi.