Hentikan klien VPN saling menjangkau di terowongan

Dua klien bisa sama-sama membuka host lompat dan tetap tidak punya urusan membuka satu sama lain. Menjangkau layanan adalah keputusan penerusan, sedangkan menjangkau rekan adalah keputusan kebijakan, dan sebagian besar tumpukan VPN menyimpannya dalam objek terpisah. Tidak ada yang Anda konfigurasi untuk yang pertama menegakkan yang kedua. Jadi tugasnya bukan menambah aturan, melainkan menemukan objek yang menentukan lalu lintas sesama rekan di server ini, menuliskan penolakan di sana, dan membuktikannya dari klien.

Rute ke layanan bersama bukan izin antar rekan

Mengiklankan subnet klien memberi tahu rekan cara menaruh paket di kabel menuju alamat klien lain. Apakah paket itu terkirim diputuskan setelahnya, oleh apa pun yang meneruskannya. Di gateway Linux itu rantai FORWARD; di dalam daemon ruang pengguna itu tabel sesi terowongan itu sendiri. Rute menjawab keterjangkauan dan membiarkan izin tak tersentuh.

Karena itu pemeriksaan isolasi yang hanya membaca rute tidak membuktikan apa pun. /24 bisa didorong ke setiap klien sementara setiap paket antar rekan dijatuhkan di kait penerusan. Kasus berbahayanya adalah kebalikannya: tidak ada aturan eksplisit, nilai bawaan yang permisif, dan isolasi yang ada hanya karena tidak ada yang mengujinya.

Tulis persyaratannya dalam satu baris sebelum membuka terminal. Jangkau blok layanan dan host lompat, jangan jangkau apa pun lagi di dalam blok klien.

Cari tahu siapa yang benar-benar meneruskan paket rekan

Dua perilaku server tampak sama dari sisi klien dan membutuhkan aturan berbeda. Entah kernel meneruskan paket keluar dari antarmuka terowongan lagi, atau daemon menyalinnya antar sesi dan kernel tidak pernah melihatnya.

WireGuard termasuk kelompok pertama: tidak ada sakelar antar rekan, jadi paket dari 10.8.0.4 ke 10.8.0.5 tiba di wg0, menghantam kait penerusan, dan dirutekan keluar dari wg0 lagi ketika AllowedIPs mencakup kedua alamat. OpenVPN adalah kelompok kedua begitu client-to-client diatur dalam konfigurasi server, karena direktif itu menyerahkan paket antar sesi di ruang pengguna. Periksa konfigurasi yang termuat untuk direktif itu sebelum menulis apa pun. Aturan kernel yang tidak pernah melihat lalu lintas tidak bisa dibedakan dari aturan yang berfungsi, dan begitulah penerapan berakhir tanpa isolasi sama sekali.

Baca konfigurasi efektif, bukan berkas yang Anda anggap termuat, karena paket distribusi membawa penyertaan mereka sendiri. Jika daemon yang meneruskan, penolakan berada di kontrol per klien miliknya sendiri, dan firewall host hanya menyaring lalu lintas yang ditujukan ke host. Jika kernel yang meneruskan, kait penerusan adalah satu-satunya tempat yang penting.

Penerapan yang dirutekan dan diterjemahkan perlu satu pemeriksaan lagi: sumber yang dilihat klien jauh mungkin bukan yang Anda harapkan. Maka aturan yang cocok dengan subnet klien tidak cocok dengan apa pun. Catat alamat yang bertahan dari penerjemahan sebelum menulis pencocokan, dan utamakan mencocokkan pasangan antarmuka daripada menebak alamat NAT.

Beri setiap alamat identitas yang bisa dicabut sendiri

Isolasi runtuh begitu dua perangkat berbagi satu kredensial. Aturan yang dikaitkan dengan identitas itu tidak dapat memisahkan keduanya, dan pencabutan laptop yang hilang mencabut seluruh grup. Sertifikat per perangkat atau kunci per rekan menjaga pencabutan tetap lokal dan kebijakan tetap terbaca, karena setiap alamat memetakan tepat ke satu orang atau mesin. Di tempat desain tidak dapat melakukannya, katakan itu di runbook alih-alih menyebut aturannya berbutir halus.

Alokasi alamat harus sesuai dengan kebijakan. Cadangkan satu blok untuk layanan, satu blok untuk klien, dan bagikan alamat klien dari kumpulan yang Anda kendalikan, bukan dari rentang siapa cepat dia dapat. Jika server menerjemahkan atau menjembatani, simpan tabel pemetaan di samping konfigurasi, karena tabel itulah yang dibutuhkan pembaca berikutnya untuk menurunkan aturan lagi.

Letakkan penolakan di tempat paket melintasi terowongan

Di gateway yang meneruskan lalu lintas WireGuard, dua aturan menutupi kasus ini: izinkan blok layanan, lalu jatuhkan sisa blok klien. Pasangan antarmuka sama pentingnya dengan alamat, karena mencocokkan tujuan saja juga menangkap lalu lintas yang datang dari LAN. Muat keduanya dalam urutan itu agar izin dievaluasi lebih dulu.

Dengan nftables pasangan itu masuk ke tabel inet filter yang sudah ada, izin lebih dulu dan penjatuhan kedua. Kedua pencocokan memaku pasangan antarmuka serta alamatnya.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

Baca kembali rantainya setelah dimuat alih-alih memercayai status keluar, dan pastikan kedua aturan berada dalam urutan yang Anda maksudkan. Tambahkan aturan ip6 yang cocok untuk kumpulan IPv6, atau pasangan v4 hanya hiasan pada terowongan dua tumpukan. Jika server sudah punya kebijakan penerusan yang permisif, tambahkan penjatuhan alih-alih mengganti seluruh rantai.

Ketika client-to-client diaktifkan pada OpenVPN, aturan penerusan ini tidak pernah cocok dengan lalu lintas antar rekan dan penolakan harus hidup di kontrol daemon itu sendiri. Pertahankan aturan kernel untuk lalu lintas yang ditujukan ke host, tetapi jangan menghitungnya sebagai kontrol isolasi.

Buktikan penolakan dari klien, bukan dari server

Pengujian dari gateway tidak membuktikan apa pun, karena lalu lintas yang dihasilkan secara lokal mengambil jalur keluaran dan tidak pernah melintasi kait penerusan. Gunakan dua klien sungguhan: satu yang seharusnya menjangkau layanan, satu yang seharusnya ditolak. Jalankan kasus izin lebih dulu, agar terowongan yang rusak tidak disalahartikan sebagai kebijakan yang berfungsi.

Dari klien yang diizinkan, pastikan layanannya menjawab di portnya. Dari klien yang sama, coba alamat rekan dan harapkan penjatuhan senyap alih-alih penolakan:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

Paket yang dijatuhkan dan rekan yang luring sama-sama tampak seperti waktu habis, jadi periksa penghitungnya sebelum menyimpulkan apa pun. Pastikan penghitung aturan penjatuhan bertambah sementara rekan terbukti aktif. Ulangi melalui IPv6, di mana aturan ip6 yang hilang membuat penolakan v4 tampak efektif. Catat hasil yang diterima dan ditolak di runbook beserta tanggalnya, karena migrasi berikutnya akan menurunkan aturan itu lagi.