Hotspot-Clienten op engem Pi erreechen d'Heem-LAN net iwwer eng TUN-VPN

Lokal Wi-Fi- an Ethernet-Clienten hänken sech un den Hotspot vum Pi, zéien eng Adress aus sengem DHCP-Beräich a lueden Internetsäiten ouni Klo. Déi selwecht Clienten daumen dann of, wann se eng Dateidelung oder eng Web-Oberfläch am Heem-LAN opmaachen, während den Pi selwer dëst LAN iwwer den Tunnel erreecht. Et ass näischt an der Drahtlose-Schicht futti. Wat fehlt ass e geroutete Kontrakt: de Hotspot-Prefix muss an d'TUN-Interface gedroe ginn, an eppes op der Heemsäit muss wësse wéi d'Äntwerten dohinner zréck geschéckt ginn. Béid Hälften mussen do sinn, ier een eenzege Paket d'Rondrees kann ofschléissen.

Dräi Uschlëss mat dräi verschiddenen Aufgaben

Eng Linux Ethernet-Bréck leet Frames no der Destinatiouns-MAC-Adress weider. OpenVPN am TUN-Modus dréit IP-Paketen an huet iwwerhaapt keng MAC-Schicht, dofir registréiert eng lokal Bréck dobäizemaachen den Tunnel ni als Port. D'Kernel-Dokumentatioun zu TUN/TAP erkläert déi Trennung: en TAP-Gerät gesäit aus wéi eng Ethernet-Interface, en TUN-Gerät net. En Design, deen zwou lokal Porte bréckt an dann routet, ass e Router, egal wat d'Interface-Nimm soen.

Dës Ënnerscheedung entscheet d'Eegentum. D'Subnetz vun de Clienten, hire Standard-Gateway an d'DHCP-Autoritéit fir dee Beräich gehéieren zum lokalen Plang vum Pi. Heem-DHCP-Broadcasts iwwerschreiden keen gerouteten Tunnel, an keng Bréck-Astellung ännert dat; d'Clienten op en Heem-DHCP-Server weisen ass en separate, bewossten Relay-Design mat sengen eegene Fehlermodusen.

Halt den Modem och baussen der Client-Bréck. Eng PPP-Uschloss ass keen Ethernet-Gerät mat engem aneren Etikett, an d'dokumentéiert Standardroute-Logik vu pppd leeft no der IPCP-Verhandlung a zitt seng Route zréck, wann dee Link fält. En DHCP-Template kopéieren an all usb0 an ppp0 ëmbenennen beweise näischt iwwer Gateway, Metrik oder Liewenszyklus.

Wielt d'Prefixen, ier Dir eng Konfiguratioun ännert

Iwwerlappend Prefixen verschwenden méi Owend wéi Firewall-Reegelen, well eng Iwwerlappung d'Routesich op déi falsch Interface schéckt och wann den Tunnel gesond ass. Fänkt mat enger Lëscht un wat et schonn um Pi gëtt, a liest d'Resultat dann als véier getrennte Becken.

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

Dat éischt Becken ass d'underlay-Adress, déi den Operateur dem Modem ginn huet; si muss aus all Client-geriichtem Plang eraus bleiwen. Dat zweet ass d'Tunnel-Subnetz, dat de Server gewielt huet, dacks en eegent private /24-Netz. Dat drëtt ass d'Hotspot-Bréck, an dat véiert ass de Heem-Prefix, deen Dir wëllt erreechen. An dësem Duerchgang kritt den Hotspot 172.28.90.0/24 mat der Bréck op 172.28.90.1, an d'Heemservice-LAN behält 192.168.77.0/24, wat d'Standardwäerter 192.168.1.0/24 an 10.0.0.0/24, déi Konsumenterouter matbréngen, an den Operateur-Beräich 100.64.0.0/10 ëmgeet.

Annoncéiert d'Bréck-Adress als Gateway am DHCP-Beräich vum Hotspot an soss näischt. Gitt Hotspot-Clienten ni eng Heemadress als Gateway; si hunn keen Ënnerlag-Pfad zu deem Segment.

Rout all Richtung op der Säit, déi et besëtzt

Den Pi brauch eng Route fir de Heem-Prefix duerch den Tunnel. Serveren am Servermodus drécken normalerweis déi Route, also confirméiert als éischt, datt d'Weiderleedung un ass an datt de Kernel eng Heemadress aus tun0 léist.

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

Wann ip route get nach ëmmer d'underlay-Interface mellt, stoppt do; näischt weider um Wee kann eng falsch Sich reparéieren.

