Bloquejar un client OpenVPN de la LAN sense aturar el túnel
Fixa l'adreça de túnel del client al seu certificat, descarta el seu trànsit de LAN al capdavant de FORWARD i després verifica IPv6, les sessions rastrejades i la supervivència al reinici.
Un client del teu servidor OpenVPN ha de perdre l'accés a la LAN mentre la resta de túnels continuen actius. Si ho busques, la resposta principal sol dir que el dimoni no ho pot fer, cosa que només és mig certa: OpenVPN no té tallafoc per client, però l'amfitrió que acaba el túnel ja filtra paquets. Les dues decisions que importen són la identitat que bloques i la posició de la regla. Encerta-ho i el canvi es converteix en una línia que pots provar i eliminar.
Fixa el client abans d'escriure la regla
OpenVPN assigna adreces de túnel d'un pool, així que 10.8.0.6 és un seient, no una persona. Quan la sessió acaba, el lloguer torna i es pot lliurar a la connexió següent, cosa que significa que una regla escrita contra aquesta adreça segueix el seient, no l'usuari. Per tant, decideix primer què bloques realment: una adreça per a un experiment curt o un certificat per a algú que vols mantenir fora.
Per lligar l'adreça al certificat, crea un fitxer al directori que indica client-config-dir i dona-li exactament el common name del certificat. Hi poses una directiva, ifconfig-push 10.8.0.6 255.255.255.0, i aquell client conserva la mateixa adreça de túnel entre reconnexions. Calen dos ajustos perquè això tingui efecte: client-config-dir ha d'estar declarat a la configuració del servidor i l'adreça enviada ha de ser en una subxarxa que el servidor pugui encaminar. Si en falta un, el fitxer s'ignora sense cap error, cosa que fa enganyosa la prova de tallafoc següent.
Un bloc temporal pot fer servir una adreça del pool, sempre que el tiquet registri quina sessió la tenia en aquell moment.
L'ordre decideix si el descart s'executa
En una passarel·la Linux que reenvia entre el túnel i la LAN, els paquets travessen la cadena FORWARD. Llegeix l'ordre de sota com una frase: insereix al capdavant de FORWARD, coincideix amb el trànsit que entra des de tun0, d'aquell únic amfitrió, adreçat a la subxarxa de la LAN, i descarta'l.
iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROPEl -I és el que fa córrer la regla. Afegida amb -A, cau sota qualsevol acceptació àmplia per a la subxarxa del túnel i no veu mai cap paquet. Verifica la posició amb iptables -vnL FORWARD --line-numbers i llegeix també els comptadors: un descart a dalt que no compta res vol dir que el trànsit arriba per un altre camí.
L'adreça LAN pròpia de la passarel·la és un camí diferent. Els paquets enviats a la mateixa caixa van a INPUT, no a FORWARD, així que un client pot perdre un amfitrió de la LAN i encara obrir la pàgina d'administració del router. Afegeix la regla INPUT corresponent quan això importi.
Què no pot veure el filtre
El filtratge passa quan s'avalua un paquet, així que una sessió TCP establerta pot continuar fins que es tanca o es reinicia. Si el bloc ha de mossegar de seguida, neteja els fluxos rastrejats d'aquella font amb conntrack -D -s 10.8.0.6 després de posar la regla. Si uns quants segons de solapament són acceptables, enregistra aquesta decisió en lloc de deixar-la implícita. De qualsevol manera, la persona següent ha de saber si la regla atura el trànsit viu o només les connexions noves.
El trànsit entre parells no toca mai el tallafoc de l'amfitrió. Amb client-to-client activat, OpenVPN reenvia aquests paquets dins del dimoni, així que ni FORWARD ni INPUT els veuen. Les úniques solucions són desactivar client-to-client o acceptar que els parells es poden abastar; una regla d'iptables no veurà aquest trànsit.
IPv6, firmware i supervivència al reinici
Una regla IPv4 no diu res sobre IPv6. Si el túnel i la LAN porten totes dues famílies, la regla equivalent ha d'existir a ip6tables, o al conjunt de regles nftables que posseeix la política en aquell amfitrió. El firmware del router sovint amaga netfilter darrere la seva pròpia abstracció, així que la sintaxi i els noms de taula copiats d'un fòrum poden no aplicar-se.
A OpenWrt, el camí documentat és una entrada de configuració del tallafoc i no una línia d'iptables escrita a mà, i una línia escrita a mà pot desaparèixer quan el tallafoc es recarrega. Altres distribucions restauren les regles amb netfilter-persistent, una unitat d'arrencada o un magatzem del fabricant, i aquests mecanismes no són intercanviables. Prova el que hagis triat amb un reinici, perquè una recàrrega exerceix un camí diferent.
Verifica per camí i després reverteix net
Prova cada camí per separat, perquè una comprovació correcta amaga les altres. Un client bloquejat hauria d'arribar encara a internet pel túnel mentre falla contra un amfitrió de la LAN, un segon client hauria d'arribar a aquell mateix amfitrió, i l'adreça de la passarel·la i el camí entre parells necessiten cadascun la seva observació. Escriu els resultats al costat de la regla perquè el canvi següent tingui una base. La taula de sota és el conjunt que val la pena guardar al tiquet.
| Camí | Esperat amb la regla | Quan falla |
|---|---|---|
| Client bloquejat a un amfitrió de la LAN | Cap resposta | La regla és sota una acceptació, o la font no coincideix |
| Client bloquejat a internet | Funciona per tun0 | La regla és massa àmplia, sense coincidència de destí |
| Segon client al mateix amfitrió de la LAN | Funciona | La regla ha coincidit amb més que l'amfitrió previst |
| Client bloquejat a l'adreça LAN de la passarel·la | Bloquejat només amb la regla INPUT corresponent | Falta la regla INPUT |
| Client bloquejat a una adreça de túnel d'un parell | Encara funciona | client-to-client està activat i fora de l'abast del tallafoc |
La reversió és una eliminació per especificació, no un flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP elimina exactament aquella entrada i deixa la resta de la cadena intacta. Treu la mateixa línia del fitxer que restaura les regles a l'arrencada, recarrega'l i confirma que el client torna a arribar a l'amfitrió de la LAN. Fer un flush de FORWARD també desfaria regles que no has escrit, cosa que converteix una reversió en un segon incident.
Abans de tancar el tiquet, confirma tres coses: l'adreça fixada coincideix amb el certificat, la regla és per sobre de les acceptacions amb un comptador diferent de zero, i el fitxer de persistència conté la mateixa regla que has provat. Si en falta alguna, el bloc és una il·lusió de sessió de shell.