Bloccare un client OpenVPN dalla LAN senza fermare il tunnel

Un client sul tuo server OpenVPN deve perdere l'accesso alla LAN mentre tutti gli altri tunnel restano attivi. Se lo cerchi, la risposta migliore di solito dice che il demone non può farlo, il che è solo mezzo vero: OpenVPN non ha un firewall per client, ma l'host che termina il tunnel filtra già i pacchetti. Le due decisioni che contano sono l'identità che blocchi e la posizione della regola. Se le azzecchi, la modifica diventa una riga che puoi provare e rimuovere.

Fissa il client prima di scrivere la regola

OpenVPN assegna indirizzi di tunnel da un pool, quindi 10.8.0.6 è un posto, non una persona. Quando la sessione finisce il noleggio torna e può essere dato alla connessione successiva, il che significa che una regola scritta contro quell'indirizzo segue il posto, non l'utente. Decidi quindi prima cosa blocchi davvero: un indirizzo per un esperimento breve, o un certificato per qualcuno che vuoi tenere fuori.

Per legare l'indirizzo al certificato, crea un file nella directory indicata da client-config-dir e dai al file esattamente il common name del certificato. Metti dentro una direttiva, ifconfig-push 10.8.0.6 255.255.255.0, e quel client mantiene lo stesso indirizzo di tunnel tra le riconnessioni. Due impostazioni devono esistere perché questo abbia effetto: client-config-dir deve essere dichiarato nella configurazione del server, e l'indirizzo inviato deve stare in una sottorete che il server può instradare. Se ne manca una, il file viene ignorato senza errore, il che rende fuorviante il successivo test del firewall.

Un blocco temporaneo può usare un indirizzo del pool, purché il ticket registri quale sessione lo teneva in quel momento.

L'ordine decide se lo scarto viene eseguito

Su un gateway Linux che inoltra tra il tunnel e la LAN, i pacchetti attraversano la catena FORWARD. Leggi il comando qui sotto come una frase: inserisci in testa a FORWARD, abbina il traffico che entra da tun0, da quell'unico host, indirizzato alla sottorete LAN, e scartalo.

iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP

È il -I che fa girare la regola. Aggiunta con -A, finisce sotto qualsiasi accettazione ampia per la sottorete del tunnel e non vede mai un pacchetto. Verifica la posizione con iptables -vnL FORWARD --line-numbers, e leggi anche i contatori: uno scarto in cima che non conta nulla significa che il traffico arriva per un'altra via.

L'indirizzo LAN del gateway stesso è un'altra via. I pacchetti inviati alla macchina vanno a INPUT, non a FORWARD, quindi un client può perdere un host della LAN e aprire comunque la pagina di amministrazione del router. Aggiungi la regola INPUT corrispondente quando conta.

Cosa il filtro non può vedere

Il filtraggio avviene quando un pacchetto viene valutato, quindi una sessione TCP stabilita può continuare finché non si chiude o viene resettata. Se il blocco deve mordere subito, svuota i flussi tracciati per quella sorgente con conntrack -D -s 10.8.0.6 dopo aver inserito la regola. Se qualche secondo di sovrapposizione è accettabile, registra quella scelta invece di lasciarla implicita. In ogni caso, la persona successiva deve sapere se la regola ferma il traffico vivo o solo le nuove connessioni.

Il traffico tra peer non tocca mai il firewall dell'host. Con client-to-client attivo, OpenVPN inoltra quei pacchetti dentro il demone, quindi né FORWARD né INPUT li vedono. Le uniche soluzioni sono disattivare client-to-client o accettare che i peer possano raggiungersi; una regola iptables non vedrà quel traffico.

IPv6, firmware e sopravvivenza al riavvio

Una regola IPv4 non dice nulla su IPv6. Se il tunnel e la LAN portano entrambe le famiglie, la regola equivalente deve esistere in ip6tables, o nel set di regole nftables che possiede la policy su quell'host. Il firmware del router spesso nasconde netfilter dietro la propria astrazione, quindi sintassi e nomi di tabella copiati da un forum possono non valere.

Su OpenWrt, il percorso documentato è una voce di configurazione del firewall e non una riga iptables scritta a mano, e una riga scritta a mano può sparire quando il firewall si ricarica. Altre distribuzioni ripristinano le regole tramite netfilter-persistent, un'unità di avvio o un archivio del fornitore, e questi meccanismi non sono intercambiabili. Dimostra quello che hai scelto con un riavvio, perché una ricarica esercita un percorso diverso.

Verifica per percorso, poi torna indietro in modo pulito

Prova ogni percorso separatamente, perché un controllo riuscito nasconde gli altri. Un client bloccato dovrebbe ancora raggiungere internet attraverso il tunnel mentre fallisce verso un host della LAN, un secondo client dovrebbe raggiungere quello stesso host, e l'indirizzo del gateway e il percorso tra peer richiedono ciascuno la propria osservazione. Scrivi i risultati accanto alla regola, così la modifica successiva ha una base. La tabella sotto è l'insieme che vale la pena tenere nel ticket.

Il ritorno indietro è una cancellazione per specifica, non un flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP rimuove esattamente quella voce e lascia intatto il resto della catena. Rimuovi la stessa riga dal file che ripristina le regole all'avvio, ricaricalo e conferma che il client raggiunga di nuovo l'host della LAN. Un flush di FORWARD annullerebbe anche regole che non hai scritto, il che trasforma un ritorno indietro in un secondo incidente.

Prima di chiudere il ticket, conferma tre cose: l'indirizzo fissato corrisponde al certificato, la regola sta sopra le accettazioni con un contatore diverso da zero, e il file di persistenza contiene la stessa regola che hai provato. Se ne manca una, il blocco è un'illusione di sessione shell.