Yönlendiricideki VPN çalışıyor ama LAN istemcilerinin interneti yok

Durum tünelin açık olduğunu söylüyor, yönlendiricinin kendi üzerindeki tarayıcı sayfaları yüklüyor ve arkasındaki her cihaz hâlâ zaman aşımına uğruyor. Bu birleşim sorunu çoğu VPN rehberinin hiç söz etmediği bir katmana indiriyor: yönlendirici, paketleri tünelden sağ çıkması gereken tek ana makine değil. Yerelde üretilen trafik ile iletilen trafik aynı kutuda farklı yollar izliyor. Bir istemciden test edin ve fark teorik olmaktan çıksın.

Arızayı bir LAN ana makinesinden okuyun

Başarısız olan cihazdan başlayın, çünkü yönlendiricide çalıştırılan bir tanılama başka bir soruyu yanıtlar. İstemcinin varsayılan ağ geçidinin bu yönlendirici olduğunu doğrulayın, kaynak adresini ve alt ağını not edin, ardından yönlendiricinin tünel arayüzünden neyin çıktığına bakın.

İstemcinin adresi çevriliyorsa uzak taraf tünel adresini görür ve oradan her şey sağlıklı görünürken istemci hâlâ başarısız olur. Çevrilmiyorsa uzak tarafın istemcinin alt ağına dönüş yolunu bilmesi gerekir ve birçok ağ geçidinde varsayılan olarak böyle bir yol yoktur. Her durumda yönlendiricinin kendi başarısı önemsizdir, çünkü paketleri yerelde üretilmiştir ve iletime yolundan hiç geçmemiştir.

Yerel trafik ile iletilen trafik farklıdır

Linux ve çoğu yönlendirici bellenimi, kutunun kendi ürettiği paketleri içinden geçen paketlerden farklı ele alır. Output zinciri birinci türü görür, forward zinciri ikinciyi görür ve yönlendiricinin kendi trafiğine göre ayarlanmış bir ilke iletime dokunmadan bırakabilir.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

İletimin hiç açık olup olmadığını denetleyin, ardından output zinciri yerine forward zincirini okuyun. Şifrelenmiş dış bağlantıya izin veren bir kural, şifresi çözülmüş paketlerin iletilmesine izin veren bir kural değildir ve ikisini karıştırmak tam olarak bu belirtiyi üretir. Tünelin açık olması yalnızca birincisini kanıtlar.

Dönüş yolu da var olmalıdır

Kaynak çevirisi dönüş yolunun gerekip gerekmediğine karar verir. Tünel arayüzünde masquerading varsa yanıtlar tünel adresine geri döner ve yönlendirici bunları geri çevirir. Yoksa uzak ağ geçidi istemcinin alt ağına açık bir yol gerektirir ve kendi ilkesi de o yöne izin vermelidir.

Herhangi bir şeyi değiştirmeden önce kurulumun iki tasarımdan hangisini kullandığını not edin, çünkü onarımlar zıt yönleri gösterir. Çeviri eklemek eksik bir dönüş yolunu gizler ve özgün kaynak adresine ihtiyaç duyan uygulamaları bozar. Çeviri olmadan dönüş yolu eklemek, uzak güvenlik duvarı tanımadığı kaynağı attığında sessizce başarısız olur. Birini seçin, belgeleyin ve diğer tarafı uyumlu hale getirin.

İstemci DNS'i de aynı incelemeye dahildir. Yönlendiricinin çözümleyicisi yanıt verebilirken başka bir sunucuya yönelen istemci hiçbir şey alamaz.

Bir izin verilen ve bir reddedilen akışı doğrulayın

Düzeltmeden sonra mevcut bir yönlendirici oturumu yerine bir istemciden yeni bağlantı test edin. Ardından tüneli kullanmaması gereken segmentin hâlâ kullanmadığını doğrulayın.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Uzak uçta gözlenen kaynak adresini denetleyin, çünkü hangi tasarımın gerçekten çalıştığını bu söyler. Adresin yanı sıra ad çözümlemesini de doğrulayın, çünkü çözümleyicinin davranışı aynı kutudan geçen ayrı bir yoldur.

Kuralları tünele ihtiyaç duyan istemci ağlarıyla sınırlı tutun ve bir testin geçmesi için iletim filtresini kapatma cazibesine direnin. Bu değişiklik testi onarır ve tünelin sağlaması gereken sınırı ortadan kaldırır. Kaynak adresini, çeviri kararını ve dönüş yolunu tarihiyle birlikte tek bir nota yazın.