Suspeito que o governo do meu país está destruindo o pacote ACK recebido em conexões TCP, de alguma forma.
Quando tento estabelecer uma conexão TCP com um host externo em portas diferentes de 80, o handshake TCP não será bem-sucedido. Capturei o arquivo pcap (gmail.pcap: link ) 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 conheço estão corretos. Alguém poderia me dizer por que meu computador (uma máquina linux) enviará o pacote RST?
Da linha do cmd:
openssl s_client -connect serveryourtryingtocontact.com:443
Isso deve verificar se você pode conectar SSL ao host remoto. Talvez faça um Wireshark desse tráfego.
Se você não tem o openssl, você pode apt-get install openssl .
Precisamos determinar onde o RST está sendo gerado. Isso acontece com todos Sites SSL? Você tem uma conexão direta com o seu gateway NAT? Você está usando um proxy?
O uso deste método exclui qualquer problema com sua pilha SSL.
Embora se diga que o governo iraniano rompe o HTTPS de tempos em tempos, a partir dos dados que você forneceu, parece que o SYN de resposta, o pacote ACK de 173.194.32.22 está chegando ao seu host, mas nunca chegando ao seu Pilha TCP. A pilha repete enviando SYNs após um segundo, dois segundos, quatro segundos e oito segundos respectivamente - mas aparentemente nunca está vendo uma resposta.
A entrada SYN, ACK parece ser filtrada - você não tem uma regra iptables para o tráfego tcp em sua cadeia INPUT que tem uma REJECT --reject-with tcp-reset alvo por acaso?
Tags networking firewall tcp rst