Contenido del artículo

Los logs del cliente son maravillosos justo hasta el momento en que muestran algo. Pero un día te topas con un muro: la aplicación escribe un lacónico connection reset, el proxy permanece en silencio en sus logs y el servidor destino jura que todo está bien. ¿Quién miente? Nadie. Simplemente estás mirando el problema desde el piso de arriba, y la verdad vive a nivel de paquetes. Y hay que bajar hasta ahí.

Este artículo es una guía de ingeniería detallada sobre el trabajo con tcpdump y Wireshark en esos casos en que el tráfico pasa a través de un proxy. Analizaremos qué ve exactamente el observador antes del proxy y después de él, por qué dentro de un túnel HTTPS solo se ve la solicitud CONNECT y nada más, y cómo distinguir con un solo volcado un corte del lado propio de un corte del lado del servidor destino. Esto no trata sobre interceptar y sustituir HTTPS a nivel de aplicación: trata sobre el nivel de paquetes y el diagnóstico honesto de cortes.

Introducción: cuando los logs del cliente ya no alcanzan

Imagina una infraestructura típica. Tu aplicación se comunica con una API externa a través del proxy HTTP Proxeon. Por lo general, todo funciona. Pero el cinco por ciento de las solicitudes fallan con error, y no entiendes por qué. Los logs de la aplicación solo muestran el hecho del corte. Los logs del proxy muestran que el túnel se estableció. El servidor destino está fuera de tu control. Estás atrapado entre tres cajas negras.

Justo aquí comienza el diagnóstico a nivel de paquetes. Un volcado de tráfico es la transcripción literal de la conversación entre máquinas, sin interpretaciones y sin derecho a mentir. Un paquete o llegó, o no llegó. El flag RST o está puesto, o no lo está. TCP no sabe fingir. Y si aprendes a leer esa transcripción, dejarás de adivinar.

De esta guía aprenderás: cómo capturar un volcado con el comando tcpdump sin llenar el disco con gigabytes; qué filtros de visualización en Wireshark ahorran horas; cómo leer un handshake TLS incluso sin descifrado; cómo identificar al culpable del corte por los flags; y cómo descifrar legalmente el tráfico propio mediante la variable SSLKEYLOGFILE. Al final te espera una checklist lista para contactar al soporte y un FAQ detallado.

Fundamentos: tres segmentos de una misma conexión

Lo primero que hay que grabarse en la cabeza: cuando el cliente trabaja a través de un proxy, no es una sola conexión, sino al menos dos conexiones TCP distintas. Una, del cliente al proxy. Otra, del proxy al servidor destino. Esta es la base sin la cual cualquier análisis posterior carece de sentido.

Qué es un volcado y cómo está estructurado

Un volcado de paquetes es una secuencia de paquetes de red capturados en una interfaz de red concreta de una máquina concreta. La palabra clave es concreta. Siempre ves solo el tráfico que pasa físicamente por el punto de captura. Si capturas en el cliente, ves la conversación cliente-proxy. Si capturas en el proxy, ves ambos lados. En el servidor destino, solo la conversación proxy-servidor.

Cada paquete lleva cabeceras de niveles: Ethernet, IP, TCP o UDP, y la carga útil. Para el diagnóstico de cortes nos interesa en primer lugar el nivel TCP: números de puerto, números de secuencia (sequence), confirmaciones (ACK) y flags: SYN, ACK, FIN, RST, PSH.

El modelo del proxy: dos conexiones en lugar de una

Analicemos el esquema del movimiento del tráfico al trabajar con un proxy HTTP en modo túnel:

  • Segmento A (cliente - proxy). El cliente abre una conexión TCP a la IP y el puerto del proxy. Por este canal envía el comando para establecer un túnel.
  • Segmento Б (proxy - servidor destino). El proxy, en su propio nombre, abre una conexión TCP aparte hacia el servidor destino. Aquí ya hay otra src-IP, otro src-puerto, otro estado.
  • Túnel lógico. Tras el establecimiento, el proxy comienza a transferir ciegamente bytes del segmento А al segmento Б y viceversa. No analiza lo que hay dentro.

¿Por qué es importante para el diagnóstico? Porque el corte puede ocurrir en cualquiera de los dos segmentos, y desde el punto de vista del cliente el síntoma será el mismo: la conexión se cayó. Pero la causa, y por lo tanto la solución, son diferentes.

Proxy HTTP, SOCKS y tunelización

En una solicitud HTTP normal sin cifrado, el proxy ve el método, la URL y las cabeceras. Pero en cuanto se trata de HTTPS, el panorama cambia. El cliente no puede entregar al proxy una solicitud sin cifrar, porque pierde el sentido del cifrado. Por eso se aplica el mecanismo de tunelización: el cliente le dice al proxy conéctame con este host en este puerto y de ahí en adelante no interfieras. Ese comando es precisamente CONNECT.

