¿Mis conexiones TCP son saboteadas por el gobierno de mi país?

Sospecho que el gobierno de mi país está destruyendo el paquete ACK recibido en las conexiones TCP, de alguna manera.

Cuando trato de establecer una conexión TCP a un host externo en puertos que no sean 80, el protocolo de enlace TCP no tendrá éxito. Capturé el archivo pcap (gmail.pcap: http://www.slingfile.com/file/aWXGLLFPwb ) y descubrí que mi computadora recibirá el ACK después de enviar TCP SYN pero en lugar de responder con un SYN ACK enviará un RST

Revisé el paquete ACK desde un host externo, pero parece completamente legítimo. El número de secuencia y todos los indicadores que conozco son correctos. ¿Alguien podría decirme por qué mi computadora (una máquina Linux) enviará el paquete RST?

captura de pantalla de pcap

networking firewall tcp rst Mohammad
fuente

¿Podemos preguntar qué país?

Kev

Deliberadamente no lo mencioné. Pero ahora que lo preguntas, no se me ocurre una razón para no decírtelo. Este es uno de mis problemas cotidianos en Irán.

Mohammad

¿La captura tomada de su máquina está tratando de establecer la conexión?

the-wabbit

Si. Ejecuto tcpdump -w gmail.pcap y luego telnet gmail.com 443.

Mohammad

telnet no funciona, necesita ver mi respuesta a continuación :-)

The Unix Janitor

Respuestas:

Desde la línea cmd:

openssl s_client -connect serveryourtryingtocontact.com:443

Esto debería verificar si puede conectarse SSL al host remoto. Quizás haga un Wireshark de este tráfico.

Si no tienes openssl, entonces puedes apt-get install openssl.

Debemos determinar dónde se genera el RST. ¿Le sucede a todos los sitios SSL? ¿Tiene una conexión directa a su puerta de enlace NAT? ¿Está utilizando un proxy?

El uso de este método descarta cualquier problema con su pila SSL.

El conserje de Unix
fuente

El problema no es SSL. Es TCP. La conexión TCP no se establecerá en primer lugar, por lo que SSL ni siquiera comenzará a enviar su encabezado. no es solo el número de puerto 443, por ejemplo, ni siquiera puedo iniciar una conexión http normal a un servidor en el puerto 8000 y su comando openssl dará como resultado "conectar: se agotó el tiempo de conexión"

Mohammad

Aunque se rumorea que el gobierno iraní rompe el HTTPS de vez en cuando, según los datos que ha proporcionado, simplemente parece que el paquete SYN, ACK que responde desde 173.194.32.22 llega a su host, pero nunca llega a su pila TCP. La pila vuelve a intentar enviar SYN después de un segundo, dos segundos, cuatro segundos y ocho segundos respectivamente, pero aparentemente nunca ve una respuesta.

El SYN entrante, ACK parece estar filtrado: ¿no tiene una iptablesregla para el tráfico tcp en su cadena INPUT que tiene un REJECT --reject-with tcp-resetobjetivo por casualidad?

el wabbit
fuente

No, mi iptables no tiene ninguna regla y, en otra nota, debo decir que puedo establecer una conexión TCP con éxito a cualquier host dentro de Irán o incluso a un par de sitios web extranjeros (¡solo kernel.org en realidad!)

Mohammad

Supongo que el gobierno está cambiando el segundo paquete (SYN / ACK) por lo que el paquete no es válido y, por lo tanto, nunca llega a la pila TCP.

Mohammad

@Mohammad El paquete es válido. Incluso si no fuera así, la pila no haría ambas cosas: responder con un RST y proceder como si no se hubiera recibido. Algo lo está atrapando en el camino a la pila. Sugiero arrancar una instalación limpia conocida (por ejemplo, un CD de Linux en vivo) y volver a ejecutar las pruebas

the-wabbit

Gracias. Yo tampoco pude encontrar ningún problema con el paquete ACK. ¡Pero la cuestión es que este problema ocurre todos los días (desde hace 4 días) en la mañana en mi lugar de trabajo! Todos los cuerpos (aproximadamente 50 personas) tienen exactamente el mismo problema y todavía me pregunto por qué. No tengo el mismo problema en casa, pero escucho de mis amigos que Internet tiene serios problemas en estos días.

Mohammad

@Mohammad busca malware entonces. Ejecutar una instalación limpia conocida como se sugirió anteriormente es una prueba fácil y significativa para este caso.

the-wabbit