Pi üzerindeki hotspot istemcileri TUN VPN üzerinden ev LAN'ına ulaşamıyor

Yerel Wi-Fi ve Ethernet istemcileri Pi'nin hotspot'una bağlanır, DHCP kapsamından bir adres alır ve internet sayfalarını şikâyet etmeden yükler. Aynı istemciler daha sonra ev LAN'ındaki bir dosya paylaşımını veya web arayüzünü açtıklarında zaman aşımına uğrar; oysa Pi'nin kendisi o LAN'a tünel üzerinden ulaşır. Kablosuz katmanda hiçbir şey bozuk değildir. Eksik olan yönlendirilmiş bir sözleşmedir: hotspot öneki TUN arayüzüne taşınmalı ve ev tarafındaki bir şey yanıtları oraya nasıl geri göndereceğini bilmelidir. Tek bir paketin gidiş-dönüşü tamamlaması için iki yarı da var olmalıdır.

Üç farklı işi olan üç bağlantı

Linux Ethernet köprüsü çerçeveleri hedef MAC adresine göre iletir. OpenVPN TUN modunda IP paketleri taşır ve hiç MAC katmanı yoktur, bu yüzden yerel bir köprü eklemek tüneli hiçbir zaman port olarak kaydetmez. çekirdeğin TUN/TAP belgeleri bu ayrımı açıklar: bir TAP aygıtı Ethernet arayüzüne benzer, TUN aygıtı benzemez. İki yerel portu köprüleyip sonra yönlendiren tasarım, arayüz adları ne derse desin bir yönlendiricidir.

Bu ayrım sahipliği belirler. İstemcilerin alt ağı, varsayılan geçitleri ve o kapsamın DHCP yetkisi Pi'nin yerel planına aittir. Ev DHCP yayınları yönlendirilmiş bir tüneli geçmez ve hiçbir köprü ayarı bunu değiştirmez; istemcileri ev DHCP sunucusuna yöneltmek kendi hata modlarına sahip ayrı ve bilinçli bir aktarma tasarımıdır.

Modemi de istemci köprüsünün dışında tutun. PPP bağlantısı farklı etiketli bir Ethernet aygıtı değildir ve pppd'nin belgelenmiş varsayılan rota mantığı IPCP görüşmesinden sonra çalışır ve o bağlantı düştüğünde rotasını geri çeker. Bir DHCP şablonunu kopyalayıp her usb0 öğesini ppp0 olarak yeniden adlandırmak geçit, metrik veya yaşam döngüsü hakkında hiçbir şey kanıtlamaz.

Herhangi bir yapılandırmayı düzenlemeden önce önekleri seçin

Çakışan önekler güvenlik duvarı kurallarından daha fazla akşam harcar, çünkü çakışma tünel sağlıklı olsa bile rota aramasını yanlış arayüze gönderir. Pi'de zaten var olanı listeleyerek başlayın, ardından sonucu dört ayrı havuz olarak okuyun.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

İlk havuz operatörün modeme verdiği underlay adresidir; istemcilere dönük her plandan uzak kalmalıdır. İkincisi sunucunun seçtiği tünel alt ağıdır, çoğu zaman kendi özel /24'ü. Üçüncüsü hotspot köprüsü, dördüncüsü ulaşmak istediğiniz ev önekidir. Bu yürüyüşte hotspot 172.28.90.0/24 alır, köprü 172.28.90.1 üzerindedir ve ev hizmet LAN'ı 192.168.77.0/24 öğesini korur; bu da tüketici yönlendiricileriyle gelen 192.168.1.0/24 ve 10.0.0.0/24 varsayılanlarını ve 100.64.0.0/10 operatör aralığını atlar.

Hotspot'un DHCP kapsamında geçit olarak yalnızca köprünün adresini duyurun, başka hiçbir şeyi değil. Hotspot istemcilerine asla geçit olarak ev adresi vermeyin; o segmente bağlantı katmanında yolları yoktur.

Her yönü sahibi olan tarafta yönlendirin

Pi'nin tünel üzerinden ev önekine bir rotaya ihtiyacı vardır. Sunucu modundaki sunucular genellikle bu rotayı iter, bu yüzden önce iletmenin açık olduğunu ve çekirdeğin tun0 üzerinden ev adresini çözümlediğini doğrulayın.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

ip route get hâlâ underlay arayüzünü bildiriyorsa orada durun; yolun ilerisindeki hiçbir şey yanlış aramayı onaramaz.