Inmersión profunda: por qué en el túnel solo se ve CONNECT

Esta es, quizás, la fuente más frecuente de desconcierto entre los ingenieros que abren por primera vez un volcado de tráfico HTTPS a través de un proxy. Esperas ver solicitudes y respuestas, y ves una sola línea y luego una papilla ilegible. Vamos a entender por qué es así, y por qué es lo correcto.

Anatomía del CONNECT

Cuando el cliente quiere establecer una conexión segura a través del proxy, envía al proxy esta solicitud en texto plano:

CONNECT api.example.com:443 HTTP/1.1\r\nHost: api.example.com:443\r\n\r\n

El proxy abre una conexión TCP hacia api.example.com en el puerto 443 y, si todo salió bien, responde al cliente:

HTTP/1.1 200 Connection established\r\n\r\n

A partir de ese momento el proxy se convierte en un tubo tonto. Todo lo que el cliente envíe después, el proxy lo retransmitirá al servidor byte a byte, y viceversa. ¿Y qué envía el cliente después? TLS ClientHello, el inicio del handshake. Intercambio cifrado. El proxy no tiene las claves y físicamente no puede mirar dentro.

Qué significa esto para el observador con un volcado

Si capturas un volcado en el cliente o en el proxy, verás:

  • El establecimiento de la conexión TCP hacia el proxy (SYN, SYN-ACK, ACK).
  • El texto plano de la solicitud CONNECT con el nombre del host destino y el puerto.
  • La respuesta del proxy sobre el estado de establecimiento del túnel.
  • Y después, solo registros TLS, un flujo cifrado del que a simple vista únicamente se leen los metadatos del handshake.

Aquí está el gran insight: el nombre del host destino en el volcado siempre se ve, en la línea CONNECT. Incluso sin un solo byte descifrado, sabes exactamente adónde intentaba llegar el cliente. Esto es invaluable en el diagnóstico: descartas de inmediato la pregunta ¿y acaso la solicitud iba hacia allá?.

TLS SNI: segunda fuente del nombre del host

Incluso si no hubiera CONNECT (por ejemplo, en una conexión directa sin proxy), el nombre del host suele verse en el campo SNI dentro del ClientHello. Server Name Indication se transmite en texto plano al inicio del handshake. Wireshark lo muestra perfectamente. En las redes modernas gana popularidad Encrypted Client Hello, que oculta el SNI, pero al trabajar a través de un túnel CONNECT esto no dificulta el diagnóstico: el nombre del host ya fue mencionado en el propio CONNECT.

tcpdump en la práctica: capturamos un volcado sin gigabytes

Pasemos a la acción. tcpdump es una utilidad de línea de comandos para la captura de paquetes, disponible en casi cualquier sistema similar a Unix. Es potente, ligera e irremplazable en servidores donde no hay interfaz gráfica. Analicemos los escenarios clave.

Captura básica en la interfaz correcta

Primero veamos la lista de interfaces:

tcpdump -D

Captura en una interfaz concreta con salida a pantalla:

tcpdump -i eth0 -n

El flag -n desactiva la resolución de nombres para que tcpdump no se ralentice con consultas DNS y muestre IP puras. Esto es importante: la resolución en tiempo real distorsiona el panorama y ralentiza la captura.

Filtrado por host y puerto

Capturar todo el tráfico de la interfaz en un servidor con carga es el camino directo a gigabytes de basura. Filtra desde el principio. Captura del tráfico hacia un proxy concreto por IP y puerto:

tcpdump -i eth0 -n host 203.0.113.10 and port 8080

Captura solo hacia el servidor destino (útil del lado del proxy):

tcpdump -i eth0 -n host api.example.com and port 443

Combinación: tráfico hacia el proxy O hacia el servidor destino:

tcpdump -i eth0 -n "(host 203.0.113.10 and port 8080) or (host 198.51.100.5 and port 443)"

Presta atención a las comillas: cuando la expresión contiene paréntesis y operadores lógicos, envuelve el filtro en comillas para que el shell no interprete los caracteres especiales.

Escritura a archivo y formato correcto

Para el análisis posterior en Wireshark se necesita un archivo en formato pcap. El flag -w escribe los paquetes en bruto a un archivo:

tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -w dump.pcap

Un punto sumamente importante: -s 0 o el comportamiento moderno por defecto captura el paquete completo (snaplen). Las versiones antiguas recortaban los paquetes. Si necesitas los datos completos, asegúrate de que el snaplen sea suficiente:

