Satu aplikasi lewat WireGuard: mengikat bukan merutekan

Setelan ini tampak seperti sakelar per aplikasi, jadi orang mengikat klien ke antarmuka WireGuard dan berharap hanya klien itu yang memakai terowongan. Yang sebenarnya dilakukan pengikatan adalah memilih alamat sumber. Kernel lalu mencari rute ke tujuan, menemukan rute bawaan biasa, dan mengirim paket keluar melalui tautan fisik dengan alamat terowongan terlampir. Hanya rute yang dipilih untuk alamat sumber itu yang menuntaskan maksudnya.

Mekanismenya punya dua bagian: tabel perutean yang seharusnya hanya dipakai lalu lintas terowongan, dan aturan yang mengirim sumber yang cocok ke sana.

Pengikatan menetapkan alamat sumber, tidak lebih

Linux memilih antarmuka keluar dengan mencari tujuan di tabel perutean, setelah aturan kebijakan sempat mengalihkan pencarian itu. Aturan dapat memilih berdasarkan alamat sumber, tanda firewall, antarmuka masuk, UID, atau bahkan port; masing-masing adalah cara lain untuk mengatakan lalu lintas ini alih-alih semuanya. Konfigurasi klien VPN memilih tabel yang memuat rute terowongan; aturannya memilih lalu lintas mana yang boleh melihatnya. Pengikatan saja tidak menyediakan keduanya.

Itulah sebabnya kegagalan ini terlihat begitu aneh. Aplikasi jelas memakai alamat terowongan, terowongan jelas aktif, dan lalu lintas jelas keluar melalui antarmuka yang salah. Setiap pernyataan benar, dan bersama-sama menggambarkan sistem yang tidak menghubungkan alamat dengan rutenya.

Beri terowongan tabelnya sendiri

wg-quick memasang rute di mana pun profil menyuruhnya. Menambahkan Table = 40 di bawah [Interface] memindahkannya ke tabel 40, bukan tabel utama. Naikkan antarmuka dan pastikan rute itu tiba: ip -4 route ls table 40 seharusnya menampilkan rute terowongan, dan ip -4 route get 10.66.127.142 menunjukkan bagaimana kernel saat ini menyelesaikan salah satunya. Dengan rute di tabelnya sendiri, tabel utama tetap berfungsi untuk semua hal lain.

Lakukan hal yang sama untuk IPv6 alih-alih mencocokkan prefiks yang lebar. ip -6 rule add from fd00::2/128 lookup 40 mematok satu alamat; fc00::/8 dapat bentrok dengan antarmuka lain di host dan menghasilkan aturan yang cocok lebih dari yang dimaksud.

Tambahkan aturan sumber dan perhatikan penghitungnya

Lalu hubungkan kedua bagian: ip -4 rule add from 10.66.127.142/32 lookup 40, dengan alamat yang sama terpasang pada antarmuka WireGuard. Letakkan kedua aturan di PostUp agar koneksi ulang memulihkannya. Verifikasi dengan permintaan sungguhan, bukan dengan setelan: ip route get 1.1.1.1 from 10.66.127.142 seharusnya menyebut perangkat terowongan, dan curl --interface wg0 ifconfig.me seharusnya melaporkan alamat terowongan alih-alih alamat rumah.

Bila masih gagal, baca ip -s rule. Aturan yang ada tetapi tidak pernah cocok menampilkan penghitung nol, dan itu membedakan aturan yang salah dari tidak adanya aturan. Satu perintah itu menghemat banyak dugaan tentang apakah aplikasi mengabaikan setelan antarmukanya.

Kasus sebaliknya: jauhkan SSH dari terowongan

Masalah kebalikannya sama umumnya: wg-quick memiliki rute bawaan dan sesi SSH ke server mati di tengah sesi. Aturannya berada pada nomor prioritas rendah, jadi pengecualian harus dievaluasi sebelum aturan itu. ip rule add dport 22 ipproto tcp table main priority 123 melakukannya pada iproute2 terbaru; bila pemilih tidak tersedia, tandai aliran di nftables dan cocokkan tandanya.

Periksa juga jalur balasannya. Sesi SSH yang terbentuk lalu membisu biasanya memiliki perutean asimetris, dengan satu arah keluar lewat terowongan dan arah lain lewat antarmuka fisik. ip route get untuk alamat server memberi tahu ke mana balasan akan pergi.

Catat nomor tabel, aturan sumber, dan pengecualian di dalam profil itu sendiri. Ketiganya termasuk satu rancangan dan akan diedit bersama.