¿Los clientes OpenVPN puenteados no tienen internet? Revise la regla NAT

El servidor puenteado está activo, la regla masquerade está presente y el navegador del cliente sigue girando. Todo parece que debería funcionar, y por eso la primera hora se va en comprobar el túnel y las credenciales. Después lee el contador de la regla NAT y encuentra un cero que no se ha movido. Una regla que nunca contó un paquete nunca coincidió con ninguno, y en un servidor puenteado la razón es estructural: el tráfico del cliente sale por el dispositivo virtual tap, mientras que la regla nombra la tarjeta física que copió de una guía más antigua.

El contador es la prueba, no la fila de la tabla

Las reglas que existen y las reglas que coinciden son cosas distintas, y el contador es lo que las separa. Liste la tabla NAT con contadores detallados y lea los números junto a cada regla antes de cambiar nada. Un contador parado en cero mientras el tráfico fluye significa que la regla se saltó, por razonables que parezcan sus direcciones. Un contador que sube mientras la conexión sigue fallando le manda a otro sitio: el reenvío, el camino de vuelta o el extremo remoto.

iptables -t nat -L POSTROUTING -v -n

Lea primero el contador junto a la coincidencia de interfaz. Si el rango de origen es correcto y el lado de salida es incorrecto, la corrección es una palabra en la regla y no una regla completamente nueva.

Encuentre el nombre que el núcleo registra realmente

Identifique el dispositivo del túnel por su nombre antes de escribir la regla, usando la lista de interfaces en lugar de la memoria. En una instalación OpenVPN puenteada el dispositivo suele ser una interfaz tap creada por el servidor, y su nombre forma parte de su configuración local, no es una constante universal. Confirme que existe mientras el túnel está activo, porque un dispositivo que solo aparece tras conectarse un cliente hará que una prueba anterior parezca un problema de regla.

ip -brief link

Anote el nombre. Cada comando posterior de este diagnóstico se refiere a él, y una errata aquí produce exactamente el mismo contador nulo que el error original.

Reescriba la regla contra el dispositivo del túnel

Apunte la regla al dispositivo del túnel y mantenga el rango de clientes como condición de coincidencia, de modo que cubra el tráfico del túnel y deje en paz las conexiones propias del equipo. Sustituya su propio rango y nombre de dispositivo, porque los dos ejemplos de abajo son ejemplos y ninguno es portable entre instalaciones.

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

Después compruebe las otras dos condiciones que esconde el mismo síntoma. Compruebe si el reenvío está habilitado y, si no lo está, habilítelo en la configuración propia de la distribución en vez de con un echo que desaparece al reiniciar. Lea también los contadores de la cadena forward y, si descarta el tráfico del túnel, permita esa interfaz en concreto y deje la política de la cadena intacta.

Leer la cadena forward con contadores cuesta un comando y descarta la mitad de las posibilidades restantes antes de tocar otra regla.

Por qué la tarjeta física nunca coincide

Un puente es un conmutador de software compuesto por el dispositivo tap y una interfaz física. La trama del cliente entra en ese conmutador y sale hacia la red física como miembro del puente, no como un paquete en la tarjeta. Por eso el núcleo atribuye el paquete al puente y a su puerto, y por eso la tarjeta que tenía en mente nunca aparece en la coincidencia. La interfaz física no tiene nada roto; simplemente no es el dispositivo al que el núcleo atribuye ese paquete.

El siguiente problema con el que la gente tropieza viene de la misma estructura: el filtrado de tramas en un puente es un mecanismo aparte del filtrado IP. Si el requisito es una restricción a nivel de trama, pertenece al filtrado del puente, no a una regla de la tabla IP.

Demuéstrelo de principio a fin y luego hágalo permanente

Levante un solo cliente y haga ping a algo en la LAN del servidor; esa ruta ejercita el reenvío sin ninguna traducción. Después pida algo público para que la regla masquerade tenga que usarse, y lea el contador una vez más: debería moverse para esta prueba y no para la anterior. Una captura tomada en el dispositivo del túnel muestra a la vez dónde aparece la trama y qué dirección lleva.

Último paso: ponga las reglas que funcionan en la configuración que lee un reinicio y anote el nombre del dispositivo que el puente de este equipo usa realmente. Todo lo escrito a mano desaparece tras un reinicio, y el mismo fallo vuelve sin nada que lo explique.

Si el contador sigue sin moverse tras reescribir la regla, compare el rango de origen de la regla con la dirección que el cliente recibió realmente, porque un servidor puenteado puede repartir direcciones de un rango que usted no pretendía.