IP server yang sama, dua jalur: menandai aliran luar OpenVPN

Perlindungan loop yang biasa adalah rute host: kirim lalu lintas ke alamat publik server VPN lewat uplink agar sesi terenkripsi tidak pernah masuk ke terowongannya sendiri. Itu berfungsi tepat sampai saat Anda juga ingin menjangkau layanan web di server yang sama melalui terowongan, karena pengecualian terikat pada tujuan dan tujuannya identik. Jalan keluarnya adalah berhenti mengklasifikasikan berdasarkan tujuan dan mulai mengklasifikasikan berdasarkan soket mana yang mengirim paket.

Mulailah dari dua aliran yang ingin Anda pisahkan

Satu aliran adalah transport OpenVPN terenkripsi itu sendiri, yang harus keluar lewat uplink, jika tidak terowongan akan membawa koneksi luarnya sendiri. Yang lain adalah permintaan HTTPS biasa ke alamat publik yang sama, yang Anda inginkan di dalam terowongan agar tiba di layanan dari sumber terowongan. Tujuan sama, dalam banyak kasus nomor port sama, jalur yang dibutuhkan berbeda.

Untuk pembahasan ini, anggap ada klien di 10.90.0.10 melalui tun1, alamat publik server 198.51.100.25, dan tabel utama yang belum disentuh dengan rute bawaan mengarah ke uplink biasa. Sisi server juga harus menerima layanan web di jalur dalam dan mengembalikan lalu lintas ke sumber terowongan; mengirim paket ke alamat publik tidak membatalkan listener atau kebijakan firewall server.

Sebelum mengubah apa pun, catat aturan host saat ini dan pilih nilai yang tidak dipakai orang lain: tanda, nomor tabel, dan tiga prioritas aturan. Pertahankan jalur kembali ke mesin yang tidak melewati koneksi ini, karena kesalahan di sini menghilangkan akses jarak jauh Anda sendiri, bukan sekadar merusak tab peramban.

Tandai soket yang membawa amplop

Konfigurasi klien mendapat tanda untuk paket keluarnya yang terenkripsi dan berhenti memasang rute sendiri, sehingga kebijakan pengganti menjadi satu-satunya yang menentukan jalur:

mark 42
route-noexec
disable-dco

Desimal 42 adalah heksadesimal 0x2a, dan bentuk heksadesimal itulah yang akan dicocokkan aturan perutean. Referensi link-options menjelaskan mark sebagai sesuatu yang berlaku untuk paket keluar terenkripsi di Linux, yaitu tepat soket yang jalurnya perlu Anda kendalikan. Menonaktifkan offload kanal data menjaga contoh ini pada jalur ruang pengguna, tempat perilaku tanda adalah yang dijelaskan.

route-noexec menekan penambahan dan penghapusan rute otomatis OpenVPN. Ia tidak memasang apa pun sebagai gantinya, jadi sejak saat ini pemilik rute harus memelihara setiap rute yang dibutuhkan terowongan. Jika tujuan privat hilang setelah perubahan, itu kebijakan pengganti yang tidak ada, bukan cacat pada tanda.

Jangan pertahankan rute host di tabel utama untuk 198.51.100.25 selama melakukan ini. Rute seperti itu memasukkan kembali persis pengecualian yang hendak dipersempit rancangan, dan ia akan menang untuk aliran HTTPS sebelum salah satu kebijakan di bawah ini ditanyakan.

Kirim semua yang lain ke tabel terowongan

Setelah antarmuka terowongan ada dan memegang alamatnya, kebijakannya terlihat 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

Aturan pertama menjaga rute spesifik host tetap terlihat, termasuk jaringan lokal yang disetujui, sekaligus membuat rute bawaan tabel utama tidak terlihat bagi pencarian ini. Perbedaan itu penting: menekan rute bawaan tidak sama dengan mengabaikan tabel, dan pengecualian lokal yang masih Anda butuhkan bertahan justru karena itu. Baca pengecualian itu satu per satu alih-alih mengasumsikan hasilnya adalah sakelar henti universal.

