Mengeluarkan satu port dari VPN memerlukan perutean berbasis kebijakan

Permintaannya selalu varian dari kalimat yang sama: pertahankan VPN untuk penjelajahan, tetapi biarkan SSH atau tugas pencadangan memakai koneksi normal. Saran yang beredar soal ini, meneruskan port dengan aturan NAT iptables, tidak melakukannya. Aturan NAT menulis ulang alamat dan port di dalam aliran; ia tidak pernah memilih antarmuka mana paket keluar. Keputusan itu milik pencarian rute, dan pencarian rute butuh bantuan untuk melihat port.

Mengapa rute biasa tidak bisa mencocokkan port

Linux memilih rute dengan mencari alamat tujuan di sebuah tabel, setelah tabel kandidat disaring lewat aturan kebijakan. Aturan itu bisa cocok dengan tanda firewall, alamat sumber, antarmuka masuk, atau UID. Entri rute sendiri tidak punya bidang port, karena rute dipilih sebelum header transport menjadi penting.

iproute2 dan kernel masa kini memperluas pemilih aturan: ipproto, sport dan dport diterima, jadi ip rule add ipproto tcp dport 22 table 100 menyatakan maksudnya dalam satu baris. Jalankan ip rule add help di host sebenarnya untuk melihat apakah build Anda mencantumkan dport. Jika ya, selesai dengan satu perintah; jika tidak, jalur tanda di bawah ini adalah padanannya.

Apa pun itu, aturan hanya penunjuk. Tabel 100 tetap butuh rute, dan itulah bagian yang orang lupakan.

Tiga bagian, atau satu

Bentuk modern adalah aturan tunggal di atas ditambah rute di tabel alternatif. Bentuk klasik menambahkan netfilter di tengah: tandai paket, lalu cocokkan tanda di aturan. Keduanya berakhir pada pencarian yang sama; bedanya di tempat port dibaca.

Pendekatan tanda ada karena netfilter melihat header transport dan kode perutean secara historis tidak. Itulah seluruh mekanismenya, dan itu menjelaskan mengapa cadangannya tiga bagian yang bekerja sama, bukan satu perintah pintar.

Ketiga bagian secara berurutan

Pertama, tandai aliran yang ingin dialihkan, dalam rantai yang berjalan cukup awal agar tanda sudah ada sebelum keputusan rute:

nft add table inet vpnexempt
nft 'add chain inet vpnexempt out { type route hook output priority mangle; }'
nft add rule inet vpnexempt out tcp dport 22 meta mark set 0x1

Kedua, kirim paket bertanda ke tabel terpisah:

ip rule add fwmark 0x1/0x1 table 100

Ketiga, beri tabel itu rute bawaan lewat tautan fisik. Alamatnya hanya contoh; ganti dengan milik Anda:

ip route add default via 192.168.1.1 dev wlan0 table 100

Lewatkan langkah ketiga dan paket bertanda tidak menemukan rute di tabel 100, jadi gagal. Gejalanya tampak seperti aturan merusak jaringan, padahal sebenarnya ia menghapus satu-satunya jalur yang tersisa bagi paket.

Apa yang menjaganya tetap bekerja setelah paket pertama

Tanda berlaku untuk paket keluar. Balasan tiba di antarmuka fisik dengan alamat yang diberikan tautan itu, dan tabel utama mungkin masih mengutamakan terowongan untuk tujuan tersebut. Dua mekanisme menjaga jalur balasan tetap konsisten: aturan berbasis sumber untuk alamat tautan, dan pelacakan koneksi yang menyimpan keputusan selama umur aliran. Menyimpan tanda ke conntrack dan memulihkannya saat balasan adalah cara biasa membuat pengecualian stateful tetap stabil.

Penyaringan jalur terbalik adalah pembunuh senyap lainnya. Jika kernel memvalidasi jalur kembali secara ketat dan balasan tiba di antarmuka yang tidak akan dipilih tabel utama, paket dibuang tanpa pesan. rp_filter nilai bawaannya berbeda menurut distribusi dan menurut apakah antarmuka diteruskan, jadi bacalah nilai efektifnya alih-alih menganggapnya mati.

Jangan menandai transport terowongan itu sendiri. Terowongan WireGuard atau UDP OpenVPN bukan TCP 22, jadi resep di atas aman, tetapi pengecualian yang ditulis sebagai semua kecuali tujuan terowongan bisa menangkap paket terenkripsi dan merusak terowongan dengan cara yang tampak seperti loop perutean.

Periksa, jangan menganggap

Tanyakan kepada kernel jalur mana yang akan diambilnya, untuk tujuan dan untuk port, lalu jalankan transfer sebenarnya:

ip route get 203.0.113.10
ip rule show
nft list ruleset

Jika tanda ada tetapi penghitungnya tidak pernah bergerak, aturannya tidak cocok. Penghitung adalah selisih antara konfigurasi yang Anda tulis dan kebijakan yang diterapkan kernel.

Kapan ini alat yang salah

Pengecualian berbasis port rapuh secara alami. Layanan berpindah port, HTTP/3 datang sebagai UDP 443, dan satu aplikasi bisa membuka beberapa aliran berbeda jenis. Jika persyaratan sebenarnya adalah program ini memakai tautan normal, lapisan perutean adalah tempat yang salah; ruang nama jaringan atau proksi per aplikasi lebih cocok.

Jika persyaratannya adalah subnet ini memakai tautan normal, lewati saja semua tanda dan tambahkan rute yang lebih spesifik. Lebih sederhana, terlihat dalam satu tabel, dan orang berikutnya bisa mengauditnya tanpa membaca kumpulan aturan.

Tuliskan mana dari tiga persyaratan yang benar-benar Anda punya sebelum menyentuh firewall. Mekanisme di atas tepat, dan ketepatan yang diterapkan pada lapisan yang salah hanyalah gangguan yang lebih lama.