Por qué el NAT doméstico no protege tu interfaz VPN
Un router doméstico reenvía el túnel, pero el host juzga el paquete descifrado. Lee el escucha, la ruta interna y la política de entrada por separado.
Los portátiles detrás de un router doméstico sin redirección de puertos siguen aceptando conexiones SSH que llegan por la VPN. No es una contradicción, porque dos dispositivos distintos juzgan dos paquetes distintos. El router reenvía el transporte cifrado y el host decide qué hacer con el paquete descifrado que llega a su interfaz de túnel. Mantener esas dos decisiones separadas es todo el ejercicio.
El router reenvía el túnel, el host juzga el paquete
Dibuja el camino desde el origen remoto hasta el servicio antes de mirar una sola regla. El tramo exterior es el transporte VPN, que manejan el router y la puerta de enlace. El tramo interior empieza cuando el extremo quita la capa del túnel y el host recibe un paquete dirigido a su dirección VPN.
Une esos dos tramos y el router se lleva el mérito de una decisión que toma el host. Una página de redirección de puertos o un registro del router describen solo conversaciones exteriores, y ninguno dice qué tráfico descifrado aceptará el host. El host aplica su propia política de entrada al paquete interior, igual que a cualquier paquete que llegue a una interfaz. En esa política se dirime realmente la cuestión de la exposición.
Un escucha comodín no es un servicio público
En Linux, enlazar con INADDR_ANY significa toda dirección local, así que un servicio puede responder en una interfaz de túnel que nunca nombró. La referencia de sockets IP describe ese enlace, y vale la pena leerla antes de sacar conclusiones de una lista de escuchas. Una entrada comodín es un hecho sobre el socket, no una afirmación sobre la alcanzabilidad.
Las dos líneas de abajo son el mismo servicio en dos enlaces distintos, y la diferencia es toda la respuesta a si la interfaz importa. Lee en qué dirección se asienta el socket antes que nada.
ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))
Nombra la disposición que podría alcanzar el puerto
Tres disposiciones ponen un paquete en esa interfaz, y tienen dueños distintos. Nombrar la correcta decide quién debe cambiar una política.
| Arrangement | What reaches the port | Where the decision lives |
|---|---|---|
| Another permitted VPN peer | A packet from the same tunnel subnet | Gateway forwarding policy and host input rules |
| A deliberate public forward | Traffic the gateway publishes on purpose | Gateway service definition |
| A subnet routed behind the gateway | Client traffic from the far side | Gateway route and host input rules |
Un resultado del navegador que muestra una dirección de salida pública no dice nada de ninguna de las tres, porque describe cómo sale el tráfico de salida y no qué se permite al tráfico de entrada. Trabaja hacia atrás desde el escucha y la dirección de origen en el registro del servicio. Si el origen es otro par del túnel, la política de la puerta de enlace es el documento interesante. Si es una dirección traducida, encuentra la traducción antes de cambiar una regla.
Acota el servicio al camino que pretendías
Si SSH solo se necesita desde un camino de gestión, escribe ese camino como un rango de origen más una interfaz. Luego acota las reglas de entrada del host por interfaz, destino y origen en lugar de por nombre de red, ya que un nombre que parece privado puede representar cualquier dirección. Deja una ruta para quien arreglará el próximo problema.
nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter input
Una regla que nombra la interfaz del túnel y el rango de gestión declara la intención en un solo lugar. Compárala con una regla escrita para la red Wi-Fi, que no dice nada del tráfico descifrado del túnel. Cuando las dos capas no coinciden, la política del host es la que encuentra el paquete.
Deja los inicios de sesión y los parches exactamente donde están; alcanzar un puerto nunca fue lo mismo que tener permiso para usarlo. Anota la familia de direcciones y la hora de cualquier origen desconocido, e investiga antes de culpar a una función o a una vulnerabilidad. Una regla que admite a cada par del túnel es un diseño distinto de una que admite una subred de gestión, y ninguna línea de registro dirá cuál se pretendía.
Acepta la corrección con un éxito y un rechazo
Prueba las dos mitades: una conexión aprobada tiene éxito y un camino excluido es rechazado. El rechazo es la mitad que la gente se salta, y es la que muestra que la regla trabaja en lugar de estar junto a un valor por defecto permisivo. Prueba desde el lado excluido en lugar de razonar sobre ello.
Repite el par tras una reconexión, porque un túnel que vuelve con otro nombre de interfaz puede saltarse en silencio una regla acotada al antiguo. La frontera que importa es la que el host aplica a los paquetes que realmente recibe.