¿Pusiste la dirección VPN en la lista blanca y sigue bloqueado? Rastréala

Poner en la lista blanca la dirección que muestra una aplicación VPN rara vez arregla un puerto bloqueado, y el paquete explica por qué. El cortafuegos no ignora tu regla; evalúa una dirección de origen que nada en la pantalla del cliente muestra. Hasta que el destino informe de ese valor, cada edición de la regla es una conjetura.

Empieza por la solicitud que llega al servicio. La dirección del túnel, la dirección de salida y cualquier traducción intermedia siguen siendo hipótesis hasta que el destino confirme una de ellas.

La dirección de la aplicación no es la que llega

Una conexión VPN lleva al menos cuatro direcciones que merece la pena nombrar por separado: el punto final del servidor, la dirección interna del túnel asignada a tu cliente, la dirección local de Wi-Fi o Ethernet y la dirección pública que ve un sitio web después de que el tráfico salga del proveedor. Puede que la ventana del cliente solo muestre la segunda. Nombra las cuatro antes de nombrar una regla. Con túnel dividido, las solicitudes a un destino público pueden saltarse el túnel por completo, así que la sesión que falla no es la que el usuario cree haber iniciado.

Decide cuál de esas cuatro debe permitir la regla y luego verifícala desde el otro lado. Si el requisito es realmente una dirección de oficina, la condición es la ruta más la disposición de salida de ese sitio, y una conexión etiquetada como Office VPN no aporta ninguna de las dos por sí sola.

Recorre una solicitud hasta su límite de filtrado

Confirma la dirección de destino y el puerto que usa el cliente y luego comprueba que este destino sigue la ruta que supones. Un puerto de contenedor publicado, un proxy inverso o una redirección de puerto pueden trasladar la decisión a un host que nunca editaste. Cada uno de esos saltos puede tener su propia política. Establecer primero la ruta te ahorra corregir una regla a la que ningún paquete llega.

En un host Linux autorizado, lee las reglas activas en orden antes de cambiarlas. Los servicios reenviados y los de contenedores suelen saltar a su propia cadena, así que inspecciona el destino del salto y también el veredicto final.

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

Cita el número de regla correspondiente en el ticket. Sin él, el siguiente lector no puede saber qué edición cambió el resultado. Un número de regla sin marca de tiempo sigue siendo ambiguo.

Verifica la ruta con una captura acotada

Una solicitud inocua y una captura estrecha resuelven la pregunta que no deja de reaparecer. Filtra por el puerto de destino y el host investigado, limita el número de paquetes y detén la captura en cuanto se complete la solicitud.

tcpdump -ni any 'tcp dst port 9443' -c 20

Compara tres valores uno al lado del otro: el origen de la captura, el origen que nombra la regla correspondiente y el rechazo que registró la aplicación. Todos pueden diferir, y solo el primero explica una caída decidida por una regla de IP. Una cabecera HTTP reenviada pertenece a la capa del proxy, así que un registro que cita esa cabecera no describe el origen que evaluó el cortafuegos.

Lee el orden de la cadena, no solo la regla

La referencia de iptables documenta el recorrido ordenado, y por eso un permiso situado bajo un rechazo terminal correspondiente nunca rescata el paquete. Una conexión aceptada antes también puede comportarse distinto que una nueva, así que un éxito antiguo no dice nada sobre la regla nueva. Busca el rechazo o la caída por encima de tu permiso antes de suponer que el permiso es incorrecto. Los contadores por regla también te dicen qué regla vio el paquete.

Borrar una regla para ver qué pasa es un cambio, no una observación. Lee los contadores, anota el número de regla y conserva la política original en el registro de cambios. Si una prueba es inevitable, ejecútala en una copia de la cadena.

Cambia la regla que controla su propietario

Actualiza solo la política de origen y de servicio prevista, a través de quien la posea. Una salida traducida compartida puede representar a muchos usuarios a la vez, así que permitir esa dirección no autentica a nadie, y los permisos de la aplicación detrás siguen donde están.

Cuando la dirección no deja de moverse, la respuesta duradera es una salida estable o un canal autenticado, no una lista de excepciones más larga. Anota el origen observado, el puerto de destino y el número de regla.