Bridged VPN-hotspot: welke standaardroute gebruikt de telefoon?

De telefoon op je gebrugde hotspot krijgt zijn adres en gateway ergens vandaan, en dat is niet de standaardroute van de Pi. De standaardroute van de Pi wijzigen verandert waar de Pi zijn eigen verkeer naartoe stuurt. De telefoon blijft de gateway gebruiken die hem is verteld, en wanneer die gateway op de externe LAN staat, gaan zijn frames gewoon over de bridge. Twee consumenten, twee beslissingen. Ze scheiden verklaart het meeste van de meldingen over een hotspot zonder internet terwijl de Pi zelf in orde is.

Twee apparaten, twee verschillende gatewaybeslissingen

De Pi heeft zijn eigen IP-stack en zijn eigen standaardroute. De telefoon heeft zijn eigen IP-stack en zijn eigen standaardroute.

Die tabel is het hele model. De gateway van de telefoon is een adres op de externe LAN, en zijn frames worden op laag 2 naar die router doorgestuurd. De standaardroute van de Pi betreft zijn eigen buitenste transport, dat de VPN-peer via de reis-uplink moet bereiken.

Een bridge stuurt frames door, hij routeert geen pakketten

Een Linux-bridge stuurt Ethernet-frames door op basis van het bestemmings-MAC, en dat is alles wat hij tussen zijn poorten doet. Het frame van de telefoon dat aan het MAC van de externe router is geadresseerd, wordt naar de TAP-poort geschakeld en gaat door de tunnel zonder de routingtabel van de Pi aan te raken. Daarom kan een kapotte standaardroute van de Pi de telefoon laten werken, en daarom kan een correcte een telefoon niet repareren die de verkeerde gateway kreeg.

TAP draagt Ethernet-frames en kan een bridgepoort zijn. TUN draagt IP-pakketten en kan dat niet. Als je ontwerp het een door het ander heeft vervangen, is de bridge geen bridge en de rest hiervan geldt niet.

Bepaal wie de lease van de telefoon uitgeeft

DHCP-optie 3 is de routeroptie, en die vertelt de client welke gateway hij voor zijn subnet moet gebruiken. Wanneer de DHCP-server van de externe LAN de enige uitgever is, krijgt de telefoon een externe gateway en is het ontwerp consistent. Wanneer iets anders aan de reiskant als eerste antwoordt, krijgt de telefoon een lokale gateway, verlaat zijn internetverkeer de reis-uplink, en heeft zijn verkeer naar de externe LAN helemaal geen pad.

Draai één uitgever voor dat broadcastdomein, en leg vast wat die uitgeeft.

De Pi is een apart geval, ook wanneer hij een adres uit dezelfde lease haalt. Besluit bewust of hij de routes moet installeren die de lease biedt, want een geïmporteerde externe standaardroute kan het eigen VPN-transport van de Pi de tunnel in slepen die hij levend probeert te houden. Met systemd-networkd is die beslissing UseRoutes= in de DHCP-sectie; met dhclient is het de routers-optie in de aanvraaglijst.

Houd de uplink buiten de gebrugde LAN

De interface die de buitenste VPN-verbinding van de Pi draagt, mag geen bridgepoort worden. Gebeurt dat wel, dan wordt het versleutelde transport in de uitgebreide LAN geschakeld en draagt de tunnel uiteindelijk zijn eigen buitenste pakketten, wat faalt op een manier die op pakketverlies lijkt in plaats van op een lus. Houd ook AP-capaciteit en bridge-ondersteuning expliciet. Een draadloze interface in station-modus kan meestal geen bridgepoort zijn, omdat de 802.11-header geen ruimte heeft voor het tweede MAC-adres dat een bridge nodig heeft.

Definieer het uitgebreide broadcastdomein, één adresplan en de framefiltering die je echt wilt. De VPN-listener op de Pi toestaan geeft niet elke gebrugde client toegang tot de beheerdiensten van de Pi. Dat zijn aparte regels, en ze als één behandelen is hoe een hotspot stil een open deur wordt.

Test de vier dingen apart wanneer het breekt

Wanneer de telefoon de externe LAN niet bereikt, scheiden vier observaties de oorzaken. Voer ze in deze volgorde uit en stop bij de eerste die faalt.

ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmp

Begin met de lease: heeft de telefoon een adres en een gateway op het externe subnet? Kijk dan naar de bridge, en bevestig dat de AP-poort en de TAP-poort beide doorsturen. Lees dan de naburige tabel, want een onopgeloste vermelding voor de externe router betekent dat frames vertrekken en niets antwoordt. Bekijk ten slotte de frames op de bridge terwijl de telefoon pingt, wat je vertelt of de fout überhaupt onder IP ligt.

Leg vast welk apparaat elke standaardroute bezit als je klaar bent. Eén regel documentatie maakt lokale versus externe uitgang een bewuste clientbeslissing, en de bridgeverwijzing is het waard ernaast te bewaren.