Cara menjalankan satu proses Linux di luar tunnel WireGuard

Anda tidak dapat mengecualikan sebuah program dari host WireGuard bertunnel penuh dengan mengedit rute. Rute memilih jalur berdasarkan tujuan, dan yang ingin Anda kecualikan adalah sebuah proses, jadi kernel tidak punya apa pun untuk dicocokkan. Pendekatan yang bisa dipakai adalah memberi proses itu konteks jaringannya sendiri: namespace dengan antarmuka, alamat, dan rute defaultnya sendiri, yang dihubungkan ke host melalui pasangan veth. Saya menjalankannya di Ubuntu 24.04 dengan wireguard-tools 1.0.20210914, dan namespace tidak pernah menjadi masalah — kebijakan penerusan host dan aturan penandaan tunnel-lah yang menjadi masalah.

Pilih dulu jenis konteks yang Anda butuhkan

Dalam praktik muncul dua bentuk. Jika host menjalankan tunnel penuh dan satu program harus keluar lewat jalur ISP, Anda membangun namespace kedua, menghubungkannya ke host, dan membiarkan host meneruskan serta menerjemahkan trafik untuknya. Jika sebuah namespace sudah membawa antarmuka VPN dan Anda hanya perlu perintah yang dijalankan di dalamnya, itu kasus biasa ip netns exec dan sebagian besar pekerjaan perutean sudah selesai.

Tidak ada satu pun bentuk yang memberi Anda aturan yang dibatasi pada satu ID proses. Netfilter mencocokkan alamat, port, tanda, dan antarmuka; tidak ada tabel perutean per proses. Penandaan dapat mengarahkan trafik, tetapi tanda harus dipasang pada paket yang sudah Anda identifikasi, dan itu masalah yang sama satu lapis lebih rendah. Namespace memisahkan seluruh tumpukan untuk pohon proses itu, dan itulah sebabnya ini jawaban yang lazim.

Jika persyaratannya memang tidak ada apa pun yang keluar dari tunnel, hentikan tunnelnya saja. Namespace ada untuk kasus campuran: satu program keluar, semua yang lain masuk, di mesin yang sama, pada waktu yang sama.

Bangun konteks kedua dan hubungkan ke host

Tata letak ilustratif: host memiliki antarmuka WireGuard yang membawa rute default, dan sebuah namespace jaringan bernama clearnet yang dihubungkan ke host melalui pasangan veth. Alamat di bawah hanyalah contoh.

ip netns add clearnet
ip link add veth-clear-out type veth peer name veth-clear-in
ip addr add 192.168.100.1/24 dev veth-clear-out
ip link set veth-clear-out up
ip link set veth-clear-in netns clearnet
ip netns exec clearnet ip addr add 192.168.100.2/24 dev veth-clear-in
ip netns exec clearnet ip link set veth-clear-in up
ip netns exec clearnet ip route add default via 192.168.100.1

Namespace itu sekarang dapat menjangkau host dan tidak ada yang lain. Host harus meneruskan trafik dan menulis ulang alamat sumber, karena 192.168.100.0/24 bersifat privat dan router di atasnya tidak memiliki rute kembali ke dalamnya:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <wan-interface> -j MASQUERADE

Konfirmasikan sisi namespace sebelum melanjutkan.ip netns exec clearnet ip route seharusnya menampilkan rute veth dan rute default melalui 192.168.100.1, dan ping ke alamat itu seharusnya menjawab. Jika ping ke alamat host gagal, alamat atau status tautan salah dan tidak ada aturan firewall yang akan menolong.

Saat nama terselesaikan tetapi tidak ada yang kembali, bacalah FORWARD

Kegagalan klasik tampak seperti bug perutean: namespace menyelesaikan sebuah nama, paket keluar, dan tidak pernah ada jawaban. Pada host dengan kebijakan FORWARD DROP — beberapa distribusi dan sebagian besar image yang diperkeras melakukannya — paket dibuang di jalan, dan galat yang dicetak aplikasi tidak mengatakan apa pun tentang penyaringan.

Baca rantainya sebelum menambahkan apa pun:

iptables -S FORWARD
nft list chain inet filter forward

Lalu izinkan trafik di kedua arah, dengan penghitung, agar Anda tahu apakah aturannya pernah cocok:

iptables -A FORWARD -i veth-clear-out -o <wan-interface> -j ACCEPT
iptables -A FORWARD -i <wan-interface> -o veth-clear-out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
watch -n1 'iptables -L FORWARD -v -n'

Aturan dengan penghitung paket nol tidak ada di jalur. Entah nama antarmuka berbeda dari yang Anda asumsikan, atau aturan sebelumnya di rantai sudah menerima, membuang, atau mengembalikan paket lebih dulu. Perbaiki urutannya, bukan teks aturannya.

Trafik balasan adalah separuh yang orang lupakan. Aturan balik membutuhkan nama veth yang sama plus pencocokan status koneksi, atau penerimaan antarmuka biasa jika Anda membiarkan kebijakannya terbuka. Tambahkan hanya aturan keluar dan gejala aslinya kembali, dengan aturan baru Anda berdiri di sana dan tampak benar.

