Dua klien OpenVPN pada satu gateway Linux: bahagikan dasar

Dua daemon OpenVPN boleh sama-sama melaporkan terowong yang berjaya sementara gateway menghantar setiap klien melalui yang sama. Tiada apa pun dalam jabat tangan yang menentukan terowong mana digunakan oleh klien; kernel yang menentukannya, paket demi paket, dengan menelusuri peraturan dasar dan kemudian jadual yang dinamakan oleh setiap peraturan. Apabila dilihat begitu, konfigurasi berhenti menjadi tentang pilihan OpenVPN dan menjadi matriks penghalaan dengan dua pemilik.

Kernel yang menentukan, bukan daemon

Paket yang dipacu ke hadapan tiba di antara muka LAN dan kod penghalaan menilai senarai peraturan mengikut susunan keutamaan. Peraturan pertama yang pemilihnya sepadan menamakan jadual, dan laluan jadual itu memilih peranti keluaran. Jika jadual tiada laluan yang sepadan, carian berterusan ke peraturan seterusnya, dan butiran inilah yang membuatkan persediaan separuh siap gagal secara senyap dan bukan secara kuat.

Proses terowong tiada suara dalam penelusuran itu. Ia mencipta antara muka dan boleh memasang laluan, tetapi sama ada paket klien tertentu masuk ke antara muka itu bergantung sepenuhnya pada jadual yang menjadi tujuannya. Oleh itu dua terowong dengan laluan import yang sama bersaing, dan penulis terakhir menang untuk semua. Itulah sebabnya persediaan boleh kelihatan seimbang dalam fail konfigurasi dan masih menghantar semua klien melalui satu daemon.

Beri setiap contoh set sumbernya sendiri

Mulakan dengan nama, kerana nama yang digunakan semula ialah cara dua contoh akhirnya berkongsi keadaan secara tidak sengaja. Tetapkan peranti terowong berbeza, fail konfigurasi berbeza, kelayakan berbeza dan unit perkhidmatan berbeza. Catat titik akhir luaran dan alamat terowong setiap contoh dalam jadual yang sama dengan matriks dasar, supaya perubahan kemudian mempunyai satu tempat untuk dilihat.

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

dev tun-lab
route-nopull

route-nopull menyimpan laluan yang ditolak oleh pelayan di luar jadual setempat, dan itulah yang anda mahu apabila jadual dasar sepatutnya eksplisit. Sama ada pelayan tertentu juga menolak pilihan redirect-gateway, dan sama ada versi klien anda menyokong bentuk penapis, wajar diperiksa dalam manual dan bukan diandaikan.

Tulis matriks: sumber, jadual, peranti

Untuk setiap kumpulan klien, tambah peraturan yang memilih jadual mengikut alamat sumber, kemudian letakkan laluan yang dimaksudkan dalam jadual 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

Jadual memerlukan laluan destinasi yang sepatutnya ada pada kumpulan, serta sebarang pengecualian setempat atau pengurusan yang memastikan gateway boleh digunakan. Jadual yang hanya mengandungi laluan lalai ialah dasar terowong penuh untuk kumpulan itu, yang mungkin betul-betul tepat, tetapi ia sepatutnya menjadi keputusan dan bukan peninggalan.

Pengangkutan terowong itu sendiri tiada dalam kumpulan klien

Paket penyulitan setiap daemon berasal dari gateway itu sendiri, dialamatkan kepada rakan luar. Peraturan yang hanya sepadan dengan awalan sumber klien membiarkan paket itu, dan sebab itulah peraturan terhad sumber lebih selamat daripada peraturan yang sepadan dengan segala-galanya. Peraturan tanpa pemilih boleh menangkap pengangkutan terowong itu sendiri dan menghantarnya semula melalui terowong, dan sambungan kemudian gagal dengan cara yang kelihatan seperti masalah penyedia.

Kekalkan sesi pengurusan setempat dan laluan lapisan bawah secara eksplisit di luar jadual dasar. Tuliskan pengecualian itu di sebelah matriks; ia sebahagian daripada reka bentuk, bukan jalan pintas yang perlu ditemui semula semasa insiden.

Memilih laluan tidak membenarkannya

Kebenaran memajukan paket ialah keputusan kedua yang dibuat kemudian dalam laluan. Peraturan tembok api yang menerima paket yang keluar melalui terowong kedua tidak membuatkan kod penghalaan memilihnya, dan jadual yang betul tidak memberikan kebenaran untuk memajukan. Kedua-duanya mesti ada, dan ujian yang hanya membuktikan satu akan mengelirukan anda tentang yang lain. Apabila satu kumpulan berfungsi dan yang lain tidak, periksa kedua-dua langkah itu secara berasingan dan bukan menulis semula jadual.

Terjemahan sumber ialah keputusan ketiga, dan ia patut dihadkan kepada kumpulan sumber dan peranti terowong yang benar-benar membawanya. Tambah rantaian khusus untuk dua contoh dan bukan mengosongkan rantaian postrouting, kerana perkhidmatan yang tidak berkaitan mungkin mempunyai entri di sana dan pengosongan membuangnya secara senyap.

Apa yang berlaku apabila satu terowong tumbang

Tentukan tingkah laku kegagalan lebih awal. Apabila jadual terowong kehilangan laluannya, carian jatuh ke peraturan seterusnya, dan trafik kumpulan berterusan melalui terowong lain atau pautan atas biasa tanpa sebarang ralat. Jika itu tidak boleh diterima, tambah peraturan penamat pada nombor keutamaan yang lebih rendah yang mengembalikan hasil tidak tercapai untuk sumber itu, supaya kehilangan itu kelihatan dan bukan diserap.

Hantar permintaan baharu daripada setiap kumpulan sumber dan catat empat fakta: jadual yang dipilih, peranti keluaran, sumber yang diterjemah, dan sama ada balasan kembali melalui laluan yang sama. Kemudian turunkan satu terowong dan ulangi. Dua peranti TUN dalam senarai antara muka membuktikan kedua-dua daemon bermula; ia tidak mengatakan apa-apa tentang yang mana digunakan oleh klien tertentu. Larian kedua, dengan satu terowong hilang, itulah yang menunjukkan sama ada peraturan sandaran anda melakukan apa yang anda niatkan.