Hotspotoví klienti na Pi nedosiahnu domácu LAN cez TUN VPN

Miestni klienti Wi-Fi a Ethernet sa pripoja k hotspotu Pi, získajú adresu z jeho DHCP rozsahu a načítavajú internetové stránky bez sťažností. Tí istí klienti potom vypršia, keď otvoria súborové zdieľanie alebo webové rozhranie v domácej LAN, zatiaľ čo samotné Pi sa k tejto LAN dostane cez tunel. V bezdrôtovej vrstve nie je nič pokazené. Chýba smerovaná zmluva: prefix hotspotu sa musí preniesť do rozhrania TUN a niečo na domácej strane musí vedieť, ako tam posielať odpovede späť. Obe polovice musia existovať, kým jeden paket dokončí cestu tam a späť.

Tri pripojenia s tromi rôznymi úlohami

Linuxový Ethernet most preposiela rámce podľa cieľovej MAC adresy. OpenVPN v režime TUN prenáša IP pakety a nemá vôbec vrstvu MAC, takže pridanie lokálneho mosta nikdy nezapíše tunel ako port. dokumentácia jadra k TUN/TAP vysvetľuje toto rozdelenie: zariadenie TAP vyzerá ako Ethernet rozhranie, zariadenie TUN nie. Návrh, ktorý premostí dva lokálne porty a potom smeruje, je router, nech sa rozhrania volajú akokoľvek.

Tento rozdiel rozhoduje o vlastníctve. Podsieť klientov, ich predvolená brána a DHCP oprávnenie pre tento rozsah patria lokálnemu plánu Pi. Domáce DHCP vysielania neprechádzajú smerovaným tunelom a žiadne nastavenie mosta to nemení; nasmerovať klientov na domáci DHCP server je samostatný, zámerný relay návrh s vlastnými režimami zlyhania.

Modem držte mimo klientskeho mosta. PPP pripojenie nie je Ethernet zariadenie s inou nálepkou a dokumentovaná logika predvolenej trasy v pppd beží po vyjednaní IPCP a svoju trasu stiahne, keď to spojenie padne. Kopírovanie DHCP šablóny a premenovanie každého usb0 na ppp0 nič nedokazuje o bráne, metrike ani životnom cykle.

Vyberte prefixy skôr, než začnete upravovať akúkoľvek konfiguráciu

Prekrývajúce sa prefixy míňajú viac večerov než pravidlá firewallu, pretože prekrytie pošle hľadanie trasy na nesprávne rozhranie aj vtedy, keď je tunel zdravý. Začnite zoznamom toho, čo na Pi už existuje, a výsledok potom čítajte ako štyri oddelené bazény.

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

Prvý bazén je underlay adresa, ktorú operátor dal modemu; musí zostať mimo každého plánu obráteného ku klientom. Druhý je podsieť tunela, ktorú zvolil server, často jeho vlastná privátna /24 sieť. Tretí je most hotspotu a štvrtý je domáci prefix, ktorý chcete dosiahnuť. V tomto postupe dostane hotspot 172.28.90.0/24 s mostom na 172.28.90.1 a domáca servisná LAN si ponechá 192.168.77.0/24, čo obchádza predvolené 192.168.1.0/24 a 10.0.0.0/24 dodávané spotrebiteľskými routermi a operátorský rozsah 100.64.0.0/10.

V DHCP rozsahu hotspotu inzerujte ako bránu iba adresu mosta a nič iné. Nikdy nedávajte hotspotovým klientom domácu adresu ako bránu; nemajú cestu na vrstve spojenia do tohto segmentu.

Smerujte každý smer na strane, ktorá ho vlastní

Pi potrebuje trasu k domácemu prefixu cez tunel. Servery v serverovom režime zvyčajne túto trasu tlačia, preto najprv potvrďte, že preposielanie je zapnuté a že jadro rozrieši domácu adresu z tun0.

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

Ak ip route get stále hlási underlay rozhranie, zastavte sa tam; nič ďalej na ceste neopraví nesprávne hľadanie.