tcpdump -i eth0 -n -s 0 host 203.0.113.10 and port 8080 -w dump.pcap

Si solo necesitas las cabeceras para el diagnóstico de cortes (flags, seq, ack) y no el contenido, limita el snaplen para que el archivo sea más compacto:

tcpdump -i eth0 -n -s 96 host 203.0.113.10 and port 8080 -w headers.pcap

Rotación de archivos: cómo no llenar el disco

En un diagnóstico prolongado de un problema intermitente, la captura puede durar horas. Para no obtener un solo archivo monstruoso, usa la rotación por tamaño y cantidad de archivos. El flag -C define el tamaño del archivo en megabytes, -W la cantidad de archivos en el búfer circular:

tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -w dump-%Y%m%d-%H%M%S.pcap -C 100 -W 10

Este comando creará hasta diez archivos de cien megabytes. Cuando el décimo se llene, tcpdump empezará a sobrescribir el primero. Así siempre conservas aproximadamente el último gigabyte de tráfico y nunca desbordarás el disco. La plantilla de tiempo en el nombre del archivo hace legible el archivo de datos.

Alternativa: rotación por tiempo. El flag -G define el intervalo en segundos tras el cual se crea un nuevo archivo:

tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -G 3600 -w dump-%Y%m%d-%H%M%S.pcap

Cada hora, un archivo nuevo. Es cómodo cuando luego hay que encontrar rápidamente el intervalo por la hora del incidente.

Captura alrededor del evento: atrapamos un corte poco frecuente

La situación más traicionera es cuando el problema se reproduce una vez por hora e impredeciblemente. Lanzas el búfer circular y esperas. En cuanto la aplicación registra el error, anotas la hora exacta y detienes la captura. Luego, en el análisis, vas al segundo deseado. Truco práctico: que la aplicación al fallar escriba en el log la marca de tiempo exacta con milisegundos; ese es tu ancla en el volcado.

Filtro por flags TCP directamente en tcpdump

A veces es útil capturar solo paquetes con ciertos flags. Por ejemplo, solo paquetes con el flag RST, para entender de inmediato si vuelan resets:

tcpdump -i eth0 -n "tcp[tcpflags] & tcp-rst != 0"

Solo paquetes SYN, cómodo para rastrear intentos de establecer conexión:

tcpdump -i eth0 -n "tcp[tcpflags] & tcp-syn != 0"

Combinación de RST o FIN para monitorear cierres de conexión hacia el proxy:

tcpdump -i eth0 -n "host 203.0.113.10 and (tcp[tcpflags] & (tcp-rst|tcp-fin) != 0)"

Wireshark: leer el volcado como un libro abierto

tcpdump captura; Wireshark lee. Es un analizador gráfico con un riquísimo sistema de filtros de visualización y decodificadores de protocolos. Abres el archivo pcap guardado y comienzas la investigación. Analicemos las herramientas que realmente necesitas para nuestra tarea.

Filtros de visualización vs filtros de captura

Es importante no confundirlos. El filtro de captura (el de tcpdump) descarta paquetes antes de la escritura: lo que no se captura, no existe. El filtro de visualización en Wireshark es una lente: solo oculta lo sobrante del archivo ya cargado, sin eliminar nada. Su sintaxis es distinta. A continuación, filtros de visualización.

Filtros de visualización básicos

Mostrar solo el tráfico hacia una IP concreta:

ip.addr == 203.0.113.10

Solo el puerto TCP del proxy:

tcp.port == 8080

Combinación de host y puerto:

ip.addr == 203.0.113.10 && tcp.port == 8080

Mostrar solo paquetes con el flag RST: de inmediato se ven todos los resets de conexión:

tcp.flags.reset == 1

Solo paquetes con FIN:

tcp.flags.fin == 1

Solo SYN sin ACK: intentos de abrir conexión:

tcp.flags.syn == 1 && tcp.flags.ack == 0

Búsqueda de CONNECT y cabeceras HTTP

Para encontrar en el volcado la propia solicitud CONNECT:

http.request.method == "CONNECT"

La respuesta del proxy sobre el establecimiento del túnel se ve como respuesta HTTP. Filtrar todas las solicitudes HTTP:

http.request

Todas las respuestas HTTP con códigos:

http.response

Follow TCP Stream: reunimos la conversación en una sola pieza

Esta es, posiblemente, la función más valiosa de Wireshark para nuestra tarea. Clic derecho en cualquier paquete de la conexión, luego Follow, luego TCP Stream. Wireshark reunirá todo el intercambio bidireccional en una ventana donde los datos del cliente y del servidor se muestran en colores distintos. Para tráfico sin cifrar verás texto limpio: la solicitud CONNECT, la respuesta del proxy y luego bytes TLS ilegibles.

