A Pi hotspot kliensei nem érik el az otthoni LAN-t TUN VPN-en át

A helyi Wi-Fi és Ethernet kliensek csatlakoznak a Pi hotspotjához, címet kapnak a DHCP-tartományából, és panasz nélkül töltenek be internetes oldalakat. Ugyanezek a kliensek aztán időtúllépésbe futnak, amikor fájlmegosztást vagy webes felületet nyitnak az otthoni LAN-on, miközben a Pi maga az alagúton keresztül éri el azt a LAN-t. A vezeték nélküli rétegben semmi sem romlott el. Ami hiányzik, az egy útvonalazott szerződés: a hotspot előtagot be kell vinni a TUN interfészbe, és valaminek az otthoni oldalon tudnia kell, hogyan küldje vissza a válaszokat. Mindkét félnek léteznie kell, mielőtt egyetlen csomag befejezheti az oda-vissza utat.

Három csatlakozás, három különböző feladattal

A Linux Ethernet híd a kereteket a cél MAC-cím szerint továbbítja. OpenVPN TUN módban IP-csomagokat szállít, és egyáltalán nincs MAC-rétege, ezért egy helyi híd hozzáadása soha nem veszi fel az alagutat portként. A kernel TUN/TAP dokumentációja magyarázza ezt a szétválasztást: a TAP-eszköz Ethernet-interfésznek látszik, a TUN-eszköz nem. Az a kialakítás, amely két helyi portot áthidal, majd útvonalaz, útválasztó, bármit is mondanak az interfészek nevei.

Ez a különbség dönti el a tulajdonjogot. A kliensek alhálózata, az alapértelmezett átjárójuk és az adott tartomány DHCP-hatásköre a Pi helyi tervéhez tartozik. Az otthoni DHCP-szórások nem kelnek át útvonalazott alagúton, és ezt semmilyen hídbeállítás nem változtatja meg; a klienseket otthoni DHCP-kiszolgálóra irányítani külön, szándékos relay-kialakítás a saját hibaüzemmódjaival.

Tartsa a modemet is a klienshídon kívül. A PPP-csatlakozás nem más címkével ellátott Ethernet-eszköz, és a pppd dokumentált alapértelmezett útvonal-logikája az IPCP-tárgyalás után fut, és visszavonja az útvonalát, amikor az a kapcsolat megszakad. Egy DHCP-sablon másolása és minden usb0 átnevezése ppp0-re semmit sem bizonyít az átjáróról, a metrikáról vagy az életciklusról.

Válassza ki az előtagokat, mielőtt bármilyen konfigurációt szerkeszt

Az átfedő előtagok több estét emésztenek fel, mint a tűzfal-szabályok, mert az átfedés rossz interfészre küldi az útvonalkeresést akkor is, ha az alagút egészséges. Kezdje annak felsorolásával, ami már létezik a Pi-n, majd olvassa az eredményt négy különálló medenceként.

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

Az első medence az underlay-cím, amelyet a szolgáltató a modemnek adott; minden kliens felé néző terven kívül kell maradnia. A második az alagút alhálózata, amelyet a kiszolgáló választott, gyakran a saját privát /24-e. A harmadik a hotspot híd, a negyedik pedig az otthoni előtag, amelyet el akar érni. Ebben a bejárásban a hotspot a 172.28.90.0/24-et kapja a 172.28.90.1-en lévő híddal, és az otthoni szolgáltató LAN megtartja a 192.168.77.0/24-öt, ami elkerüli a fogyasztói útválasztókkal érkező 192.168.1.0/24 és 10.0.0.0/24 alapértelmezéseket és a 100.64.0.0/10 szolgáltatói tartományt.

Hirdesse meg a híd címét átjáróként a hotspot DHCP-tartományában, és semmi mást. Soha ne adjon a hotspot klienseknek otthoni címet átjáróként; nincs kapcsolati rétegbeli útjuk ahhoz a szegmenshez.

Minden irányt azon az oldalon útvonalazzon, amelyik birtokolja

A Pi-nek útvonalra van szüksége az otthoni előtaghoz az alagúton keresztül. A kiszolgáló módú kiszolgálók általában tolják ezt az útvonalat, ezért először erősítse meg, hogy a továbbítás be van kapcsolva, és hogy a kernel az tun0-ból oldja fel az otthoni címet.

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

Ha a ip route get még mindig az underlay interfészt jelenti, álljon meg ott; semmi a további útvonalon nem tudja kijavítani a rossz keresést.

