Hotspot VPN in bridge: quale rotta predefinita usa il telefono?

Il telefono del vostro hotspot in bridge ottiene il suo indirizzo e il suo gateway da qualche parte, e non è la rotta predefinita del Pi. Cambiare la rotta predefinita del Pi cambia dove il Pi invia il proprio traffico. Il telefono continua a usare il gateway che gli è stato indicato, e quando quel gateway si trova sulla LAN remota le sue frame attraversano semplicemente il bridge. Due consumatori, due decisioni. Separarle spiega la maggior parte delle segnalazioni di un hotspot senza internet mentre il Pi stesso è a posto.

Due dispositivi, due decisioni di gateway diverse

Il Pi ha la propria pila IP e la propria rotta predefinita. Il telefono ha la propria pila IP e la propria rotta predefinita.

Quella tabella è tutto il modello. Il gateway del telefono è un indirizzo sulla LAN remota, e le sue frame vengono inoltrate al livello 2 verso quel router. La rotta predefinita del Pi riguarda il suo trasporto esterno, che deve raggiungere il peer VPN tramite l'uplink di viaggio.

Un bridge inoltra frame, non instrada pacchetti

Un bridge Linux inoltra le frame Ethernet in base al MAC di destinazione, e questo è tutto ciò che fa fra le sue porte. La frame del telefono indirizzata al MAC del router remoto viene commutata sulla porta TAP e attraversa il tunnel senza toccare la tabella di routing del Pi. Per questo una rotta predefinita rotta del Pi può lasciare il telefono funzionante, e per questo una corretta non può riparare un telefono a cui è stato dato il gateway sbagliato.

TAP trasporta frame Ethernet e può essere una porta di bridge. TUN trasporta pacchetti IP e non può esserlo. Se il vostro progetto ha sostituito l'uno con l'altro, il bridge non è un bridge e il resto di questo non si applica.

Decidete chi distribuisce il lease del telefono

L'opzione 3 di DHCP è l'opzione router, e dice al client quale gateway usare per la sua sottorete. Quando il server DHCP della LAN remota è l'unico assegnatore, il telefono ottiene un gateway remoto e il progetto è coerente. Quando qualcos'altro sul lato viaggio risponde per primo, il telefono ottiene un gateway locale, il suo traffico internet esce dall'uplink di viaggio e il suo traffico verso la LAN remota non ha alcun percorso.

Eseguite un solo assegnatore per quel dominio di broadcast, e annotate cosa distribuisce.

Il Pi è un caso a parte anche quando prende un indirizzo dallo stesso lease. Decidete deliberatamente se deve installare le rotte offerte dal lease, perché una rotta predefinita remota importata può trascinare il trasporto VPN del Pi nel tunnel che sta cercando di mantenere vivo. Con systemd-networkd quella decisione è UseRoutes= nella sezione DHCP; con dhclient è l'opzione routers nell'elenco delle richieste.

Tenete l'uplink fuori dalla LAN in bridge

L'interfaccia che porta la connessione VPN esterna del Pi non deve diventare una porta di bridge. Se lo diventa, il trasporto cifrato viene commutato nella LAN estesa e il tunnel finisce per trasportare i propri pacchetti esterni, il che fallisce in un modo che sembra perdita di pacchetti più che un loop. Tenete esplicite anche la capacità AP e il supporto bridge. Un'interfaccia wireless in modalità station di solito non può essere una porta di bridge, perché l'intestazione 802.11 non ha spazio per il secondo indirizzo MAC che serve a un bridge.

Definite il dominio di broadcast esteso, un piano di indirizzamento e il filtraggio delle frame che volete davvero. Consentire l'ascoltatore VPN sul Pi non dà a ogni client in bridge l'accesso ai servizi di gestione del Pi. Sono regole separate, e trattarle come una sola è il modo in cui un hotspot diventa silenziosamente una porta aperta.

Provate le quattro cose separatamente quando si rompe

Quando il telefono non riesce a raggiungere la LAN remota, quattro osservazioni separano le cause. Eseguitele in questo ordine e fermatevi alla prima che fallisce.

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

Iniziate dal lease: il telefono ha un indirizzo e un gateway sulla sottorete remota? Poi guardate il bridge, e confermate che la porta AP e la porta TAP inoltrino entrambe. Poi leggete la tabella dei vicini, perché una voce non risolta per il router remoto significa che le frame escono e nulla risponde. Infine osservate le frame sul bridge mentre il telefono fa ping, il che vi dice se il guasto è sotto IP o no.

Annotate quale dispositivo possiede ciascuna rotta predefinita quando avete finito. Una riga di documentazione trasforma l'uscita locale rispetto a quella remota in una decisione consapevole del client, e il riferimento del bridge merita di stare accanto.