VPN durumuna bağlı güvenlik duvarı kapısı neden yalnızca tünelden ping kuralı değildir

Adlandırılmış bir VPN profili bağlı olduğunda sunucunun genel adresi için ICMP echo'yu açan bir güvenlik duvarı kuralı düşünün. Bu, «yalnızca tünelden ping» gibi okunur ve bu okuma önemli bir biçimde yanlıştır. Kural kimin ana bilgisayara ulaşabileceğini kısıtlamaz; başka bir bağlantı tesadüfen açıkken genel arabirimin neye yanıt verdiğini değiştirir. Bunlar iki farklı politikadır ve biri maruziyeti sessizce genişletir.

Yazdığınızı sandığınız kural

Amaçlanan gereksinim genellikle dardır: izleme sistemi ya da VPN'deki tek yönetici, sunucunun canlı olduğunu doğrulayabilmelidir. Cümle olarak yazıldığında tünelde erişim denetimi gibi kulağa gelir. Güvenlik duvarı nesnesi olarak yazıldığında ise genel profilde bir koşula dönüşür, çünkü echo isteği tam oraya gelir.

Koşul kaynak adres yerine bağlantı durumu olduğunda, izin verilen göndericiler kümesi artık VPN eşleri kümesi değildir. Genel adrese ulaşabilen herkes, kapı açıkken echo isteği gönderebilir. Tünel yol olmadı; tünel anahtar oldu.

Bu fikri pazarlayanlar genellikle istedikleri etki konusunda yalan söylemezler. Yalnızca bağlantı sağlıklıyken yanıt veren bir denetime ihtiyaçları vardı ve bağlantının sağlığını gözlemlemenin en kolay yolu VPN'di. Hata, kullanılabilirlik sinyalini erişim kararı saymak ve sonra bunu otomatikleştirmektir.

Kapının gerçekte neyi denetlediği

Bu tasarım iki bağımsız şeyi birleştirir ve bunları ayırmak düzeltmenin büyük bölümüdür. Birincisi kapsamdır: hangi yerel adres, hangi uzak adresler, hangi protokol ve hangi ICMP türü. İkincisi koşuldur: kural nesnesinin şu anda etkin olup olmadığı. Kapsam, güvenlik duvarının paket başına değerlendirdiğidir; koşul, bir betiğin ilke deposuna yazdığıdır ve ikisi tamamen farklı saatlerde uzlaştırılır.

Gereksinim gerçekten yalnızca VPN eşleriyse, kapsam bunu herhangi bir bağlantı durumu mantığı olmadan yanıtlar: kuralı tünel arabirimine ya da tünel adres aralığına bağlayın, uzak adresleri istemci havuzuyla sınırlayın ve «ICMP» yerine echo türünü belirtin. Bu kural hiçbir VPN açık değilken de doğru kalır ve ilgisiz bir profil onu açamaz.

Gereksinim gerçekten genel bir kapıysa bunu ilke metninde söyleyin, çünkü kabul ölçütleri değişir. Genel bir kapı tam profili adlandırmalı, «bağlı»nın ne anlama geldiğini tanımlamalı ve genel göndericilerin tasarım gereği kapsamda olduğunu belirtmelidir. Karışıklığın çoğu, birinin o cümleyi yazmaya zorlandığı anda ortadan kalkar.

Nesneyi bir kez oluşturun, sonra açıp kapatın

Sabit kimlikli tek bir kuralı önceden, devre dışı olarak hazırlayın ve denetleyicinin yalnızca etkinlik durumunu değiştirmesine izin verin. Her çalıştırmada görünen ada göre kural oluşturmak, ilke deposunun beş neredeyse aynı nesneyle ve bunları kaldırmanın güvenilir bir yolu olmadan kalmasının yoludur.

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

Ad kalıcı tanımlayıcıdır; görünen ad bir insanın düzenleyebileceği belgedir. -Name üzerinde uzlaştırın ve betik yinelenen üretmeyi bırakır. Aynı komut biçimi IPv6 durumunu -Protocol ICMPv6 -IcmpType 128 ile kapsar, ancak bu ayrı bir kuraldır çünkü echo türü numaraları iki ailede farklıdır.

Adres ailesini ve ICMP türünü açık tutun, ikinci bir neden daha var: -Protocol ICMPv4 tür olmadan profilin izin verdiği her ICMPv4 iletisine izin verir, kabul etmeyi hiç düşünmediğiniz iletiler dahil. Tür 8'i adlandırmak kuralı echo isteğine daraltır ve erişilebilirlik denetiminin gönderdiği tek şey budur.

Otomasyonun niyetle çeliştiği yer

Bir istemci profilini birkaç dakikada bir yoklamak anlık bir sınır üretemez. Bağlantı düştükten sonraki yoklamaya kadar kural genel adreste yanıt vermeye devam eder; bağlantı kalktıktan sonraki yoklamaya kadar yanıt vermez. Bu gecikmeyi kabul etmek dürüsttür, tasarımın katı bir değişmezi zorladığını iddia etmek değildir.

Durum denetiminin kendisinde bir kapsam tuzağı var. Get-VpnConnection makinede yapılandırılmış istemci profillerini bildirir, varsayılan olarak geçerli kullanıcı ve -AllUserConnection ile tüm kullanıcılar için. Şu anda bir RRAS sunucusuna bağlanmış uzak kullanıcıları bildirmez; bu başka bir cmdlet ile yapılan başka bir gözlemdir. Yanlış olanın üzerine kurulmuş bir kapı hiçbir şeye bağlı değildir.

Sonra kimsenin betiklemediği durumları kapsayın: kuralın önceki bir çalıştırmadan etkin kalmasıyla başlangıç, kapı açıkken denetleyicinin çökmesi ve kuralı yaşarken profilin silinmesi. Her biri tanımlı bir varsayılan gerektirir ve genel bir izin için güvenli varsayılan devre dışıdır. Gereksinim yoklama penceresini gerçekten kaldıramıyorsa, duruma bağlı kural yanlış araçtır ve uygulama tünele aittir, genel arabirime değil.

Son olarak, genel isteği iki kez test edin: bir kez seçili bağlantı açıkken ve bir kez kapalıyken, VPN'de olmayan bir ana bilgisayardan. Tünelin içinden başarılı bir ping bu politika hakkında hiçbir şey kanıtlamaz ve çoğu dağıtımın atladığı ölçüm budur.