Hotspotoví klienti na Pi nedosáhnou domácí LAN přes TUN VPN

Místní klienti Wi-Fi a Ethernet se připojí k hotspotu Pi, získají adresu z jeho DHCP rozsahu a načítají internetové stránky bez stížností. Ti samí klienti pak vyprší, když otevřou souborové sdílení nebo webové rozhraní v domácí LAN, zatímco samotné Pi se k této LAN dostane přes tunel. V bezdrátové vrstvě není nic rozbité. Chybí směrovaná smlouva: prefix hotspotu musí být přenesen do rozhraní TUN a něco na domácí straně musí vědět, jak tam posílat odpovědi. Obě poloviny musí existovat, než jediný paket dokončí cestu tam a zpět.

Tři připojení se třemi různými úkoly

Linuxový Ethernet most přeposílá rámce podle cílové MAC adresy. OpenVPN v režimu TUN přenáší IP pakety a nemá vůbec vrstvu MAC, takže přidání místního mostu nikdy nezapíše tunel jako port. dokumentace jádra TUN/TAP toto rozdělení vysvětluje: zařízení TAP vypadá jako Ethernet rozhraní, zařízení TUN ne. Návrh, který přemostí dva místní porty a pak směruje, je router, ať se rozhraní jmenují jakkoli.

Toto rozlišení rozhoduje o vlastnictví. Podsíť klientů, jejich výchozí brána a pravomoc DHCP pro tento rozsah patří místnímu plánu Pi. Domácí DHCP broadcasty nepřekračují směrovaný tunel a žádné nastavení mostu to nezmění; nasměrovat klienty na domácí DHCP server je samostatný, záměrný relay návrh s vlastními režimy selhání.

Modem držte mimo klientský most. PPP připojení není Ethernet zařízení s jinou nálepkou a dokumentovaná logika výchozí trasy v pppd běží po vyjednání IPCP a svou trasu stáhne, když to spojení spadne. Kopírování DHCP šablony a přejmenování každého usb0 na ppp0 nic nedokazuje o bráně, metrice ani životním cyklu.

Vyberte prefixy, než začnete upravovat jakoukoli konfiguraci

Překrývající se prefixy ztrácejí více večerů než pravidla firewallu, protože překryv pošle hledání trasy na špatné rozhraní, i když je tunel zdravý. Začněte seznamem toho, co na Pi už existuje, a výsledek pak čtěte jako čtyři oddělené bazény.

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

První bazén je underlay adresa, kterou operátor dal modemu; musí zůstat mimo každý plán obrácený ke klientům. Druhý je podsíť tunelu, kterou zvolil server, často vlastní privátní /24 síť. Třetí je most hotspotu a čtvrtý je domácí prefix, který chcete dosáhnout. V tomto postupu dostane hotspot 172.28.90.0/24 s mostem na 172.28.90.1 a domácí servisní LAN si ponechá 192.168.77.0/24, což obchází výchozí 192.168.1.0/24 a 10.0.0.0/24, které dodávají spotřebitelské routery, i operátorský rozsah 100.64.0.0/10.

Inzerujte adresu mostu jako bránu v DHCP rozsahu hotspotu a nic jiného. Nikdy nedávejte hotspotovým klientům domácí adresu jako bránu; nemají cestu na vrstvě spoje do tohoto segmentu.

Směrujte každý směr na straně, která ho vlastní

Pi potřebuje trasu pro domácí prefix přes tunel. Servery v serverovém režimu obvykle tuto trasu tlačí, takže nejprve potvrďte, že přeposílání je zapnuté a že jádro rozřeší domácí 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

Pokud ip route get stále hlásí underlay rozhraní, zastavte se tam; nic dál na cestě neopraví špatné hledání.

