Client OpenVPN in bridge senza internet? Controllate la regola NAT

Il server in bridge è attivo, la regola masquerade c’è, e il browser sul client continua a girare. Tutto sembra dover funzionare, ed è per questo che la prima ora se ne va a controllare il tunnel e le credenziali. Poi leggete il contatore sulla regola NAT e trovate uno zero che non si è mosso. Una regola che non ha mai contato un pacchetto non ne ha mai incontrato uno, e su un server in bridge la ragione è strutturale: il traffico del client esce dal dispositivo virtuale tap, mentre la regola nomina la scheda fisica che avete copiato da una guida più vecchia.

Il contatore è la prova, non la riga della tabella

Le regole che esistono e le regole che corrispondono sono cose diverse, e il contatore le separa. Elencate la tabella NAT con contatori dettagliati e leggete i numeri accanto a ogni regola prima di cambiare qualcosa. Un contatore fermo a zero mentre il traffico scorre significa che la regola è stata saltata, per quanto sensati appaiano i suoi indirizzi. Un contatore che sale mentre la connessione continua a fallire vi manda altrove: l’inoltro, il percorso di ritorno o l’estremità remota.

iptables -t nat -L POSTROUTING -v -n

Leggete prima il contatore accanto alla corrispondenza dell’interfaccia. Se l’intervallo di origine è corretto e il lato di uscita è sbagliato, la correzione è una parola nella regola, non una regola del tutto nuova.

Trovate il nome che il kernel registra davvero

Identificate il dispositivo del tunnel per nome prima di scrivere la regola, usando l’elenco delle interfacce e non la memoria. In un’installazione OpenVPN in bridge il dispositivo è di solito un’interfaccia tap creata dal server, e il suo nome fa parte della vostra configurazione locale, non è una costante universale. Confermate che esista mentre il tunnel è attivo, perché un dispositivo che compare solo dopo la connessione di un client farà sembrare un test precedente un problema di regola.

ip -brief link

Annotate il nome. Ogni comando successivo di questa diagnosi vi fa riferimento, e un errore di battitura qui produce esattamente lo stesso contatore nullo dell’errore originale.

Riscrivete la regola sul dispositivo del tunnel

Puntate la regola al dispositivo del tunnel e mantenete l’intervallo dei client come condizione di corrispondenza, così copre il traffico del tunnel e lascia in pace le connessioni proprie dell’host. Sostituite con il vostro intervallo e il nome del vostro dispositivo, perché entrambi gli esempi sotto sono esempi e nessuno è trasferibile tra installazioni.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

Poi controllate le altre due condizioni che lo stesso sintomo nasconde. Controllate se l’inoltro è abilitato e, se non lo è, abilitatelo nella configurazione della distribuzione invece che con un echo che sparisce al riavvio. Leggete anche i contatori della catena forward e, se scarta il traffico del tunnel, permettete specificamente quell’interfaccia e lasciate intatta la politica della catena.

Leggere la catena forward con i contatori costa un comando ed esclude metà delle possibilità rimanenti prima di toccare un’altra regola.

Perché la scheda fisica non corrisponde mai

Un bridge è uno switch software composto dal dispositivo tap e da un’interfaccia fisica. Il frame del client entra in quello switch ed esce verso la rete fisica come membro del bridge, non come pacchetto sulla scheda. Per questo il kernel attribuisce il pacchetto al bridge e alla sua porta, ed è per questo che la scheda a cui pensavate non compare mai nella corrispondenza. L’interfaccia fisica non ha nulla di rotto; semplicemente non è il dispositivo a cui il kernel attribuisce quel pacchetto.

Il problema successivo che la gente incontra viene dalla stessa struttura: il filtraggio dei frame su un bridge è un meccanismo separato dal filtraggio IP. Se il requisito è una restrizione a livello di frame, appartiene al filtraggio del bridge, non a una regola della tabella IP.

Dimostratelo da un capo all’altro, poi rendetelo permanente

Avviate un solo client e fate ping a qualcosa sulla LAN del server; quel percorso esercita l’inoltro senza alcuna traduzione. Poi richiedete qualcosa di pubblico perché la regola masquerade debba essere usata, e leggete di nuovo il contatore: dovrebbe muoversi per questo test e non per il precedente. Una cattura presa sul dispositivo del tunnel mostra sia dove compare il frame sia quale indirizzo porta.

Ultimo passo: mettete le regole che funzionano nella configurazione che un riavvio legge, e annotate il nome del dispositivo che il bridge di questo host usa davvero. Tutto ciò che è digitato a mano sparisce dopo un riavvio, e lo stesso guasto torna senza nulla che lo spieghi.

Se il contatore non si muove ancora dopo la riscrittura, confrontate l’intervallo di origine della regola con l’indirizzo che il client ha ricevuto davvero, perché un server in bridge può distribuire indirizzi da un intervallo che non intendevate.