I client hotspot su un Pi non raggiungono la LAN di casa tramite una VPN TUN

I client Wi-Fi ed Ethernet locali si collegano all'hotspot del Pi, prendono un indirizzo dal suo ambito DHCP e caricano pagine internet senza lamentarsi. Gli stessi client poi vanno in timeout quando aprono una condivisione file o un'interfaccia web sulla LAN di casa, mentre il Pi stesso raggiunge quella LAN attraverso il tunnel. Nulla nello strato wireless è rotto. Quello che manca è un contratto instradato: il prefisso dell'hotspot deve essere portato nell'interfaccia TUN, e qualcosa sul lato casa deve sapere come inviare le risposte indietro. Entrambe le metà devono esistere prima che un singolo pacchetto possa completare il viaggio di andata e ritorno.

Tre collegamenti con tre compiti diversi

Un bridge Ethernet Linux inoltra i frame in base all'indirizzo MAC di destinazione. OpenVPN in modalità TUN trasporta pacchetti IP e non ha alcuno strato MAC, quindi aggiungere un bridge locale non registra mai il tunnel come porta. La documentazione del kernel su TUN/TAP spiega questa separazione: un dispositivo TAP sembra un'interfaccia Ethernet, un dispositivo TUN no. Un progetto che crea un bridge tra due porte locali e poi instrada è un router, qualunque cosa dicano i nomi delle interfacce.

Questa distinzione decide la proprietà. La sottorete dei client, il loro gateway predefinito e l'autorità DHCP per quell'ambito appartengono al piano locale del Pi. I broadcast DHCP di casa non attraversano un tunnel instradato, e nessuna impostazione del bridge lo cambia; puntare i client a un server DHCP di casa è un progetto di relay separato e deliberato, con i suoi modi di guasto.

Tieni anche il modem fuori dal bridge dei client. Un collegamento PPP non è un dispositivo Ethernet con un'etichetta diversa, e la logica documentata della rotta predefinita di pppd gira dopo la negoziazione IPCP e ritira la sua rotta quando quel collegamento cade. Copiare un modello DHCP e rinominare ogni usb0 in ppp0 non dimostra nulla su gateway, metrica o ciclo di vita.

Scegli i prefissi prima di modificare qualsiasi configurazione

I prefissi sovrapposti fanno perdere più serate delle regole del firewall, perché una sovrapposizione manda la ricerca della rotta sull'interfaccia sbagliata anche quando il tunnel è sano. Inizia elencando ciò che esiste già sul Pi, poi leggi il risultato come quattro pool separati.

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

Il primo pool è l'indirizzo underlay che l'operatore ha dato al modem; deve restare fuori da ogni piano rivolto ai client. Il secondo è la sottorete del tunnel scelta dal server, spesso una /24 privata sua. Il terzo è il bridge dell'hotspot, e il quarto è il prefisso di casa che vuoi raggiungere. In questo percorso l'hotspot riceve 172.28.90.0/24 con il bridge su 172.28.90.1, e la LAN dei servizi di casa mantiene 192.168.77.0/24, il che evita le impostazioni predefinite 192.168.1.0/24 e 10.0.0.0/24 con cui arrivano i router consumer e l'intervallo dell'operatore 100.64.0.0/10.

Annuncia l'indirizzo del bridge come gateway nell'ambito DHCP dell'hotspot e nient'altro. Non dare mai ai client dell'hotspot un indirizzo di casa come gateway; non hanno alcun percorso a livello di collegamento verso quel segmento.

Instrada ogni direzione sul lato che la possiede

Il Pi ha bisogno di una rotta per il prefisso di casa attraverso il tunnel. I server in modalità server di solito spingono quella rotta, quindi prima conferma che l'inoltro sia attivo e che il kernel risolva un indirizzo di casa da tun0.

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

Se ip route get riporta ancora l'interfaccia underlay, fermati lì; nulla più avanti nel percorso può riparare una ricerca sbagliata.

