hostapd e OpenVPN su un solo Pi: a chi appartiene la rotta predefinita?

I telefoni si associano al punto di accesso, ricevono un indirizzo e poi non raggiungono più nulla non appena il tunnel sale. hostapd di solito è sano in quello stato, e OpenVPN anche; ciò che si rompe è la rotta predefinita, che o non è mai esistita sul bridge o è stata sostituita dal tunnel senza lasciare un percorso verso il server VPN stesso. Questo manuale rimette quella rotta al suo posto e dimostra il risultato da un client anziché dal Pi. Ogni passo è reversibile, e nulla qui cambia la configurazione del tunnel finché non sapete quale traffico volete al suo interno.

Inventariate le interfacce prima di modificare qualsiasi cosa

La disposizione abituale mette la radio wireless e la porta cablata dentro br0, avvia hostapd contro il bridge e distribuisce lease da dnsmasq, mentre un client OpenVPN crea tun0. Poi tre requisiti separati sembrano uno solo: i client del punto di accesso hanno bisogno del Pi come gateway, il Pi ha bisogno di una rotta verso internet per raggiungere il suo server, e il bridge ha bisogno di un indirizzo gateway che quei client possano usare.

Leggete lo stato attuale prima di cambiarlo, perché questi quattro comandi separano un problema di interfaccia da un problema di routing.

ip -br addr
ip route show
ip link show master br0
bridge link show

Se br0 porta un indirizzo ma nessuna rotta predefinita, i client raggiungono il Pi e nulla oltre. Se la rotta predefinita punta a tun0 mentre il tunnel è abbassato, il Pi non ha alcun percorso funzionante, e il sintomo del client appare esattamente lo stesso. Entrambi i casi appaiono identici da un telefono, per questo la tabella di routing va letta direttamente.

Date al bridge una rotta predefinita che le appartenga

Raspberry Pi OS spesso lascia il bridge senza rotta predefinita quando il bridge è nato dopo la scrittura del file di interfaccia. La stanza appartiene a /etc/dhcpcd.conf, e dovrebbe nominare il router a monte invece del Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

In quell'esempio 192.168.50.1 è il router esistente e 192.168.50.2 è l'indirizzo del bridge del Pi nella stessa sottorete, quindi sostituite con il vostro piano invece di copiare i numeri. I membri del bridge non devono nemmeno richiedere router, altrimenti il Pi finisce con rotte predefinite concorrenti il cui vincitore dipende dalla metrica e dai tempi e non dall'intenzione.

Dopo systemctl restart dhcpcd, ip route show default dovrebbe elencare br0 una volta e nessun duplicato dalla porta cablata. Confermate la ricerca e non la tabella, perché una voce obsoleta può sedere accanto a una vincente: ip -4 route get 203.0.113.10 deve nominare br0. Quell'indirizzo proviene dall'intervallo di documentazione TEST-NET-3, quindi non può scontrarsi con un server reale mentre leggete questo.

Impedite al tunnel di dirottare il percorso verso il suo stesso server

Un client OpenVPN che accetta redirect-gateway prende la rotta predefinita e la indirizza nel tunnel. È corretto quando ogni client del punto di accesso dovrebbe usare la VPN, ed errato quando dovrebbero farlo solo alcune destinazioni. In ogni caso, la connessione del Pi verso il server non deve viaggiare dentro il tunnel che sta ancora costruendo. OpenVPN aggiunge una rotta host verso il remoto attraverso il gateway originale quando reindirizza la predefinita, ed è esattamente il comportamento che tiene vivo il trasporto; se quella rotta manca, il tunnel crolla non appena si stabilisce.

Un rapido confronto di quel percorso di trasporto prima e dopo la connessione vale quei dieci secondi. ip -4 route get 203.0.113.10 dovrebbe nominare il dispositivo sottostante in entrambi gli stati, con solo la metrica che cambia. Se nomina tun0 dopo la salita del tunnel, la rotta host non è mai stata installata e la prossima riconnessione fallirà.

Quando solo prefissi selezionati devono attraversare il tunnel, usate route-nopull e aggiungete le rotte desiderate a mano, oppure inviate un insieme più ristretto dal server. Il bridge conserva la rotta predefinita in quel progetto, e il DNS diventa la decisione successiva: l'inoltro di dnsmasq a un resolver di casa ha senso solo per i nomi che vivono davvero lì.

Decidete la storia dell'inoltro e del NAT

Il tunnel completo richiede l'inoltro abilitato sul Pi e un gateway dall'altra parte disposto a instradare la sottorete del punto di accesso. Controllate l'inoltro prima di ogni altra cosa, perché uno zero rende irrilevante ogni cambio di rotta.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

La regola NAT è la scorciatoia che funziona quando il server non accetterà il prefisso del punto di accesso, al costo che ogni client appaia come l'indirizzo del tunnel del Pi nei log del lato remoto. Instradare il prefisso senza NAT mantiene gli indirizzi visibili e dipende da una rotta di ritorno per 192.168.50.0/24 sul lato di casa.

Annotate la scelta accanto alle regole del firewall, perché una regola NAT invisibile nel progetto diventa inspiegabile sei mesi dopo. Tenete IPv6 nella stessa decisione; un percorso IPv4 funzionante accanto a un percorso IPv6 rotto si legge ancora come mezzo rotto in un browser.

Verificate da un client, poi tornate indietro in modo pulito

Provate in questo ordine da un telefono o portatile sul punto di accesso: un lease da dnsmasq, un ping all'indirizzo del bridge, poi una destinazione dall'altra parte del tunnel. Ogni passo isola uno strato invece di produrre un singolo guasto inutile.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Poi confermate che il Pi abbia ancora la sua uscita: ip route get 203.0.113.10 dovrebbe nominare il dispositivo sottostante, e ping -c 3 -I br0 203.0.113.10 dovrebbe rispondere se il server consente ICMP. Se i primi due passi del client passano e il terzo fallisce, il guasto è nell'inoltro o nel NAT. Se fallisce il secondo passo, il bridge o il DHCP sono ancora incompleti.

Il rollback è una modifica a un file e due comandi: rimuovete la stanza, riavviate dhcpcd e sostituite la rotta predefinita esplicitamente con ip route replace default via 192.168.50.1 dev br0. Fatelo prima che la finestra di manutenzione si chiuda e non dopo, perché un Pi che ha perso la rotta predefinita è irraggiungibile dalla rete che usereste per ripararlo.