Mengapa gerbang firewall yang terikat pada keadaan VPN bukan peraturan ping hanya melalui terowong

Bayangkan peraturan firewall yang menghidupkan ICMP echo untuk alamat awam pelayan setiap kali profil VPN bernama disambungkan. Ia dibaca seperti «ping hanya melalui terowong», dan bacaan itu salah dalam cara yang penting. Peraturan itu tidak mengehadkan siapa yang boleh mencapai hos; ia mengubah apa yang dijawab antara muka awam sementara sambungan lain kebetulan aktif. Itu dua dasar berbeza, dan salah satunya memperluas pendedahan secara senyap.

Peraturan yang anda sangka telah anda tulis

Keperluan yang dimaksudkan biasanya sempit: sistem pemantauan, atau satu-satunya pentadbir pada VPN, harus dapat mengesahkan bahawa pelayan masih hidup. Ditulis sebagai ayat, ia kedengaran seperti kawalan akses pada terowong. Ditulis sebagai objek firewall, ia menjadi syarat pada profil awam, kerana di situlah permintaan echo tiba.

Sebaik sahaja syaratnya ialah keadaan sambungan dan bukan alamat sumber, set penghantar yang dibenarkan bukan lagi set rakan VPN. Sesiapa yang boleh mencapai alamat awam boleh menghantar permintaan echo selagi gerbang terbuka. Terowong tidak menjadi laluan; terowong menjadi suis.

Mereka yang mempromosikan idea ini biasanya tidak berbohong tentang kesan yang mereka mahukan. Mereka memerlukan pemeriksaan yang hanya menjawab apabila pautan sihat, dan kesihatan pautan paling mudah diperhatikan melalui VPN. Kesilapannya ialah memperlakukan isyarat ketersediaan sebagai keputusan akses, dan kemudian mengautomasikannya.

Apa yang sebenarnya dikawal oleh gerbang

Reka bentuk ini meleburkan dua perkara bebas, dan memisahkannya ialah sebahagian besar pembetulan. Yang pertama ialah skop: alamat tempatan mana, alamat jauh mana, protokol mana dan jenis ICMP mana. Yang kedua ialah syarat: sama ada objek peraturan diaktifkan pada masa ini. Skop ialah apa yang dinilai firewall bagi setiap paket; syarat ialah apa yang ditulis skrip ke dalam stor dasar, dan kedua-duanya didamaikan pada jam yang sama sekali berbeza.

Jika keperluan itu benar-benar hanya rakan VPN, skop menjawabnya tanpa sebarang logik keadaan sambungan: ikat peraturan pada antara muka terowong atau julat alamat terowong, hadkan alamat jauh kepada kumpulan klien, dan nyatakan jenis echo dan bukannya «ICMP». Peraturan itu kekal betul apabila tiada VPN aktif dan tidak boleh dibuka oleh profil tidak berkaitan.

Jika keperluan itu benar-benar gerbang awam, katakan demikian dalam teks dasar, kerana kriteria penerimaan berubah. Gerbang awam mesti menamakan profil yang tepat, mentakrifkan apa yang dimaksudkan dengan «disambungkan», dan menyatakan bahawa penghantar awam berada dalam skop mengikut reka bentuk. Sebahagian besar kekeliruan hilang pada saat seseorang dipaksa menulis ayat itu.

Bina objek itu sekali, kemudian togolkannya

Sediakan lebih awal satu peraturan dengan identiti yang stabil, dinyahdayakan, dan biarkan pengawal hanya mengubah keadaan pengaktifannya. Mencipta peraturan mengikut nama paparan pada setiap larian ialah cara stor dasar berakhir dengan lima objek yang hampir serupa dan tanpa cara yang boleh dipercayai untuk mengeluarkannya.

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 ialah pengecam yang tahan lama; nama paparan ialah dokumentasi yang boleh disunting oleh manusia. Damai pada -Name dan skrip berhenti menghasilkan pendua. Bentuk arahan yang sama meliputi kes IPv6 dengan -Protocol ICMPv6 -IcmpType 128, tetapi itu peraturan berasingan kerana nombor jenis echo berbeza antara dua keluarga.

Kekalkan keluarga alamat dan jenis ICMP secara eksplisit atas sebab kedua: -Protocol ICMPv4 tanpa jenis membenarkan setiap mesej ICMPv4 yang dibenarkan profil, termasuk yang tidak pernah anda niatkan untuk terima. Menamakan jenis 8 menyempitkan peraturan kepada permintaan echo, dan itulah satu-satunya yang dihantar oleh pemeriksaan ketersampaian.

Di mana automasi bercanggah dengan niat

Meninjau profil klien setiap beberapa minit tidak dapat menghasilkan sempadan segera. Antara sambungan terputus dan tinjauan seterusnya peraturan masih menjawab pada alamat awam; antara sambungan naik dan tinjauan seterusnya ia tidak menjawab. Mengakui kelewatan itu jujur, dan mendakwa reka bentuk itu menguatkuasakan invarian yang ketat tidak jujur.

Terdapat perangkap skop dalam pemeriksaan keadaan itu sendiri. Get-VpnConnection melaporkan profil klien yang dikonfigurasikan pada mesin, secara lalai untuk pengguna semasa dan untuk semua pengguna dengan -AllUserConnection. Ia tidak melaporkan pengguna jauh yang sedang dial-in ke pelayan RRAS; itu pemerhatian lain dengan cmdlet lain. Gerbang yang dibina atas yang salah tidak bersambung dengan apa-apa.

Kemudian liputi keadaan yang tiada siapa skripkan: permulaan dengan peraturan sudah diaktifkan daripada larian sebelumnya, pengawal ranap semasa gerbang terbuka, dan profil dipadam sementara peraturannya kekal hidup. Setiap satu memerlukan lalai yang ditakrifkan, dan lalai yang selamat untuk kebenaran awam ialah dinyahdayakan. Jika keperluan itu benar-benar tidak tahan tetingkap tinjauan, peraturan terikat keadaan ialah alat yang salah dan penguatkuasaan terletak pada terowong, bukan pada antara muka awam.

Akhir sekali, uji permintaan awam dua kali, sekali dengan sambungan terpilih hidup dan sekali dengannya mati, dari hos yang tidak berada pada VPN. Ping yang berjaya dari dalam terowong tidak membuktikan apa-apa tentang dasar ini, dan itulah ukuran yang dilangkau oleh kebanyakan penggunaan.