OpenVPN redirect-gateway: apa yang setiap flag lakukan pada laluan

Sambung dengan redirect-gateway dalam profil, dan laluan lalai mesin anda mungkin hilang, terbelah dua, atau kekal tepat di tempatnya, bergantung pada flag yang tiada siapa baca dua kali. Pilihan ini hanya mengubah keadaan penghalaan dan tidak yang lain, jadi satu-satunya bukti yang boleh dipercayai tentang apa yang dilakukannya ialah jadual yang dipasang klien selepas itu. Berikut ialah jadual selepas sambungan, laluan yang mengekalkan terowong itu sendiri hidup, dan trafik IPv6 yang tidak pernah didakwa dilindungi oleh arahan ini. Setiap langkah ialah perintah yang boleh anda jalankan pada klien semasa terowong aktif.

Apa yang setiap flag lakukan pada laluan lalai

Tanpa sebarang flag, pilihan ini membuang laluan lalai biasa dan meletakkan terowong di tempatnya, jadi get laluan lama hilang daripada jadual semasa sambungan aktif. Tambah def1 dan laluan lalai itu kekal tersenarai, dengan dua laluan lebih sempit melakukan kerja itu. Tambah bypass-dhcp dan laluan DHCP juga kekal, yang penting pada rangkaian di mana klien masih perlu sampai ke pelayan DHCP tempatan. Senarai flag pada halaman manual OpenVPN 2.6 cukup pendek untuk dibaca sekali, dan setiap entri mengubah laluan mana yang berakhir dalam jadual.

Pilihan yang ditolak berkelakuan sama apabila tiba, jadi profil klien mungkin tidak mengandungi apa-apa sementara jadual kelihatan dialihkan sepenuhnya. Itu normal: pelayan menghantar flag, klien menggunakannya, dan fail tempatan tidak pernah menyebut arahan itu. Apabila tolakan kelihatan tidak melakukan apa-apa, semak penapis sebelah klien yang menerima atau membuang pilihan yang ditarik, kerana pilihan yang dibuang tidak menimbulkan ralat pada mana-mana pihak.

def1 menang melalui kekhususan tanpa menyentuh laluan lalai anda

Dua laluan separuh lalai bersama-sama meliputi ruang IPv4, 0.0.0.0/1 dan 128.0.0.0/1. Setiap satu lebih khusus daripada 0.0.0.0/0, jadi carian mengutamakannya sementara laluan lalai sebenar kekal dalam jadual untuk apa-apa yang meminta padanan paling tidak khusus.

Baca jadual, bukan profil, kerana hanya jadual menunjukkan kes mana yang anda alami. Dua baris cukup untuk membezakannya:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Perhatikan antara muka dan metrik pada setiap baris, bukan hanya destinasi. Laluan lalai yang menunjuk ke terowong dan sepasang separuh lalai yang menunjuk ke terowong menggambarkan niat yang sama dan gagal secara berbeza apabila terowong jatuh, kerana dalam satu kes sandaran masih wujud. Catat kedua-dua medan dalam nota perubahan. Sandaran yang terselamat kadangkala yang mengekalkan sesi jauh hidup cukup lama untuk membaiki terowong, dan ia juga yang membocorkan trafik apabila niatnya terowong penuh.

Kekalkan titik akhir terowong boleh dicapai

Klien memerlukan laluan ke hujung jauh terowong yang tidak melalui terowong itu sendiri. OpenVPN memasang laluan hos itu sebelum mengubah apa-apa lagi, dan suntingan laluan manual atau klien VPN kedua boleh mengambilnya. Gejalanya kemudian ialah sambungan yang melaporkan bersambung dan kemudian tidak melepaskan apa-apa.

Tanya kernel antara muka mana yang akan digunakannya untuk alamat titik akhir semasa terowong aktif. Jawapannya mesti menamakan antara muka fizikal dan get laluannya, tidak pernah tun0:

ip route get 198.51.100.20

Jika carian itu mengembalikan peranti terowong, terowong membawa pengangkutan sendiri dan akan runtuh sebaik sahaja paket perlu keluar. Prefiks tempatan, penyesuai kedua dan penghalaan berasaskan dasar masih penting di sini, sebab itu pengalihan yang berfungsi pada komputer riba bersih boleh gagal pada hos dengan antara muka pengurusan dan dua laluan lalai. Biasanya profil dipersalahkan atas apa yang dilakukan pelan alamat.

Trafik IPv6 terus menggunakan jadualnya sendiri

Mengalihkan IPv4 membiarkan IPv6 tidak terganggu, dan kedua-dua keluarga diubah oleh flag yang berbeza. Pada hos tindanan berganda dengan laluan lalai v6 yang berfungsi, trafik v4 boleh duduk sepenuhnya di dalam terowong sementara setiap destinasi yang mampu v6 keluar melalui pautan fizikal. Hos yang kelihatan betul dalam satu jadual bocor dalam jadual yang lain.

Semak jadual v6 selepas bersambung dan bukannya menganggap terowong telah meliputinya. Arahan ini membawa flag keluarga alamat tepat kerana sebab ini, dan profil yang meninggalkannya mewarisi apa yang platform lakukan secara lalai:

ip -6 route show default
ip -6 route get 2001:db8::10

Buktikan antara muka mana yang digunakan oleh aplikasi

Keadaan bersambung bukan sekatan, dan perubahan laluan bukan suis pemutus. Jika trafik langsung mesti berhenti apabila terowong gagal, dasar itu hidup dalam tembok api dan memerlukan ujiannya sendiri.

Uji laluan yang benar-benar dilalui aplikasi, bukan laluan yang diterangkan oleh profil. Minta laluan itu dahulu, kemudian ikat permintaan pada setiap antara muka secara bergilir dan bandingkan apa yang dilaporkan oleh sebelah jauh:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Jika kedua-dua permintaan mengembalikan alamat yang sama, aplikasi tidak menggunakan terowong walaupun jadual penghalaan mengatakan sepatutnya. Jika hanya permintaan yang terikat pada terowong berjaya, laluan fizikal ditapis untuk destinasi itu dan terowong melakukan apa yang anda minta. Tulis flag, laluan yang dipasang, carian titik akhir dan kedua-dua hasil keluar dalam rekod perubahan, supaya orang seterusnya mewarisi fakta dan bukannya tangkapan skrin.