route-gateway bukan redirect-gateway: apa yang sebenarnya berubah
Pilihan ini hanya memberikan hop seterusnya kepada laluan yang dipasang OpenVPN. Mengalih keluarnya tidak mematikan terowong penuh yang ditolak, dan pembetulan terletak pada ubah hala.
Terowong anda naik, subnet peribadi menjawab, dan pelayaran biasa masih hilang ke dalam VPN walaupun seseorang telah memadam baris gateway daripada profil. Gabungan itu ialah cap jari direktif yang salah yang diedit. Apa yang dialih keluar memberi klien hop seterusnya untuk laluan yang dipasangnya; apa yang terus menangkap trafik datang dari tempat lain dan ditolak oleh pelayan. Liputan dan hop seterusnya ialah tugas berasingan, dan hanya satu daripadanya menentukan sama ada destinasi awam menggunakan terowong.
Baris yang anda alih keluar ialah hop seterusnya, bukan suis dasar
Setiap laluan yang dipasang klien memerlukan alamat gateway untuk dituju, dan direktif gateway ialah sumber alamat itu apabila laluan tidak menamakan satu sendiri. Padamkannya dan laluan itu tidak mempunyai tempat untuk berpaut, jadi ia sama ada gagal dipasang atau mendarat di laluan yang tidak menuju ke mana-mana. Subnet peribadi ialah tepat apa yang dibawa oleh laluan sedemikian.
Sementara itu tingkah laku yang terselamat mempunyai pengarang lain: pilihan ubah hala dalam blok yang ditolak, yang memindahkan trafik keluar biasa ke dalam terowong mengikut bendera. Mengalih keluar gateway tidak melumpuhkannya dan tidak melemahkannya. Hasilnya adalah yang terburuk daripada kedua-dua keadaan, dengan trafik awam masih ditangkap dan destinasi peribadi yang membenarkan terowong itu kini tidak dapat dicapai. Itulah sebabnya suntingan kedua, yang dibuat dalam semangat yang sama, juga tidak mengubah apa-apa.
Empat tuas, empat tugas berbeza
Empat direktif dipetik secara bergantian dalam perbincangan ini, dan hanya satu daripadanya mengawal liputan, iaitu destinasi mana yang melalui terowong. Yang kedua menetapkan hop seterusnya yang digunakan oleh laluan, yang ketiga memasang satu awalan, dan yang keempat membuang semua yang ditolak oleh pelayan, termasuk laluan peribadi yang diperlukan oleh penggunaan. Jadual menyusunnya mengikut apa yang cuba diubah oleh pentadbir dan bukan mengikut nama, kerana nama itulah yang menyebabkan kekeliruan. Anggap ia sebagai empat keputusan berasingan dan pilih yang benar-benar ingin anda balikkan.
Dalam amalan keempat-empatnya sering tiba dalam satu blok yang ditolak, baris demi baris, yang membuatnya kelihatan seperti bahagian satu tetapan. Ia bukan, dan rujukan OpenVPN mendokumenkannya sebagai mekanisme berbeza semata-mata kerana itu. Mengetahui keputusan mana yang anda balikkan ialah tugasnya; suntingan ialah 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 |
Tapis baris yang ditolak, kekalkan hop seterusnya
Jika liputan yang anda bantah tiba sebagai pilihan yang ditolak, respons sempit ialah mengabaikan pilihan itu mengikut namanya dan membiarkan seluruh blok yang ditolak itu tidak tersentuh. Ditulis sebagai penapis, ia kelihatan seperti baris di bawah, dan tempatnya dalam profil klien yang terjejas, bukan dalam konfigurasi pelayan.
pull-filter ignore "redirect-gateway"
Kesempitan itulah maksudnya. Kerana penapis membandingkan awalan teks, corak yang lebih pendek juga sepadan dengan direktif hop seterusnya, yang mengupas tepat maklumat yang bergantung pada laluan peribadi dan mengulangi kesilapan asal dalam pakaian baharu. Penapis juga hanya bertindak pada pilihan yang ditolak, jadi ia tidak pernah menyentuh baris setara yang ditulis secara tempatan atau yang dikenakan oleh pengurus rangkaian. Sambung semula selepas itu, kerana sesi langsung tidak menilai semula apa yang ditolak oleh pelayan.
Baca carian, bukan jadual
Selepas memuat semula profil, tanyakan kepada kernel ke mana dua destinasi sebenarnya akan pergi: satu di dalam awalan peribadi dan satu di internet awam. Longgokan penuh jadual utama lebih sukar dibaca dan lebih mudah salah dibaca, kerana laluan boleh wujud dan masih kalah kepada padanan yang lebih khusus. Dalam penghalaan berasaskan dasar, peraturan, jadual dan alamat sumber juga termasuk dalam pemeriksaan.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show
Varian def1 patut dikenali, kerana ia membiarkan entri lalai lama kelihatan sementara sepasang separuh lalai menang dalam carian. Jadi baris 0.0.0.0/0 dalam output tidak membuktikan apa-apa dengan sendirinya. Carian menjawab soalan yang senarai itu hanya kelihatan menjawab.
DNS, IPv6 dan laluan peribadi masih perlu berfungsi
Menolak satu ubah hala IPv4 tidak berkata apa-apa tentang penyelesai, jadi pilihan DNS yang ditolak boleh terus menghantar pertanyaan ke dalam terowong sementara laluan kelihatan betul. Lalai IPv6 boleh melakukan perkara yang sama untuk keluarga alamat yang tidak pernah disentuh oleh pemeriksaan IPv4. Kedua-duanya memerlukan keputusan yang jelas dan bukan andaian. Kemudian sahkan perkhidmatan peribadi masih menjawab, kerana terowong berpecah yang kehilangan laluan peribadinya bukan terowong berpecah, ia terowong rosak.
Satu alat yang lebih luas wajar diberi amaran: route-nopull membuang setiap laluan yang ditolak dan setiap pilihan DNS yang ditolak, yang pasti menghentikan terowong penuh dan sama pasti merosakkan laluan peribadi yang bergantung pada penggunaan, jadi ia ialah tukul yang jauh lebih besar daripada penapis nama yang menuju satu pilihan. Semak destinasi peribadi, destinasi awam dan penyelesai selepas setiap perubahan, dan anggap jabat tangan yang selesai sebagai bukti tiada apa-apa selain jabat tangan itu.