IP pelayan yang sama, dua laluan: menanda aliran luar OpenVPN

Perlindungan gelung biasa ialah laluan hos: hantar trafik ke alamat awam pelayan VPN keluar melalui uplink supaya sesi tersulit tidak pernah masuk ke terowongnya sendiri. Itu berfungsi tepat sehingga saat anda juga mahu mencapai perkhidmatan web pada pelayan yang sama melalui terowong, kerana pengecualian itu terikat pada destinasi dan destinasinya sama. Jalan keluarnya ialah berhenti mengelaskan mengikut destinasi dan mula mengelaskan mengikut soket mana yang menghantar paket.

Mulakan dengan dua aliran yang anda mahu pisahkan

Satu aliran ialah pengangkutan OpenVPN tersulit itu sendiri, yang mesti keluar melalui uplink, jika tidak terowong akan membawa sambungan luarnya sendiri. Yang lain ialah permintaan HTTPS biasa ke alamat awam yang sama, yang anda mahu di dalam terowong supaya ia tiba di perkhidmatan dari sumber terowong. Destinasi sama, dalam banyak kes nombor port sama, laluan diperlukan berbeza.

Untuk tinjauan ini, andaikan klien pada 10.90.0.10 melalui tun1, alamat awam pelayan 198.51.100.25, dan jadual utama yang tidak disentuh dengan laluan lalai menghala ke uplink biasa. Bahagian pelayan juga mesti menerima perkhidmatan web pada laluan dalam dan memulangkan trafik ke sumber terowong; menghantar paket ke alamat awam tidak mengatasi pendengar atau dasar firewall pelayan.

Sebelum mengubah apa-apa, catat peraturan semasa hos dan pilih nilai yang tiada orang lain guna: tanda, nombor jadual dan tiga keutamaan peraturan. Kekalkan laluan kembali ke mesin yang tidak melalui sambungan ini, kerana kesilapan di sini menghilangkan akses jauh anda sendiri, bukan sekadar merosakkan tab pelayar.

Tandakan soket yang membawa sampul

Konfigurasi klien mendapat tanda untuk paket keluarnya yang tersulit dan berhenti memasang laluan sendiri, supaya dasar penggantian menjadi satu-satunya yang menentukan laluan:

mark 42
route-noexec
disable-dco

Perpuluhan 42 ialah perenambelasan 0x2a, dan bentuk perenambelasan itulah yang akan dipadankan oleh peraturan penghalaan. Rujukan link-options menerangkan mark sebagai sesuatu yang terpakai kepada paket keluar tersulit di Linux, iaitu tepat soket yang laluannya perlu anda kawal. Mematikan offload kanal data mengekalkan contoh ini pada laluan ruang pengguna, tempat tingkah laku tanda adalah yang diterangkan.

route-noexec menyekat penambahan dan penghapusan laluan automatik OpenVPN. Ia tidak memasang apa-apa sebagai ganti, jadi mulai saat ini pemilik laluan mesti menyelenggara setiap laluan yang diperlukan terowong. Jika destinasi peribadi hilang selepas perubahan, itu dasar penggantian yang tiada, bukan kecacatan pada tanda.

Jangan kekalkan laluan hos dalam jadual utama untuk 198.51.100.25 semasa melakukan ini. Laluan sedemikian memasukkan semula tepat pengecualian yang cuba disempitkan oleh reka bentuk, dan ia akan menang untuk aliran HTTPS sebelum mana-mana dasar di bawah ditanya.

Hantar semua yang lain ke jadual terowong

Sebaik sahaja antara muka terowong wujud dan memegang alamatnya, dasar kelihatan seperti ini:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

Peraturan pertama mengekalkan laluan khusus hos kelihatan, termasuk mana-mana rangkaian tempatan yang diluluskan, sambil menjadikan laluan lalai jadual utama tidak kelihatan bagi carian ini. Perbezaan itu penting: menyekat laluan lalai bukan sama dengan mengabaikan jadual, dan pengecualian tempatan yang masih anda perlukan bertahan justeru kerananya. Baca pengecualian itu satu demi satu daripada menganggap hasilnya ialah suis henti sejagat.

