OpenVPN redirect-gateway: apa yang dilakukan tiap flag pada rute

Sambungkan dengan redirect-gateway di profil, dan rute bawaan mesin Anda bisa hilang, terbelah dua, atau tetap persis di tempatnya, tergantung flag yang tidak dibaca siapa pun dua kali. Opsi ini hanya mengubah keadaan perutean dan tidak yang lain, jadi satu-satunya bukti tepercaya tentang apa yang dilakukannya adalah tabel yang dipasang klien sesudahnya. Berikut adalah tabel setelah koneksi, rute yang menjaga terowongan itu sendiri tetap hidup, dan lalu lintas IPv6 yang tidak pernah diklaim dicakup direktif. Setiap langkah adalah perintah yang dapat Anda jalankan di klien selama terowongan aktif.

Apa yang dilakukan tiap flag pada rute bawaan

Tanpa flag apa pun, opsi ini menghapus rute bawaan biasa dan menempatkan terowongan di posisinya, sehingga gateway lama hilang dari tabel selama koneksi aktif. Tambahkan def1 dan rute bawaan itu tetap terdaftar, dengan dua rute yang lebih sempit mengerjakan tugasnya. Tambahkan bypass-dhcp dan rute DHCP juga bertahan, yang penting di jaringan tempat klien masih harus menjangkau server DHCP lokal. Daftar flag di halaman manual OpenVPN 2.6 cukup pendek untuk dibaca sekali, dan setiap entri mengubah rute mana yang berakhir di tabel.

Opsi yang didorong berperilaku sama saat tiba, sehingga profil klien bisa tidak berisi apa pun sementara tabel tampak sepenuhnya dialihkan. Itu normal: server mengirim flag, klien menerapkannya, dan berkas lokal tidak pernah menyebut direktif itu. Ketika dorongan tampak tidak melakukan apa pun, periksa filter sisi klien yang menerima atau membuang opsi yang ditarik, karena opsi yang dibuang tidak memunculkan galat di kedua sisi.

def1 menang karena kekhususan tanpa menyentuh rute bawaan Anda

Dua rute setengah-bawaan bersama-sama menutupi ruang IPv4, 0.0.0.0/1 dan 128.0.0.0/1. Masing-masing lebih spesifik daripada 0.0.0.0/0, sehingga pencarian mengutamakannya sementara rute bawaan sebenarnya tetap di tabel untuk apa pun yang meminta kecocokan paling tidak spesifik.

Baca tabelnya, bukan profilnya, karena hanya tabel yang menunjukkan kasus mana yang Anda alami. Dua baris cukup untuk membedakannya:

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

Perhatikan antarmuka dan metrik di setiap baris, bukan hanya tujuan. Rute bawaan yang menunjuk ke terowongan dan sepasang setengah-bawaan yang menunjuk ke terowongan menggambarkan maksud yang sama dan gagal secara berbeda saat terowongan jatuh, karena cadangan masih ada dalam satu kasus. Catat kedua bidang dalam catatan perubahan. Cadangan yang bertahan kadang yang menjaga sesi jarak jauh tetap hidup cukup lama untuk memperbaiki terowongan, dan itu juga yang membocorkan lalu lintas ketika maksudnya terowongan penuh.

Jaga titik akhir terowongan tetap terjangkau

Klien memerlukan rute ke ujung jauh terowongan yang tidak melewati terowongan itu sendiri. OpenVPN memasang rute host itu sebelum mengubah hal lain, dan penyuntingan rute manual atau klien VPN kedua dapat mengambilnya. Gejalanya kemudian adalah koneksi yang melaporkan tersambung lalu tidak melewatkan apa pun.

Tanyakan kepada kernel antarmuka mana yang akan dipakainya untuk alamat titik akhir selama terowongan aktif. Jawabannya harus menyebut antarmuka fisik dan gateway-nya, tidak pernah tun0:

ip route get 198.51.100.20

Jika pencarian itu mengembalikan perangkat terowongan, terowongan membawa transportasinya sendiri dan akan runtuh begitu sebuah paket harus keluar. Prefiks lokal, adaptor kedua, dan perutean berbasis kebijakan masih penting di sini, karena itu pengalihan yang bekerja di laptop bersih bisa gagal di host dengan antarmuka manajemen dan dua rute bawaan. Biasanya profil disalahkan atas apa yang dilakukan rencana alamat.

Lalu lintas IPv6 tetap memakai tabelnya sendiri

Mengalihkan IPv4 membiarkan IPv6 apa adanya, dan kedua keluarga diubah oleh flag yang berbeda. Di host tumpukan ganda dengan rute bawaan v6 yang bekerja, lalu lintas v4 dapat sepenuhnya berada di dalam terowongan sementara setiap tujuan yang mampu v6 keluar lewat tautan fisik. Host yang tampak benar di satu tabel bocor di tabel lain.

Periksa tabel v6 setelah menyambung alih-alih menganggap terowongan telah mencakupnya. Direktif membawa flag keluarga alamat justru karena alasan ini, dan profil yang menghilangkannya mewarisi apa yang dilakukan platform secara bawaan:

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

Buktikan antarmuka mana yang dipakai aplikasi

Keadaan tersambung bukanlah blokir, dan perubahan rute bukanlah sakelar pemutus. Jika lalu lintas langsung harus berhenti saat terowongan gagal, kebijakan itu hidup di tembok api dan perlu ujinya sendiri.

Uji jalur yang benar-benar ditempuh aplikasi, bukan jalur yang dijelaskan profil. Minta rutenya lebih dulu, lalu ikat permintaan ke tiap antarmuka bergantian dan bandingkan apa yang dilaporkan sisi jauh:

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

Jika kedua permintaan mengembalikan alamat yang sama, aplikasi tidak memakai terowongan meskipun tabel perutean mengatakan seharusnya. Jika hanya permintaan yang terikat ke terowongan yang berhasil, jalur fisik disaring untuk tujuan itu dan terowongan melakukan apa yang Anda minta. Tuliskan flag, rute yang terpasang, pencarian titik akhir, dan kedua hasil keluar ke catatan perubahan, agar orang berikutnya mewarisi fakta alih-alih tangkapan layar.