Pérdida de Ping en una VPN: agrupa las solicitudes Echo antes del porcentaje

Una captura contiene seis solicitudes Echo y tres respuestas, y alguien escribe en el ticket una pérdida de paquetes del 50 por ciento. Ese número puede ser cierto para la captura y falso para el túnel. Puede que las seis solicitudes pertenezcan a dos conversaciones distintas con dos contratos de entrega distintos. Agrúpalas antes de dividir, y la proporción deja de ser la parte interesante del informe.

Paso 1: separa los flujos por origen y destino

Una solicitud Echo lleva un origen y un destino, y esos dos campos definen a qué conversación pertenece. Una sonda generada por la puerta de enlace usa la dirección del túnel de la puerta de enlace, mientras que una sonda reenviada en nombre de un host LAN conserva la dirección de ese host. El lado remoto puede tener una ruta de retorno para una y no para la otra, lo que hace que los dos grupos se comporten de forma distinta por motivos que nada tienen que ver con el túnel.

Divide la captura por esos campos antes de contar nada, y mantén el destino como parte de la clave. Dos flujos hacia pares distintos no son comparables aunque compartan un origen.

Anota los grupos con sus recuentos, porque el paso siguiente decide qué respuestas pertenecen a cada grupo. Un grupo con tres solicitudes y ninguna respuesta coincidente es un hallazgo. Un grupo con tres solicitudes y tres respuestas es una línea base.

Paso 2: empareja por el identificador y la secuencia

El formato Echo de la RFC 792 lleva un identificador y un número de secuencia, y los trata como los campos que emparejan una respuesta con su solicitud. Ambos hacen falta para esa tarea. Un número de secuencia por sí solo no es único, ya que distintos emisores o procesos pueden reutilizar el mismo valor dentro de una ventana de captura. El identificador acota el emisor y la secuencia acota la posición, y la pareja en conjunto es lo que hace defendible una coincidencia.

Una respuesta invierte la dirección de direcciones de su solicitud, así que una coincidencia es una pareja solicitud-respuesta y no dos tuplas idénticas. Compara el origen de la solicitud con el destino de la respuesta y el destino de la solicitud con el origen de la respuesta, y luego confirma que el identificador y la secuencia coinciden.

Conserva también la ventana de observación, porque una captura larga puede contener una reutilización legítima de ambos campos. Recortar la ventana a una ráfaga elimina la mayor parte de esa ambigüedad. También hace que los recuentos sean reproducibles para quien lea el ticket.

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

Paso 3: compara las tuplas en la misma frontera

Si la traducción de direcciones de red se sitúa entre el punto de captura y el par, las direcciones de la solicitud y la respuesta diferirán por diseño. Compara las tuplas en una sola frontera, o bien lleva el mapeo de forma explícita para que la diferencia quede contabilizada. Mezclar solicitudes anteriores a la traducción con respuestas posteriores inventa desajustes que nunca existieron en el cable.

Decide la frontera antes de empezar a contar, e indícala en el informe para que la siguiente persona pueda reproducir la agrupación. Una captura en el lado del cliente y otra en el lado del servidor son dos fronteras distintas. Cada una responde a una pregunta distinta sobre dónde desapareció la respuesta.

Un grupo de sondas traducidas también hereda el estado propio del dispositivo de traducción, que puede ser la razón real por la que una respuesta nunca llega. Comprueba ese estado antes de culpar al camino que hay más allá.

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

Paso 4: di qué puede y qué no puede demostrar la captura

Un hueco observado no establece que el host remoto haya callado. El punto de captura puede ver solo una dirección, un filtro puede descartar la respuesta, o el búfer puede haberse desbordado durante la ventana. Cada uno de ellos produce la misma ausencia y una conclusión distinta.

Anota la ubicación de la captura, la expresión del filtro y los contadores de descartes junto a los recuentos, porque una proporción sin ellos no se puede auditar. Esas tres líneas son lo que hace defendible el número más adelante.

Después separa lo que la observación establece de lo que sugiere, en dos frases en lugar de una. La primera frase indica los recuentos y la frontera. La segunda indica la hipótesis y qué la confirmaría.

Cuando la pregunta es si una ruta concreta descarta paquetes, una sonda controlada con una dirección de origen explícita es una evidencia más fuerte que un recuento pasivo de tráfico mezclado. Envíala desde la misma máquina, a la misma hora, al mismo par. Cambia una variable y la comparación se mantiene.

Informa de los grupos y de la próxima frontera

El informe tiene tres líneas: la definición del grupo, los recuentos emparejados dentro de cada grupo y la frontera en la que se hizo la comparación. Así el lector puede ver que un grupo respondió por completo y otro no, lo que apunta a una ruta o un permiso y no a una pérdida aleatoria.

Adjunta el archivo de captura y las expresiones de filtro para que la agrupación se pueda reproducir. Un resumen sin el archivo es una afirmación, no un resultado.

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

Cuando un grupo muestra cinco respuestas y el otro ninguna, el hallazgo es que un origen tiene una ruta de retorno que funciona y el otro no. Es un ticket mucho mejor que un porcentaje mezclado, y orienta la siguiente comprobación hacia la ruta de retorno en lugar de hacia una instancia VPN no relacionada.