Egress terpisah: kumpulan VPN di usb0, lalu lintas gateway di eth0

Klien terhubung dan terautentikasi, lalu lalu lintasnya keluar lewat uplink yang salah, karena satu-satunya rute default di mesin itu milik gateway sendiri. Mengganti rute default tersebut akan merusak pembaruan mesin dan akses manajemennya, jadi pemilihannya harus lebih sempit daripada «semua lalu lintas». Bentuk yang bisa dijalankan adalah aturan kebijakan yang berbasis pada alamat sumber dalam kumpulan klien, menunjuk ke tabel perutean kedua yang memiliki WAN alternatif. Dari situ daftar periksa berfokus pada kelengkapan dan perilaku saat gagal, bukan pada aturannya sendiri.

Pastikan alamat sumber bertahan hingga keputusan perutean

Aturan kebijakan yang cocok dengan rentang sumber hanya aktif bila paket masih membawa sumber itu saat pencarian. Lalu lintas klien yang diteruskan membawanya, asalkan tidak ada yang menulis ulang di hulu sebelum perutean. Lalu lintas yang dibuat gateway sendiri tidak, dan itulah sebabnya rute default gateway bisa tetap di tempatnya.

Di sinilah uji lokal menyesatkan. curl yang dijalankan di gateway adalah aliran yang dibuat secara lokal dengan alamat gateway, sehingga ia memakai tabel utama dan tidak membuktikan apa pun tentang jalur klien. Ujilah dari klien yang terhubung, atau buat lalu lintas dengan sumber yang benar-benar milik kumpulan itu.

Mulailah dengan menuliskan nilai sebenarnya: prefiks kumpulan, antarmuka tunnel yang membawanya, alamat dan hop berikutnya dari WAN kedua, serta nomor tabel yang hendak dipakai. Bersihkan aturan lama dari percobaan sebelumnya sebelum menambahkan yang baru, karena aturan ganda pada prioritas berbeda menghasilkan kegagalan yang tampak acak.

Bangun tabel terpilih yang lengkap

Tabel bukan rute default dengan seorang teman. Tabel butuh cukup rute agar setiap pencarian terselesaikan di dalamnya, termasuk rute terhubung untuk subnet WAN supaya hop berikutnya dapat dijangkau. Untuk kumpulan 10.77.0.0/24 di tun1, alamat WAN 203.0.113.20/24 dengan hop berikutnya 203.0.113.1, dan tabel 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

Aturan berada pada prioritas di bawah aturan penangkap-semua mana pun yang ada, sehingga klien yang cocok mengenai tabel 600 lebih dulu dan semua yang lain jatuh ke tabel utama. Referensi ip-rule menjelaskan model pencarian berurutan dan sintaks pemilih secara lengkap.

Lalu pikirkan apa yang tidak dimuat tabel. Tujuan yang hanya punya rute di tabel utama, misalnya subnet manajemen yang dapat dijangkau lewat eth0, tidak akan ditemukan di tabel 600 dan tidak akan kembali ke tabel utama begitu ada rute default di sana. Jika jalur itu penting, tambahkan secara eksplisit ke tabel terpilih, yang biasanya merupakan jawaban tepat untuk tabel egress VPN.

Jauhkan lalu lintas pendengar itu sendiri dari kebijakan

Pendengar OpenVPN punya koneksi luar sendiri, yang dibawa lewat uplink yang dipakai klien untuk mencapainya. Lalu lintas itu harus mempertahankan jalur kembali saat datang, dan aturan luas yang mencakup alamat publik server atau seluruh antarmuka tunnel dapat menyeretnya ke tabel alternatif. Batasi aturan pada kumpulan dalam dan tidak pada hal lain.

Pemfilteran jalur balik layak dilihat karena alasan yang sama. Ketika balasan ke klien keluar lewat usb0 sementara permintaan datang lewat tautan lain, pengaturan rp_filter yang ketat dapat menjatuhkan paket yang dianggap sah oleh kebijakan perutean. Periksa nilai sysctl efektif pada kedua antarmuka sebelum menyimpulkan bahwa aturannya gagal.

Urutan juga penting terhadap hal lain di mesin. Jembatan Docker, VPN kedua, dan aturan apa pun yang sudah ada dari image penyedia semuanya menambah prioritas, jadi baca daftar aturan lengkap alih-alih menganggap prioritas 100 berdiri sendiri.

Selaraskan penerusan dan penerjemahan dengan rute

Perutean memilih uplink; ia tidak memberi izin untuk meneruskan. Kernel harus mengaktifkan penerusan IPv4, dan firewall harus menerima arah klien ke WAN serta lalu lintas balasan. Tabel yang benar dengan rantai FORWARD yang menjatuhkan aliran menghasilkan gejala yang sama dengan rute yang hilang, karena itu keduanya diperiksa dalam satu langkah.

Jika WAN kedua tidak merutekan kumpulan privat kembali kepada Anda, terjemahkan sumbernya di egress itu. Untuk antarmuka beralamat dinamis, pilihan lazimnya adalah aturan masquerade sempit yang dibatasi pada kumpulan dan antarmuka:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Cakupan di sini lebih penting daripada target. Aturan masquerade yang cocok dengan antarmuka keluar mana pun juga akan menulis ulang lalu lintas yang keluar dengan benar lewat eth0, dan itu menyembunyikan kesalahan perutean alih-alih memperbaikinya. Penerjemahan berjalan setelah keputusan perutean, jadi ia tidak pernah dapat memperbaiki paket yang dikirim ke uplink yang salah.

Beban tunnel juga perlu perhatian begitu jalurnya berbeda. Jika klien menyepakati MSS TCP besar dan WAN alternatif punya MTU lebih rendah atau tunnel di dalamnya, segmen besar tersendat sementara yang kecil berjalan. Membatasi MSS pada jalur penerusan mengubahnya menjadi perilaku yang dapat diprediksi, bukan macet sesekali.

Putuskan apa yang terjadi saat usb0 hilang

Tabel kosong bukan keadaan menutup saat gagal. Jika rute yang cocok hilang, pencarian berlanjut ke aturan berikutnya, mencapai tabel utama, dan mengambil default eth0. Lalu lintas yang seharusnya keluar lewat WAN kedua diam-diam keluar lewat yang pertama, yang pada penerapan berperutean kebijakan biasanya hasil yang paling tidak Anda inginkan.

Di mana kemunduran itu tidak dapat diterima, tambahkan rute terminal eksplisit di tabel 600, misalnya default blackhole, atau buang kumpulan di firewall selama antarmuka mati. Keduanya adalah keputusan yang dapat Anda tuliskan; diam bukan.

Ketahanan adalah butir terakhir. Siapa pun yang memiliki kedua tautan, entah manajer jaringan, skrip pengirim, atau siklus hidup koneksi, harus membuat ulang rute dan aturan pada setiap sambung ulang tanpa menambahkan duplikat. Verifikasi dengan permintaan dari klien nyata dan permintaan terpisah dari gateway, konfirmasi egress yang teramati pada keduanya, lalu cabut WAN kedua dan lihat hasil mana dari dua hasil yang Anda rancang benar-benar terjadi. IPv6 memerlukan tabel, aturan, dan penerjemahannya sendiri; aturan IPv4 di atas tidak mengatakan apa pun tentangnya.