I dispositivi di casa non hanno rotta verso 172.28.90.0/24, quindi le loro risposte seguono il gateway predefinito e muoiono al router. Esistono due riparazioni supportate. O aggiungi una rotta statica sul router di casa che punti il prefisso dell'hotspot all'indirizzo LAN del server VPN, oppure, quando il server è esso stesso il gateway, registra il prefisso del client nella tabella di routing del server. In modalità multi-client di OpenVPN la directory specifica del client porta quell'associazione: un file intitolato al nome comune del certificato del client, che contiene iroute 172.28.90.0 255.255.255.0 più la riga route corrispondente che lo installa nel kernel del server. Una rotta del kernel indovinata sul server non è la stessa affermazione che dire al server quale client possiede il prefisso.

Non spostare il servizio DHCP della rete di casa sul server VPN per far funzionare tutto questo. Sostituire il gateway predefinito di un'intera casa è un cambiamento molto più grande che aggiungere una rotta di ritorno privata, e trascina DNS, prenotazioni di indirizzi e ogni dispositivo che ignora il nuovo lease nel guasto.

Apri l'inoltro senza tirare a indovinare sul firewall

L'inoltro attivo non significa che il pacchetto sia autorizzato a passare. Il traffico dal bridge al tunnel colpisce ancora le regole di filtro, e una politica di inoltro predefinita drop scarta il traffico dell'hotspot mentre il traffico del Pi continua a funzionare, il che produce esattamente il sintomo diviso qui sopra.

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

Cerca una regola di accettazione da br0 a tun0 e la direzione di risposta corrispondente, e una regola postrouting che possa riscrivere la sorgente. Se la politica della catena è drop e nessuna regola corrisponde, aggiungi le accettazioni strette e riprova invece di ribaltare la politica su accept.

La traduzione è una scelta di politica, non un requisito. Il NAT di sorgente verso la LAN di casa fa sembrare ogni client dell'hotspot l'indirizzo del tunnel del Pi, il che perde l'attribuzione per client nei log di casa e rompe i servizi che si aspettano la sorgente originale. L'instradamento senza NAT mantiene visibili gli indirizzi dei client ma dipende dalla rotta di ritorno qui sopra. Scegline una e tratta DNS e IPv6 allo stesso modo, perché un percorso IPv4 funzionante accanto a un percorso IPv6 rotto si legge ancora come mezzo rotto nel browser.

Verifica il viaggio di andata e ritorno, poi rompilo di proposito

Prova da un client dell'hotspot, mai dal Pi, perché il traffico del Pi stesso aggira sia il percorso di andata sia quello di ritorno. Osserva entrambe le interfacce mentre un client cerca di raggiungere un servizio di casa.

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

Leggi le due catture insieme. Le richieste su br0 che non compaiono mai su tun0 significano che il Pi non inoltra o che la rotta punta altrove. Le richieste su tun0 senza risposte significano che il lato casa non ha una rotta di ritorno o che il server ha filtrato il pacchetto. Le risposte su tun0 che non riappaiono mai su br0 significano che manca la regola di filtro inversa, dove il tunnel sembra perfetto e il client ancora non vede nulla.

Poi rompi il percorso di proposito. Abbassa e rialza la connessione del modem e riesegui i controlli di rotta e cattura; una rotta che sopravvive al tunnel ma sparisce alla riconnessione appartiene al profilo di connessione, non a un comando una tantum. Conferma che il trasporto del tunnel esca ancora attraverso l'underlay e non attraverso se stesso, il classico loop quando una rotta predefinita spinta viene accettata senza una rotta host verso il peer.

Accetta il progetto solo quando un client dell'hotspot può risolvere un nome di casa, aprire un servizio TCP e mantenere viva una sessione attraverso una riconnessione del modem. Se un'applicazione richiede davvero il rilevamento a livello Ethernet sul segmento di casa, scegli un progetto Layer 2 supportato invece di descrivere il bridge locale come collegato in bridge e aspettare che compaia il broadcast.