Ev cihazlarının 172.28.90.0/24 için rotası yoktur, bu yüzden yanıtları varsayılan geçidi izler ve yönlendiricide ölür. Desteklenen iki onarım vardır. Ya ev yönlendiricisine hotspot önekini VPN sunucusunun LAN adresine yönlendiren statik bir rota ekleyin ya da sunucunun kendisi geçit olduğunda istemci önekini sunucunun kendi yönlendirme tablosuna kaydedin. OpenVPN'in çok istemcili modunda istemciye özgü dizin bu ilişkiyi taşır: istemci sertifikasının ortak adıyla adlandırılmış bir dosya, içinde iroute 172.28.90.0 255.255.255.0 ve onu sunucu çekirdeğine kuran eşleşen route satırı bulunur. Sunucuda tahmin edilen bir çekirdek rotası, sunucuya hangi istemcinin öneki sahiplendiğini söylemekle aynı ifade değildir.

Bunun çalışması için ev ağının DHCP hizmetini VPN sunucusuna taşımayın. Tüm bir evin varsayılan geçidini değiştirmek tek bir özel dönüş rotası eklemekten çok daha büyük bir değişikliktir ve DNS'i, adres rezervasyonlarını ve yeni kiralamayı yok sayan her cihazı hataya sürükler.

Güvenlik duvarı hakkında tahmin yürütmeden iletmeyi açın

İletmenin açık olması paketin geçmesine izin verildiği anlamına gelmez. Köprüden tünele trafik hâlâ filtre kurallarına çarpar ve varsayılan drop iletme politikası hotspot trafiğini düşürürken Pi'nin kendi trafiği çalışmaya devam eder; bu da yukarıdaki bölünmüş belirtiyi tam olarak üretir.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 öğesinden tun0 öğesine bir kabul kuralı ve eşleşen yanıt yönü ile kaynağı yeniden yazabilecek bir postrouting kuralı arayın. Zincir politikası drop ise ve hiçbir kural eşleşmiyorsa politikayı accept'e çevirmek yerine dar kabulleri ekleyin ve yeniden test edin.

Çeviri bir politika seçimidir, gereklilik değil. Ev LAN'ına doğru kaynak NAT'ı her hotspot istemcisini Pi'nin tünel adresi gibi gösterir; bu, ev günlüklerinde istemci başına atfı kaybeder ve özgün kaynağı bekleyen hizmetleri bozar. NAT'sız yönlendirme istemci adreslerini görünür tutar ama yukarıdaki dönüş rotasına bağlıdır. Birini seçin ve DNS ile IPv6'ya aynı şekilde davranın, çünkü bozuk IPv6 yolunun yanındaki çalışan IPv4 yolu tarayıcıda hâlâ yarı bozuk okunur.

Gidiş-dönüşü doğrulayın, sonra bilerek bozun

Hotspot istemcisinden test edin, asla Pi'den değil, çünkü Pi'nin kendi trafiği hem ileri hem dönüş yolunu atlar. Bir istemci ev hizmetine ulaşmaya çalışırken iki arayüzü de izleyin.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

İki kaydı birlikte okuyun. br0 üzerinde görünüp tun0 üzerinde hiç görünmeyen istekler Pi'nin iletmediğini veya rotanın başka yeri gösterdiğini anlatır. tun0 üzerinde yanıtsız istekler ev tarafında dönüş rotası olmadığını veya sunucunun paketi filtrelediğini anlatır. tun0 üzerinde görünüp br0 üzerinde bir daha görünmeyen yanıtlar ters filtre kuralının eksik olduğunu anlatır; tünel kusursuz görünür ama istemci yine hiçbir şey görmez.

Sonra yolu bilerek bozun. Modem bağlantısını düşürüp yeniden kaldırın ve rota ile kayıt denetimlerini yeniden çalıştırın; tüneli atlatıp yeniden bağlanmada kaybolan rota tek seferlik bir komuta değil bağlantı profiline aittir. Tünelin taşımasının hâlâ underlay üzerinden çıktığını, kendi içinden çıkmadığını doğrulayın; eşe ana makine rotası olmadan itilen varsayılan rotanın kabul edildiği klasik döngü.

Tasarımı yalnızca bir hotspot istemci ev adını çözümleyebildiğinde, bir TCP hizmeti açabildiğinde ve bir modem yeniden bağlanması boyunca oturumu canlı tutabildiğinde kabul edin. Bir uygulama ev segmentinde gerçekten Ethernet düzeyinde keşif gerektiriyorsa, yerel köprüyü köprülenmiş diye tanımlayıp yayın beklemek yerine desteklenen bir Layer 2 tasarımı seçin.