Domácí zařízení nemají trasu do 172.28.90.0/24, takže jejich odpovědi následují výchozí bránu a umírají na routeru. Existují dvě podporované opravy. Buď přidejte statickou trasu na domácím routeru, která směruje prefix hotspotu na LAN adresu VPN serveru, nebo, když je server sám bránou, zaregistrujte klientský prefix ve vlastní směrovací tabulce serveru. V multi-client režimu OpenVPN nese toto spojení adresář specifický pro klienta: soubor pojmenovaný podle společného jména klientského certifikátu, obsahující iroute 172.28.90.0 255.255.255.0 plus odpovídající řádek route, který jej instaluje do jádra serveru. Odhadnutá trasa jádra na serveru není stejné tvrzení jako říct serveru, který klient prefix vlastní.

Nepřesouvejte DHCP službu domácí sítě na VPN server, aby to fungovalo. Nahrazení výchozí brány pro celý dům je mnohem větší změna než přidání jedné privátní zpětné trasy a vtahuje DNS, rezervace adres a každé zařízení, které ignoruje nový pronájem, do selhání.

Otevřete přeposílání, aniž byste hádali firewall

Zapnuté přeposílání neznamená, že paket smí projít. Provoz z mostu do tunelu stále naráží na pravidla filtrování a výchozí politika přeposílání drop zahazuje hotspotový provoz, zatímco vlastní provoz Pi dál funguje, což vytváří přesně rozdvojený příznak výše.

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

Hledejte pravidlo přijetí z br0 do tun0 a odpovídající směr odpovědi a pravidlo postrouting, které může přepsat zdroj. Pokud je politika řetězu drop a žádné pravidlo neodpovídá, přidejte úzká přijetí a otestujte znovu, místo abyste politiku přepnuli na accept.

Překlad je volba politiky, ne požadavek. Source NAT směrem k domácí LAN dělá z každého hotspotového klienta adresu tunelu Pi, což ztrácí přiřazení po klientech v domácích záznamech a láme služby, které očekávají původní zdroj. Směrování bez NAT udržuje adresy klientů viditelné, ale závisí na zpětné trase výše. Vyberte jedno a zacházejte s DNS a IPv6 stejně, protože funkční cesta IPv4 vedle rozbité cesty IPv6 se v prohlížeči stále čte jako napůl rozbitá.

Ověřte cestu tam a zpět a potom ji schválně rozbijte

Testujte z hotspotového klienta, nikdy z Pi, protože vlastní provoz Pi obchází jak dopřednou, tak zpětnou cestu. Sledujte obě rozhraní, zatímco se jeden klient snaží dosáhnout domácí služby.

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

Čtěte oba záznamy společně. Požadavky na br0, které se nikdy neobjeví na tun0, znamenají, že Pi nepřeposílá nebo trasa ukazuje jinam. Požadavky na tun0 bez odpovědí znamenají, že domácí strana nemá zpětnou trasu nebo server paket vyfiltroval. Odpovědi na tun0, které se už nikdy neobjeví na br0, znamenají, že chybí obrácené pravidlo filtrování, kdy tunel vypadá dokonale a klient přesto nic nevidí.

Potom cestu záměrně rozbijte. Snižte modemové připojení a znovu je zvedněte a znovu spusťte kontroly trasy a záznamu; trasa, která přežije tunel, ale při opětovném připojení zmizí, patří do profilu připojení, ne do jednorázového příkazu. Potvrďte, že transport tunelu stále vychází přes underlay a ne skrz sebe, klasická smyčka, když je tlačená výchozí trasa přijata bez trasy k hostiteli protějšku.

Návrh přijměte jen tehdy, když hotspotový klient dokáže přeložit domácí jméno, otevřít TCP službu a udržet relaci živou přes jedno opětovné připojení modemu. Pokud aplikace skutečně vyžaduje objevování na úrovni Ethernet v domácím segmentu, zvolte podporovaný návrh Layer 2, místo abyste místní most popisovali jako přemostěný a čekali, až se objeví broadcast.