VPN bağlı ama güvenlik duvarı hâlâ engelliyor: hangisi olduğu nasıl anlaşılır

Tünel çalışıyor ve bir bağlantı noktası hâlâ başarısız. Önce yolu okuyun, sonra her katmandaki politikayı, ve iki denetimden birini kapatmak yerine en dar kuralı değiştirin.

İstemci bağlı olduğunu söylüyor, kaynak hâlâ reddediyor ve olağan sonraki adım bir şeyi kapatmak. O cümledeki iki denetim farklı işler yapar: VPN kapsanan trafik için bir yol kurar, güvenlik duvarı ise her bağlantı için trafiğin geçip geçemeyeceğine karar verir. Reddeden bir politikayla çalışan tünel, kullanıcının koltuğundan tam olarak bozuk bir tünel gibi görünür, bu yüzden iş hangi katmanın yanıt verdiğini bulmaktır. İşte izlediğim sıra, durmanızı söyleyen okumayla birlikte.

Yolu politikadan ayırın

Arızanın şekliyle başlayın, çünkü bu bedava bilgidir. Paketin düşmesi bir zaman aşımı üretir: istemci yeniden dener, hiçbir şey dönmez ve komut pes edene kadar asılı kalır. Ret, bir reddetme veya sıfırlama üretir: bir şey yanıt verdi ve hayır dedi. Dinlemeyen bir hizmet, ana makinenin kendisinde reddeder, hiç güvenlik duvarı olmadan.

Bu üç sonuç farklı katmanlara işaret eder. Zaman aşımı, bir yerde bir politikanın sessizce attığını veya yolun makineden hiç çıkmadığını gösterir. Reddedildi, ana makineye ulaştığınızı ve yığınının veya yerel güvenlik duvarının hayır dediğini gösterir. Tünel arayüzü açıkken ve hedefe yol yokken tam sessizlik, yolun yanlış olduğunu ve hiçbir güvenlik duvarı kuralının bunu düzeltmeyeceğini gösterir.

Yolu tek geçişte okuyun

Tek bir kurala bakmadan önce tünelin hedefi kapsadığını doğrulayın. Yalnızca ofis alt ağını taşıyan bölünmüş bir tünel, isteği başka bir aralığa yönlendirmez ve o zaman arıza, olmadığı hâlde güvenlik duvarı engeli gibi görünür:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Yol çıktısı, paketin hangi arayüzden çıkacağını ve hangi kaynak adresini taşıyacağını belirtir. Bu arayüz tünel değil de fiziksel ağ kartınızsa, sorun yönlendirmede veya tünelin izin verilen aralıklarındadır ve VPN yapılandırmasına aittir, güvenlik duvarına değil.

VPN'e özgü bir tuzak kendi kontrolünü hak eder. WireGuard'da bir eşin AllowedIPs değeri hem yol hem kriptografik filtredir: kaynak adresi eşin izin verilen kümesine uymayan paket, herhangi bir güvenlik duvarı kuralına bakılmadan önce atılır. Bu yüzden tamamen doğru bir ana makine güvenlik duvarı, politika gibi görünen sessiz bir atmanın arkasında olabilir ve düzeltme bir kural değil, anahtar yapılandırma satırıdır.

Politikayı yanıt veren katmanda okuyun

Yol doğru olduğunda, politikayı ana makineden dışa doğru yürüyün ve sayaçları hareket eden tek katmanı izleyin:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Dinleyen soket, kurallardan farklı bir soruya yanıt verir. Bağlantı noktasında hiçbir şey dinlemiyorsa, çekirdek bağlantıyı reddeder ve hiçbir gelen kuralı ilgili değildir. Soket varsa ve uzak istemciden gelen bağlantı zaman aşımına uğrarsa, yolda bir yerde atma oluyor ve kural sayaçları bunun burada olup olmadığını söyler.

Dışarıdan tahmin etmek yerine şüphelendiğiniz profil veya zincir için günlük kaydını açın. Kaynağı, hedefi ve bağlantı noktasını belirten tek bir kayıtlı atma, katmanı ve kuralı tanımlar, ayrıca paketin geldiğini kanıtlar; bunu istemci tarafındaki hiçbir test ortaya koyamaz.

Tünel orada sona eriyorsa ağ geçidinin kararını okuyun

Siteden siteye veya uzaktan erişim ağ geçidinde VPN bir kullanıcının kimliğini doğrular ve politika bir kaynağa yetki verir, bunlar ayrı izinlerdir. Tünele alınan kullanıcı her iç ana makineye otomatik olarak alınmaz ve ret, tünelin kendisi sağlıklıyken çoğu zaman bir iletme kuralından gelir. Aynı ayrım IPsec'te de görülür: trafiği seçen güvenlik politikası onu kabul eden filtreden farklıdır, bu yüzden ikisi farklı mekanizmalar olarak RFC 4301.

Dönüş yolunu gidiş yolu kadar dikkatle kontrol edin. Durum bilgili filtreleme yanıtı görmelidir, bu yüzden tünel üzerinden bir yönde ve çevresinden diğer yönde asimetrik yönlendirme, rastgele görünen ve yalnızca bazı istemcilerden yinelenen atmalar üretir. Trafik ağ geçidine ulaşıp durursa, herhangi bir şeyi genişletmeden önce iletme kuralını ve dönüş yolunu birlikte okuyun.

Ağ geçidi aynı zamanda bir NAT veya maskeleme kuralının gerçek kaynağı gizleyebildiği yerdir. İç ana makineler istemci yerine ağ geçidinin adresini görürse, istemci havuzuyla eşleşmesi gereken ana makine güvenlik duvarı kuralları asla eşleşmez ve düzeltme her sunucuya değil ağ geçidine aittir.

En dar katmanı değiştirin, sonra doğrulayın

Geniş onarıma direnin. Ana makine güvenlik duvarını kapatmak, her şeye izin veren bir kural eklemek veya her arayüzü güvenilen bir profile zorlamak, her seferinde işini yapan denetimi ortadan kaldırır ve değişiklik olaydan sonra da yaşar. Kaynak aralığına ve söz konusu bağlantı noktasına sınırlı bir kuralı gözden geçirmek daha kolaydır, kaldırmak daha kolaydır ve makinenin geri kalan politikasını bozulmadan bırakır.

Başarısız olan aynı testle, aynı istemciden doğrulayın, sonra yeniden bağlandıktan sonra bir kez daha, çünkü tünel yeniden görüşmeden önce eşleşen bir kural sonrasında eşleşmeyi bırakabilir:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Kapatmadan önce:

  • Hedefe giden yol tünel arayüzünden çıkar ve kaynak adres politikanın beklediğiyle eşleşir.
  • Bağlantı noktasında bir şey dinliyor ve ret veya zaman aşımı varsayılmak yerine adlandırılmış bir kurala atfediliyor.
  • Ağ geçidi iki yönde de iletir ve hedef, kurallarınızın yazıldığı kaynağı görür.
  • Test geçsin diye hiçbir denetim kapatılmadı ve yaptığınız değişiklik tek bir kaynak aralığı ve tek bir bağlantı noktası belirtiyor.

İlgili makaleler