route-gateway bukan redirect-gateway: apa yang sebenarnya berubah
Opsi ini hanya memberi hop berikutnya bagi rute yang dipasang OpenVPN. Menghapusnya tidak mematikan tunnel penuh yang didorong, dan perbaikannya ada pada pengalihan.
Tunnel Anda naik, subnet privat menjawab, dan penjelajahan biasa tetap menghilang ke dalam VPN meski seseorang telah menghapus baris gateway dari profil. Kombinasi itu adalah sidik jari dari direktif yang salah diedit. Yang dihapus memberi klien hop berikutnya untuk rute yang dipasangnya; yang terus menangkap lalu lintas datang dari tempat lain dan didorong oleh server. Cakupan dan hop berikutnya adalah tugas terpisah, dan hanya satu di antaranya yang menentukan apakah tujuan publik memakai tunnel.
Baris yang Anda hapus adalah hop berikutnya, bukan sakelar kebijakan
Setiap rute yang dipasang klien memerlukan alamat gateway untuk dituju, dan direktif gateway adalah asal alamat itu ketika sebuah rute tidak menyebutkan sendiri. Hapus itu dan rute-rute tersebut tidak punya tempat bergantung, sehingga mereka entah gagal dipasang atau mendarat di jalur yang tidak menuju ke mana-mana. Subnet privat justru hal yang dibawa oleh rute semacam itu.
Sementara itu perilaku yang bertahan punya penulis lain: opsi pengalihan di blok yang didorong, yang memindahkan lalu lintas keluar biasa ke dalam tunnel sesuai flag-nya. Menghapus gateway tidak menonaktifkannya dan tidak melemahkannya. Hasilnya adalah yang terburuk dari kedua keadaan, dengan lalu lintas publik masih tertangkap dan tujuan privat yang menjadi alasan tunnel kini tak terjangkau. Itu sebabnya suntingan kedua, yang dibuat dengan semangat sama, juga tidak mengubah apa pun.
Empat tuas, empat tugas berbeda
Empat direktif dikutip secara bergantian dalam diskusi ini, dan hanya satu yang mengatur cakupan, yaitu tujuan mana yang benar-benar dirutekan melalui tunnel. Yang kedua menetapkan hop berikutnya yang dipakai rute, yang ketiga memasang satu prefiks, dan yang keempat membuang semua yang didorong server, termasuk rute privat yang dibutuhkan penerapan. Tabel mengurutkannya menurut apa yang ingin diubah administrator, bukan menurut nama, karena nama-nama itulah yang menyebabkan kebingungan. Perlakukan sebagai empat keputusan terpisah dan pilih yang benar-benar ingin Anda balikkan.
Dalam praktik keempatnya sering datang dalam satu blok yang didorong, baris demi baris, sehingga tampak seperti bagian dari satu pengaturan. Bukan begitu, dan referensi OpenVPN mendokumentasikannya sebagai mekanisme berbeda justru karena alasan itu. Mencari tahu keputusan mana yang Anda balikkan adalah tugasnya; penyuntingannya satu baris.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
Filter baris yang didorong, pertahankan hop berikutnya
Jika cakupan yang Anda keberatkan datang sebagai opsi yang didorong, respons sempit adalah mengabaikan opsi itu berdasarkan namanya dan membiarkan bagian lain dari blok yang didorong tetap utuh. Ditulis sebagai filter, tampilannya seperti baris di bawah ini, dan tempatnya di profil klien yang terdampak, bukan di konfigurasi server.
pull-filter ignore "redirect-gateway"Kesempitan itulah intinya. Karena filter membandingkan prefiks teks, pola yang lebih pendek juga cocok dengan direktif hop berikutnya, yang mengupas tepat informasi yang menjadi sandaran rute privat dan mengulangi kesalahan awal dalam kostum baru. Filter juga hanya bekerja pada opsi yang didorong, jadi tidak pernah menyentuh baris setara yang ditulis lokal atau dipaksakan oleh manajer jaringan. Sambungkan ulang sesudahnya, karena sesi hidup tidak mengevaluasi ulang apa yang didorong server.
Baca pencariannya, bukan tabelnya
Setelah memuat ulang profil, tanyakan ke kernel ke mana dua tujuan sebenarnya akan pergi: satu di dalam prefiks privat dan satu di internet publik. Dump lengkap tabel utama lebih sulit dibaca dan lebih mudah salah dibaca, karena rute bisa ada dan tetap kalah dari kecocokan yang lebih spesifik. Pada perutean berbasis kebijakan, aturan, tabel, dan alamat sumber juga termasuk dalam pemeriksaan.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showVarian def1 layak dikenali, karena ia membiarkan entri default lama tetap terlihat sementara sepasang setengah-default memenangkan pencarian. Jadi baris 0.0.0.0/0 di keluaran tidak membuktikan apa pun dengan sendirinya. Pencarian menjawab pertanyaan yang tampaknya hanya dijawab oleh daftar.
DNS, IPv6, dan rute privat tetap harus berfungsi
Menolak satu pengalihan IPv4 tidak mengatakan apa pun tentang resolver, sehingga opsi DNS yang didorong bisa terus mengirim kueri ke dalam tunnel sementara rute tampak benar. Default IPv6 dapat melakukan hal yang sama untuk keluarga alamat yang tidak pernah disentuh pemeriksaan IPv4. Keduanya memerlukan keputusan eksplisit, bukan asumsi. Lalu pastikan layanan privat masih menjawab, karena tunnel terbelah yang kehilangan rute privatnya bukan tunnel terbelah, melainkan tunnel rusak.
Satu alat yang lebih lebar pantas diberi peringatan: route-nopull membuang setiap rute yang didorong dan setiap opsi DNS yang didorong, yang pasti menghentikan tunnel penuh dan sama pastinya merusak rute privat yang menjadi sandaran penerapan, jadi itu palu yang jauh lebih besar daripada filter nama yang diarahkan ke satu opsi. Periksa tujuan privat, tujuan publik, dan resolver setelah setiap perubahan, dan anggap jabat tangan yang selesai sebagai bukti tidak ada apa pun selain jabat tangan itu.