Elija el punto de observación correcto para un escaneo de VPN en el teléfono

Una evaluación autorizada de una VPN alojada en un teléfono falla en silencio cuando el escáner se sitúa en el lado equivocado del túnel. Se obtienen resultados, parecen plausibles y responden a una pregunta que nadie formuló. Recorra las cinco comprobaciones siguientes en orden. Cada una tiene una condición de parada, y detenerse antes es más barato que volver a probar desde cero después de escribir el informe.

Paso 1: nombre la superficie que pretende alcanzar

Tres superficies se confunden habitualmente porque un solo dispositivo las conecta. Ejecutan código y políticas distintas, así que anote cuál está dentro del alcance antes de empezar nada.

Si el alcance aprobado no dice cuál de las tres, deténgase y pregunte. Obtener root en el teléfono no responde a esta pregunta y cambia la cosa sometida a prueba, no el punto de observación.

Anote los objetivos, las direcciones de origen permitidas, la ventana temporal y el límite de intensidad al mismo tiempo. El túnel le lleva hasta ese alcance; no le autoriza a sondear todo lo que puede enrutar.

Paso 2: elija el origen que puede ver esa superficie

Un escáner situado dentro de la VPN no puede reproducir un observador de internet no autenticado. Ya tiene rutas, credenciales y permisos de los que carece el observador externo, así que sus resultados describen la visión posterior a la admisión incluso cuando la superficie objetivo es la misma. El error inverso es igual de común. Un escaneo público del puerto VPN no dice casi nada sobre un servicio privado tras el inicio de sesión, y presentarlo como si lo dijera exagera la exposición en una dirección y la minimiza en la otra.

Deténgase si el origen que puede obtener no coincide con la superficie. Una evaluación ejecutada desde un par dentro del túnel no debe presentarse como resultado previo a la autenticación, y una prueba que requiere un origen externo aprobado no debe trasladarse en silencio hacia dentro para evitar el papeleo.

Paso 3: confirme la ruta y el camino de respuesta a través del teléfono

Cuando el teléfono reenvía a otra subred, el escáner necesita una ruta permitida y el objetivo necesita un camino de retorno que funcione. Confirme ambos en lugar de suponer que una respuesta de ping significa que el camino está completo.

ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8

El NAT de origen cambia lo que ve el servicio posterior. Si el teléfono traduce la dirección del escáner, las reglas de acceso y los registros del objetivo se aplican a la dirección traducida, así que un servicio que parece aceptarle puede estar aceptando al teléfono y no al escáner.

Vigile también una superposición con la red del propio escáner. Si el teléfono enruta 192.168.1.0/24 y el escáner está en una LAN numerada de la misma forma, las sondas alcanzan dispositivos locales y el informe los describe como el objetivo. Compruebe la ruta que usaría el propio escáner antes de enviar un solo paquete.

Escanee la dirección real del objetivo y conserve el nombre de host que la aplicación necesita para la identidad TLS y el alojamiento virtual. Alcanzar una puerta de enlace demuestra que la puerta responde; no prueba el servicio que hay detrás.

Paso 4: trate el descubrimiento como una sonda con supuestos

El descubrimiento de hosts es donde los resultados de la evaluación fallan con más frecuencia. El descubrimiento local por Ethernet no cruza una VPN enrutada, así que las sondas que funcionan en una LAN plana simplemente no llegan. Las sondas de descubrimiento bloqueadas hacen entonces que un servicio accesible y autorizado parezca ausente.

Decida conscientemente si omite el descubrimiento y escanea las direcciones conocidas directamente, y dígalo en el informe. Un puerto que responde no es prueba de que la autenticación de VPN haya tenido éxito, y una respuesta filtrada no es prueba de que nada escuche. El ritmo forma parte del mismo problema. Un teléfono que limita o descarta paquetes bajo un escaneo rápido produce estados filtrados que pertenecen al teléfono y no al servicio, así que reduzca la concurrencia y vuelva a escanear antes de registrar un puerto como cerrado.

La condición de parada aquí es de interpretación, no de técnica: si no puede decir qué significa un estado para este camino, el resultado pertenece a un apéndice y no a las conclusiones.

Paso 5: mantenga la ventana y luego ciérrela

Un teléfono es un mal servidor porque está diseñado para dormir. La optimización de batería, el doze y la gestión de energía del Wi-Fi pueden suspender la aplicación a mitad de la evaluación, y una reconexión del túnel puede cambiar la dirección que usa el objetivo. Una ejecución que atraviesa uno de esos eventos tiene una ventana de resultados no válida.

Mantenga el rol de puerta de enlace en el alcance más pequeño que permita la tarea aprobada, observe el túnel mientras la ejecución está activa y registre el inicio y el final de cada ventana que informe. Cuando termine la evaluación, retire el acceso temporal a través de su propietario, conserve el registro de origen y ruta y proteja la salida como cualquier otro artefacto de prueba.

Si necesita un punto de observación repetible en lugar de un éxito puntual, esa es la entrega por la que merece la pena argumentar. la referencia sobre el descubrimiento de hosts explica qué sondas presuponen un segmento local, y ese es el detalle que convierte un resultado vacío en una afirmación defendible.