Bloquear IPv6 para asegurar WireGuard rompe el host

El objetivo es razonable: solo los usuarios del túnel deberían llegar a los servicios de esta máquina. La implementación a la que se recurre es una cadena de entrada IPv6 que descarta todo salvo WireGuard, lo que también descarta el tráfico que mantiene al host unido a su propio enlace. El descubrimiento de vecinos y los mensajes de mantenimiento de ruta no son acceso a servicios, y eliminarlos produce una máquina inalcanzable por motivos ajenos a tu política. El túnel se levanta, los servicios están bien acotados y nada más del enlace funciona.

Tres responsabilidades, un conjunto de reglas

La primera responsabilidad es la operación de la red externa: el host debe seguir unido a su enlace, resolver vecinos y conocer los límites de ruta de ese enlace. La segunda es el oyente cifrado, que acepta UDP en la dirección y el puerto que elegiste. La tercera es el conjunto de servicios descifrados que quieres que alcancen los usuarios del túnel.

Son tres políticas distintas, y solo la segunda y la tercera tienen que ver con la VPN. Un conjunto de reglas que las trata como una sola hereda un modo de fallo en el que apretar la frontera de la aplicación rompe en silencio la unión del host.

Mantenlas en cadenas separadas o al menos en comentarios separados, para que la siguiente persona vea qué línea existe y por qué.

Qué hace ICMPv6 por el host

IPv6 depende de ICMPv6 para mucho más que el eco. La solicitud y el anuncio de vecino sustituyen a ARP y son necesarios para la entrega local. Packet Too Big transporta información de MTU de ruta, e ignorarlo produce transferencias que se atascan con paquetes grandes. Los anuncios de encaminador llevan la ruta por defecto y la información de prefijo cuando el enlace usa configuración automática.

RFC 4890 separa los mensajes que un filtro de host debe permitir de los que son una decisión administrativa, y lo hace en una sección de host distinta de las reglas para un encaminador que reenvía entre redes. Leer solo la sección de reenvío produce una política de entrada demasiado estricta para el host que protege.

La regla práctica es permitir los mensajes esenciales de error y configuración en la interfaz que los necesita, acotados por tipo y origen donde la plataforma lo permita, y tomar una decisión explícita sobre el resto.

Sustituir todo eso por un permiso general de ICMPv6 resuelve el problema de disponibilidad y renuncia al filtrado. Sustituirlo por un descarte general resuelve el problema de filtrado y renuncia al host.

Admite el túnel, luego el servicio

Acepta el transporte WireGuard en la dirección externa prevista y el puerto UDP, y acepta el tráfico de vuelta mediante seguimiento de conexiones. Después permite los servicios de aplicación por la interfaz del túnel, desde las fuentes que realmente autorizas.

Un permiso para el puerto UDP externo no autoriza las peticiones descifradas dentro de él. Esa distinción es el motivo entero por el que la interfaz del túnel aparece en las reglas de servicio.

Lee el conjunto de reglas tal como es, no como lo describe el archivo:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

Un oyente en una dirección física es una exposición separada del mismo servicio en la dirección del túnel. Si la máquina también reenvía tráfico a otra, eso es una decisión de cadena de reenvío y no esta política de entrada, y necesita su propio razonamiento.

Prueba el enlace, no solo el túnel

Un túnel que funciona tras el cambio demuestra menos de lo que parece, porque una entrada de vecino existente y una conexión establecida pueden ocultar un mensaje de control que la política ahora descarta.

Comprueba la unión directamente y luego comprueba que la ruta excluida sigue fallando:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

Una tabla de vecinos que permanece completa tras un reinicio es la señal de que el descubrimiento sigue funcionando. Una tabla que se vacía y nunca se vuelve a llenar es la señal de que la has filtrado. El tercer comando valida la sintaxis del conjunto de reglas sin aplicarlo, algo que vale la pena hacer mientras aún tienes sesión.

Recupera un host del que te has quedado fuera

Antes de cambiar reglas de cortafuegos que transportan tu propia sesión de administración, mantén un segundo canal: una consola, una conexión serie o una reversión programada que elimine las reglas nuevas si no la cancelas.

Si un cambio te deja fuera, la recuperación pasa por ese canal y no por la red que acabas de quitar. Restaura el conjunto de reglas anterior desde una copia guardada, confirma que el host vuelve a ser alcanzable y solo entonces reaplica la política prevista en piezas más pequeñas.

La política final no es universal. El direccionamiento, el enrutamiento y la implementación del cortafuegos son entradas de despliegue, pero la frontera es la misma en todas partes: deniega el acceso no deseado a las aplicaciones mientras mantienes el tráfico de control que transporta el túnel autorizado.