Mengapa nftables tidak dapat melihat lalu lintas OpenVPN antar klien
Lalu lintas antar peer dikirim di dalam proses VPN, jadi penghitung penerusan tidak pernah bergerak. Menghitungnya berarti memilih antara jalur kernel dan jalur proses.
Dua klien di satu server bertukar berkas, transfernya berhasil, dan setiap aturan penerusan yang Anda arahkan ke terowongan melaporkan nol paket. Aturannya tidak rusak dan rantainya tidak salah tempat. Dengan penerusan antar peer diaktifkan, paket dikirim di dalam proses server dan tumpukan host tidak pernah menjadi perute, sehingga tidak ada yang bisa dihitung oleh firewall kernel. Memahami pemisahan itu menentukan apakah Anda mempertahankan jalan pintas atau membangun ulang jalur melalui kernel.
Ikuti satu paket menembus server
Dalam terowongan yang dirutekan, daemon menyerahkan paket terdekripsi setiap klien ke perangkat terowongan. Dari sana host merutekannya, kait penerusan berjalan, dan aturan yang cocok dengan perangkat terowongan dapat menghitung atau menjatuhkan lalu lintas. Itulah jalur yang diasumsikan sebagian besar contoh firewall.
| Forwarding path | Who decides | What the host firewall sees |
|---|---|---|
| Kernel routing between clients | Host routing table and forward rules | Every inner packet, with interface names |
| Peer forwarding inside the server process | The VPN daemon's own peer table | Only the outer encrypted transport |
Jalan pintas mengeluarkan host dari tengah. Paket terdekripsi satu sesi diserahkan ke sesi lain di dalam daemon, dan paket dalam tidak pernah dipancarkan pada perangkat terowongan atau dirutekan oleh host. Lalu lintas yang dienkapsulasi tetap melintasi antarmuka fisik, jadi tangkapan luar terlihat sibuk sementara aturan dalam tetap diam. Tangkapan yang diambil pada perangkat terowongan tidak menunjukkan apa pun, yang mengejutkan siapa pun yang mengharapkan melihat transfer di sana. Asimetri itu adalah cara tercepat mengenali jalan pintas dari luar daemon.
Uji penghitung yang menentukan jalur mana yang berjalan
Pasang penghitung pada aturan yang seharusnya berlaku, jalankan transfer antara dua klien yang seharusnya diblokir aturan itu, lalu baca penghitungnya.
sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward
Jika transfer berhasil dan penghitung tetap nol, kernel tidak pernah menangani paket-paket itu, dan tidak ada penyuntingan aturan yang akan mengubahnya. Ulangi uji yang sama terhadap layanan di server itu sendiri, karena aliran itu memang melintasi tumpukan host dan penghitungnya bergerak. Membandingkan kedua hasil itulah yang menghasilkan jawabannya.
Dua detail mencegah pembacaan keliru. Nama antarmuka yang ditulis dalam label rantai tidak menyaring apa pun dengan sendirinya, karena pencocokan terjadi pada bidang antarmuka di dalam aturan. Dan desain jembatan lapisan 2 berperilaku lain lagi: di sana klien berbagi satu domain siaran, jadi penemuan peer memang diharapkan, bukan kesalahan perutean.
Switch bukan daftar akses
Inilah bagian yang memakan satu sore. Penerusan antar peer adalah satu pengaturan hidup atau mati, dan selama hidup, daemon adalah satu-satunya titik penerusan. Firewall host tidak dapat menyatakan siapa boleh mencapai siapa, dan berkas per klien tidak mengubah switch menjadi matriks kebijakan.
Jika Anda memerlukan aturan per peer, pilihannya adalah antara melepaskan jalan pintas dan melepaskan firewall host sebagai kendali. Mematikannya memulihkan penerusan kernel, yang menuntut penerusan IP aktif di server dan aturan eksplisit untuk aliran yang Anda inginkan. Membiarkannya hidup berarti kebijakan tinggal di konfigurasi daemon, yang dalam praktiknya berarti semua peer atau tidak ada peer.
Proses server terpisah dengan kumpulan alamat dan port sendiri adalah jalan tengah yang dapat dijalankan. Setiap proses membawa tepat satu keputusan akses, jadi dua kelompok dapat memiliki aturan berbeda tanpa matriks kebijakan. Host dapat merutekan antar kumpulan bila itu yang dimaksud, dan firewall kemudian melihat aliran itu karena melintasi host. Biayanya adalah port tambahan, sertifikat tambahan, dan profil per kelompok.
Memilih titik penerusan
Pilih penerusan kernel ketika firewall adalah mesin kebijakan, ketika Anda memerlukan pencatatan per aliran, atau ketika akuntansi penting. Biayanya adalah throughput melalui tumpukan host dan lebih banyak aturan untuk dirawat. Manfaatnya adalah setiap alat yang ada, dari penghitung hingga pengekspor aliran, kembali menggambarkan lalu lintas. Pada server kecil biaya itu tak terlihat; pada relai sibuk tidak.
Pilih penerusan di dalam proses ketika lalu lintas antar peer seluruhnya diizinkan atau seluruhnya ditolak dan server disesuaikan untuk itu. Biayanya adalah penghitung, disiplin antrean, dan pelacakan koneksi tidak lagi menggambarkan aliran dalam; itu hanya dapat diterima jika nanti tidak ada yang bergantung padanya.
Apa pun yang Anda pilih, tuliskan di samping aturan firewall. Himpunan aturan yang tampak mengizinkan lalu lintas antar peer sementara daemon tetap memutuskan menyesatkan orang berikutnya yang mendebug transfer gagal. Siapa pun yang hanya membaca aturan akan menganggap kernel adalah gerbangnya.
Apa yang harus diperiksa sebelum mengubah aturan
Baca konfigurasi yang benar-benar dimuat server, bukan berkas yang Anda ingat telah disunting, dan pastikan apakah opsi peer ada. Jika Anda mengubahnya, pastikan layanan memuat ulang dan bukan hanya menulis ulang berkas di disk.
Lalu ulangi uji dengan aliran klien ke server untuk membuktikan aturan itu cocok sama sekali, dan periksa rute yang didorong, karena rute yang hilang tampak persis seperti blokir firewall dari sisi klien. Ubah urutan aturan hanya setelah Anda tahu titik penerusan mana yang memiliki keputusan itu.