Heemgeräter hunn keng Route op 172.28.90.0/24, dofir follegen hir Äntwerten dem Standard-Gateway a stierwen um Router. Et gëtt zwou ënnerstëtzt Reparaturen. Entweder füügt eng statesch Route um Heemrouter derbäi, déi de Hotspot-Prefix op d'LAN-Adress vum VPN-Server weist, oder, wann de Server selwer de Gateway ass, registréiert de Client-Prefix an der eegener Routingtabell vum Server. Am Multi-Client-Modus vun OpenVPN dréit de Client-spezifeschen Verzeechnes déi Associatioun: eng Datei, benannt nom Common Name vum Client-Zertifikat, mat iroute 172.28.90.0 255.255.255.0 an der passender route-Linn, déi se am Server-Kernel installéiert. Eng geroden Kernel-Route um Server ass net déiselwecht Ausso wéi dem Server ze soen, wéi e Client de Prefix besëtzt.

Verlee den DHCP-Service vum Heemnetz net op de VPN-Server, fir datt dëst funktionnéiert. De Standard-Gateway fir en ganzt Haus ersetzen ass eng vill méi grouss Ännerung wéi eng privat Retourroute derbäizemaachen, an et zitt DNS, Adressreservatiounen an all Gerät, dat dee neie Lease ignoréiert, an de Fehler.

Maach d'Weiderleedung op, ouni d'Firewall ze roden

Datt d'Weiderleedung un ass heescht net, datt de Paket duerchgelooss gëtt. Traffic vun der Bréck an den Tunnel trëfft nach ëmmer d'Filterreegelen, an eng Standard-Drop-Weiderleedungspolitik léisst den Hotspot-Traffic fale wärend den eegene Traffic vum Pi weiderleeft, wat genee de gespléckten Symptom uewen erzeugt.

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

Sich eng Akzeptanzreegel vun br0 op tun0 an déi passend Äntwertrichtung, an eng Postrouting-Reegel, déi d'Quell ëmschreiwe kann. Wann d'Kettepolitik drop ass an keng Reegel passt, füügt déi schmuel Akzeptanzen derbäi an testt nach eng Kéier, amplaz d'Politik op accept ze dréinen.

Iwwersetzung ass eng Politikwiel, net eng Fuerderung. Source-NAT zum Heem-LAN léisst all Hotspot-Client wéi d'Tunneladress vum Pi ausgesinn, wat d'Attributioun pro Client an den Heemlogs verléiert an d'Servicer brécht, déi déi originell Quell erwaarden. Routing ouni NAT hält d'Clientadressen sichtbar, awer hänkt vun der Retourroute uewen of. Wielt eng a behandelt DNS an IPv6 d'selwecht, well en fonctionéierende IPv4-Wee nieft engem futti IPv6-Wee liest sech am Browser nach ëmmer als hallef futti.

Verifizéiert d'Rondrees a briecht se dann absichtlech

Test vun engem Hotspot-Client, ni vum Pi, well den eegene Traffic vum Pi souwuel de Wee hin wéi och de Retourwee ëmgeet. Observéiert béid Interface, während ee Client probéiert en Heemservice z'erreechen.

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

Liest déi zwou Opnamen zesummen. Ufroen op br0, déi ni op tun0 erschéngen, heeschen datt den Pi net weiderleet oder d'Route soss anzwousch hiweist. Ufroen op tun0 ouni Äntwerten heeschen, datt d'Heemsäit keng Retourroute huet oder de Server de Paket gefiltert huet. Äntwerten op tun0, déi ni nees op br0 erschéngen, heeschen, datt déi ëmgedréit Filterreegel feelt, wou den Tunnel perfekt ausgesäit an de Client nach ëmmer näischt gesäit.

Briecht dann de Wee absichtlech. Huelt d'Modemverbindung erof an erëm erop a fuert d'Route- an Opnamekontrollen nach eng Kéier aus; eng Route, déi den Tunnel iwwerlieft awer bei enger Reconnect verschwënnt, gehéiert an de Verbindungsprofil an net an en eenzegaartege Befehl. Confirméiert, datt den Transport vum Tunnel nach ëmmer iwwer den underlay erausgeet an net duerch sech selwer, déi klassicch Loop, wann eng gedréckt Standardroute ouni Host-Route op de Peer ugeholl gëtt.

Akzeptéiert den Design nëmmen, wann en Hotspot-Client en Heemnumm kann opléisen, en TCP-Service opmaachen an eng Sessioun iwwer eng eenzeg Modem-Reconnect lieweg halen. Wann eng Applikatioun wierklech Ethernet-Niveau-Entdeckung um Heemsegment verlaangt, wielt en ënnerstëtzten Layer 2-Design, amplaz d'lokal Bréck als gebréckt ze beschreiwen an op Broadcast ze waarden.