Firewall Windows saja sebagai sakelar mati VPN: bisakah bertahan?

Tanyakan apakah firewall Windows dapat bertindak sendiri sebagai sakelar mati dan Anda akan mendapat dua jawaban yang yakin dan tidak cocok. Yang satu mengatakan aturan tipe antarmuka mengerjakan seluruh tugas; yang lain mengatakan tidak dapat bekerja tanpa skrip. Keduanya menjelaskan separuh mekanisme yang sama. Firewall dapat menyatakan blokir, dan apakah hasilnya benar-benar gagal tertutup bergantung pada tiga hal: bagaimana Windows mengklasifikasikan adaptor tunnel, apakah pengecualian titik akhir bertahan, dan apakah resolusi nama serta IPv6 tercakup. Salah satu saja keliru, mesin akan bocor atau kehilangan seluruh konektivitas.

Tiga syarat, dalam urutan ini

Syarat pertama adalah klasifikasi, dan itu menentukan apakah aturan yang Anda inginkan bahkan dapat dinyatakan. Aturan firewall Windows dapat dibatasi berdasarkan tipe antarmuka: berkabel, nirkabel, atau akses jarak jauh. Kebijakan yang memblokir lalu lintas keluar pada tipe fisik sekaligus mengizinkan tunnel hanya berfungsi jika Windows mengenali tunnel sebagai akses jarak jauh.

Syarat kedua adalah pengecualian titik akhir. Sebelum ada tunnel, klien harus mencapai server VPN melalui adaptor fisik, sehingga blokir menyeluruh pada adaptor itu justru mencegah koneksi yang akan membuat blokir tidak perlu. Pengecualian harus menyebut server dan portnya, dan paket harus keluar melalui gateway fisik, bukan masuk ke tunnel yang belum aktif.

Yang ketiga adalah cakupan. Kumpulan aturan yang memblokir IPv4 dan melupakan IPv6, atau mengizinkan resolver lokal mencari titik akhir dan karena itu mengizinkan setiap pencarian lain, gagal terbuka tepat pada jendela yang menjadi alasan sakelar mati ada. Itu celah desain, bukan bug di firewall. Itu juga celah yang bertahan dari setiap uji di meja.

Klasifikasi adalah gerbang pertama

Lihat apa yang Windows pikirkan tentang adaptor sebelum menulis satu aturan pun. Koneksi VPN asli Windows biasanya muncul sebagai akses jarak jauh. Klien pihak ketiga yang membuat adaptor virtualnya sendiri sering muncul sebagai berkabel, yang berarti blokir yang dibatasi pada adaptor berkabel juga memblokir tunnel.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundAction

Perintah ketiga memberi tahu apakah blokir keluar bawaan sudah berlaku, yang mengubah seluruh bentuk desain. Jika bawaannya sudah memblokir, Anda menulis aturan izin, bukan pengecualian terhadap dasar yang permisif, dan itu sikap yang jauh lebih mudah dipikirkan.

Jika adaptor tunnel Anda melaporkan diri sebagai berkabel, firewall saja bukan alat yang tepat untuk desain gagal tertutup, dan tidak ada penyesuaian aturan yang mengubahnya. Inilah kasus ketika pendapat kedua di setiap utas forum benar.

Pengecualian titik akhir memerlukan rute selain aturan

Misalkan klasifikasi berhasil. Pengecualian terdiri atas dua bagian, dan keduanya hidup di subsistem berbeda. Aturan firewall mengizinkan lalu lintas; rute host membuatnya keluar melalui antarmuka yang benar selama tunnel mati.

New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
  -Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32

Tanpa rute, pengecualian hanya membantu selama rute bawaan masih menunjuk ke gateway fisik. Begitu klien memasang rute bawaannya sendiri lalu mati, paket yang diizinkan tidak punya tempat masuk akal untuk pergi dan koneksi tidak dapat dibangun kembali. Kegagalan itu tampak seperti klien rusak dan sebenarnya rute yang hilang.

Jaga pengecualian sesempit yang diizinkan klien. Satu alamat dan satu port dapat ditinjau; rentang yang mencakup seluruh jaringan penyedia tidak. Aturan yang lebih luas itu juga mengizinkan apa pun yang dihosting di penyedia yang sama, yang biasanya lebih dari yang Anda maksudkan.

DNS dan IPv6 adalah tempat ia gagal terbuka

Resolusi nama adalah kebocoran klasik. Jika titik akhir berupa nama host, klien harus menyelesaikannya sebelum tunnel ada, yang berarti adaptor fisik harus diizinkan mencapai resolver. Izin yang sama membiarkan setiap pencarian lain keluar selama tunnel mati, dan satu pencarian cukup untuk mengungkap apa yang hendak Anda kunjungi.

IPv6 adalah yang kedua. Aturan yang ditulis untuk IPv4 tidak mencakup keluarga satunya, dan banyak klien hanya memasang rute IPv4. Mesin dengan konektivitas IPv6 asli karena itu dapat terus berbicara dengan internet sementara sisi IPv4 diblokir tegas, dan sakelar mati melaporkan keberhasilan sepanjang waktu.

Baris ketiga layak dipahami daripada dihindari. Firewall memutuskan soal paket, bukan soal antarmuka mana yang diminta aplikasi, dan program yang mengikat diri secara eksplisit bisa sulit dikendalikan. Itu argumen untuk sakelar mati di sisi klien yang bekerja di bawah aplikasi, bukan untuk lebih banyak aturan.

Uji dengan menghentikan klien, bukan mencabut kabel

Satu-satunya uji bermakna adalah yang meniru kegagalan yang Anda cegah. Hentikan layanan, matikan proses, atau nonaktifkan adaptor yang dibuat klien, lalu coba jangkau internet dan sebuah nama:

Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443

Ketiganya harus gagal. Jika yang pertama berhasil, blokir tidak berlaku; jika yang kedua berhasil di tempat yang pertama gagal, Anda punya kebocoran DNS; jika yang ketiga berhasil, IPv6 tidak tercakup. Setiap hasil menunjuk tepat pada satu celah di atas.

Ulangi uji setelah tidur dan bangun, karena profil firewall dapat berubah ketika Windows memutuskan jaringan bersifat publik atau privat, dan aturan yang dibatasi pada profil mengikutinya. Desain yang bertahan di meja dan gagal di kereta adalah desain yang diuji sekali.

Jika gerbang klasifikasi atau syarat DNS membuat pendekatan firewall-saja tidak dapat dijalankan, sakelar mati di sisi klien adalah jawaban jujur. Jika tunnel berakhir di router, kebijakan seharusnya milik router, karena satu aturan di sana mencakup setiap perangkat di belakangnya dan tidak bergantung pada cara Windows menamai adaptor.