Rutekan hanya satu layanan web lokal melewati VPN berdasarkan port

Satu layanan host harus menjawab internet lewat tautan naik fisik sementara semua yang lain di mesin tetap memakai terowongan. Tiga syarat menentukan apakah perutean berbasis kebijakan mampu menanggung beban itu, dan masing-masing murah diperiksa sebelum Anda menulis aturan. Layanan harus berakhir di host ini, bukan di balik DNAT atau porta yang diteruskan, aturan VPN itu sendiri harus mengizinkan pengecualian, dan Anda harus mencocokkan balasannya, bukan permintaannya. Gagal salah satu dari tiga, perintah di bawah termuat bersih tetapi tidak melakukan hal berguna.

Periksa tiga syarat sebelum menulis aturan

Kontainer yang menerbitkan porta melalui DNAT, atau server di balik penerusan porta, menghasilkan paket yang tidak berasal dari host ini. Paket itu diteruskan, jadi aturan yang berbasis pada masukan lokal host tidak pernah melihatnya dan lalu lintas tetap mengambil rute bawaan. Pastikan di mana layanan benar-benar berjalan sebelum melanjutkan, karena inilah syarat yang paling sering salah dipahami orang.

Syarat kedua adalah kebijakan, bukan mekanika. Rute apa pun yang melewati terowongan adalah pengecualian dari tujuan terowongan, dan pada host terkelola keputusan itu milik pemilik kebijakan, bukan orang yang men-debug batas waktu.

Cocokkan balasannya, bukan porta tujuan klien

Balasan dari server yang mendengarkan di TCP 443 meninggalkan host dengan porta sumber 443. Peramban di host yang sama yang terhubung ke situs HTTPS jauh mengirim porta sumber sementara dan porta tujuan 443. Keduanya lalu lintas porta 443 dan hanya satu yang seharusnya memakai tabel WAN, itulah sebabnya pencocokan porta tujuan akan menangkap separuh yang salah.

Arah balasan adalah yang dapat Anda bedakan. Cocokkan porta sumber, batasi aturan pada paket yang dibuat secara lokal, dan aturan itu mencakup jawaban layanan sendiri tanpa menyentuh permintaan peramban.

Bangun tabel balik yang lengkap sebelum aturan menunjuk ke sana

Tabel kosong berarti tidak ada rute, yang terlihat seperti layanan rusak, bukan kebijakan rusak. Isi dulu, dengan nomor tabel dan prioritas yang tidak diklaim hal lain di host:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Baca angka dari host yang hidup alih-alih menyalinnya. ip -4 rule show memberi tahu prioritas mana yang terpakai, dan menambahkan aturan pada prioritas yang sudah ada diam-diam mengubah urutan dua aturan yang masing-masing tampak baik.

Dua pemilih melakukan pekerjaan sebenarnya di sini. iif lo adalah cara kernel melaporkan paket yang dihasilkan host sendiri, sehingga aturan tidak bisa secara tidak sengaja menangkap lalu lintas diteruskan yang datang dari luar. ipproto tcp sport 443 mempersempitnya ke satu transport dan satu porta, yang seketat yang diizinkan persyaratan. Hapus pemilih protokol dan aturan juga menangkap UDP 443, yang merupakan layanan lain dengan perilaku berbeda.

Jaga balasan privat tetap di dalam terowongan

Jika pendengar yang sama juga menjawab klien di sisi privat, rute bawaan WAN yang menangkap semua di tabel 100 akan mencoba mengembalikan balasan itu lewat tautan naik. Tambahkan prefiks privat yang tidak boleh mengikuti bawaan WAN, atau biarkan mereka jatuh ke aturan kebijakan berikutnya:

ip -4 route add table 100 throw 10.90.0.0/24

Rute throw mengakhiri pencarian di tabel ini dan mengembalikan paket ke daftar aturan, sehingga kebijakan VPN yang mengikutinya mendapat kesempatannya. Rute itu sendiri tidak merutekan apa pun ke terowongan, dan jika tidak ada aturan berikutnya yang punya rute cocok, paket tetap gagal; verifikasi kebijakan berikutnya alih-alih menganggap throw adalah perbaikan.

Penyaringan jalur balik dan aturan firewall host tetap berlaku untuk permintaan yang datang. Lihat putusan sebenarnya sebelum melonggarkan validasi, karena pengecualian perutean tidak membuat rp_filter menerima jalur balik yang dianggapnya mustahil.

Uji TCP, lalu QUIC, lalu mulai ulang

Buka satu koneksi dari klien eksternal yang diizinkan dan satu dari sisi privat, lalu periksa pencarian balasan dengan alamat dan porta sebenarnya. Jika balasan eksternal memakai tabel 100 dan yang privat tidak, kebijakan melakukan apa yang Anda minta.

HTTP/3 disajikan melalui UDP dan tidak akan dicocokkan oleh aturan TCP, jadi pendengar QUIC perlu pemilihnya sendiri atau ia tetap memakai terowongan sementara HTTPS berfungsi. Simpan aturan yang Anda pilih pada komponen yang memiliki antarmuka, dan konfirmasi setelah menyambung ulang atau pembaruan DHCP. Ketika manajer pesaing menghapus rute runtime setelah mulai ulang, itu masalah kepemilikan yang harus diperbaiki di sumbernya, bukan alasan menambahkan aturan NAT yang lebih luas di atasnya.