Cara menyematkan satu aplikasi Linux pada VPN dengan peraturan UID

Menyematkan satu program pada VPN di Linux kebanyakannya masalah penghalaan, dan peraturan firewall hanya memutuskan apa yang berlaku selepas laluan dipilih. Jika anda memadankan UID program dalam OUTPUT sebelum terowong memiliki laluan lalai, peraturan itu menggugurkan trafik yang anda mahu lindungi. Peraturan yang sama juga tidak melihat proses penyelesai yang menjawab pertanyaan DNS program. Betulkan susunannya dan satu akaun tanpa keistimewaan menjadi pemilih terowong berpecah yang boleh dipercayai.

Beri akaun laluan sebelum keputusan

Padanan pemilik menjawab satu soalan: adakah soket tempatan milik UID ini membina paket itu? Ia tidak memilih antara muka dan tidak boleh memindahkan trafik yang sudah dihantar oleh jadual utama melalui NIC fizikal. Itulah sebabnya peraturan UID tanpa laluan yang sepadan menyekat program itu dan bukan mengalihkannya.

Hantar akaun melalui jadualnya sendiri dahulu, kemudian biarkan firewall mengesahkan hasilnya. Ini berfungsi pada hos yang iproute2-nya memahami uidrange, yang ip rule help melaporkannya dalam satu baris. Jadual 100 menyimpan laluan lalai melalui terowong, dan peraturan itu menghantar hanya UID 1000 ke jadual tersebut. Semua yang lain kekal pada jadual utama dan terus menggunakan pautan fizikal.

ip rule add uidrange 1000-1000 table 100
ip route add default dev tun0 table 100

Akaun kedua yang memerlukan terowong lain mendapat jadual 101 dan peraturannya sendiri, kerana dua profil tidak boleh sama-sama memiliki laluan lalai dalam jadual yang sama. Profil NetworkManager adalah seluruh sistem, jadi bahagian ini kekal manual, dan peraturan hilang semasa but semula melainkan sesuatu memulihkannya. Tulis jadual ke dalam skrip but di sebelah definisi terowong supaya penyambungan semula tidak meninggalkan satu akaun di laluan yang salah.

Mengapa pengecualian loopback membunuh terowong

Kebanyakan versi peraturan yang disalin menggugurkan setiap paket yang tidak keluar melalui loopback. Terowong bukan loopback, jadi bentuk itu juga menggugurkan trafik terowong, dan hasilnya kelihatan seperti VPN mati dan bukan kesilapan firewall.

Apabila OUTPUT berjalan, kernel sudah memilih antara muka keluar, jadi -o dibandingkan dengan jawapan laluan dan bukan dengan pengepala paket. Padanan pemilik hanya dirujuk dalam OUTPUT dan POSTROUTING, dan paket yang diteruskan tidak membawa soket untuk dibacanya. Gabungan itu bermakna pengecualian mesti menamakan antara muka terowong dan menafikan padanan tersebut, bukan menafikan loopback.

Loopback masih layak mendapat ACCEPT sendiri di atas DROP, kerana paket DNS pertama daripada program pergi ke stub tempatan melalui lo. Letakkan kedua-dua peraturan dalam susunan ini dan akaun itu sampai ke stub, kemudian terowong, dan tidak ke mana-mana lagi.

iptables -I OUTPUT 1 -o lo -m owner --uid-owner vpnapp -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner vpnapp ! -o tun0 -j DROP

IPv6 ialah set peraturan berasingan, dan pasangan khusus v4 membiarkan ip6tables tidak disentuh. Program yang mengutamakan rekod AAAA kemudian akan keluar melalui pautan fizikal tanpa pernah sampai ke DROP. Cerminkan kedua-dua peraturan dalam ip6tables, atau lumpuhkan IPv6 pada hos apabila terowong tidak membawa alamat v6. Peraturan yang ditambah dengan tangan juga hilang semasa but semula, jadi simpan dengan netfilter-persistent save atau bina semula logik yang sama sebagai jadual nftables yang dimuatkan oleh unit but.

Jawapan DNS datang daripada proses lain

Pertanyaan program ke 127.0.0.53 melepasi ACCEPT loopback, dan di situlah padanan UID berhenti. Penyelesai stub meneruskan ke atas daripada akaun perkhidmatannya sendiri, jadi peraturan yang dikunci kepada vpnapp tidak pernah melihat pertanyaan kedua. Jika penyelesai memilih pelayan LAN untuk pautan, jawapan kembali melalui NIC fizikal sementara paket program itu sendiri kekal di terowong. Hasil yang kelihatan ialah terowong yang berfungsi dengan nama yang rosak, atau nama yang dijawab oleh pelayan yang anda tidak pilih.

Betulkan penyelesaian nama pada pautan terowong, bukan pada aplikasi. Beri profil terowong pelayan DNS dan domain penghalaan, kemudian sahkan dengan resolvectl query dan resolvectl status tun0 bahawa penyelesai menggunakannya untuk nama yang penting. Di dalam ruang nama rangkaian masalah itu hilang, kerana penyelesai ruang nama hanya mengenal terowong.

Periksa peraturan daripada akaun itu sendiri

Tanya kernel laluan apa yang diterima oleh UID, kemudian buat permintaan sebagai akaun itu dan bandingkan alamat keluar dengan alamat akaun anda sendiri. Jika kedua-duanya melaporkan alamat yang sama, peraturan itu memadankan sesuatu yang lain daripada trafik yang anda uji. Perintah pertama di bawah menunjukkan carian laluan tanpa menghantar paket, yang memisahkan kesilapan penghalaan daripada kesilapan firewall.

ip route get 1.1.1.1 uid 1000
sudo -u vpnapp curl -s https://ifconfig.co

Kaunter menunjukkan sama ada peraturan pernah tercetus. Jalankan iptables -vnL OUTPUT, baca bilangan paket di sebelah setiap peraturan, dan anggap sifar di sebelah DROP selepas trafik sebenar sebagai kesilapan padanan.

Trafik yang diteruskan berada di luar reka bentuk ini. Kontena atau VM di belakang jambatan tidak mempunyai soket tempatan milik vpnapp, jadi padanan pemilik tidak pernah tercetus dan paket itu mengikut dasar FORWARD. Jika beban kerja itu perlu dilindungi, ujinya secara berasingan dan tulis dasar yang dikunci kepada jambatan atau alamat kontena. Reka bentuk ini bertahan apabila jadual, pengecualian antara muka, penyelesai dan peraturan v6 semuanya menunjuk ke arah yang sama; tinggalkan mana-mana satu daripadanya dan akaun itu sama ada bocor atau kehilangan sambungan.