Precisamente en Follow Stream se ve claramente el corte en CONNECT. Las primeras líneas se leen como texto humano y luego comienza la zona cifrada. Esto confirma: el túnel está establecido, después viene el cifrado y sin claves no se puede mirar más adentro, lo cual es absolutamente normal.

Lectura del handshake TLS sin descifrado

Incluso sin tener las claves, el handshake TLS cuenta mucho. Filtra los registros del handshake:

tls.handshake

Encontrar el ClientHello, donde el cliente se presenta al servidor:

tls.handshake.type == 1

Encontrar el ServerHello, la respuesta del servidor:

tls.handshake.type == 2

¿Qué aporta este par? Si ves ClientHello, pero nunca ves ServerHello, el servidor no respondió al handshake. Causa: o el servidor destino es inalcanzable a través del proxy, o el corte ocurrió antes de la respuesta. Si ves ambos, pero luego hay un corte, el problema es más profundo, ya en el intercambio cifrado o a nivel de aplicación.

Dentro del ClientHello, sin ningún descifrado, se lee el campo SNI: el nombre del host al que va dirigida la solicitud:

tls.handshake.extensions_server_name == "api.example.com"

También ves las versiones de TLS y los conjuntos de cifrado propuestos. Si el servidor responde con Alert en lugar de ServerHello, significa que el handshake fue rechazado, por ejemplo, por incompatibilidad de versiones o cifrados. Filtro para los alertas:

tls.alert_message

Diagnóstico por volcado: quién exactamente cortó la conexión

Hemos llegado al corazón del artículo. La conexión se cayó; la pregunta es quién la cortó y por qué. TCP deja pistas, y con ellas se puede emitir un veredicto. Analicemos las señales clave.

Cierre normal: FIN

El cierre ordenado de una conexión ocurre mediante el intercambio de paquetes FIN. Una parte dice terminé la transmisión, la otra confirma y también envía FIN. Es una despedida cortés. Si en el volcado ves un intercambio pulcro FIN-ACK-FIN-ACK, la conexión se cerró correctamente. La cuestión es solo si tu cliente esperaba ese cierre. Si el servidor envió FIN, entregando la respuesta completa, todo bien. Si el FIN llegó en medio de los datos esperados, el servidor cerró antes de tiempo.

Cierre de emergencia: RST

El flag RST es un corte brusco. No es una despedida, es un portazo. RST significa: esta conexión no es válida, olvídala de inmediato. Las causas son variadas:

  • El puerto está cerrado: nadie escucha de ese lado. El RST llega casi al instante después del SYN.
  • La aplicación de ese lado cerró el socket de forma anómala.
  • Un dispositivo intermedio (firewall, balanceador, el propio proxy) reinició la conexión por timeout o política.
  • Una de las partes recibió un paquete para una conexión que ya había olvidado.

La clave para resolver el enigma es quién envió el RST. Mira el source IP del paquete con RST. Si el RST llegó desde la IP del proxy, cortó el proxy o algo entre el proxy y tú. Si llegó desde la IP del servidor destino, significa que el segmento proxy-servidor llegó al servidor y lo cortó él o un dispositivo cercano a él.

Pero recuerda los dos segmentos. Al capturar en el cliente, verás el RST solo desde la IP del proxy, porque no te comunicas directamente con el servidor: entre tú y él está el proxy. Para entender qué ocurre en el segmento Б, se necesita un volcado del lado del proxy. De esto hablaremos en la sección de la checklist.

Retransmisiones: retransmission

Wireshark marca automáticamente las retransmisiones. Filtro:

tcp.analysis.retransmission

Una retransmisión significa que el emisor no recibió ACK del segmento enviado en el plazo y lo envía otra vez. Retransmisiones aisladas son normales en internet. Pero una avalancha de retransmisiones es síntoma de pérdida de paquetes en el camino. Es especialmente característico de redes móviles e inestables.

Filtros útiles relacionados. ACK duplicados, que señalan un segmento perdido:

tcp.analysis.duplicate_ack

Todos los eventos problemáticos que Wireshark pudo reconocer:

tcp.analysis.flags

Si ves una serie de retransmisiones seguida de un RST, el panorama se arma: se perdían paquetes, una de las partes se cansó de esperar y cortó la conexión. Es la historia típica de un canal malo.

Zero Window: el receptor se ahogó

TCP tiene un mecanismo de control de flujo mediante la ventana de recepción. Si el receptor no alcanza a procesar los datos, declara zero window: el búfer está lleno, frena. Filtro:

tcp.analysis.zero_window

