Minhas conexões TCP são sabotadas pelo governo do meu país?

Suspeito que o governo do meu país esteja destruindo o pacote ACK recebido nas conexões TCP, de alguma forma.

Quando tento estabelecer uma conexão TCP com um host externo em portas que não sejam 80, o handshake do TCP não será bem-sucedido. Capturei o arquivo pcap (gmail.pcap: http://www.slingfile.com/file/aWXGLLFPwb ) e descobri que meu computador receberá o ACK após enviar o TCP SYN, mas em vez de responder com um SYN ACK, ele enviará um RST.

Eu verifiquei o pacote ACK do host externo, mas parece completamente legítimo. O número de sequência e todos os sinalizadores que eu conheço estão corretos. Alguém poderia me dizer por que meu computador (uma máquina Linux) enviará o pacote RST?

captura de tela pcap

— Mohammad
fonte

Podemos perguntar qual país?

— Kev

Eu deliberadamente não mencionei isso. Mas agora que você pergunta, não consigo pensar em uma razão para não contar. Este é um dos meus problemas diários no Irã.

— Mohammad

A captura feita em sua máquina está tentando estabelecer a conexão?

— the-wabbit

Sim. Eu executo o tcpdump -w gmail.pcap e, em seguida, o telnet gmail.com 443.

— Mohammad

O telnet não funcionará, você precisa ver a minha resposta abaixo :-)

— The Unix Janitor

Respostas:

Na linha cmd:

openssl s_client -connect serveryourtryingtocontact.com:443

Isso deve verificar se é possível conectar SSL ao host remoto. Talvez faça um Wireshark desse tráfego.

Se você não possui o openssl, pode apt-get install openssl.

Devemos determinar onde o RST está sendo gerado. Isso acontece com todos os sites SSL? Você tem uma conexão direta com o seu gateway NAT? você está usando um proxy?

O uso desse método elimina qualquer problema com sua pilha SSL.

— O zelador do Unix
fonte

O problema não é SSL. É o TCP. A conexão TCP não será estabelecida em primeiro lugar, portanto, o SSL nem começará a enviar seu cabeçalho. não é apenas o número da porta 443, por exemplo, eu não consigo nem iniciar uma conexão http normal com um servidor na porta 8000 e seu comando openssl resultará em "connect: Connection timed out" #

— Mohammad

Embora haja rumores de que o governo iraniano interrompa o HTTPS de tempos em tempos, a partir dos dados que você forneceu parece apenas o pacote SYN, ACK de 173.194.32.22 que está respondendo está chegando ao seu host, mas nunca chegando à sua pilha TCP. A pilha tenta enviar SYNs após um segundo, dois segundos, quatro segundos e oito segundos, respectivamente - mas aparentemente nunca está vendo uma resposta.

O SYN de entrada, ACK parece estar filtrado - você não tem uma iptablesregra para o tráfego tcp na sua cadeia de ENTRADA que tem um REJECT --reject-with tcp-resetalvo por acaso?

— o wabbit
fonte

Não, meu iptables não possui nenhuma regra e, em outra nota, devo dizer que posso estabelecer uma conexão TCP com êxito para qualquer host dentro do Irã ou mesmo para alguns sites estrangeiros (apenas o kernel.org atualmente!)

— Mohammad

Meu palpite é que o governo está alterando o segundo pacote (SYN / ACK) para que o pacote não seja válido e, portanto, nunca está chegando à pilha TCP.

— Mohammad

@ Mohammad O pacote é válido. Mesmo se não fosse, a pilha não faria as duas coisas: responder com um RST e prosseguir como se não tivesse sido recebida. Algo está pegando no caminho para a pilha. Sugiro a inicialização de um conhecido-instalação limpa (por exemplo, um CD Linux live) e re-executar os testes

— o wabbit

Obrigado. Também não encontrei nenhum problema com o pacote ACK. Mas o problema é que esse problema acontece todos os dias (de 4 dias atrás) de manhã no meu local de trabalho! Todo corpo (cerca de 50 pessoas) tem exatamente o mesmo problema e ainda me pergunto por quê? Não tenho o mesmo problema em casa, mas ouvi de meus amigos que a Internet tem sérios problemas hoje em dia.

— Mohammad

@Mohammad verifique se há malware então. A execução de uma instalação limpa conhecida, como sugerido acima, é um teste fácil e significativo para este caso.

— the-wabbit