WireGuard el sıkışması çalışıyor, hizmet çalışmıyor

El sıkışma tamamlanıyor, istemci güncel bir aktarım sayacı gösteriyor ve yine de aynı sunucudaki bir hizmete yapılan istek başarısız oluyor. Bu kombinasyon insanları şaşırtıyor, çünkü tünelin çalıştığı kanıtlanmış durumda. Kanıtlanmayan şey yerel teslimat: paket ana bilgisayara ulaştı ve ana bilgisayar onu hâlâ doğru sokette kabul edip yanıt verme izni olan bir sürece iletmek zorunda. Bu üç denetim noktasını sırayla inceleyin.

Tutmayan ilk noktada durun ve diğerleri için kural eklemeyin.

El sıkışma yalnızca tüneli kanıtlar

WireGuard el sıkışması eşler arasında anahtarlar kurar ve her eşin listelediği aralıklar için trafiğe izin verir. Sunucuda hangi süreçlerin dinlediği hakkında hiçbir şey söylemez, ana bilgisayarın güvenlik duvarının kendi adreslerinden birine gönderilen paketleri kabul edip etmediği hakkında da hiçbir şey söylemez.

En çok gözden kaçan tam da bu son ayrımdır: ana bilgisayarın kendisine giden trafik yerel giriştir, ana bilgisayardan başka bir yere geçen trafik ise yönlendirmedir. Bunları farklı güvenlik duvarı zincirleri ve farklı ayarlar ele alır. Yanlış zinciri denetlemek bir öğleden sonraya mal olur ve masum görünen sayaçlar döndürür.

Dinleyiciyi ve yolu okuyun

İstemcide sunucunun tünel adresinin tünele yönlendirildiğini doğrulayın. Sunucuda istemcinin kullandığı adreste bir soket bulunduğunu ve arkasındaki sürecin amaçladığınız süreç olduğunu doğrulayın.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

127.0.0.1 üzerinde dinleyen bir şey, güvenlik duvarı neye izin verirse versin 10.66.0.1 adresine gönderilen bir isteğe asla yanıt vermez. Genel adres üzerinde dinleyen bir şey ise bir kural engellemedikçe yanıt verir. Dolayısıyla soket listesi herhangi bir kural incelenmeden önce vakaların yarısını çözer. Bağlantı noktası ve adres birlikte bir isteğin ulaşıp ulaşamayacağına karar verir.

İstemcinin kullandığı adresi sunucunun tünel arabiriminde gerçekten sahip olduğu adresle karşılaştırın. Herhangi bir taraftaki eski yapılandırma, o adrese sahip olmayan bir eşe doğru şekilde yönlendirilen bir istek üretir.

Yerel giriş için kural uygulayın, yönlendirme için değil

Paket ulaşır ve soket varsa, kalan sınır giriş ilkesidir. Yönlendirmeye izin veren bir kural yerel teslimata izin vermez ve tek bir arabirimle sınırlı bir kural beklediğiniz tünel arabirimi adıyla eşleşmeyebilir.

Ana bilgisayarı açmak yerine amaçlanan hizmete izin verilen tek bir bağlantı noktasıyla test edin. Ardından uygulamanın kendi yetkilendirmesini denetleyin: bir izin listesi, bir hesap gereksinimi veya belirli bir ana bilgisayar adına bağlama, ağın başarıyla teslim ettiği bir isteği reddedebilir.

Sertifika denetimlerini yerinde tutun. Beklenmedik bir sertifika kimliği, hangi ana bilgisayarın yanıt verdiğine dair bilgidir, atlatılması gereken bir engel değil. Üzerine tıklayıp geçmek, yanlış hizmeti tanımlayan tek ipucunu gizler.

Ad, boyut ve kimlik hatalarını ayırın

Adrese göre çalışıp ada göre başarısız olan hizmet bir DNS sorunudur ve düzeltme güvenlik duvarında değil, istemciye gönderilen çözümleyici yapılandırmasındadır. Küçük isteklere yanıt verip daha büyük yanıtlarda tıkanan hizmet ise paket boyutuna ve MTU'ya işaret eder, bu tamamen başka bir incelemedir.

Yanlış ana bilgisayarı adlandıran bir HTTPS hatası genellikle isteğin başka bir hizmete ulaştığı anlamına gelir, çoğunlukla o bağlantı noktasına bir vekil sunucu veya başka bir dinleyici sahiptir. Sertifikanın konusunu okuyun ve ulaşmak istediğiniz ana bilgisayarla karşılaştırın. Bu karşılaştırma hiçbir şeye mal olmaz ve çoğu zaman incelemeyi bitirir.

Hangi denetim noktasının başarısız olduğunu kaydedin: soket, giriş kuralı veya uygulama ilkesi. O tek satır bir ağ arızasını yetkilendirme kararından ayırır. Aynı zamanda bir sonraki kişinin hiç sorun olmayan bağlantı noktalarını açmasını da önler.