Marka yang dipasang di nftables seharusnya mengirim satu kelas lalu lintas melalui terowongan, tetapi lalu lintas tetap keluar melalui antarmuka fisik. Himpunan aturan tampak benar jika dilihat sendiri. Yang biasanya terjadi adalah sesuatu yang lain menulis marka yang sama, atau aturan perutean cocok dengan mask yang tidak lagi dipenuhi nilai baru.

Pemeriksaan 1: baca aturan yang dicocokkan kernel

Mulailah dari aturan kebijakan, bukan dari firewall. Kernel meninjau aturan menurut urutan prioritas dan kecocokan pertama yang menentukan tabel. Baca nilai fwmark dan mask dari aturan itu sendiri, lalu pastikan bahwa paket dengan marka yang Anda pasang benar-benar cocok dengannya. Aturan yang mengharapkan nilai 32 bit penuh tidak akan cocok dengan paket yang hanya membawa satu bit.

Kemudian pastikan tabel mana yang dipilih aturan itu dan apa isi tabel tersebut. Aturan yang menunjuk ke tabel kosong menghasilkan kegagalan pencarian, yang pada banyak sistem berarti paket jatuh ke aturan berikutnya dan keluar melalui antarmuka fisik.

Dua perintah menyelesaikannya: daftar aturan, dan pencarian rute untuk tujuan di tabel itu.

Pemeriksaan 2: marka paket atau marka koneksi

nftables dapat memasang marka pada paket dan marka pada entri pelacakan koneksi, dan keduanya objek yang berbeda. Marka paket hidup selama satu lintasan pemrosesan paket, sedangkan marka koneksi bertahan untuk aliran dan harus disalin dengan sengaja. Memasang satu dan mengharapkan yang lain adalah perbaikan setengah yang umum.

Jika aturan perutean bergantung pada marka paket, memulihkan marka koneksi di kemudian hari dalam jalur tidak berpengaruh pada keputusan itu, karena keputusan sudah diambil.

Tentukan objek mana yang memiliki sinyal perutean, lalu pasang di titik tempat keputusan perutean dibuat.

Pemeriksaan 3: siapa lagi yang menulis marka itu

Perkakas WireGuard sendiri memberi marka pada paket UDP-nya agar transportasi terenkripsi tidak dirutekan kembali ke terowongan miliknya. Jika himpunan aturan Anda memberikan nilai yang tidak terkait pada bidang yang sama, pengecualian itu hilang dan lalu lintas luar terowongan mencoba masuk ke dirinya sendiri. Gejalanya adalah terowongan yang terbentuk lalu berhenti meneruskan lalu lintas.

Marka juga dipakai oleh perkakas firewall lain, jaringan kontainer, dan perutean kebijakan untuk tujuan lain, jadi dua subsistem yang menulis seluruh bidang adalah konflik meskipun masing-masing benar secara terpisah.

Daftar penulisnya sebelum menambah satu lagi.

Pemeriksaan 4: mask menentukan apa yang Anda pertahankan

Marka adalah bidang 32 bit, dan mask adalah cara beberapa pemilik berbagi bidang itu. Memasang nilai dengan mask mempertahankan bit yang bukan milik Anda; memasang seluruh bidang menghancurkan bit semua orang lain. Baca mask di setiap aturan yang menyentuh bidang itu, termasuk yang tidak Anda tulis.

Dokumentasikan pembagian bit di samping himpunan aturan.

Jika tidak, orang berikutnya akan memakai ulang nilai yang sudah punya pemilik, dan konflik di sini tampak seperti bug perutean padahal itu bug pengalamatan. Dokumentasi nftables tentang metadata paket menjelaskan operasi markanya sendiri.

Pemeriksaan 5: verifikasi dengan aliran nyata, bukan pencarian

Pencarian rute biasa tidak membawa marka, sehingga bisa menunjukkan jalur berbeda dari paket sebenarnya. Hasilkan lalu lintas yang Anda pedulikan dan amati penghitung, entri pelacakan koneksi, dan antarmuka tempat ia benar-benar keluar. Uji kelas yang disertakan dan kelas yang dikecualikan, karena marka yang terlalu lebar merusak pengecualian sambil tampak berhasil. Jika kelas yang disertakan berfungsi dan kelas yang dikecualikan juga masuk terowongan, marka itu terlalu lebar, bukan terlalu sempit.

Hindari membersihkan status koneksi untuk memaksa penyegaran selama sesi aktif, karena aliran baru dan yang sudah ada dapat mengambil jalur berbeda secara sah.

Catat marka, mask, dan tabel di satu tempat, dan suntingan berikutnya menjadi dapat ditinjau.

Artikel terkait