Lalu lintas yang tidak ditandai kemudian jatuh ke tabel terowongan, mengambil sumber terowongan, dan keluar melalui VPN. Lalu lintas bertanda gagal pada uji fwmark di dua aturan berikutnya dan berlanjut ke pencarian utama biasa yang lebih bawah dalam daftar, tempat rute bawaan uplink masih berada. Aturan unreachable terakhir adalah yang mencegah aliran tak bertanda diam-diam jatuh kembali ke uplink ketika rute terowongan tidak ada. Pemilihnya adalah tanda dari awal sampai akhir, dan alamat tujuan tidak pernah masuk ke keputusan.

Pertahankan penjaga itu di tempatnya di antara pemutusan, dan pasang bersama sisa kebijakan, bukan dengan tangan. Aturan yang hilang bersama antarmuka bukan kebijakan, melainkan kebetulan. Menghapus kebijakan saat terowongan putus mengubah mode kegagalan dari “terblokir” menjadi “bocor”, dan rute terowongan usang yang kedaluwarsa nanti adalah masalah yang jauh lebih mudah dijelaskan daripada lalu lintas yang keluar lewat antarmuka yang salah.

Biarkan jalur balik melihat tanda yang sama

Tanda keluar hanyalah separuh mekanisme, dan inilah bagian yang dilewatkan sebagian besar reproduksi. Balasan untuk sesi terenkripsi tiba di uplink dan tunduk pada validasi jalur balik, yang bertanya apakah sumber akan dirutekan kembali melalui jalur yang sama. Tanpa bantuan, pencarian itu menerapkan kebijakan terowongan tak bertanda Anda dan menyimpulkan bahwa paket berada di antarmuka yang salah.

Perbaikannya milik pemilik firewall: simpan tanda pada koneksi keluar, pulihkan pada paket masuk yang cocok, dan aktifkan penanganan tanda tervalidasi sumber untuk jalur terkait. OpenVPN menetapkan tanda soket tidak melakukan satu pun dari ketiga hal itu, dan resep yang hanya mencantumkan opsi klien tidak lengkap. Mintalah integrasi itu secara tertulis, karena itulah bagian rancangan yang paling tidak terlihat dan paling mudah hilang dalam pembangunan ulang.

Pemeriksaan jalur balik yang longgar juga bukan pengganti. Mode longgar tetap memerlukan adanya rute untuk sumber, dan penjaga unreachable yang Anda tambahkan sengaja menghapus satu untuk pencarian tak bertanda. Selesaikan dan tinjau integrasi tanda koneksi sebelum Anda mengandalkan rancangan ini, dan perlakukan filter host sebagai pertanyaan terpisah: tanda adalah sinyal perutean, bukan izin. Jika integrasinya tidak ada, gejalanya adalah sesi yang terbentuk lalu membisu begitu balasan mulai tiba.

Buktikan dengan dua pencarian rute

Bandingkan apa yang diputuskan kernel untuk kedua konteks, dan bacalah bidang dev dan src alih-alih status keluar:

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

Pencarian pertama seharusnya menyelesaikan ke tun1 dengan sumber terowongan, dan yang kedua ke uplink. Itu pencarian sintetis, jadi keduanya membuktikan kebijakan dan bukan proses yang berjalan: konfirmasikan jalur transport nyata klien yang berjalan secara terpisah, lalu buat permintaan HTTPS sungguhan dengan verifikasi sertifikat tetap aktif.

Catat apa yang tidak dicakup rancangan sebelum menyatakannya selesai. DNS, IPv6, dan siklus hidup aturan masing-masing memerlukan keputusan sendiri, dan ini contoh perutean IPv4, bukan konfigurasi privasi lengkap. Nilainya adalah pemilih: amplop mendapat pengecualian uplink, dan layanan biasa di alamat yang sama tidak harus mewarisinya.