Ping yalnızca tek yönde çalışır: Windows sunucunun yankısını neden düşürür

İstemciniz sunucuya ping atıyor, sunucu istemciye ping atamıyor ve tünel her iki ifadede de paketleri açıkça taşıyor. Farklı olan yol değil, her testin ilk paketidir: biri Windows'un zaten izlediği bir akışa verilen yanıt, diğeri hiçbir kuralın kabul etmediği yeni bir gelen istektir. Bu fark tek yönlü ping raporlarının çoğunu açıklar ve doğrudan yazmanız gereken kurala işaret eder. Zıt yönlerde yapılan iki test durumları yaklaşık bir dakikada ayırır.

İki yön, iki farklı karar

İstemci yankı isteğini gönderdiğinde Windows güvenlik duvarı izin vermeye karar verdiği bir giden bağlantı görür. Yanıt bu kurulmuş akışın içinde geri döner, bu yüzden durumu izleyen motor ICMP için herhangi bir gelen kurala sormadan onu kabul eder. Durum tabanlı filtreleme pratikte bunu ifade eder ve kimsenin yazmadığı kural burada yer almaz. Dolayısıyla istemcinin başarısı gelen politikası hakkında hiçbir şey söylemez.

Sunucu isteği ilk gönderdiğinde ona uyan hiçbir durum yoktur. Windows paketi yeni bir gelen bağlantı olarak ele alır ve gelen politikasına sorar; bu politika varsayılan olarak rastgele kaynaklardan gelen yankı istekleri için hiçbir şey öngörmez.

Yani istemcinin başarısı giden ICMP'nin ve dönüş yolunun çalıştığını kanıtladı. Gelen kararı hiçbir zaman sınamadı ve güvenlik duvarının iyi olduğu yönündeki doğal sonuç makul ama yanlış. Bu yüzden hata, kanıtı zaten içeren ticket'larda tekrar eder.

Paket kaybolana kadar izleyin

Bir şeyi değiştirmeden önce adresleri doğrulayın: istemcinin gerçekten sahip olduğu tünel adresini kullanın ve sunucunun istemcinin arkasındaki LAN adresine değil ona yönlendirdiğini kontrol edin. İki arıza sunucunun komut satırından aynı görünür, çünkü ikisi de zaman aşımıyla biter. Paketin nerede öldüğü neyin değiştirileceğine karar veren tek olgudur.

İstek tünel arayüzüne ulaşıp dışarı hiçbir şey çıkmıyorsa olası neden yerel güvenlik duvarıdır. Arayüze hiç ulaşmıyorsa cevap yukarıdadır: sunucuda bir rota, bir giden politika ya da VPN'in kendi eşler arası teslimi.

Sunucu ping atarken istemcinin tünel arayüzünde kayıt alın. İsteğin yanında yanıt olmadan geldiğini görmek, Windows kuralı yazmayı haklı çıkaran kanıttır. Hiçbir şey görmemek sizi yukarı gönderir ve o durumda eklenen kural makineyi hiç gelmemiş bir paket için yalnızca daha hoşgörülü yapar. Her durumda kayıt, yerini aldığı tahminlerden daha ucuza gelir.

ICMP'yi açmak yerine tek bir kuralı sınırlayın

Herhangi bir şey yazmadan önce bağdaştırıcıyı ve geçerli kategorisini belirleyin, çünkü ikisi de ayarlamak üzere olduğunuz kapsamda görünür. Bu takma ad Windows arayüzünün adıdır ve içe aktardığınız VPN profilinin adı olmak zorunda değildir. Aşağıdaki komutlar nelerin var olduğunu listeler, ardından sınırlandırılmış bir kuralın önizlemesini uygulamadan gösterir.

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

ICMPv4 tür 8 yankı isteğidir, sunucunun yanıt alması gereken tek mesajdır. Bunu sunucunun tünel adresiyle ve tünel arayüzüyle sınırlayın ve profili bağdaştırıcı gerçekte neyse öyle bırakın. Bir ağı örneğe uydurmak için yeniden adlandırmak, kendi sonuçları olan ayrı bir değişikliktir.

Kuralın kapsamadığı şeyler

IPv6 yankısı farklı mesaj türüne sahip farklı bir protokoldür, bu yüzden ICMPv4 kuralı onun hakkında hiçbir şey söylemez ve iki aileyi de taşıyan tünel diğeri için kendi kuralına ihtiyaç duyar. Bu kural başka hiçbir şeyi açmaz: RDP, dosya paylaşımı ve diğer tüm hizmetler hâlâ kendi politikalarına bağlıdır. Geniş ICMP iznini etkinleştirmek yerine tek bir dar kuralı sınırlamanın bütün anlamı budur. Geniş izin kolay düzeltmedir ve en uzun süre dayananıdır, çünkü sonrasında kimse onu fark etmez.

Yönetilen bir cihazda kural bir sonraki ilke yenilemesinde değiştirilebilir, bu yüzden eşdeğer değişikliği yerel yönetici değil ilkenin sahibi yapmalıdır. Niyeti komutla birlikte ticket'a yazın, çünkü yenileme komutu siler ve gereksinimi olduğu gibi bırakır. İkisi aynı eser değildir ve yalnızca biri hayatta kalır.

Sonucu doğru yönde okuyun

Kural yürürlüğe girdikten sonra sunucudan ping atın ve bir yanıtın istemciye ulaştığını doğrulayın, ardından hâlâ dışlanması gereken bir kaynaktan ping atın ve ulaşmadığını doğrulayın. Tünel diğer adres ailesini de taşıyorsa erişilebilirlik testini o tarafta yineleyin.

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

Yürürlüğe giren kuralı yazdırmak, onu oluşturan komuta güvenmekten daha faydalıdır, çünkü önizleme ile uygulanmış kural farklı durumlardır. Adres filtresi amaçladığınız kaynağı gösteriyor ve dışlanan kaynak hâlâ zaman aşımına uğruyorsa, kural kapsamının söylediğini tam olarak yapar. İstemciden başlatılan başarılı bir ping bunu asla göstermezdi, bu yüzden her testin yönü sonucunun yanındaki kayda aittir. Ticket'ta iki yönü de saklayın, yoksa bir sonraki okuyucu başarısız olamayacak testi yineler.