Hentikan klien VPN daripada saling mencapai di terowong

Dua klien boleh sama-sama membuka hos lompat dan masih tiada urusan membuka satu sama lain. Mencapai perkhidmatan ialah keputusan penghantaran, manakala mencapai rakan sebaya ialah keputusan dasar, dan kebanyakan tindanan VPN menyimpannya dalam objek berasingan. Tiada apa yang anda konfigurasikan untuk yang pertama menguatkuasakan yang kedua. Jadi tugasnya bukan menambah peraturan, tetapi mencari objek yang menentukan trafik rakan sebaya pada pelayan ini, menulis penafian di sana, dan membuktikannya daripada klien.

Laluan ke perkhidmatan bersama bukan kebenaran antara rakan sebaya

Mengiklankan subnet klien memberitahu rakan sebaya cara meletakkan paket pada wayar menuju alamat klien lain. Sama ada paket itu dihantar diputuskan kemudian, oleh apa yang menghantarnya. Pada gateway Linux itu rantai FORWARD; di dalam daemon ruang pengguna itu jadual sesi terowong itu sendiri. Laluan menjawab kebolehcapaian dan membiarkan kebenaran tidak disentuh.

Sebab itu pemeriksaan pengasingan yang hanya membaca laluan tidak membuktikan apa-apa. /24 boleh ditolak kepada setiap klien sementara setiap paket antara rakan sebaya digugurkan pada cangkuk penghantaran. Kes berbahaya ialah sebaliknya: tiada peraturan eksplisit, nilai lalai yang permisif, dan pengasingan yang wujud hanya kerana tiada siapa mengujinya.

Tulis keperluan dalam satu baris sebelum membuka terminal. Capai blok perkhidmatan dan hos lompat, jangan capai apa-apa lagi di dalam blok klien.

Cari siapa yang sebenarnya menghantar paket rakan sebaya

Dua tingkah laku pelayan kelihatan sama dari sisi klien dan memerlukan peraturan berbeza. Sama ada kernel menghantar paket keluar dari antara muka terowong sekali lagi, atau daemon menyalinnya antara sesi dan kernel tidak pernah melihatnya.

WireGuard tergolong dalam kumpulan pertama: ia tiada suis antara rakan sebaya, jadi paket dari 10.8.0.4 ke 10.8.0.5 tiba pada wg0, melanggar cangkuk penghantaran dan dihalakan keluar dari wg0 semula apabila AllowedIPs meliputi kedua-dua alamat. OpenVPN ialah kumpulan kedua sebaik sahaja client-to-client ditetapkan dalam konfigurasi pelayan, kerana arahan itu menyerahkan paket antara sesi di ruang pengguna. Periksa konfigurasi yang dimuatkan untuk arahan itu sebelum menulis apa-apa. Peraturan kernel yang tidak pernah melihat trafik tidak dapat dibezakan daripada peraturan yang berfungsi, dan begitulah penggunaan berakhir tanpa sebarang pengasingan.

Baca konfigurasi berkesan dan bukan fail yang anda andaikan dimuatkan, kerana pakej distro membawa kemasukan mereka sendiri. Jika daemon yang menghantar, penafian terletak dalam kawalan per kliennya sendiri, dan firewall hos hanya menapis trafik yang dialamatkan kepada hos. Jika kernel yang menghantar, cangkuk penghantaran ialah satu-satunya tempat yang penting.

Penggunaan yang dihalakan dan diterjemah memerlukan satu lagi pemeriksaan: sumber yang dilihat klien jauh mungkin bukan yang anda jangkakan. Maka peraturan yang sepadan dengan subnet klien tidak sepadan dengan apa-apa. Catat alamat yang bertahan selepas terjemahan sebelum menulis padanan, dan utamakan memadankan pasangan antara muka daripada meneka alamat NAT.

Beri setiap alamat identiti yang boleh ditarik balik sendiri

Pengasingan runtuh sebaik dua peranti berkongsi satu kelayakan. Peraturan yang terikat pada identiti itu tidak dapat memisahkan mereka, dan penarikan balik komputer riba yang hilang menarik balik seluruh kumpulan. Sijil per peranti atau kunci per rakan sebaya mengekalkan penarikan balik secara setempat dan dasar kekal boleh dibaca, kerana setiap alamat memetakan tepat kepada satu orang atau mesin. Di tempat reka bentuk tidak dapat berbuat demikian, nyatakan dalam buku panduan dan bukannya menerangkan peraturan itu sebagai halus.

Peruntukan alamat mesti bersetuju dengan dasar. Rizab satu blok untuk perkhidmatan, satu blok untuk klien, dan agihkan alamat klien daripada kumpulan yang anda kawal dan bukan julat siapa cepat dia dapat. Jika pelayan menterjemah atau menjambatani, simpan jadual pemetaan di sebelah konfigurasi, kerana jadual itulah yang diperlukan pembaca seterusnya untuk memperoleh peraturan semula.

Letakkan penafian di tempat paket melintasi terowong

Pada gateway yang menghantar trafik WireGuard, dua peraturan meliputi kes ini: benarkan blok perkhidmatan, kemudian gugurkan baki blok klien. Pasangan antara muka sama penting dengan alamat, kerana memadankan destinasi sahaja turut menangkap trafik dari LAN. Muatkan kedua-duanya dalam susunan itu supaya kebenaran dinilai dahulu.

Dengan nftables pasangan itu masuk ke jadual inet filter sedia ada, kebenaran dahulu dan pengguguran kemudian. Kedua-dua padanan memaku pasangan antara muka 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 semula rantai selepas dimuatkan dan jangan percaya status keluar, dan sahkan kedua-dua peraturan berada dalam susunan yang anda maksudkan. Tambah peraturan ip6 yang sepadan untuk kumpulan IPv6, jika tidak pasangan v4 hanyalah hiasan pada terowong dua tindanan. Jika pelayan sudah mempunyai dasar penghantaran permisif, tambah pengguguran dan bukannya menggantikan seluruh rantai.

Apabila client-to-client diaktifkan pada OpenVPN, peraturan penghantaran ini tidak pernah sepadan dengan trafik rakan sebaya dan penafian mesti hidup dalam kawalan daemon itu sendiri. Kekalkan peraturan kernel untuk trafik yang dialamatkan kepada hos, tetapi jangan kira ia sebagai kawalan pengasingan.

Buktikan penafian daripada klien, bukan daripada pelayan

Menguji dari gateway tidak membuktikan apa-apa, kerana trafik yang dijana secara setempat mengambil laluan keluaran dan tidak pernah melintasi cangkuk penghantaran. Gunakan dua klien sebenar: satu yang sepatutnya mencapai perkhidmatan, satu yang sepatutnya ditolak. Jalankan kes kebenaran dahulu, supaya terowong rosak tidak disalah anggap sebagai dasar yang berfungsi.

Dari klien yang dibenarkan, sahkan perkhidmatan menjawab pada portnya. Dari klien yang sama, cuba alamat rakan sebaya dan jangkakan pengguguran senyap dan bukannya 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 digugurkan dan rakan sebaya luar talian kedua-duanya kelihatan seperti tamat masa, jadi periksa pembilang sebelum membuat kesimpulan. Sahkan pembilang peraturan pengguguran meningkat semasa rakan sebaya terbukti aktif. Ulang melalui IPv6, di mana peraturan ip6 yang tiada membuatkan penafian v4 kelihatan berkesan. Catat keputusan yang diterima dan ditolak dalam buku panduan bersama tarikh, kerana migrasi seterusnya akan memperoleh peraturan semula.