Qué puede y qué no puede demostrar una pantalla de iftop sobre una VPN

Una pantalla de iftop responde una pregunta a la vez: qué pares de hosts intercambian bytes por la interfaz hacia la que la dirigió. No responde si cada aplicación sigue una política de VPN, y una pantalla vacía no demuestra que no se haya filtrado nada. Justo en la diferencia entre esas dos afirmaciones fallan la mayoría de los debates sobre pruebas de fugas. Tres condiciones deciden qué significa realmente la pantalla, y las tres son visibles en la línea de comandos que usó.

Tres condiciones deciden qué significa la pantalla

Las condiciones son qué interfaz se muestra, qué ocultan el filtro y la propia herramienta, y qué ejercitó realmente la prueba. Respóndalas en ese orden, porque un error en la primera vuelve inútiles las otras dos.

La condición de la interfaz importa porque la vista del túnel y la vista física muestran capas distintas del mismo tráfico. Mirar la interfaz del túnel muestra los flujos dentro del túnel; mirar la interfaz física muestra el portador del túnel, más cualquier tráfico legítimo de configuración, control o local que comparta ese enlace. Ninguna de las dos vistas es incorrecta, y ninguna es la imagen completa. Nombrar cuál está mirando es la diferencia entre una prueba y una impresión.

Condición uno: qué interfaz se muestra

iftop toma la interfaz explícitamente con -i, y su manual describe el comportamiento cuando no lo hace: elige una, que puede ser el dispositivo que parece externo en lugar del túnel. Ese valor predeterminado es una opción razonable para una herramienta de ancho de banda y mala para una prueba de fugas.

Pase siempre la interfaz y anótela junto al resultado. Una captura de pantalla sin el nombre de la interfaz no es reproducible.

Condición dos: qué ocultan el filtro y la herramienta

iftop acepta una expresión de filtro, y un flujo que el filtro excluye es invisible por construcción, no por ausencia. La herramienta también realiza búsquedas de nombres de host de forma predeterminada para etiquetar direcciones, y esas búsquedas generan su propio tráfico DNS, es decir, tráfico que usted no pretendía observar. -n desactiva las búsquedas y hace numérica la pantalla; ocultar después las filas de DNS no es lo mismo que no generar las consultas.

Vale la pena decir esa distinción sin rodeos, porque también aparece en otras herramientas: suprimir la visualización de una actividad no es lo mismo que impedirla. Si las búsquedas de DNS forman parte de lo que está probando, ejecute la prueba con las búsquedas desactivadas para que la observación no quede contaminada por el observador.

Condición tres: qué ejercitó realmente la prueba

Una sola petición de una aplicación, a un destino, en una familia de direcciones, demuestra algo sobre esa petición. No demuestra nada sobre otra aplicación, otro destino ni la otra familia de direcciones, y IPv6 es la familia que más se olvida justamente en este tipo de comprobación.

Así que defina la petición antes de empezar: un destino inofensivo, desde la aplicación que le importa, en la familia que le importa, con el túnel en su estado aprobado. Luego compruebe el lado receptor o los propios diagnósticos del cliente, porque el extremo lejano sabe qué llegó de una forma que la pantalla local no puede. Después ejercite el caso aprobado de túnel no disponible y observe si el tráfico se detiene, porque ese es el comportamiento al que normalmente se refiere el requisito.

El DNS merece su propia observación. El destinatario de la consulta y la ruta que tomó la consulta son dos hechos, y una pantalla de ancho de banda no muestra ninguno de los dos.

Usar iftop como prueba de apoyo

Solo entonces iftop aporta valor, y lo aporta como corroboración. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" muestra si el flujo que esperaba aparece en la interfaz que esperaba, con recuentos de bytes que hacen verificable una afirmación de inactividad.

Compare eso con ss -tnp para la vista a nivel de socket y ip route get para la ruta que elegiría el núcleo, y tendrá tres observaciones de una petición en lugar de una impresión de una máquina. El manual de iftop documenta la selección de interfaz, la sintaxis del filtro y el comportamiento de las búsquedas, que son las tres cosas de las que depende una prueba de fugas. Una pantalla de ancho de banda localiza la actividad; la ruta, las excepciones y el comportamiento ante fallos deciden si esa actividad cumple el requisito.