Zero window no es una pérdida de red, sino una señal de que la aplicación receptora lee lentamente del socket. Por ejemplo, tu cliente recibe una respuesta grande, pero la procesa en un solo hilo y no alcanza. El emisor espera, la ventana no se abre y al final puede dispararse un timeout. Si después de zero window viene window update, todo se normalizó. Si después de zero window hay silencio y luego RST, el receptor se colgó o se cayó.

Señal pariente: window full, cuando el emisor chocó contra la ventana declarada y no puede enviar más:

tcp.analysis.window_full

Matriz de veredictos

Reunamos la lógica en un marco práctico. Mira los últimos paquetes de la conexión viva antes del corte:

  • Hay SYN, no hay SYN-ACK, luego RST o silencio. La conexión no se estableció. El punto destino es inalcanzable o el puerto está cerrado. Al trabajar a través de un proxy, el RST llegará del proxy si el servidor detrás de él es inalcanzable.
  • El establecimiento pasó, se envió CONNECT, no hay respuesta. El proxy aceptó el comando, pero no pudo alcanzar al servidor destino o este calla. Espera el timeout.
  • Hay ClientHello, no hay ServerHello. El servidor destino no respondió al handshake. El problema está en el segmento proxy-servidor.
  • Había datos, luego RST del servidor. El servidor cerró la conexión de forma anómala: sobrecarga, error de aplicación, timeout de su lado.
  • Había datos, luego FIN del servidor en medio de la respuesta. El servidor cerró ordenadamente, pero antes de lo que el cliente esperaba: probablemente un límite al tamaño de la respuesta o un timeout de la solicitud.
  • Avalancha de retransmission y luego RST. Pérdidas en el canal. Busca el problema en la red: conexión móvil, ruta sobrecargada.
  • Zero window, luego silencio. Tu cliente no leía los datos lo suficiente rápido. El problema está de tu lado, en el procesamiento.

Descifrado del tráfico propio mediante SSLKEYLOGFILE

A veces los metadatos no alcanzan: hace falta ver el contenido del intercambio cifrado. Esto es legal y correcto solo cuando el tráfico es tuyo: tu cliente, tus claves, tu aplicación. No interceptamos lo ajeno y no sustituimos certificados. Le pedimos a nuestro propio cliente que amablemente escriba las claves de sesión en un archivo, para luego dárselas a Wireshark.

Cómo funciona

Muchas bibliotecas cliente de TLS soportan la variable de entorno SSLKEYLOGFILE. Si está definida, la biblioteca agrega al archivo indicado los secretos de las sesiones en formato estándar. Wireshark sabe leer ese archivo y descifrar las sesiones correspondientes en el volcado. Ninguna magia y ningún hackeo: el cliente entrega voluntariamente sus claves porque tú, dueño del cliente, así lo dispusiste.

Ejemplo para la línea de comandos y navegadores con motor compatible

Definir la variable antes de lanzar la aplicación en un sistema similar a Unix:

export SSLKEYLOGFILE=/home/user/tls-keys.log

Lanzar el cliente, por ejemplo curl, que soporte esta variable al compilarse con la biblioteca adecuada:

SSLKEYLOGFILE=/home/user/tls-keys.log curl -x http://203.0.113.10:8080 https://api.example.com/status

Aquí el flag -x define el proxy Proxeon, y SSLKEYLOGFILE hace que se escriban las claves de la sesión. En paralelo capturas el volcado con tcpdump. Después de eso tienes tanto el pcap como el archivo de claves.

Conexión de las claves en Wireshark

En Wireshark abre la configuración, encuentra la sección del protocolo TLS, indica la ruta al archivo de claves en el campo para el archivo de log de pre-master secrets. Después de eso vuelve a leer el volcado. Los registros TLS antes ilegibles se volverán descifrados: verás las verdaderas solicitudes y respuestas HTTP dentro del túnel. Ahora Follow TLS Stream mostrará el intercambio de aplicación por completo.

Límites importantes de aplicabilidad

  • Solo se descifra el tráfico cuyas claves cayeron en el archivo. Las sesiones ajenas permanecen cifradas, y eso es lo correcto.
  • Las claves son sensibles. El archivo tls-keys.log de hecho abre el contenido de tus sesiones. Guárdalo como un secreto, bórralo tras la depuración.
  • El método está destinado a la depuración de aplicaciones propias, no a la observación del tráfico ajeno. Es una frontera ética y legal de principio.

Patrones típicos de cortes y cómo leerlos

La teoría sin patrones reconocibles se desvanece rápido. Analicemos varios escenarios característicos que encontrarás una y otra vez. Aprende a reconocerlos a primera vista.

Timeout de conexión: el servidor detrás del proxy es inalcanzable

