Dua klien OpenVPN di satu gateway Linux: bagi kebijakannya

Dua daemon OpenVPN bisa sama-sama melaporkan terowongan yang berhasil sementara gateway mengirim setiap klien lewat yang sama. Tidak ada apa pun dalam jabat tangan yang memutuskan terowongan mana yang dipakai klien; kernel yang memutuskan, paket demi paket, dengan menelusuri aturan kebijakan lalu tabel yang disebut tiap aturan. Begitu dilihat seperti itu, konfigurasi berhenti soal opsi OpenVPN dan menjadi matriks perutean dengan dua pemilik.

Kernel yang memutuskan, bukan daemon

Paket yang diteruskan tiba di antarmuka LAN dan kode perutean mengevaluasi daftar aturan dalam urutan prioritas. Aturan pertama yang pemilihnya cocok menyebut sebuah tabel, dan rute tabel itu memilih perangkat keluaran. Jika tabel tidak punya rute yang cocok, pencarian berlanjut ke aturan berikutnya, dan detail itulah yang membuat penyiapan setengah jadi gagal diam-diam alih-alih berisik.

Proses terowongan tidak punya suara dalam penelusuran itu. Ia membuat antarmuka dan bisa memasang rute, tetapi apakah paket klien tertentu masuk ke antarmuka itu sepenuhnya bergantung pada tabel ke mana paket itu dikirim. Karena itu dua terowongan dengan rute impor yang identik saling bersaing, dan penulis terakhir menang untuk semua. Itulah sebabnya penyiapan bisa tampak seimbang di berkas konfigurasi dan tetap mengirim semua klien lewat satu daemon.

Beri tiap instans kumpulan sumber dayanya sendiri

Mulailah dari nama, karena nama yang dipakai ulang adalah cara kedua instans akhirnya berbagi status secara tidak sengaja. Tetapkan perangkat terowongan yang berbeda, berkas konfigurasi yang berbeda, kredensial yang berbeda, dan unit layanan yang berbeda. Catat titik akhir luar dan alamat terowongan tiap instans di tabel yang sama dengan matriks kebijakan, agar perubahan kemudian punya satu tempat untuk dilihat.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull menjaga rute yang didorong server tetap di luar tabel lokal, dan itulah yang Anda inginkan ketika tabel kebijakan seharusnya eksplisit. Apakah server tertentu juga mendorong opsi redirect-gateway, dan apakah versi klien Anda mendukung bentuk filter, sebaiknya diperiksa di manual daripada diasumsikan.

Tulis matriksnya: sumber, tabel, perangkat

Untuk setiap grup klien, tambahkan aturan yang memilih tabel berdasarkan alamat sumber, lalu taruh jalur yang dimaksud di tabel itu:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Tabel membutuhkan rute tujuan yang seharusnya dimiliki grup, ditambah pengecualian lokal atau manajemen apa pun yang menjaga gateway tetap bisa dipakai. Tabel yang hanya berisi rute bawaan adalah kebijakan terowongan penuh untuk grup itu, yang mungkin memang tepat, tetapi itu semestinya keputusan, bukan kelalaian.

Transportasi terowongan itu sendiri bukan di grup klien

Paket terenkripsi tiap daemon berasal dari gateway itu sendiri, dialamatkan ke rekan luar. Aturan yang hanya cocok dengan prefiks sumber klien membiarkan paket itu, dan karena itu aturan terbatas sumber lebih aman daripada aturan yang cocok dengan segalanya. Aturan tanpa pemilih bisa menangkap transportasi terowongan itu sendiri dan mengirimnya kembali lewat terowongan, lalu koneksi gagal dengan cara yang tampak seperti masalah penyedia.

Jaga sesi manajemen lokal dan jalur lapisan bawah tetap eksplisit di luar tabel kebijakan. Tuliskan pengecualian itu di samping matriks; itu bagian dari rancangan, bukan akal-akalan yang harus ditemukan lagi saat insiden.

Memilih jalur tidak mengizinkannya

Izin penerusan adalah keputusan kedua yang diambil kemudian dalam jalur. Aturan firewall yang menerima paket yang keluar lewat terowongan kedua tidak membuat kode perutean memilihnya, dan tabel yang benar tidak memberi izin untuk meneruskan. Keduanya harus ada, dan uji yang hanya membuktikan salah satunya akan menyesatkan Anda soal yang lain. Saat satu grup berfungsi dan yang lain tidak, periksa kedua langkah itu secara terpisah alih-alih menulis ulang tabel.

Penerjemahan sumber adalah keputusan ketiga, dan sebaiknya dibatasi pada grup sumber dan perangkat terowongan yang benar-benar membawanya. Tambahkan rantai khusus untuk kedua instans alih-alih mengosongkan rantai postrouting, karena layanan yang tidak terkait mungkin punya entri di sana dan pengosongan menghapusnya diam-diam.

Apa yang terjadi saat satu terowongan putus

Putuskan perilaku kegagalan sejak awal. Ketika tabel terowongan kehilangan rutenya, pencarian jatuh ke aturan berikutnya, dan lalu lintas grup berlanjut lewat terowongan lain atau uplink biasa tanpa kesalahan apa pun. Jika itu tidak dapat diterima, tambahkan aturan penghenti pada nomor prioritas lebih rendah yang mengembalikan hasil tak terjangkau untuk sumber itu, agar kehilangan terlihat alih-alih terserap.

Kirim permintaan baru dari tiap grup sumber dan catat empat fakta: tabel yang dipilih, perangkat keluaran, sumber yang diterjemahkan, dan apakah balasannya kembali lewat jalur yang sama. Lalu matikan satu terowongan dan ulangi. Dua perangkat TUN dalam daftar antarmuka membuktikan kedua daemon menyala; itu tidak mengatakan apa pun tentang mana yang dipakai klien tertentu. Putaran kedua, dengan satu terowongan hilang, itulah yang menunjukkan apakah aturan cadangan Anda melakukan yang dimaksud.