Trafik tidak ditanda kemudian jatuh ke jadual terowong, mengambil sumber terowong dan keluar melalui VPN. Trafik bertanda gagal ujian fwmark pada dua peraturan berikutnya dan meneruskan ke carian utama biasa lebih jauh ke bawah senarai, tempat laluan lalai uplink masih berada. Peraturan unreachable terakhir ialah yang menghalang aliran tidak bertanda daripada jatuh semula secara senyap ke uplink apabila laluan terowong tiada. Pemilihnya ialah tanda dari awal hingga akhir, dan alamat destinasi tidak pernah masuk ke dalam keputusan.

Kekalkan pengawal itu di tempatnya merentasi pemutusan sambungan, dan pasang bersama seluruh dasar, bukan secara manual. Peraturan yang hilang bersama antara muka bukan dasar, ia kebetulan. Memadam dasar apabila terowong jatuh mengubah mod kegagalan daripada “tersekat” kepada “bocor”, dan laluan terowong lapuk yang tamat tempoh kemudian ialah masalah yang jauh lebih mudah dijelaskan daripada trafik yang keluar melalui antara muka yang salah.

Biarkan laluan balik melihat tanda yang sama

Tanda keluar hanyalah separuh mekanisme, dan inilah bahagian yang ditinggalkan oleh kebanyakan penghasilan semula. Balasan kepada sesi tersulit tiba di uplink dan tertakluk kepada pengesahan laluan balik, yang bertanya sama ada sumber akan dihalakan semula melalui laluan yang sama. Tanpa bantuan, carian itu menggunakan dasar terowong tidak bertanda anda dan membuat kesimpulan bahawa paket berada pada antara muka yang salah.

Pembetulan itu milik pemilik firewall: simpan tanda pada sambungan keluar, pulihkannya pada paket masuk yang sepadan dan dayakan pengendalian tanda yang disahkan sumber untuk laluan berkenaan. OpenVPN menetapkan tanda soket tidak melakukan mana-mana daripada tiga perkara itu, dan resipi yang hanya menyenaraikan pilihan klien tidak lengkap. Minta integrasi itu secara bertulis, kerana itulah bahagian reka bentuk yang paling kurang kelihatan dan paling mudah hilang semasa pembinaan semula.

Pemeriksaan laluan balik longgar juga bukan pengganti. Mod longgar masih memerlukan adanya laluan untuk sumber, dan pengawal unreachable yang anda tambah sengaja membuang satu untuk carian tidak bertanda. Selesaikan dan semak integrasi tanda sambungan sebelum anda bergantung pada reka bentuk ini, dan anggap penapis hos sebagai soalan berasingan: tanda ialah isyarat penghalaan, bukan kebenaran. Jika integrasi tiada, gejalanya ialah sesi yang terbentuk dan kemudian senyap sebaik sahaja balasan mula tiba.

Buktikan dengan dua carian laluan

Bandingkan apa yang diputuskan kernel untuk kedua-dua konteks, dan baca medan dev dan src bukan status keluar:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

Carian pertama sepatutnya menyelesaikan ke tun1 dengan sumber terowong, dan yang kedua ke uplink. Itu carian sintetik, jadi ia membuktikan dasar dan bukan proses yang berjalan: sahkan laluan pengangkutan sebenar klien yang berjalan secara berasingan, kemudian buat permintaan HTTPS sebenar dengan pengesahan sijil dibiarkan hidup.

Catat apa yang tidak diliputi oleh reka bentuk sebelum mengisytiharkannya selesai. DNS, IPv6 dan kitaran hayat peraturan masing-masing memerlukan keputusan sendiri, dan ini contoh penghalaan IPv4, bukan konfigurasi privasi lengkap. Nilainya ialah pemilih: sampul mendapat pengecualian uplink, dan perkhidmatan biasa pada alamat yang sama tidak perlu mewarisinya.