Az otthoni eszközöknek nincs útvonaluk a 172.28.90.0/24-hez, ezért válaszaik az alapértelmezett átjárót követik, és meghalnak az útválasztónál. Két támogatott javítás létezik. Vagy adjon hozzá statikus útvonalat az otthoni útválasztón, amely a hotspot előtagot a VPN-kiszolgáló LAN-címére irányítja, vagy, amikor a kiszolgáló maga az átjáró, jegyezze be a kliens előtagot a kiszolgáló saját útválasztási táblájába. Az OpenVPN többklienses módjában az ügyfélspecifikus könyvtár hordozza ezt a társítást: az ügyfél tanúsítványának köznapi nevéről elnevezett fájl, amely a iroute 172.28.90.0 255.255.255.0-et és a hozzá illeszkedő route sort tartalmazza, amely telepíti a kiszolgáló kernelébe. A kiszolgálón kitalált kernel-útvonal nem ugyanaz az állítás, mint megmondani a kiszolgálónak, melyik kliens birtokolja az előtagot.

Ne helyezze át az otthoni hálózat DHCP-szolgáltatását a VPN-kiszolgálóra, hogy ez működjön. Egy egész ház alapértelmezett átjárójának lecserélése sokkal nagyobb változás, mint egyetlen privát visszatérő útvonal hozzáadása, és magával rántja a DNS-t, a címfoglalásokat és minden eszközt, amely figyelmen kívül hagyja az új bérletet.

Nyissa meg a továbbítást anélkül, hogy találgatna a tűzfallal

A bekapcsolt továbbítás nem jelenti azt, hogy a csomag átmehet. A hídról az alagútba tartó forgalom még mindig a szűrőszabályokba ütközik, és az alapértelmezett drop továbbítási házirend eldobja a hotspot-forgalmat, miközben a Pi saját forgalma tovább működik, ami pontosan a fenti kettős tünetet eredményezi.

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

Keressen elfogadási szabályt a br0-tól a tun0-ig és a hozzá tartozó válaszirányt, valamint olyan postrouting szabályt, amely átírhatja a forrást. Ha a lánc házirendje drop, és egyetlen szabály sem illeszkedik, adja hozzá a szűk elfogadásokat, és tesztelje újra, ahelyett hogy accept-re fordítaná a házirendet.

A fordítás házirendválasztás, nem követelmény. Az otthoni LAN felé irányuló forrás-NAT minden hotspot klienst a Pi alagútcímének láttat, ami elveszíti az ügyfelenkénti hozzárendelést az otthoni naplókban, és megtöri az eredeti forrást váró szolgáltatásokat. A NAT nélküli útvonalazás láthatóan tartja a klienscímeket, de a fenti visszatérő útvonaltól függ. Válasszon egyet, és kezelje a DNS-t és az IPv6-ot ugyanúgy, mert egy működő IPv4-útvonal egy törött IPv6-útvonal mellett a böngészőben továbbra is félig töröttként olvasható.

Ellenőrizze az oda-vissza utat, majd szándékosan törje meg

Hotspot kliensről teszteljen, soha ne a Pi-ről, mert a Pi saját forgalma megkerüli az oda- és a visszautat is. Figyelje mindkét interfészt, miközben egy kliens otthoni szolgáltatást próbál elérni.

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

Olvassa együtt a két felvételt. A br0-on megjelenő kérések, amelyek soha nem jelennek meg a tun0-on, azt jelentik, hogy a Pi nem továbbít, vagy az útvonal máshová mutat. A tun0-on válasz nélküli kérések azt jelentik, hogy az otthoni oldalnak nincs visszatérő útvonala, vagy a kiszolgáló szűrte a csomagot. A tun0-on megjelenő válaszok, amelyek soha nem jelennek meg újra a br0-on, azt jelentik, hogy hiányzik a fordított szűrőszabály, ahol az alagút tökéletesnek látszik, és a kliens mégsem lát semmit.

Aztán szándékosan törje meg az utat. Vigye le és fel újra a modemkapcsolatot, és futtassa újra az útvonal- és felvétel-ellenőrzéseket; az az útvonal, amely túléli az alagutat, de újracsatlakozáskor eltűnik, a kapcsolatprofilba tartozik, nem egy egyszeri parancsba. Erősítse meg, hogy az alagút szállítása még mindig az underlay-en keresztül megy ki, és nem önmagán keresztül, a klasszikus hurok, amikor egy tolt alapértelmezett útvonalat fogadnak el anélkül, hogy hosztútvonal vezetne a partnerhez.

Csak akkor fogadja el a kialakítást, ha egy hotspot kliens fel tud oldani egy otthoni nevet, tud TCP-szolgáltatást nyitni, és egy modem-újracsatlakozáson át életben tud tartani egy munkamenetet. Ha egy alkalmazás valóban Ethernet-szintű felderítést igényel az otthoni szegmensen, válasszon támogatott Layer 2 kialakítást ahelyett, hogy a helyi hidat áthidaltként írja le, és várja a szórás megjelenését.