Jauhkan aturan penandaan tunnel dari jalur baru

Langkah ini mengubah namespace yang berfungsi menjadi bocor. Pemasangan WireGuard biasanya memasang kebijakan tanda firewall bersama aturan perutean mereka sendiri dan tabel khusus, sehingga paket tanpa tanda jatuh kembali ke tabel utama sementara paket bertanda memakai tabel tunnel. Trafik yang diteruskan dari namespace dievaluasi terhadap perutean kebijakan saat keluar, dan tergantung bagaimana aturan itu ditulis, ia bisa masuk ke tabel tunnel.

Dua tambahan memisahkan jalurnya. Kembalilah lebih awal di rantai mangle untuk subnet namespace, dan tambahkan aturan berbasis sumber yang menaruh subnet itu di tabel utama:

iptables -t mangle -I PREROUTING -s 192.168.100.0/24 -j RETURN
ip rule add from 192.168.100.0/24 lookup main priority 100

Prioritas 100 diurutkan sebelum aturan tunnel di host saya, jadi tabel biasa yang memutuskan untuk sumber itu. Jangan menyalin angkanya secara buta: prioritas yang wg-quick dipasang berbeda antarversi dan antara pemasangan IPv4 dan IPv6, jadi jalankan ip rule show dan pilih prioritas yang jatuh di depan aturan tunnel di mesin Anda.

Verifikasi dengan pencarian khusus sumber alih-alih memercayai daftar aturan:

ip route get 1.1.1.1 from 192.168.100.2
ip netns exec clearnet ip route get 1.1.1.1

Jika perintah pertama melaporkan antarmuka WireGuard, aturan baru belum berada di depan kebijakan tunnel. Jika ia melaporkan antarmuka WAN sementara yang kedua masih menampilkan rute default veth, host dan namespace tidak sepakat dan Anda sebaiknya membaca ulang kedua tabel perutean.

Jalankan proses yang membuka koneksi

Menjalankan perintahnya hanya satu baris, tetapi jalankan proses yang benar-benar membuat socket.ip netns exec clearnet curl -s https://ifconfig.me adalah uji jujur terkecil: ia menunjukkan alamat yang ditampilkan namespace kepada dunia, bukan alamat yang akan dipakai host.

Untuk layanan, lampirkan namespace lewat jalur agar proses tetap di dalamnya sepanjang hidupnya:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Aplikasi grafis adalah tempat pendekatan satu baris diam-diam gagal. Peramban yang diluncurkan dari menu sering menyerahkan permintaan ke instans yang sudah berjalan di luar namespace, sehingga jendela baru muncul dan trafik tetap keluar lewat tunnel. Beri ia profil terpisah agar instans baru benar-benar dibuat, lalu periksa konteks prosesnya alih-alih menduga:

readlink /proc/$(pgrep -f clearnet-profile | head -1)/ns/net
readlink /run/netns/clearnet

Kedua keluaran harus cocok. Pemeriksaan yang sama berlaku untuk program apa pun yang berjalan lama, dan ada baiknya melakukannya sekali per aplikasi alih-alih menganggap peluncur melakukan apa yang Anda maksud.

Resolusi nama memerlukan keputusannya sendiri. Membuat namespace tidak memberinya konfigurasi resolver; berkas per namespace didukung melalui /etc/netns/<name>/resolv.conf dan tanpanya Anda mewarisi perilaku yang mudah salah dibaca. IPv6 memerlukan perlakuan yang sama: jika namespace tidak memiliki rute default v6 sementara aplikasi memilih v6, permintaan dapat tersendat sebelum mundur, yang tampak seperti tunnel rusak.

Periksa kerangkanya, bukan hanya alamat keluar

Alamat publik yang berfungsi membuktikan rutenya, bukan seluruh persyaratannya. Telusuri sisanya dalam urutan ini:

• ip netns exec clearnet ip route get 1.1.1.1 menampilkan rute default veth, bukan antarmuka WireGuard.
• Penghitung FORWARD pada kedua aturan bertambah selama permintaan berjalan.
• Proses aplikasi melaporkan inode namespace yang Anda harapkan.
• Setelah reboot namespace sudah ada sebelum layanan dimulai; unit yang berjalan lebih awal gagal, atau lebih buruk, berjalan di luar namespace.

Lalu putuskan apa yang harus terjadi saat tunnel putus. Namespace tetap berfungsi, itulah inti latihan ini dan sekaligus risikonya: program yang dikecualikan tetap terhubung sementara semua yang lain berhenti. Catat itu sebagai pilihan kebijakan dan bersikap jelas tentang apa yang tidak dicakup pengecualian — identitas akun, status peramban yang tersimpan, dan penyedia DNS Anda semuanya berada di luar cakupan namespace jaringan, dan memperlakukan pengecualian sebagai anonimitas adalah kesalahan yang bertahan lebih lama daripada konfigurasinya.