Cómo bloquear la salida de Linux para que no se filtre nada cuando cae la VPN

Imagina una caja multimedia en un enlace doméstico que solo debería llegar a internet a través de un túnel. Cuando el túnel cae, la aplicación debería detenerse en lugar de continuar en silencio por la interfaz física. Conseguir ese comportamiento es un problema de cortafuegos y no de enrutamiento, y la distinción importa porque una ruta se puede sustituir reiniciando el demonio, mientras que un filtro se queda donde lo pusiste. A continuación verás cómo decide realmente la ruta del paquete y luego cómo acotar las excepciones que mantienen el túnel reconectando.

La salida local es un gancho distinto del reenvío

Un paquete que sale de una aplicación del equipo atraviesa el gancho de salida; un paquete que el equipo enruta para otro host atraviesa el reenvío. Una política que solo menciona forward restringe el segundo y deja el primero completamente abierto, y por eso tantos bloqueos de salida parecen correctos y no hacen nada. La coincidencia de interfaz pertenece a la misma regla: oifname "tun0" accept deja pasar el tráfico que ya se ha enrutado por el túnel. Enrutamiento y filtrado también siguen siendo decisiones separadas, así que puede existir una ruta de enlace mientras el filtro rechaza el paquete. Esa separación es el mecanismo en el que confías.

Una puerta de enlace que reenvía para otros dispositivos necesita ambos ganchos. Bloquear solo la salida protege al equipo y deja a cada cliente aguas abajo libre para filtrar.

Escribe la lista de excepciones desde el extremo hacia fuera

Empieza por el extremo del túnel: una dirección de destino o un conjunto pequeño aprobado, el protocolo de transporte y el puerto de destino, por ejemplo udp dport 1194 ip daddr 203.0.113.7 accept. Si el cliente resuelve un nombre de host, el intercambio DNS inicial necesita su propia regla limitada al resolver y al puerto 53, no un permiso general a la dirección de ese resolver. Cada excepción debería nombrar el motivo por el que existe. Un permiso para todo el tráfico UDP hacia el puerto de la VPN cubre mucho más que el único servicio autenticado que tenías en mente.

La resolución inicial es donde suelen pudrirse los bloqueos. Un conjunto de direcciones que se refresca con un temporizador necesita un comportamiento definido cuando el refresco falla, y ese comportamiento no puede ser abrir el enlace hasta que funcione. Refresca por el túnel mientras el túnel está levantado y, en caso contrario, vuelve al último extremo bueno conocido.

La administración local necesita el mismo trato. Una subred de gestión no es fiable solo porque sus direcciones sean privadas, y una regla que confía en ella invita a un segundo camino alrededor del bloqueo.

Coincidir la interfaz no demuestra un túnel sano

Las reglas que aceptan todo lo que sale de tun0 suponen que un paquete en esa interfaz vino del túnel. Los nombres de interfaz se recrean, y un nombre no es una identidad criptográfica. El par también puede haberse ido mientras la interfaz sigue levantada, lo que convierte la regla en una no-operación muy convincente.

El seguimiento de conexiones añade una trampa relacionada. Una regla amplia de conexiones establecidas reproduce el permiso que un flujo obtuvo antes, así que una sesión iniciada antes de que cayera el túnel sigue funcionando después. Restringe la aceptación con estado a las interfaces y direcciones que realmente quieres, o habrás construido un bloqueo que se abre solo. Las reglas de entrada y de salida también responden preguntas distintas, y endurecer una ignorando la otra deja el equipo accesible en la dirección que no consideraste.

Qué sobrevive a una caída del demonio

Un filtro instalado por un script que se ejecuta después de que suba el túnel desaparece con el túnel, justo en el momento en que hacía falta. Carga el bloqueo al arrancar y deja que el demonio gestione solo sus excepciones.

Borrar la ruta por defecto tampoco es un sustituto. La ruta es estado que el demonio posee y reescribe, y eliminarla puede quitar el camino necesario para reconectar. IPv6 necesita su propio plan, porque el descubrimiento de vecinos y los anuncios de router son servicios de enlace que deben seguir funcionando mientras el tráfico ordinario está bloqueado. DHCP pertenece a la misma categoría. Anota estas cosas como excepciones con un propósito, en lugar de descubrirlas después como caídas.

Camino de recuperación antes del despliegue

Prueba el bloqueo tal como fallará: arrancar sin túnel, matar el demonio, cambiar el extremo y reconectar. Cada caso debería detener las aplicaciones y dejar el canal de recuperación funcionando. Hazlo desde una consola, porque un shell remoto es la sesión que más probablemente quede bloqueada por tu propia regla.

Después comprueba a qué puede llegar todavía una aplicación corriente, con un destino inocuo y una petición que puedas verificar. El resultado que quieres es un rechazo en el enlace y un éxito por el túnel, no un tiempo de espera ambiguo que podría significar cualquiera de las dos cosas. Mantén el conjunto de reglas bajo el mismo propietario que el resto del cortafuegos, en lugar de sustituir toda la tabla desde un script de shell. Una política en la que cada permiso puede justificarse vale más que un conjunto largo de reglas que nadie sabe explicar.