Batasi Gateway OpenVPN ke Satu LAN dengan Aturan UFW

Putuskan izinnya sebelum Anda membuka berkas firewall: klien terautentikasi boleh membuka koneksi ke satu subnet tertentu, dan gateway harus menolak setiap jalur transit lain bahkan ketika klien memasang rute tambahan. Kalimat itu adalah rancangannya, dan setiap aturan di bawah ada untuk menegakkannya. Apa pun yang lebih luas, seperti seluruh ruang alamat privat, keluar ke internet melalui tunnel, atau lalu lintas peer-to-peer, adalah rancangan berbeda yang perlu keputusannya sendiri. Aturannya juga sengaja membosankan, karena firewall pintar adalah yang tidak bisa diaudit siapa pun nanti.

Tuliskan topologi dan izinnya lebih dulu

Contohnya memakai server Community OpenVPN dengan perangkat TUN ruang pengguna bernama tun0, kumpulan klien 10.77.0.0/24, dan satu subnet terpasang 192.168.60.0/24 pada lan0. Penerusan IPv4 sudah bekerja dan LAN sudah punya rute balik ke kumpulan itu, jadi tidak ada yang bergantung pada penerjemahan di antara keduanya.

UFW memiliki firewall di host ini, dan tidak ada kumpulan aturan kontainer atau tabel nftables terpisah yang boleh memasang jalur penerimaan lebih awal. Pintasan pengalihan beban aliran yang melewati filter akan membuat rantai penjaga hanya jadi hiasan, jadi pastikan tidak ada yang aktif. Biarkan penerusan client-to-client milik OpenVPN sendiri nonaktif, karena lalu lintas peer-to-peer yang tidak pernah melewati filter sistem operasi tidak bisa dibatasi dengannya. Pendengar eksternal dan aturan administrasi tetap seperti adanya, sebab perubahan ini mengatur lalu lintas tunnel yang didekripsi alih-alih menggantikan firewall.

Tempatkan penjaga sebelum penerimaan awal UFW

Izin rute yang diikuti penolakan tidak cukup untuk batas yang ketat. Aturan before bawaan menerima lalu lintas yang sudah terbentuk dan sebagian ICMP sebelum aturan pengguna mana pun diperiksa, sehingga aliran yang diizinkan pekan lalu bisa tetap di luar pembatasan tujuan baru semata karena masih punya state. Cadangkan berkas UFW dan pertahankan konsol di luar jalur tetap terbuka sebelum menyunting.

Di bagian *filter berkas /etc/ufw/before.rules, nyatakan dua rantai di samping deklarasi yang ada dan sebelum baris aturan mana pun.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Tepat setelah deklarasi, dan sebelum izin masuk serta penerusan, lompat ke dalamnya dan tentukan apa yang mereka izinkan.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Pertahankan bagian selebihnya dan baris COMMIT -nya. Menempel tabel filter kedua atau menghapus aturan yang tidak berkaitan adalah cara perubahan firewall menjadi gangguan layanan, dan berkas itu berjarak satu reboot dari menjadi satu-satunya salinan yang penting.

Baca apa yang diizinkan dan ditolak tiap penjaga

Rantai pertama melanjutkan pemrosesan hanya ketika sumber ada di kumpulan, tujuan adalah satu subnet itu, antarmuka keluar adalah LAN, dan paket bergerak dalam arah asli alirannya. Segala hal lain yang datang dari tunnel dibuang, termasuk sumber di luar kumpulan dan tujuan mana pun di luar subnet yang diizinkan.

Paket peer-to-peer masuk dan keluar tun0, jadi ia gagal pada uji antarmuka LAN bahkan sebelum pemeriksaan tujuan tercapai. Koneksi baru dari LAN menuju klien juga gagal pada uji arah balasan, yang menutup jalur panggilan balik terbalik secara bawaan.

Sasaran RETURN mempertahankan kebijakan UFW biasa tetap berlaku. Rantai ini menyaring, dan izin rute yang Anda tambahkan berikutnya tetap menentukan apakah paket yang bertahan diterima. Pemisahan itulah yang memungkinkan Anda mengubah subnet yang diizinkan di satu tempat nanti. Jika para penjaga menerima paket begitu saja, setiap aturan mendatang harus ditambahkan dua kali.

Izinkan subnet dan tutup pintu samping

Pratinjau izin rute lebih dulu, lalu lepaskan tanda pratinjau untuk menerapkannya: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Setelah itu tinjau urutan aturan pengguna, karena penolakan yang lebih awal tetap menang atas izin yang lebih akhir. Izin untuk seluruh subnet juga bentuk yang keliru ketika hanya port HTTPS satu host yang seharusnya bisa dijangkau.

Perhatikan apa yang dilakukan pembuangan masuk: klien tunnel tidak dapat menjangkau layanan apa pun di gateway itu sendiri, termasuk pendengar DNS yang terikat ke alamat LAN-nya. Meng-host DNS di sana memerlukan pengecualian yang disengaja sebelum pembuangan dan kontrak izin yang direvisi. Jika UFW mengelola IPv6, tambahkan pembuangan yang sesuai untuk tun0 di before6.rules juga, karena daftar tujuan IPv4 tidak mengatakan apa pun tentang paket IPv6.

Verifikasi kebijakan yang dimuat, bukan pratinjaunya

Pratinjau pemuatan ulang, terapkan dalam jendela pemeliharaan, dan baca kumpulan aturan yang hidup.

sudo ufw --dry-run reload
sudo ufw show raw

Pastikan penjaga tunnel muncul sebelum izin state bawaan dan ICMP. ufw status biasa tidak menampilkan aturan before yang disunting tangan, itulah sebabnya operator menyimpulkan ada aturan yang hilang padahal sebenarnya sudah dimuat. Baca daftar mentah dari atas ke bawah alih-alih mencari potongannya. Jika penjaga muncul setelah izin state, batas itu tidak melakukan apa yang disarankan berkas.

Lalu uji perilakunya, bukan teksnya. Buka koneksi baru ke host yang diizinkan dan amati balasannya, arahkan permintaan tak berbahaya ke tujuan di luar subnet dan pastikan ia mati, coba koneksi peer-to-peer, coba layanan lokal gateway, dan coba koneksi LAN-ke-klien yang tidak diminta. Sertakan satu aliran di luar cakupan yang sudah ada sebelum perubahan, dan hapus hanya aliran itu alih-alih mengosongkan seluruh tabel pelacakan mesin.

Catat batasannya bersama aturannya: ini membatasi transit dan tidak yang lain. Ini tidak mencegah klien memakai koneksi internetnya sendiri, tidak mencegah host LAN yang diizinkan meneruskan lalu lintas lebih jauh, dan tidak menggantikan autentikasi di dalam layanan yang diizinkan.