Panorama en el volcado del cliente: el TCP hacia el proxy se estableció normalmente, el cliente envió CONNECT y llegó el silencio. No hay respuesta 200 del proxy. Con el tiempo, o llega un RST del proxy, o la aplicación misma cierra la conexión por su propio timeout.

Qué significa: el proxy aceptó tu comando, intentó abrir el segmento Б hacia el servidor destino, pero este no respondió. El servidor destino está caído, el puerto está cerrado o la ruta hacia él está cortada. Tu lado y el proxy funcionan correctamente. Acción: verificar la disponibilidad del host destino, si es necesario capturar un volcado del lado del proxy para ver el segmento Б.

Corte en medio de la respuesta

Panorama: el túnel está establecido, TLS funcionó, empezaron los datos, parte de la respuesta fue recibida, y de pronto FIN o RST del lado del servidor. El cliente recibió una respuesta incompleta y se queja de contenido truncado.

Si es FIN, el servidor cerró ordenadamente, pero prematuramente: quizás se disparó un límite de tiempo de generación de la respuesta o una restricción de tamaño de su lado. Si es RST, el servidor o un dispositivo cercano a él cortaron de forma anómala. Acción: si el problema se repite en respuestas grandes, busca timeouts y límites. El descifrado de tu propio tráfico mediante SSLKEYLOGFILE ayudará a ver si se recibió la cabecera HTTP y cuánto cuerpo alcanzó a llegar.

Pérdidas en red móvil

Panorama: muchos paquetes marcados como retransmission, aparecen duplicate ack, se observan saltos notables de tiempo entre paquetes. La conexión o es dolorosamente lenta o termina rompiéndose por timeout.

Es el clásico de un canal de radio inestable. Los paquetes se pierden, TCP los reenvía, la velocidad cae. Las redes móviles también tienden a romper conexiones que llevan mucho tiempo inactivas por los timeouts NAT del equipo intermedio del operador: en medio del silencio, de pronto llega un RST cuando una de las partes intenta reanudar el intercambio por una conexión que el operador ya olvidó. Acción: configurar keep-alive y timeouts razonables, reintentos a nivel de aplicación, no mantener conexiones largas inactivas.

El proxy es totalmente inalcanzable

Panorama: el cliente envía SYN a la IP y el puerto del proxy, pero no recibe SYN-ACK. O bien silencio y retransmisiones de SYN, o bien un RST instantáneo. Si es silencio, algo filtra los paquetes entre tú y el proxy, o el proxy no escucha. Si es RST instantáneo, en ese puerto no responde nadie. Acción: verificar la dirección y el puerto del proxy, la disponibilidad de red, la corrección de la configuración.

Cliente lento: zero window

Panorama: el intercambio fluye, pero periódicamente el cliente declara zero window, el emisor se pausa, luego window update reanuda el flujo. Si esto se repite con frecuencia, tu aplicación lee del socket más lento de lo que el servidor entrega. Acción: optimizar el procesamiento de la respuesta, leer el flujo en un hilo aparte, aumentar los búferes.

Errores típicos al capturar y leer un volcado

La experiencia es una colección de chichones. Reunamos los errores más frecuentes para que no los repitas.

  • Capturar el volcado en el lugar equivocado. Buscas el corte en el segmento proxy-servidor, pero capturaste en el cliente, donde ese segmento no se ve. Piensa siempre qué segmento necesitas y captura en el punto correcto.
  • Capturar todo sin distinción. Sin filtro, en un servidor con carga obtendrás gigabytes y te ahogarás en ellos. Filtra por host y puerto desde el principio.
  • Snaplen recortado donde se necesitan datos. Si quieres ver el contenido y pusiste un snaplen corto, la carga útil quedará truncada y Follow Stream mostrará fragmentos.
  • Resolución de nombres activada. Olvidaste el flag -n, y tcpdump se ralentiza en DNS, distorsionando los tiempos. Siempre -n al capturar.
  • Ignorar la dirección del RST. Ven el RST y sacan conclusiones sin mirar quién lo envió. El source IP del paquete RST es la mitad de la respuesta.
  • Confundir un FIN normal con una avería. FIN es un cierre normal. Hay que alarmarse no por el FIN en sí, sino por el FIN que llegó antes del final esperado de los datos.
  • Olvidar las zonas horarias y la hora exacta. Los logs de la aplicación y el volcado deben estar sincronizados en tiempo, si no, no encontrarás el momento deseado. Mantén NTP en orden.
  • Guardar el archivo de claves SSLKEYLOGFILE. Tras la depuración debe eliminarse. Es un secreto que revela el contenido de tus sesiones.
  • Sacar conclusiones de una sola conexión. Los problemas intermitentes requieren estadística. Una solicitud caída puede ser casualidad; un patrón de diez, un diagnóstico.

