¿Por qué cambian los resultados del escaneo de puertos tras una salida VPN?
Cambie la salida y un puerto puede responder distinto sin que el servicio se mueva. Separe la observación de la ruta del inventario que realmente necesita.
Ejecute la misma comprobación de puerto desde una línea de oficina y desde una salida VPN, y las dos respuestas pueden discrepar sobre una dirección que nadie cambió. Esa brecha viene de la ruta y de qué host respondió, no de si el servicio está activo o caído. Tres preguntas separan esas explicaciones: qué preguntó realmente la sonda, qué host respondió y qué registró su propio servidor. Recórralas en ese orden y anote cada respuesta antes de pasar a la siguiente.
Corrija la sonda antes de comparar dos ejecuciones
Una palabra de estado solo es comparable con otra palabra de estado cuando ambas salieron del mismo experimento. Cinco campos lo fijan: la dirección de origen que vio el lado remoto, el destino resuelto, el puerto, el tipo de escaneo y la hora. Cambie cualquiera de ellos y habrá hecho un segundo experimento en lugar de medir el primero dos veces.
Compruebe el origen antes que nada, porque un cliente VPN puede estar activo mientras el tráfico aún sale por la interfaz física. Pregunte al lado remoto qué ve y luego pregunte al núcleo qué interfaz eligió:
curl -s https://ifconfig.me
ip route get 203.0.113.20Dos direcciones en redes distintas significan que la explicación ya está en la mano, y el resto de estas comprobaciones solo la confirmarán. Cuando coincidan, capture la sonda con el indicador de motivo activado, para que el estado vuelva ligado a una explicación en lugar de quedarse solo como una palabra desnuda. El tipo de escaneo también pertenece a ese registro, porque describe qué se preguntó y no qué volvió. Un estado sin origen, sin método y sin marca de tiempo no se puede comparar con nada:
nmap -sT -p 443,8443 --reason 203.0.113.20Guarde esa salida junto al registro y no en un búfer de desplazamiento que la siguiente persona no pueda ver. Dos escaneos honestos que discrepan solo son una discusión cuando nadie escribió las condiciones. Con las condiciones fijadas, o los resultados coinciden y la cuestión queda cerrada, o difieren y la diferencia es un hecho sobre la ruta.
Averigüe qué host terminó el apretón de manos
Un apretón de manos completado demuestra que algún host lo completó, y ese host no tiene por qué ser el proceso que tiene en mente. Un balanceador de carga, un proxy inverso o un proxy SYN pueden responder antes de que intervenga el servidor real, lo cual es diseño habitual y no un síntoma. Un certificado válido para el nombre esperado tampoco lo acota, porque un certificado describe una relación de servicio y no dice nada sobre qué máquina terminó la conexión.
La referencia de estados de puerto de Nmap lo considera básico: un estado registra lo que una sonda pudo observar desde donde se envió, no una propiedad del puerto. Lea una palabra de estado así y dos ejecuciones que discrepaban empiezan a parecer coherentes en lugar de contradictorias, mientras la pregunta pasa de si el puerto está abierto a quién estaba delante de él.
Responda la segunda pregunta en el backend y no desde fuera. Un frontend que acepta conexiones y luego no alcanza su upstream produce exactamente la imagen externa de un servicio sano con una aplicación lenta. Solo el registro propio del upstream separa los dos casos:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'La línea del registro muestra la dirección de cliente que la aplicación vio realmente, y el segundo comando muestra si el proceso que mantiene el puerto 443 es su aplicación o algo delante de ella. Si los dos discrepan sobre qué dirección se conectó, está mirando dos tramos de una misma petición y el tíquet debería decirlo.
Compruebe sus propias reglas antes de culpar al túnel
La política deliberada es la razón más común de que un puerto responda en una red y no en otra, y es la explicación menos interesante disponible. Las reglas de acceso existen para permitir un origen y descartar el resto, así que un cambio de salida es exactamente el suceso para el que se escribieron. Por eso un estado distinto a través de una VPN no demuestra que el proveedor inspeccione el tráfico. Demuestra que su dirección de origen ahora es distinta, lo cual es una afirmación mucho menor.
Esas reglas se pueden leer en el servidor, así que léalas en lugar de especular sobre el centro de la red. Enumere las reglas de filtro que mencionen cualquiera de los dos rangos de direcciones y luego compruebe si la conexión llegó siquiera al demonio:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113Un segundo resultado vacío es informativo, porque nada llegó al demonio y la pregunta pertenece a un filtro, a un grupo de seguridad o a la propia ruta. Un acierto significa que el servicio vio su origen y eligió su respuesta, y esa decisión suele estar escrita en una regla que puede leer. Ninguno de los dos resultados sostiene una historia sobre el proveedor, y ambos son más baratos de comprobar que una captura de paquetes.
Lea transporte, certificado y respuesta por separado
Tres capas producen tres observaciones, y una sonda que prueba una de ellas no puede informar sobre las otras dos. Manténgalas como líneas separadas en el registro en lugar de plegarlas en un solo veredicto, porque cada línea falla a su manera y el modo de fallo le dice dónde mirar después.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
Un solo comando produce las tres primeras filas contra un servicio que usted controla. Ponga su salida en el registro junto al escaneo y no en un mensaje de chat:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Lea la salida en orden: el apretón de manos responde la pregunta de transporte, el sujeto del certificado responde la pregunta del nombre y el cuerpo de la respuesta responde la pregunta de la aplicación. Cuando la línea del apretón de manos tiene éxito y la de respuesta no, tiene un frontend con un upstream roto y no un puerto bloqueado. Ese es un tíquet distinto del que abrió, y vale la pena decirlo con claridad.
Termine escribiendo cuatro hechos en el tíquet: dirección de origen, tipo de escaneo, el host que respondió y la hora. Todo lo que una comparación posterior necesita vive en esos cuatro, y quien retome el caso después no tendrá el historial de su terminal. Si no puede rellenar los cuatro, la ejecución no ha terminado.