Satu aplikasi melalui WireGuard: ikatan bukan penghalaan

Tetapan ini kelihatan seperti suis setiap aplikasi, jadi orang mengikat klien pada antara muka WireGuard dan menjangka hanya klien itu menggunakan terowong. Apa yang sebenarnya dilakukan oleh ikatan ialah memilih alamat sumber. Kernel kemudian mencari laluan untuk destinasi, menemui laluan lalai biasa dan menghantar paket keluar melalui pautan fizikal dengan alamat terowong dilampirkan. Hanya laluan yang dipilih untuk alamat sumber itu menyempurnakan hasratnya.

Mekanisme ini mempunyai dua separuh: jadual penghalaan yang sepatutnya hanya digunakan oleh trafik terowong, dan peraturan yang menghantar sumber yang sepadan ke sana.

Ikatan menetapkan alamat sumber, tidak lebih

Linux memilih antara muka keluar dengan mencari destinasi dalam jadual penghalaan, selepas peraturan dasar berpeluang mengubah hala carian itu. Peraturan boleh memilih mengikut alamat sumber, tanda tembok api, antara muka masuk, UID atau malah port; setiap satunya ialah cara lain untuk mengatakan trafik ini dan bukan semuanya. Konfigurasi klien VPN memilih jadual yang memuatkan laluan terowong; peraturan memilih trafik mana yang dibenarkan merujuknya. Ikatan sahaja tidak menyediakan kedua-duanya.

Itulah sebabnya kegagalan ini kelihatan begitu pelik. Aplikasi itu memang menggunakan alamat terowong, terowong itu memang berjalan, dan trafik itu memang keluar melalui antara muka yang salah. Setiap pernyataan benar, dan bersama-sama ia menggambarkan sistem yang tiada apa-apa menghubungkan alamat dengan laluan.

Beri terowong jadualnya sendiri

wg-quick memasang laluan di mana sahaja profil menyuruhnya. Menambah Table = 40 di bawah [Interface] memindahkannya ke jadual 40 dan bukan jadual utama. Naikkan antara muka dan sahkan ia sampai: ip -4 route ls table 40 sepatutnya menunjukkan laluan terowong, dan ip -4 route get 10.66.127.142 menunjukkan cara kernel menyelesaikan salah satunya sekarang. Dengan laluan dalam jadualnya sendiri, jadual utama terus berfungsi untuk semua yang lain.

Lakukan perkara sama untuk IPv6 dan bukan memadankan awalan yang luas. ip -6 rule add from fd00::2/128 lookup 40 memakukan satu alamat; fc00::/8 boleh berlanggar dengan antara muka lain pada hos dan menghasilkan peraturan yang sepadan lebih daripada yang dimaksudkan.

Tambah peraturan sumber dan perhatikan pembilangnya

Kemudian sambungkan kedua-dua separuh: ip -4 rule add from 10.66.127.142/32 lookup 40, dengan alamat yang sama dilampirkan pada antara muka WireGuard. Letakkan kedua-dua peraturan dalam PostUp supaya sambungan semula memulihkannya. Sahkan dengan permintaan sebenar dan bukan tetapan: ip route get 1.1.1.1 from 10.66.127.142 sepatutnya menamakan peranti terowong, dan curl --interface wg0 ifconfig.me sepatutnya melaporkan alamat terowong dan bukan alamat rumah.

Apabila ia masih gagal, baca ip -s rule. Peraturan yang wujud tetapi tidak pernah sepadan menunjukkan pembilang sifar, dan itu membezakan peraturan yang salah daripada ketiadaan peraturan. Satu arahan itu menjimatkan banyak tekaan tentang sama ada aplikasi mengabaikan tetapan antara mukanya.

Kes sebaliknya: jauhkan SSH daripada terowong

Masalah sebaliknya juga sama biasa: wg-quick memiliki laluan lalai dan sesi SSH ke pelayan mati di tengah-tengah. Peraturannya terletak pada nombor keutamaan rendah, jadi pengecualian mesti dinilai lebih awal daripadanya. ip rule add dport 22 ipproto tcp table main priority 123 melakukannya pada iproute2 terkini; di mana pemilih tidak tersedia, tandakan aliran dalam nftables dan padankan tandanya.

Periksa juga laluan balasan. Sesi SSH yang terbentuk dan kemudian senyap biasanya mempunyai penghalaan tidak simetri, dengan satu arah keluar melalui terowong dan arah lain melalui antara muka fizikal. ip route get untuk alamat pelayan memberitahu anda arah mana balasan akan pergi.

Catat nombor jadual, peraturan sumber dan pengecualian dalam profil itu sendiri. Ketiga-tiganya tergolong dalam satu reka bentuk dan akan disunting bersama.