Herramientas y recursos del ingeniero

Reunamos el arsenal que conviene tener a mano al trabajar con tráfico de proxy.

Captura

  • tcpdump: la herramienta principal de captura en servidores y en consola. Ligera, siempre disponible, filtro flexible.
  • dumpcap: la utilidad de consola del conjunto de Wireshark, especialmente afinada para la captura eficiente con rotación.
  • tshark: el Wireshark de consola. Permite aplicar filtros de visualización sin gráficos, cómodo para scripts y servidores remotos.

Análisis

  • Wireshark: analizador gráfico, decodificadores de cientos de protocolos, potente sistema de filtros, Follow Stream, estadísticas por conexión.
  • Información experta de Wireshark: panel integrado que resalta anomalías: retransmisiones, resets, zero window. Comienza la investigación justo por él.
  • Estadísticas de conversaciones: tabla de todas las conexiones TCP del volcado con bytes y duración. Rápidamente se ve qué conexión es anormalmente corta.

Recursos útiles de línea de comandos

Ver rápidamente el contenido del pcap en consola con tshark y un filtro de visualización:

tshark -r dump.pcap -Y "tcp.flags.reset == 1"

Mostrar solo las solicitudes CONNECT del archivo:

tshark -r dump.pcap -Y "http.request.method == \"CONNECT\""

Ver todas las retransmisiones:

tshark -r dump.pcap -Y "tcp.analysis.retransmission"

Estos comandos son invaluables cuando no hay gráficos y hay que resolver aquí y ahora, por ssh.

Casos y resultados de la aplicación

Nada convence más que las historias reales. Presento casos colectivos que reflejan la práctica real de ingeniería en el diagnóstico de tráfico de proxy.

Caso 1: el cinco por ciento de las solicitudes fallan de noche

El equipo de integración se quejaba: alrededor del cinco por ciento de las solicitudes a una API externa a través del proxy fallaban con respuesta truncada, principalmente de noche. Los logs de la aplicación mostraban contenido incompleto. Los logs del proxy, túneles establecidos sin errores.

Capturamos un volcado en el cliente con rotación circular durante varias horas y una marca exacta del error del log. En el momento del incidente vimos: el túnel está establecido, TLS funcionó, llegó parte del cuerpo de la respuesta, luego FIN desde el proxy. El descifrado de nuestro propio tráfico mediante SSLKEYLOGFILE mostró: llegaba una cabecera HTTP correcta con el tamaño del cuerpo indicado, pero el cuerpo se cortaba a la mitad. Conclusión: el servidor destino cerraba la conexión por su propio timeout de generación de los grandes informes nocturnos. Solución del lado de la integración: solicitar los datos por páginas en porciones más pequeñas. El problema desapareció por completo.

Caso 2: el misterioso RST instantáneo

Otro ingeniero recibía un reset instantáneo justo después de enviar CONNECT hacia un host concreto, mientras que con otros hosts todo funcionaba. La primera sospecha recaía en el proxy.

El volcado en el cliente mostró: el CONNECT salió y casi al instante regresó un RST con la IP del proxy. Pero la instantaneidad alertaba: normalmente la inalcanzabilidad del servidor da un timeout, no un reset instantáneo. Capturamos un volcado del lado del proxy y vimos el segmento Б: el proxy abría la conexión hacia el host destino en el puerto indicado y el servidor destino respondía RST al SYN: el puerto estaba cerrado. El proxy transmitía honestamente ese rechazo al cliente. Resultó que el servicio destino había cambiado de puerto recientemente. Conclusión: un RST instantáneo suele ser un puerto cerrado, no un problema del proxy. El puerto correcto restauró el funcionamiento.

Caso 3: degradación en el segmento móvil

Una aplicación en dispositivos móviles que trabajaba a través de un proxy perdía la conexión regularmente en parte de los usuarios. El volcado desde el dispositivo en la zona de cobertura problemática mostró el panorama clásico: series de retransmisiones, ACK duplicados, intervalos crecientes y, al final, RST tras una larga inactividad: resultado del timeout NAT del operador.

Conclusión: es la red, no el proxy ni el servidor. Solución a nivel de aplicación: introdujimos reintentos adaptativos, keep-alive razonables y manejo grácil de los cortes con restablecimiento de conexión. La cantidad de errores visibles para el usuario cayó varias veces, aunque el canal de radio siguió igual. El volcado de paquetes permitió no perder tiempo en hipótesis falsas sobre el proxy y centrarse en la causa real.

Insight general de los casos

