Oorbrugde VPN-hotspot: watter verstekroete gebruik die foon?
Die Pi se verstekroete is nie die foon se gateway nie. Skei die twee besluite, hou die uplink buite die brug, en toets die lease voor die tonnel.
Die foon op jou oorbrugde hotspot kry sy adres en gateway van iewers, en dit is nie die Pi se verstekroete nie. Om die Pi se verstek te verander, verander waar die Pi sy eie verkeer stuur. Die foon bly die gateway gebruik wat aan hom gesê is, en wanneer daardie gateway op die afgeleë LAN sit, kruis sy rame bloot die brug. Twee verbruikers, twee besluite. Om hulle te skei verduidelik die meeste verslae van 'n hotspot sonder internet terwyl die Pi self reg is.
Twee toestelle, twee verskillende gateway-besluite
Die Pi het 'n eie IP-stapel en 'n eie verstekroete. Die foon het 'n eie IP-stapel en 'n eie verstekroete.
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The Pi sends its own outer transport packets over the underlay |
Daardie tabel is die hele model. Die foon se gateway is 'n adres op die afgeleë LAN, en sy rame word op laag 2 na daardie router aangestuur. Die Pi se verstekroete raak die Pi se eie buitenste vervoer, wat die VPN-port oor die reis-uplink moet bereik.
'n Brug stuur rame aan, dit roeteer nie pakette nie
'n Linux-brug stuur Ethernet-rame aan volgens bestemming-MAC, en dit is al wat dit tussen sy poorte doen. Die foon se raam wat aan die afgeleë router se MAC gerig is, word na die TAP-poort geskakel en kruis die tonnel sonder om die Pi se roetertabel te raak. Daarom kan 'n stukkende Pi-verstekroete die foon laat werk, en daarom kan 'n korrekte een nie 'n foon regstel wat die verkeerde gateway gekry het nie.
TAP dra Ethernet-rame en kan 'n brugpoort wees. TUN dra IP-pakkette en kan nie. As jou ontwerp die een deur die ander vervang het, is die brug nie 'n brug nie en geld die res hiervan nie.
Besluit wie die foon se lease uitdeel
DHCP-opsie 3 is die router-opsie, en dit sê vir die kliënt watter gateway vir sy subnet gebruik moet word. Wanneer die afgeleë LAN se DHCP-bediener die enigste toekanner is, kry die foon 'n afgeleë gateway en is die ontwerp konsekwent. Wanneer iets anders aan die reiskant eerste antwoord, kry die foon 'n plaaslike gateway, sy internetverkeer verlaat deur die reis-uplink, en sy afgeleë-LAN-verkeer het glad geen pad nie.
Hardloop een toekanner vir daardie broadcast-domein, en teken aan wat dit uitdeel.
Die Pi is 'n aparte geval selfs wanneer dit 'n adres uit dieselfde lease kry. Besluit doelbewus of dit die roetes moet installeer wat die lease bied, want 'n ingevoerde afgeleë verstek kan die Pi se eie VPN-vervoer in die tonnel intrek wat dit probeer lewendig hou. Met systemd-networkd is daardie besluit UseRoutes= onder die DHCP-afdeling; met dhclient is dit die routers-opsie in die versoeklys.
Hou die uplink buite die oorbrugde LAN
Die koppelvlak wat die Pi se buitenste VPN-verbinding dra, mag nie 'n brugpoort word nie. As dit wel gebeur, word die versleutelde vervoer in die uitgebreide LAN geskakel en die tonnel dra uiteindelik sy eie buitenste pakkette, wat misluk op 'n manier wat soos pakketverlies lyk eerder as 'n lus. Hou AP-vermoë en brugondersteuning ook eksplisiet. 'n Draadlose koppelvlak in station-mode kan gewoonlik nie 'n brugpoort wees nie, want die 802.11-kop het geen ruimte vir die tweede MAC-adres wat 'n brug nodig het nie.
Definieer die uitgebreide broadcast-domein, een adresplan, en die raamfiltering wat jy werklik wil hê. Om die VPN-luisteraar op die Pi toe te laat, gee nie elke oorbrugde kliënt toegang tot die Pi se bestuursdienste nie. Dit is aparte reëls, en om hulle as een te behandel, is hoe 'n hotspot stilweg 'n oop deur word.
Toets die vier dinge afsonderlik wanneer dit breek
Wanneer die foon nie die afgeleë LAN kan bereik nie, skei vier waarnemings die oorsake. Hardloop hulle in hierdie volgorde en stop by die eerste een wat misluk.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpBegin met die lease: het die foon 'n adres en 'n gateway op die afgeleë subnet? Kyk dan na die brug, en bevestig dat die AP-poort en die TAP-poort albei aanstuur. Lees dan die buurtabel, want 'n onopgeloste inskrywing vir die afgeleë router beteken rame vertrek en niks antwoord nie. Kyk laastens na rame op die brug terwyl die foon ping, wat jou sê of die fout hoegenaamd onder IP lê.
Teken aan watter toestel elke verstek besit wanneer jy klaar is. Een reël dokumentasie maak van plaaslike versus afgeleë uitgang 'n doelbewuste kliëntbesluit, en die brugverwysing is werd om daarby te hou.