Unha pantalla de iftop responde unha pregunta cada vez: que pares de hosts intercambian bytes pola interface cara á que a dirixiu. Non responde se cada aplicación segue unha política de VPN, e unha pantalla baleira non demostra que non se filtrase nada. Xusto na diferenza entre esas dúas afirmacións fallan a maioría dos debates sobre probas de fugas. Tres condicións deciden que significa realmente a pantalla, e as tres son visibles na liña de ordes que usou.

Tres condicións deciden que significa a pantalla

As condicións son que interface se mostra, que ocultan o filtro e a propia ferramenta, e que exercitou realmente a proba. Respóndallas nesa orde, porque un erro na primeira volve inútiles as outras dúas.

A condición da interface importa porque a vista do túnel e a vista física mostran capas distintas do mesmo tráfico. Mirar a interface do túnel mostra os fluxos dentro do túnel; mirar a interface física mostra o portador do túnel, máis calquera tráfico lexítimo de configuración, control ou local que comparta esa ligazón. Ningunha das dúas vistas é incorrecta, e ningunha é a imaxe completa. Nomear cal está a mirar é a diferenza entre unha proba e unha impresión.

Condición un: que interface se mostra

iftop toma a interface explicitamente con -i, e o seu manual describe o comportamento cando non o fai: escolle unha, que pode ser o dispositivo que parece externo en lugar do túnel. Ese valor predeterminado é unha opción razoable para unha ferramenta de ancho de banda e mala para unha proba de fugas.

Pase sempre a interface e anótea xunto ao resultado. Unha captura de pantalla sen o nome da interface non é reproducible.

Condición dous: que ocultan o filtro e a ferramenta

iftop acepta unha expresión de filtro, e un fluxo que o filtro exclúe é invisible por construción, non por ausencia. A ferramenta tamén realiza buscas de nomes de host de forma predeterminada para etiquetar enderezos, e esas buscas xeran o seu propio tráfico DNS, é dicir, tráfico que vostede non pretendía observar. -n desactiva as buscas e fai numérica a pantalla; ocultar despois as filas de DNS non é o mesmo que non xerar as consultas.

Paga a pena dicir esa distinción sen rodeos, porque tamén aparece noutras ferramentas: suprimir a visualización dunha actividade non é o mesmo que impedila. Se as buscas de DNS forman parte do que está a probar, execute a proba coas buscas desactivadas para que a observación non quede contaminada polo observador.

Condición tres: que exercitou realmente a proba

Unha soa petición dunha aplicación, a un destino, nunha familia de enderezos, demostra algo sobre esa petición. Non demostra nada sobre outra aplicación, outro destino nin a outra familia de enderezos, e IPv6 é a familia que máis se esquece xustamente neste tipo de comprobación.

Así que defina a petición antes de comezar: un destino inofensivo, desde a aplicación que lle importa, na familia que lle importa, co túnel no seu estado aprobado. Logo comprobe o lado receptor ou os propios diagnósticos do cliente, porque o extremo afastado sabe que chegou dunha forma que a pantalla local non pode. Despois exercite o caso aprobado de túnel non dispoñible e observe se o tráfico se detén, porque ese é o comportamento ao que normalmente se refire o requisito.

O DNS merece a súa propia observación. O destinatario da consulta e a ruta que tomou a consulta son dous feitos, e unha pantalla de ancho de banda non mostra ningún dos dous.

Usar iftop como proba de apoio

Só entón iftop achega valor, e achégao como corroboración. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" mostra se o fluxo que esperaba aparece na interface que esperaba, con recontos de bytes que fan verificable unha afirmación de inactividade.

Compare iso con ss -tnp para a vista a nivel de socket e ip route get para a ruta que elixiría o núcleo, e ten tres observacións dunha petición en lugar dunha impresión dunha máquina. O manual de iftop documenta a selección de interface, a sintaxe do filtro e o comportamento das buscas, que son as tres cousas das que depende unha proba de fugas. Unha pantalla de ancho de banda localiza a actividade; a ruta, as excepcións e o comportamento ante fallos deciden se esa actividade cumpre o requisito.

Artigos relacionados