Domáce zariadenia nemajú trasu do 172.28.90.0/24, takže ich odpovede nasledujú predvolenú bránu a zomierajú na routeri. Existujú dve podporované opravy. Buď pridajte statickú trasu na domácom routeri, ktorá smeruje prefix hotspotu na LAN adresu VPN servera, alebo, keď je server sám bránou, zaregistrujte klientsky prefix vo vlastnej smerovacej tabuľke servera. V multi-client režime OpenVPN nesie toto spojenie adresár špecifický pre klienta: súbor pomenovaný podľa spoločného názvu klientskeho certifikátu, obsahujúci iroute 172.28.90.0 255.255.255.0 plus zodpovedajúci riadok route, ktorý ho inštaluje do jadra servera. Uhádnutá trasa jadra na serveri nie je rovnaké tvrdenie ako povedať serveru, ktorý klient vlastní prefix.

Nepresúvajte DHCP službu domácej siete na VPN server, aby to fungovalo. Nahradenie predvolenej brány pre celý dom je oveľa väčšia zmena než pridanie jednej privátnej spiatočnej trasy a vtiahne DNS, rezervácie adries a každé zariadenie, ktoré ignoruje nový nájom, do zlyhania.

Otvorte preposielanie bez hádania firewallu

Zapnuté preposielanie neznamená, že paket smie prejsť. Premávka z mosta do tunela stále naráža na pravidlá filtrovania a predvolená politika preposielania drop zahadzuje hotspotovú premávku, kým vlastná premávka Pi ďalej funguje, čo vytvára presne rozdvojený príznak vyššie.

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

Hľadajte pravidlo prijatia z br0 do tun0 a zodpovedajúci smer odpovede a pravidlo postrouting, ktoré môže prepísať zdroj. Ak je politika reťazca drop a žiadne pravidlo nevyhovuje, pridajte úzke prijatia a otestujte znova, namiesto toho aby ste politiku prepnuli na accept.

Preklad je voľba politiky, nie požiadavka. Source NAT smerom k domácej LAN robí z každého hotspotového klienta adresu tunela Pi, čo stráca priradenie po klientoch v domácich logoch a láme služby, ktoré očakávajú pôvodný zdroj. Smerovanie bez NAT udržiava adresy klientov viditeľné, ale závisí od spiatočnej trasy vyššie. Vyberte jedno a zaobchádzajte s DNS a IPv6 rovnako, pretože funkčná cesta IPv4 vedľa pokazenej cesty IPv6 sa v prehliadači stále číta ako napoly pokazená.

Overte cestu tam a späť a potom ju schválne pokazte

Testujte z hotspotového klienta, nikdy z Pi, pretože vlastná premávka Pi obchádza doprednú aj spiatočnú cestu. Sledujte obe rozhrania, kým sa jeden klient snaží dosiahnuť domácu službu.

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

Čítajte oba záznamy spolu. Požiadavky na br0, ktoré sa nikdy neobjavia na tun0, znamenajú, že Pi nepreposiela alebo trasa ukazuje inam. Požiadavky na tun0 bez odpovedí znamenajú, že domáca strana nemá spiatočnú trasu alebo server paket vyfiltroval. Odpovede na tun0, ktoré sa už nikdy neobjavia na br0, znamenajú, že chýba opačné pravidlo filtrovania, kde tunel vyzerá dokonale a klient napriek tomu nič nevidí.

Potom cestu zámerne pokazte. Znížte modemové pripojenie a znova ho zdvihnite a znova spustite kontroly trasy a záznamu; trasa, ktorá prežije tunel, ale pri opätovnom pripojení zmizne, patrí do profilu pripojenia, nie do jednorazového príkazu. Potvrďte, že transport tunela stále vychádza cez underlay a nie cez seba, klasická slučka, keď je tlačená predvolená trasa prijatá bez trasy k hostiteľovi partnera.

Návrh prijmite len vtedy, keď hotspotový klient dokáže vyriešiť domáce meno, otvoriť TCP službu a udržať reláciu živú cez jedno opätovné pripojenie modemu. Ak aplikácia naozaj vyžaduje objavovanie na úrovni Ethernet v domácom segmente, vyberte podporovaný návrh Layer 2, namiesto toho aby ste lokálny most opisovali ako premostený a čakali na vysielanie.