Hindi naaabot ng mga hotspot client sa Pi ang home LAN sa pamamagitan ng TUN VPN

Kumokonekta ang mga lokal na Wi-Fi at Ethernet client sa hotspot ng Pi, kumukuha ng address mula sa saklaw ng DHCP nito at naglo-load ng mga pahina sa internet nang walang reklamo. Pagkatapos, nag-time out ang parehong mga client kapag nagbukas ng file share o web UI sa home LAN, samantalang ang Pi mismo ay nakakaabot sa LAN na iyon sa pamamagitan ng tunnel. Walang sira sa wireless layer. Ang kulang ay isang routed na kontrata: kailangang dalhin ang prefix ng hotspot sa TUN interface, at may dapat malaman sa bahagi ng bahay kung paano ipadala pabalik ang mga tugon. Dapat umiral ang dalawang kalahati bago makumpleto ng isang pakete ang paglalakbay pabalik-balik.

Tatlong attachment na may tatlong magkaibang trabaho

Ang Linux Ethernet bridge ay nagpapasa ng mga frame ayon sa destination MAC address. OpenVPN sa TUN mode ay nagdadala ng IP packets at wala talagang MAC layer, kaya ang pagdagdag ng lokal na bridge ay hindi kailanman nagrerehistro ng tunnel bilang port. Ang dokumentasyon ng kernel sa TUN/TAP ay nagpapaliwanag ng paghahati na iyon: ang TAP device ay mukhang Ethernet interface, ang TUN device ay hindi. Ang disenyong nagbu-bridge ng dalawang lokal na port at pagkatapos ay nagra-route ay isang router, anuman ang sabihin ng mga pangalan ng interface.

Ang pagkakaibang iyon ang nagtatakda ng pagmamay-ari. Ang subnet ng mga client, ang default gateway nila at ang DHCP authority para sa saklaw na iyon ay kabilang sa lokal na plano ng Pi. Hindi tumatawid ang home DHCP broadcast sa routed tunnel, at walang setting ng bridge ang nagbabago nito; ang pagturo sa mga client sa home DHCP server ay hiwalay at sinadyang relay design na may sariling failure modes.

Panatilihin ding nasa labas ng client bridge ang modem. Ang PPP attachment ay hindi Ethernet device na may ibang label, at ang dokumentadong default-route logic ng pppd ay tumatakbo pagkatapos ng IPCP negotiation at binabawi ang ruta nito kapag bumagsak ang link na iyon. Ang pagkopya ng DHCP template at pagpapalit ng pangalan ng bawat usb0 sa ppp0 ay walang pinapatunayan tungkol sa gateway, metric o lifecycle.

Piliin ang mga prefix bago mag-edit ng anumang config

Ang magkakapatong na prefix ay gumugugol ng mas maraming gabi kaysa sa firewall rules, dahil ang overlap ay nagpapadala ng route lookup sa maling interface kahit malusog ang tunnel. Magsimula sa paglilista ng umiiral na sa Pi, pagkatapos ay basahin ang resulta bilang apat na hiwalay na pool.

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

Ang unang pool ay ang underlay address na ibinigay ng carrier sa modem; dapat itong manatili sa labas ng bawat planong nakaharap sa mga client. Ang pangalawa ay ang tunnel subnet na pinili ng server, kadalasan ay sarili nitong pribadong /24 network. Ang pangatlo ay ang hotspot bridge, at ang pang-apat ay ang home prefix na gusto mong maabot. Sa paglalakbay na ito, ang hotspot ay nakakakuha ng 172.28.90.0/24 na may bridge sa 172.28.90.1, at ang home service LAN ay nagpapanatili ng 192.168.77.0/24, na umiiwas sa mga default na 192.168.1.0/24 at 10.0.0.0/24 na kasama ng consumer routers at sa carrier range na 100.64.0.0/10.

I-anunsyo ang address ng bridge bilang gateway sa DHCP scope ng hotspot at wala nang iba. Huwag kailanman bigyan ang mga hotspot client ng home address bilang gateway; wala silang link-layer path patungo sa segment na iyon.

I-route ang bawat direksyon sa panig na nagmamay-ari nito

Kailangan ng Pi ng ruta para sa home prefix sa pamamagitan ng tunnel. Ang mga server sa server mode ay karaniwang nagtutulak ng rutang iyon, kaya tiyakin muna na nakabukas ang forwarding at nire-resolve ng kernel ang home address mula sa tun0.

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

Kung ang ip route get ay nag-uulat pa rin ng underlay interface, huminto roon; walang mas malayo sa landas ang makakapagayos ng maling lookup.

