Windows'ta WireGuard sunucusunun genel IP'sine SSH başarısız oluyor

Sunucunun genel adresine SSH çalışmayı bırakırken tünellerin yükselmesi, sunucunun bağlantıyı reddetmesi gibi görünür. Windows'ta daha olası neden yereldir: tam tünelli bir /0 AllowedIPs, tünelin kendi taşımasına ve çok az başka şeye izin veren kısıtlayıcı güvenlik duvarı kurallarını etkinleştirir. O adrese ulaşan şifreli paketler, aynı adrese ayrı bir TCP bağlantısının çıkıp çıkamayacağı hakkında hiçbir şey söylemez.

Eş listesine dokunmadan önce uç noktanın genel adresini iç tünel adresinden ayırın. Bunu AllowedIPs'i düzenleyerek düzeltmeye yönelik neredeyse her girişim, rotayı doğru yapmak yerine politikayı zayıflatır.

Yönlendirme izni ile güvenlik duvarı izni farklıdır

Rota bir paketin nereye gönderileceğine, güvenlik duvarı kuralı ise gönderilip gönderilemeyeceğine karar verir. Bu yüzden uç noktanın genel IP'si için rota eklemek, filtrenin hâlâ engelleyebileceği bir yol üretir ve bu belirtinin yarattığı karışıklık tam olarak budur. Windows'ta filtre eklenti değil uygulamanın parçasıdır, bu yüzden hiçbir rota girdisi onu değiştirmez. Bu iki karar başka yerlerde de ayrıdır, gerçi varsayılanlar farklıdır.

Bu yüzden uç noktaya bir traceroute başarılı olabilirken SSH denemesi başarısız olur. İlki istisnanın sahibi olan hizmet tarafından taşınır, ikincisi taşınmaz.

Windows'ta /0 ne yapar

İzin verilen adresleri tüm IPv4 alanını kapsayan tek bir eş olduğunda, WireGuard for Windows aksi hâlde tünelin dışına çıkacak trafiği engelleyen kısıtlayıcı bir güvenlik duvarı tutumu uygular. Tünel hizmetinin kendi taşımasına izin verilir, çünkü VPN başka türlü çalışamazdı. Aynı genel adrese giden başka bir uygulama böyle bir izin almaz, çünkü istisna adrese değil taşımaya aittir. Windows ağ notları bu davranışı ve düzenleyicideki ilgili denetimi açıklar.

Bu kurallar kill switch ifadesinin arkasındaki mekanizmadır. O adı taşıyan bir onay kutusuyla değil, yapılandırmanın biçimiyle etkinleşirler.

İstisnalar koruma modelini değiştirir

/0'ı iki yarı varsayılan önekle değiştirmek, kısıtlayıcı anlambilim olmadan geniş yönlendirmeyi korumanın belgelenmiş yoludur ve bu daha kısa bir yazım değil, farklı bir koruma modelidir. Uç nokta adresini izin verilen öneklerden çıkarmak, listeyi uzatan ve hangi kuralların etkinleştiğini de değiştiren diğer yaygın çözümdür. Hiçbiri yerel etkili yerel bir düzenleme değildir. Her biri makinedeki her akış için sınırı kaydırır, yalnızca onardığınız bağlantı için değil.

Doğrudan genel SSH gerçekten gerektiğinde, profil sahibi hem dış rotayı hem de onun güvenlik duvarı iznini tasarlamalı ve tünel düştüğünde ilgisiz trafiğe ne olacağına karar vermelidir. IPv4 ve IPv6'yı ayrı ayrı incelemek de buna dahildir, çünkü kurallar aile bazında ifade edilir. Tek bir yönetim oturumunu kurtarmak için eklenen geniş bir atlatma genellikle oturumdan daha fazlasını açığa çıkarır.

Seçtiğiniz yönetim yolunu test edin

Önce yönetimin tünelin içinden mi dışından mı geçmesi gerektiğine karar verin, sonra ikisini birden değil bu seçimi test edin. Aşağıdaki komutlar istemcinin adreslerini, eş durumunu ve her hedefe bağlantıyı denetler. Tünel açıkken bunları Windows istemcisinden çalıştırın.

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

İç adrese başarılı bir SSH, tünelin yönetim trafiğini taşıdığını ve sunucunun kendi güvenlik duvarının bunu eş aralığından kabul ettiğini kanıtlar. Her iki hedefte de başarısızlık Windows yönlendirmesi değil, sunucu tarafı veya anahtar sorunudur. İç adres çalışıp dış adres çalışmıyorsa, yerel güvenlik duvarı tutumu tam olarak tasarlandığı işi yapıyor. Bir profili düzenlemeden önce üç sonucu bu sırayla okuyun.

Yönetim yolunu, kullanılan adresi ve tünel kapalıyken davranışı kaydedin. Beş dakika kazanmak için atlatmayı genişletmekten bir sonraki kişiyi alıkoyan tam olarak o nottur.