Mengapa gerbang firewall yang terikat status VPN bukan aturan ping hanya lewat terowongan

Bayangkan aturan firewall yang menyalakan ICMP echo untuk alamat publik server setiap kali profil VPN bernama terhubung. Bunyinya seperti «ping hanya lewat terowongan», dan pembacaan itu salah dengan cara yang penting. Aturan itu tidak membatasi siapa yang boleh menjangkau host; ia mengubah apa yang dijawab antarmuka publik selama koneksi lain kebetulan aktif. Keduanya kebijakan berbeda, dan salah satunya diam-diam memperlebar paparan.

Aturan yang Anda kira sudah Anda tulis

Persyaratan yang dimaksud biasanya sempit: sistem pemantauan, atau satu-satunya administrator di VPN, harus bisa memastikan server masih hidup. Ditulis sebagai kalimat, bunyinya seperti kontrol akses pada terowongan. Ditulis sebagai objek firewall, ia berubah menjadi syarat pada profil publik, karena di situlah permintaan echo tiba.

Begitu syaratnya menjadi status koneksi alih-alih alamat sumber, himpunan pengirim yang diizinkan bukan lagi himpunan rekan VPN. Siapa pun yang bisa menjangkau alamat publik dapat mengirim permintaan echo selama gerbang terbuka. Terowongan tidak menjadi jalur; terowongan menjadi sakelar.

Orang-orang yang mempromosikan gagasan ini biasanya tidak berbohong tentang efek yang mereka inginkan. Mereka perlu pemeriksaan yang hanya menjawab ketika tautan sehat, dan kesehatan tautan paling mudah diamati lewat VPN. Kesalahannya adalah memperlakukan sinyal ketersediaan sebagai keputusan akses, lalu mengotomatiskannya.

Apa yang sebenarnya dikendalikan gerbang

Rancangan ini meleburkan dua hal yang independen, dan memisahkannya adalah sebagian besar perbaikannya. Yang pertama adalah cakupan: alamat lokal mana, alamat jarak jauh mana, protokol mana, dan jenis ICMP mana. Yang kedua adalah syarat: apakah objek aturan aktif saat ini. Cakupan adalah yang dinilai firewall per paket; syarat adalah yang ditulis skrip ke penyimpanan kebijakan, dan keduanya direkonsiliasi pada jam yang sama sekali berbeda.

Jika persyaratannya benar-benar hanya rekan VPN, cakupan menjawabnya tanpa logika status koneksi apa pun: ikat aturan ke antarmuka terowongan atau ke rentang alamat terowongan, batasi alamat jarak jauh ke kumpulan klien, dan tentukan jenis echo alih-alih «ICMP». Aturan itu tetap benar ketika tidak ada VPN aktif dan tidak dapat dibuka oleh profil tak terkait.

Jika persyaratannya benar-benar gerbang publik, katakan itu dalam teks kebijakan, karena kriteria penerimaan berubah. Gerbang publik harus menyebut profil yang tepat, mendefinisikan arti «terhubung», dan menyatakan bahwa pengirim publik berada dalam cakupan menurut rancangan. Sebagian besar kebingungan hilang pada saat seseorang dipaksa menuliskan kalimat itu.

Bangun objeknya sekali, lalu togol

Sediakan lebih dulu satu aturan dengan identitas stabil, nonaktif, dan biarkan pengendali hanya mengubah status aktifnya. Membuat aturan berdasarkan nama tampilan pada setiap proses adalah cara penyimpanan kebijakan berakhir dengan lima objek hampir identik dan tanpa cara andal untuk menghapusnya.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

Nama adalah pengenal yang bertahan; nama tampilan adalah dokumentasi yang boleh diedit manusia. Rekonsiliasi pada -Name dan skrip berhenti menghasilkan duplikat. Bentuk perintah yang sama mencakup kasus IPv6 dengan -Protocol ICMPv6 -IcmpType 128, tetapi itu aturan terpisah karena nomor jenis echo berbeda antara kedua keluarga.

Jaga keluarga alamat dan jenis ICMP tetap eksplisit karena alasan kedua: -Protocol ICMPv4 tanpa jenis mengizinkan setiap pesan ICMPv4 yang diizinkan profil, termasuk yang tidak pernah ingin Anda terima. Menyebut jenis 8 mempersempit aturan ke permintaan echo, dan itulah satu-satunya yang dikirim pemeriksaan keterjangkauan.

Di mana otomatisasi bertentangan dengan niat

Melakukan polling profil klien setiap beberapa menit tidak dapat menghasilkan batas yang seketika. Antara koneksi putus dan polling berikutnya aturan masih menjawab pada alamat publik; antara koneksi naik dan polling berikutnya tidak menjawab. Mengakui jeda itu jujur, dan mengklaim rancangan menegakkan invarian ketat tidak jujur.

Ada jebakan cakupan dalam pemeriksaan status itu sendiri. Get-VpnConnection melaporkan profil klien yang dikonfigurasi di mesin, secara bawaan untuk pengguna saat ini dan untuk semua pengguna dengan -AllUserConnection. Ia tidak melaporkan pengguna jarak jauh yang saat ini dial-in ke server RRAS; itu pengamatan lain dengan cmdlet lain. Gerbang yang dibangun di atas yang salah tidak terhubung ke apa pun.

Lalu tutupi keadaan yang tidak diskrip siapa pun: mulai dengan aturan yang sudah aktif dari proses sebelumnya, pengendali mogok saat gerbang terbuka, dan profil dihapus sementara aturannya tetap hidup. Masing-masing butuh default yang ditetapkan, dan default aman untuk izin publik adalah nonaktif. Jika persyaratannya benar-benar tidak tahan jendela polling, aturan terikat status adalah alat yang salah dan penegakan berada di terowongan, bukan di antarmuka publik.

Terakhir, uji permintaan publik dua kali, sekali dengan koneksi terpilih aktif dan sekali dengannya mati, dari host yang tidak berada di VPN. Ping yang berhasil dari dalam terowongan tidak membuktikan apa pun tentang kebijakan ini, dan itulah pengukuran yang dilewati sebagian besar penerapan.