Ang mga device sa bahay ay walang ruta patungo sa 172.28.90.0/24, kaya ang kanilang mga tugon ay sumusunod sa default gateway at namamatay sa router. May dalawang suportadong pag-aayos. O magdagdag ng static route sa home router na nagtuturo sa hotspot prefix patungo sa LAN address ng VPN server, o, kapag ang server mismo ang gateway, irehistro ang client prefix sa sariling routing table ng server. Sa multi-client mode ng OpenVPN, dinadala ng client-specific directory ang association na iyon: isang file na pinangalanan sa common name ng client certificate, na naglalaman ng iroute 172.28.90.0 255.255.255.0 kasama ang tugmang route line na nag-i-install nito sa server kernel. Ang hinulaang kernel route sa server ay hindi kaparehong pahayag ng pagsasabi sa server kung aling client ang nagmamay-ari ng prefix.

Huwag ilipat ang DHCP service ng home network sa VPN server para gumana ito. Ang pagpapalit ng default gateway para sa isang buong bahay ay mas malaking pagbabago kaysa sa pagdagdag ng isang pribadong return route, at kinakaladkad nito ang DNS, address reservations at bawat device na hindi pinapansin ang bagong lease sa failure.

Buksan ang forwarding nang hindi nanghuhula sa firewall

Ang bukas na forwarding ay hindi nangangahulugang pinapayagang dumaan ang pakete. Ang trapik mula sa bridge patungo sa tunnel ay tumatama pa rin sa filter rules, at ang default-drop forward policy ay nagtatapon ng hotspot traffic habang patuloy na gumagana ang sariling traffic ng Pi, na gumagawa ng eksaktong split symptom sa itaas.

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

Maghanap ng accept rule mula sa br0 patungo sa tun0 at ang tugmang reply direction, at ng postrouting rule na maaaring mag-rewrite ng source. Kung ang chain policy ay drop at walang rule na tumutugma, idagdag ang makitid na accepts at muling subukan sa halip na ibaliktad ang policy sa accept.

Ang pagsasalin ay pagpili ng patakaran, hindi kinakailangan. Ang source NAT patungo sa home LAN ay ginagawang mukhang tunnel address ng Pi ang bawat hotspot client, na nawawala ang per-client attribution sa mga log ng bahay at sinisira ang mga serbisyong umaasa sa orihinal na source. Ang routing na walang NAT ay nagpapanatili ng nakikitang client addresses ngunit umaasa sa return route sa itaas. Pumili ng isa at tratuhin ang DNS at IPv6 sa parehong paraan, dahil ang gumaganang IPv4 path sa tabi ng sirang IPv6 path ay nababasa pa rin bilang kalahating sira sa browser.

I-verify ang paglalakbay pabalik-balik, pagkatapos ay sadyang sirain ito

Subukan mula sa hotspot client, hindi kailanman mula sa Pi, dahil ang sariling trapik ng Pi ay lumalampas sa forward at return path. Pagmasdan ang dalawang interface habang sinusubukan ng isang client na maabot ang serbisyo sa bahay.

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

Basahin ang dalawang capture nang magkasama. Ang mga request sa br0 na hindi kailanman lumilitaw sa tun0 ay nangangahulugang hindi nagpapasa ang Pi o ang ruta ay tumuturo sa ibang lugar. Ang mga request sa tun0 na walang tugon ay nangangahulugang walang return route ang bahagi ng bahay o sinasalà ng server ang pakete. Ang mga tugon sa tun0 na hindi na muling lumilitaw sa br0 ay nangangahulugang kulang ang reverse filter rule, kung saan perpekto ang tunnel at wala pa ring nakikita ang client.

Pagkatapos, sadyang sirain ang landas. Ibaba at itaas muli ang modem connection at muling patakbuhin ang route at capture checks; ang rutang nakaligtas sa tunnel ngunit nawawala sa muling pagkonekta ay kabilang sa connection profile, hindi sa isang beses na utos. Tiyakin na ang transport ng tunnel ay lumalabas pa rin sa underlay at hindi sa sarili nito, ang klasikong loop kapag tinatanggap ang itinulak na default route nang walang host route patungo sa peer.

Tanggapin ang disenyo lamang kapag ang isang hotspot client ay makakaresolve ng home name, makakapagbukas ng TCP service at makapagpapanatili ng session na buhay sa isang modem reconnect. Kung ang isang application ay tunay na nangangailangan ng Ethernet-level discovery sa home segment, pumili ng suportadong Layer 2 design sa halip na ilarawan ang lokal na bridge bilang naka-bridge at maghintay na lumitaw ang broadcast.