Bloquear un cliente OpenVPN da LAN sen deter o túnel

Un cliente do teu servidor OpenVPN ten que perder o acceso á LAN mentres o resto de túneles seguen activos. Se o buscas, a resposta principal adoita dicir que o daemon non pode facelo, o que só é medio certo: OpenVPN non ten cortalumes por cliente, pero o host que remata o túnel xa filtra paquetes. As dúas decisións que importan son a identidade que bloqueas e a posición da regra. Acerta con ambas e o cambio convértese nunha liña que podes probar e retirar.

Fixa o cliente antes de escribir a regra

OpenVPN asigna enderezos de túnel desde un grupo, así que 10.8.0.6 é un asento, non unha persoa. Cando remata a sesión o alugueiro volve e pode entregarse á seguinte conexión, o que significa que unha regra escrita contra ese enderezo segue o asento, non o usuario. Decide primeiro que bloqueas de verdade: un enderezo para un experimento curto ou un certificado para alguén a quen queres deixar fóra.

Para vincular o enderezo ao certificado, crea un ficheiro no directorio que indica client-config-dir e dálle exactamente o common name do certificado. Pon dentro unha directiva, ifconfig-push 10.8.0.6 255.255.255.0, e ese cliente conserva o mesmo enderezo de túnel entre reconexións. Deben existir dous axustes para que isto teña efecto: client-config-dir ten que estar declarado na configuración do servidor e o enderezo enviado debe estar nunha subrede que o servidor poida encamiñar. Se falta un, o ficheiro ignórase sen erro, o que fai enganosa a seguinte proba de cortalumes.

Un bloqueo temporal pode usar un enderezo do grupo, sempre que o ticket rexistre que sesión o tiña naquel momento.

A orde decide se o descarte se executa

Nunha pasarela Linux que reenvía entre o túnel e a LAN, os paquetes cruzan a cadea FORWARD. Le o comando de abaixo como unha frase: insire na cabeza de FORWARD, coincide co tráfico que entra desde tun0, dese único host, dirixido á subrede da LAN, e descártao.

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

O -I é o que fai que a regra se execute. Engadida con -A, cae por baixo de calquera aceptación ampla para a subrede do túnel e nunca ve un paquete. Verifica a posición con iptables -vnL FORWARD --line-numbers e le tamén os contadores: un descarte arriba que non conta nada significa que o tráfico chega por outro camiño.

O propio enderezo LAN da pasarela é outro camiño. Os paquetes enviados á máquina van a INPUT, non a FORWARD, así que un cliente pode perder un host da LAN e aínda abrir a páxina de administración do router. Engade a regra INPUT correspondente cando iso importe.

O que o filtro non pode ver

A filtragem ocorre cando se avalía un paquete, así que unha sesión TCP establecida pode continuar ata que se peche ou se restableza. Se o bloqueo debe morder de inmediato, limpa os fluxos rastrexados desa orixe con conntrack -D -s 10.8.0.6 despois de poñer a regra. Se uns segundos de solapamento son aceptables, rexistra esa escolla en vez de deixala implícita. De calquera xeito, a seguinte persoa necesita saber se a regra detén o tráfico vivo ou só as conexións novas.

O tráfico entre pares nunca toca o cortalumes do host. Con client-to-client activado, OpenVPN reenvía eses paquetes dentro do daemon, así que nin FORWARD nin INPUT os ven. As únicas solucións son desactivar client-to-client ou aceptar que os pares poden alcanzarse; unha regra de iptables non verá ese tráfico.

IPv6, firmware e supervivencia ao reinicio

Unha regra IPv4 non di nada sobre IPv6. Se o túnel e a LAN levan ambas as familias, a regra equivalente debe existir en ip6tables, ou no conxunto de regras nftables que posúe a política nese host. O firmware do router adoita agochar netfilter tras a súa propia abstracción, así que a sintaxe e os nomes de táboa copiados dun foro poden non aplicarse.

En OpenWrt, o camiño documentado é unha entrada de configuración do cortalumes e non unha liña de iptables escrita a man, e unha liña escrita a man pode desaparecer cando o cortalumes se recarga. Outras distribucións restauran as regras mediante netfilter-persistent, unha unidade de arranque ou un almacén do fabricante, e eses mecanismos non son intercambiables. Proba o que escolleses cun reinicio, porque unha recarga exercita un camiño distinto.

Verifica por camiño e despois reverte limpo

Proba cada camiño por separado, porque unha comprobación correcta agocha as demais. Un cliente bloqueado debería seguir chegando a internet polo túnel mentres falla contra un host da LAN, un segundo cliente debería chegar a ese mesmo host, e o enderezo da pasarela e o camiño entre pares necesitan cada un a súa propia observación. Escribe os resultados xunto á regra para que o seguinte cambio teña unha base. A táboa de abaixo é o conxunto que paga a pena gardar no ticket.

A reversión é un borrado por especificación, non un flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP elimina exactamente esa entrada e deixa intacto o resto da cadea. Retira a mesma liña do ficheiro que restaura as regras no arranque, recárgao e confirma que o cliente volve chegar ao host da LAN. Un flush de FORWARD tamén desfaría regras que non escribiches, o que converte unha reversión nun segundo incidente.

Antes de pechar o ticket, confirma tres cousas: o enderezo fixado coincide co certificado, a regra está por riba das aceptacións cun contador distinto de cero e o ficheiro de persistencia contén a mesma regra que probaches. Se falta algunha, o bloqueo é unha ilusión de sesión de shell.