Rangkaikan Dua Klien OpenVPN pada Satu Hos Linux dengan fwmark

Menyusun klien OpenVPN kedua pada satu hos Linux gagal di salah satu daripada dua tempat. Sama ada klien dalam tidak dapat mencapai pelayannya sendiri kerana terowong luar telah merampas pengangkutan itu, atau klien kedua menulis semula jadual laluan dan terowong pertama berhenti berfungsi. Kedua-dua masalah terletak pada penghalaan, bukan penyulitan, dan kedua-duanya diselesaikan sebelum terowong baharu membawa sebarang trafik aplikasi. Alamat di sini adalah ilustrasi: tun0 ialah terowong luar, 203.0.113.9 ialah pelayan dalam, dan TCP 9999 ialah aliran yang mesti menggunakan laluan dalam.

Dua mod kegagalan, satu jadual laluan

Klien dalam membuka soket UDP ke pelayannya, dan soket itu mengikut jadual laluan semasa seperti mana-mana yang lain. Jika terowong luar sudah memiliki laluan lalai, paket jabat tangan masuk ke terowong luar. Itu hanya berkesan apabila pelayan luar dapat mencapai pelayan dalam dan pihak seberang bersetuju membawa aliran itu; jika tidak, jabat tangan terhenti dan klien mencuba lagi.

Kegagalan kedua datang daripada push pelayan. Push biasa ialah redirect-gateway def1, yang memasang 0.0.0.0/1 dan 128.0.0.0/1 dan bukannya menggantikan laluan lalai. Dua klien yang masing-masing memasang pasangan /1 sendiri bertembung kerananya, dan pasangan terbaharu menang untuk hampir setiap destinasi. Cari kedua-dua awalan itu dalam jadual apabila terowong mati selepas yang kedua bersambung, kerana laluan lalai itu sendiri mungkin tidak pernah berubah.

Tandakan aliran dan berikan ia jadual

Halakan trafik terpilih dengan menandakannya dalam jadual mangle dan memadankan tanda itu dalam peraturan dasar. Peraturan menunjuk ke jadual khusus yang laluan lalainya ialah peranti dalam, jadi hanya paket bertanda menempuh laluan dalam.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

Kebanyakan kegagalan dalam set peraturan ini datang daripada dua kesilapan. Nilai tanda yang ditetapkan oleh firewall dan nilai yang dipadankan oleh peraturan mesti sama, kerana ketidakpadanan tidak menghasilkan ralat mahupun kesan. Dan PREROUTING hanya melihat paket yang datang dari luar, jadi sambungan yang dimulakan pada hos ini memerlukan peraturan OUTPUT dengan padanan yang sama sebelum ia ditandakan sama sekali.

Rampas pemilikan laluan daripada klien kedua

Dua pilihan menghalang klien kedua daripada menyunting jadual, dan kedua-duanya bertindak pada titik berbeza. route-nopull mengabaikan pilihan laluan yang di-push, jadi tiada apa dipasang. route-noexec menerima pilihan yang di-push ke dalam persekitaran klien tetapi menyerahkan perubahan jadual kepada hook, dan itulah yang anda mahukan apabila anda perlu melihat apa yang ditawarkan oleh pelayan.

Hook berjalan dengan nilai yang di-push dalam persekitarannya, dan ia sepatutnya hanya menambah entri yang anda luluskan. Jadikan ia idempoten: kosongkan jadual yang dimilikinya sebelum membina semula, dan jangan andaikan larian sebelumnya meninggalkan keadaan bersih. Sambungan semula memanggil hook sekali lagi, dan hook yang menambah tanpa membersih mengumpul laluan pendua.

Pilih satu pemilik dan catatkannya. Profil yang menetapkan kedua-dua pilihan, atau hook yang bersaing dengan skrip manual, menghasilkan jadual yang tiada siapa dapat menjelaskan kemudian.

Sematkan kedua-dua alamat pelayan

Pelayan dalam memerlukan laluan hos melalui peranti luar sebelum klien dalam bersambung. Entri itulah yang menahan pengangkutan dalam di dalam terowong luar daripada membiarkannya mengikut laluan lalai.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Tambah juga laluan hos yang sepadan untuk pelayan luar dalam jadual utama, jika tidak sambungan semula boleh menghalakan pengangkutan klien luar itu sendiri ke dalam terowongnya sendiri. Urutannya tidak pilihan: tambah entri ini selepas antara muka berkaitan wujud, iaitu hook atau skrip yang berjalan selepas sambungan. Laluan yang menunjuk ke peranti yang mati dialihkan atau diabaikan, jadi entri yang ditulis semasa but tidak bertahan melalui urutan yang anda andaikan.

Periksa carian dan bukannya membaca seluruh jadual. Output carian laluan menamakan peranti dan alamat sumber yang akan digunakan oleh kernel, dan itulah tepat apa yang klien dapat apabila ia membuka soketnya.

Uji rantaian dan jadikan kegagalan kelihatan

Tangkap pada antara muka luar semasa klien dalam bersambung. Jabat tangan dalam sepatutnya muncul sebagai muatan tersulit di dalam terowong luar; jika ia muncul sebagai UDP biasa ke 203.0.113.9, laluan hos tiada dan rantaian itu tidak pernah dibina.

Rantaian yang senyap kembali ke uplink fizikal ialah hasil terburuk, kerana keadaan antara muka tidak mengumumkan apa-apa dan trafik dalam keluar dari alamat sumber yang salah. Jika klien kedua boleh bersambung semula secara langsung apabila terowong luar jatuh, lumpuhkan laluan itu atau ikatkannya pada antara muka luar supaya kegagalan itu kelihatan.

Akhiri dengan dua aliran dan satu dump peraturan: sambungan bertanda dan tidak bertanda sepatutnya menempuh laluan berbeza, dan ip rule show sepatutnya menyenaraikan keutamaan yang anda maksudkan. Jika kedua-dua aliran menempuh laluan yang sama, tanda itu tidak digunakan di tempat yang anda sangka.