Bridgad VPN-hotspot: vilken standardväg använder telefonen?
Pins standardväg är inte telefonens gateway. Separera de två besluten, håll uplink utanför bryggan och testa lease före tunneln.
Telefonen på din bridgade hotspot får sin adress och sin gateway från någonstans, och det är inte Pins standardväg. Att ändra Pins standard ändrar vart Pin skickar sin egen trafik. Telefonen fortsätter att använda den gateway den fick veta, och när den gatewayen ligger på det avlägsna LAN:et korsar dess ramar bara bryggan. Två konsumenter, två beslut. Att skilja dem åt förklarar de flesta rapporterna om en hotspot utan internet medan Pin själv är i ordning.
Två enheter, två olika gatewaybeslut
Pin har sin egen IP-stack och sin egen standardväg. Telefonen har sin egen IP-stack och sin egen standardväg.
| 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 |
Den tabellen är hela modellen. Telefonens gateway är en adress på det avlägsna LAN:et, och dess ramar vidarebefordras på lager 2 mot den routern. Pins standardväg gäller Pins egen yttre transport, som måste nå VPN-peer:n via reseuplinken.
En brygga vidarebefordrar ramar, den routar inte paket
En Linux-brygga vidarebefordrar Ethernet-ramar efter destinations-MAC, och det är allt den gör mellan sina portar. Telefonens ram adresserad till den avlägsna routerns MAC kopplas till TAP-porten och korsar tunneln utan att röra Pins routingtabell. Därför kan en trasig standardväg på Pin låta telefonen fortsätta fungera, och därför kan en korrekt inte reparera en telefon som fick fel gateway.
TAP bär Ethernet-ramar och kan vara en bryggport. TUN bär IP-paket och kan inte. Om din design bytte ut det ena mot det andra är bryggan inte en brygga och resten här gäller inte.
Bestäm vem som delar ut telefonens lease
DHCP-alternativ 3 är rutteralternativet, och det talar om för klienten vilken gateway den ska använda för sitt subnät. När det avlägsna LAN:ets DHCP-server är den enda utdelaren får telefonen en avlägsen gateway och designen är konsekvent. När något annat på ressidan svarar först får telefonen en lokal gateway, dess internettrafik går ut via reseuplinken, och dess trafik till det avlägsna LAN:et har ingen väg alls.
Kör en enda utdelare för den broadcastdomänen, och anteckna vad den delar ut.
Pin är ett särskilt fall även när den tar en adress från samma lease. Bestäm medvetet om den ska installera de rutter som leasen erbjuder, eftersom en importerad avlägsen standard kan dra in Pins egen VPN-transport i tunneln den försöker hålla vid liv. Med systemd-networkd är det beslutet UseRoutes= under DHCP-avsnittet; med dhclient är det routers-alternativet i begärandelistan.
Håll uplinken utanför det bridgade LAN:et
Gränssnittet som bär Pins yttre VPN-anslutning får inte bli en bryggport. Om det blir det kopplas den krypterade transporten in i det utökade LAN:et och tunneln bär till slut sina egna yttre paket, vilket misslyckas på ett sätt som ser ut som paketförlust snarare än en loop. Håll också AP-förmåga och bryggstöd explicita. Ett trådlöst gränssnitt i station-läge kan vanligtvis inte vara en bryggport, eftersom 802.11-huvudet inte har plats för den andra MAC-adress som en brygga behöver.
Definiera den utökade broadcastdomänen, en adressplan och den ramfiltrering du faktiskt vill ha. Att tillåta VPN-lyssnaren på Pin ger inte varje bridgad klient åtkomst till Pins hanteringstjänster. Det är separata regler, och att behandla dem som en är hur en hotspot tyst blir en öppen dörr.
Testa de fyra sakerna var för sig när det går sönder
När telefonen inte når det avlägsna LAN:et skiljer fyra observationer orsakerna. Kör dem i den här ordningen och stanna vid den första som misslyckas.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpBörja med leasen: har telefonen en adress och en gateway på det avlägsna subnätet? Titta sedan på bryggan och bekräfta att AP-porten och TAP-porten båda vidarebefordrar. Läs sedan grann-tabellen, eftersom en olöst post för den avlägsna routern betyder att ramar lämnar och ingenting svarar. Slutligen observera ramarna på bryggan medan telefonen pingar, vilket talar om för dig om felet överhuvudtaget ligger under IP.
Anteckna vilken enhet som äger varje standardväg när du är klar. En rad dokumentation gör lokal kontra avlägsen utgång till ett medvetet klientbeslut, och bryggreferensen är värd att ha bredvid.