En las tres historias, el volcado ahorró semanas de correspondencia y acusaciones mutuas entre equipos. Los paquetes no mienten. En cuanto aparece sobre la mesa un volcado con la dirección del RST, la presencia o ausencia de ServerHello y el panorama de retransmisiones, la discusión sobre el culpable termina en minutos. Ese es el principal valor del método: traslada el diagnóstico del plano de las opiniones al plano de los hechos.

Checklist de captura de volcado para contactar al soporte

Cuando te comunicas con el soporte, ya sea del proveedor de proxy Proxeon, ya sea del dueño de la API destino, un volcado bien capturado acelera la solución varias veces. Aquí tienes una checklist que conviene completar antes de contactar.

Antes de la captura

  • Fija la hora exacta del inicio del diagnóstico y sincroniza los relojes por NTP en todas las máquinas participantes.
  • Define los puntos de captura: al menos en el cliente, si es posible también del lado donde tengas acceso.
  • Reúne los datos de entrada: IP y puerto del proxy, nombre y puerto del host destino, comportamiento esperado y real.

Durante la captura

  • Lanza tcpdump con filtro por el host del proxy y el puerto destino, con snaplen completo y rotación: 
    tcpdump -i eth0 -n -s 0 "host 203.0.113.10 and port 8080" -w support-%Y%m%d-%H%M%S.pcap -C 100 -W 10
  • Reproduce el problema y anota la hora exacta del incidente con milisegundos desde el log de la aplicación.
  • No olvides guardar en paralelo los logs de la aplicación del mismo intervalo.

Qué adjuntar a la solicitud

  • El propio archivo pcap, recortado al intervalo de tiempo relevante, para no enviar gigabytes.
  • Las marcas de tiempo exactas del incidente y la zona horaria.
  • IP y puerto del proxy, nombre y puerto del host destino, descripción del escenario.
  • Fragmento de los logs de la aplicación con el error.
  • Tu análisis preliminar: quién envió el RST o el FIN, si hubo ServerHello, si se observaron retransmisiones. Esto demuestra que hiciste la tarea.

Cómo recortar el pcap al intervalo deseado

Un archivo enorme se puede recortar por tiempo mediante tshark o editcap. Ejemplo de recorte por filtro:

tshark -r big.pcap -Y "frame.time >= \"2026-01-01 03:00:00\" && frame.time <= \"2026-01-01 03:05:00\"" -w small.pcap

Un volcado tan pulcro y enfocado el soporte lo procesará rápido, porque no tendrá que buscar una aguja en un pajar.

FAQ: preguntas frecuentes sobre volcados a través de proxy

¿Por qué en el volcado de tráfico HTTPS a través de un proxy solo veo CONNECT y luego algo ilegible?

Porque tras el establecimiento del túnel el proxy solo retransmite bytes TLS cifrados, sin tener las claves. En texto plano va únicamente el comando CONNECT con el nombre del host y la respuesta del proxy sobre el establecimiento. Todo lo demás está protegido por cifrado, y es exactamente para eso que existe HTTPS. Para ver el contenido de tu propio tráfico, usa SSLKEYLOGFILE.

¿Cómo entender que la conexión la cortó el servidor destino y no el proxy?

Mira el source IP del paquete con RST o FIN. Pero recuerda los dos segmentos: en el volcado del cliente ves solo la IP del proxy, porque no te comunicas directamente con el servidor. Para atribuir con precisión el corte al servidor destino, se necesita un volcado del lado del proxy, donde se ve el segmento proxy-servidor. Si el RST en el segmento Б llega desde la IP del servidor, lo cortó él.

¿En qué se diferencia retransmission de RST en el sentido del diagnóstico?

Retransmission es el reenvío de un segmento no confirmado, señal de pérdida de paquetes en el canal, pero la conexión aún está viva y lucha. RST es el cierre, una orden de olvidar la conexión. Una avalancha de retransmisiones que se convierte en RST se lee así: el canal perdía paquetes, la parte se cansó de esperar y cortó. Retransmisiones aisladas son normales en internet.

¿Qué significa zero window y tiene la culpa el proxy?

Zero window lo declara el receptor, cuyo búfer de recepción está desbordado porque la aplicación lee...

Sobre el autor

Andrey Kokh

Andrey Kokh

Leading Expert and Business Consultant

Experiencia laboral: Leading expert with 12 years of experience. Consults Forbes-listed companies, author of 3 books. Teaches at HSE and SKOLKOVO. His methodologies are used by hundreds of companies across Russia. RBC and Forbes expert on strategic development and digital transformation.
Formación académica: Higher School of Economics. Faculty of Economics, Master's Program
Especialización:
Strategic Consulting Digital Transformation Change Management Business Strategy Innovation Management Organizational Development Lean Management Agile Transformation

Comparte el artículo: