OpenVPN üzerinden LAN erişimi bozuk mu? Bölgeleri, rotaları ve dönüş yolunu kontrol edin

Tünel başarılı bir bağlantı bildiriyor, yönlendiricinin kendi sayfası yükleniyor ve arkasındaki bir makineye sürücü eşlemesi hâlâ zaman aşımına uğruyor. Bu birleşimde çelişki yok: yönlendirici kendisi olarak yanıt veriyor ve arkasındaki bir şeye ulaşmak başka bir yerde verilen başka bir karardır. Aşağıdaki kontrolleri sırayla yapın ve ilk başarısızlıkta durun, çünkü her biri bir öncekine dayanır. Dördü de geçtiğinde hata tünelin içinde değil üstündedir.

LAN'a giden paketi hangi filtre görür

Yönlendiriciye adreslenen paket yerelde tüketilir; arkasındaki bir konağa adreslenen paket iletilmelidir ve güvenlik duvarları bu iki durumu ayrı ayrı değerlendirir. Yani yönlendiriciye ulaşma izni, onu geçme izni hakkında hiçbir şey söylemez. Kural kümelerini gizleyen donanım yazılımı yine de ikisini uygular, genellikle LAN, internet veya her ikisini sunan bir seçici olarak. Seçici LAN'ı dışarıda bırakırsa sonraki hiçbir kontrol önemli olmaz.

OpenWrt bu ayrımı denetlenebilir kılar ve fark bir kez okunmaya değer. Tüneli sonlandıran bölgenin LAN bölgesine yönelen bir iletme kuralına ihtiyacı vardır, giriş kuralı ise yalnızca yönlendiricinin kendi hizmetlerini yönetir. Çalışan bir yönetim sayfasının yanında ölü bir LAN, o eksik iletme kuralının olağan sonucudur.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Tüneli taşıyan bölgenin iletme hedefine bakın: accept merdivenin ihtiyacı olan değerdir ve reject aşağıdaki her zaman aşımını açıklar. Komşu iki ayar aynı belirtiyi üretir, bu yüzden buradayken onları eleyin. Kablosuz yalıtım kablolu konakları kablosuz istemcilerden gizler ve boştaki LAN konaklarını çevrimdışı sayan bir yönlendirici, iletme çalıştıktan sonra bile yanıtları düşürebilir.

Bölünmüş tünel neden itilen öneke ihtiyaç duyar

Tüm trafiği tünelden gönderen bir istemci LAN önekini zaten varsayılan rotası üzerinden taşır, yani eklenecek bir şey yoktur. Bölünmüş tünel, önekin açıkça belirtilmesini gerektiren durumdur, çünkü yapılandırmada başka hiçbir şey ondan söz etmez. Yönergeyi sunucu yapılandırmasına ekleyin ve hizmeti yeniden yükleyin.

push "route 192.168.50.0 255.255.255.0"

İçeren profiller route-nopull itilen rotaları yok sayar, bu yüzden aynı önek istemci dosyasına aittir. Her durumda girişin geldiğini doğrulayın, varsaymayın, çünkü sessiz bir geçersiz kılma güvenlik duvarı sorunuyla tamamen aynı görünür.

ip route show | grep 192.168.50

Siteden siteye bir eş, itmekten fazlasını ister. Sunucu o eşin arkasında hangi öneklerin olduğunu öğrenmelidir, bunu client-config-dir dosyasındaki iroute satırı yapar ve kendi tablosunun da tünele giden eşleşen bir rotaya ihtiyacı vardır.

Yanıtın ulaşabileceği bir adrese ihtiyacı var

İsteği iletmek bir takasın yalnızca yarısıdır, çünkü LAN konağı tünel havuzundaki bir adrese yanıt vermelidir. Küçük yönlendiriciler bunu genellikle kaynağı tünel bölgesinde çevirerek düzenler, böylece yanıt yönlendiriciye adreslenir ve başka yerde yapılandırma gerekmez. Bu çeviriyi kaldırın, konak havuza kendi rotasına ihtiyaç duyar; bunu yönlendirici varsayılan ağ geçidi olduğunda bedava alır. Adresi elle ayarlanmış ve ağ geçidi farklı olan bir konak o ağ geçidi üzerinden yanıt verir ve istemci oturumun açılıp sonra takıldığını görür.

tcpdump -ni tun0 host 192.168.50.20

İstemci isteğini yinelerken bunu yönlendiricide çalıştırın ve isteğin kendisi yerine yanıtın hedefini okuyun. Havuza adreslenen bir yanıt, dönüş yolunun çalıştığı ve hatanın daha içeride olduğu anlamına gelir. Hiç yanıt olmaması, konağın paketi hiç kabul etmediği anlamına gelir; bu sizi kural kümesine geri gönderir.

Doğru yerde biten bir merdiven

Dört kontrol katmanı belirler ve her biri bir yargı değil tek bir komuttur. Bunları sırayla çalıştırın ve ilk başarısızlıkta durun. Sıra komutlardan daha önemlidir, çünkü sonraki geçen bir adım öncekinin neden başarısız olduğunu gizler.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Adlar merdivenin sonuna aittir, asla başına değil. 192.168.50.20 olarak yanıt veren ama nas.local olarak vermeyen bir paylaşım ad çözümlemesine veya arama sonekine işaret eder ve güvenlik duvarı düzenlemeleri ikisini de değiştiremez.

İlk başarısız adımı kaydedin, sonra hizmet bağlantı noktalarına kendi turunu verin, çünkü dinleyici ve konak izni ayrı gereksinimlerdir. Dosya paylaşımı, uzak masaüstü ve kamera akışları ikisini de gerektirir ve LAN alt ağına güvenip tünel havuzuna güvenmeyen bir konak güvenlik duvarı ping hâlâ başarılıyken istemciyi düşürür. Tüm kontroller geçtiğinde ve uygulama hâlâ başarısız olduğunda hata tünelin üstündedir: tek bir arayüze bağlı bir hizmet veya istemcide yapılandırılmış bir vekil sunucu.