Tenho um laptop Windows 10 com um problema peculiar que nenhum navegador consegue abrirhttps://rutracker.org/
É assim (no modo de ferramentas de desenvolvedor): por um longo tempo o navegador não reconhece que envia algo para o controle remoto (por exemplo, o Chrome relata que está 'parado') e então a solicitação é listada como falhada sem motivo aparente. Eu tentei também o Firefox e o Edge com os mesmos resultados, pois eles não conseguem se conectar e não fornecem qualquer depuração significativa.
Eu até instalei o cURL. O resultado é o seguinte:
curl -k -vvv https://rutracker.org/forum/index.php
* Trying 195.82.146.214...
* TCP_NODELAY set
* Connected to rutracker.org (195.82.146.214) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
então ele irá travar por um longo tempo e então reclamar de SSL_ERROR_SYSCALL. Por outro lado, no Linux parece totalmente diferente:
curl -k -vvv https://rutracker.org/forum/index.php
* Hostname was NOT found in DNS cache
* Trying 195.82.146.214...
* Connected to rutracker.org (195.82.146.214) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
* subject: CN=rutracker.org
* start date: 2018-07-20 04:13:49 GMT
* expire date: 2018-10-18 04:13:49 GMT
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
> GET /forum/index.php HTTP/1.1
> User-Agent: curl/7.38.0
> Host: rutracker.org
> Accept: */*
>
< HTTP/1.1 200 OK
Talvez exista uma construção de navegador que use OpenSSL puro, evite totalmente a implementação de SSL do Windows? Porque parece que é o problema aqui. Verifiquei recentemente com o Malwarebytes e não encontrei nada em particular.
EDITAR: Observei que isso só acontecerá quando eu estiver conectado por VPN PPTP. Quando mudei para L2TP, posso abrir o site repentinamente sem problemas. O que esta acontecendo aqui?
Responder1
Não há nada de errado com a biblioteca TLS do Windows (e de fato o curl no Linux se comporta da mesma maneira quando compilado no OpenSSL/1.1.0i) - ele simplesmente usa um formato de handshake mais recente que tenta usar menos mensagens maiores (reduzindo a latência), enquanto seu curl usa uma biblioteca antiga que ainda possui o modo "compatível com SSLv3".
Mas essa é apenas uma das muitas coisas que podem desencadear o mesmo problema. O verdadeiro problema é:
- No servidor VPN, a interface de rede virtual "clientes PPTP" tem seu MTU definido para um valor relativamente baixo (por exemplo, 1280 bytes) – para compensar a sobrecarga da VPN e mais alguns.
- Durante o handshake TLS, o servidor Rutracker envia um pacote IP maior que este MTU.
- O servidor VPN não pode encaminhar o pacote porque ele é maior que a interface de saída e retorna um pacote de erro ICMP "Too Large" indicando o MTU suportado.
- O servidor web Rutrackerignoraa mensagem ICMP, não ajusta seu cache de rota adequadamente e continua enviando o mesmo pacote grande. Recomece a partir do passo 2.
Essa negociação de MTU baseada em ICMP é chamada de "Path MTU Discovery", e a situação em que o remetente ignora o conselho do destinatário é conhecida como "PMTU blackhole". Talvez os administradores do Rutracker tenham ouvido em algum lugar que bloquear completamente o ICMP torna o site de alguma forma "mais seguro"...
Veja como fica do ponto de vista de um exemplo de servidor VPN (usando um OpenVPN deliberadamente mal configurado) – observe como o pacote grande está sendo recusado repetidamente:
IP 31.220.xy48872 > 195.82.146.214.443: Flags [S], seq 2337162999, win 29200, opções [mss 1358,sackOK,TS val 674971446 ecr 0,nop,wscale 7], comprimento 0 IP 195.82.146.214.443 > 31.220.xy48872: Flags [S.], seq 2391406816, ack 2337163000, win 14600, opções [mss 1460,nop,wscale 8], comprimento 0 IP 31.220.xy48872 > 195.82.146.214.443: Sinalizadores [.], ack 1, vitória 229, comprimento 0 IP 31.220.xy48872 > 195.82.146.214.443: Sinalizadores [P.], seq 1:217, ack 1, vitória 229, comprimento 216 IP 195.82.146.214.443 > 31.220.xy48872: Sinalizadores [.], ack 217, vitória 62, comprimento 0 IP 195.82.146.214.443 > 31.220.xy48872: Sinalizadores [.], seq 1:1359, ack 217, vitória 62, comprimento 1358 IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy inacessível - precisa frag (mtu 1280), comprimento 556 IP 195.82.146.214.443 > 31.220.xy48872: Sinalizadores [P.], seq 1359:3242, ack 217, vitória 62, comprimento 1883 IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy inacessível - precisa frag (mtu 1280), comprimento 556 IP 195.82.146.214.443 > 31.220.xy48872: Sinalizadores [.], seq 1:1359, ack 217, vitória 62, comprimento 1358 IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy inacessível - precisa frag (mtu 1280), comprimento 556 IP 195.82.146.214.443 > 31.220.xy48872: Sinalizadores [.], seq 1:1359, ack 217, vitória 62, comprimento 1358 IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy inacessível - precisa frag (mtu 1280), comprimento 556 IP 195.82.146.214.443 > 31.220.xy48872: Sinalizadores [.], seq 1:1359, ack 217, vitória 62, comprimento 1358 IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy inacessível - precisa frag (mtu 1280), comprimento 556 IP 195.82.146.214.443 > 31.220.xy48872: Sinalizadores [.], seq 1:1359, ack 217, vitória 62, comprimento 1358 IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy inacessível - precisa frag (mtu 1280), comprimento 556
A VPN L2TP não será afetada por vários motivos possíveis:
- ele poderia usar um padrão de 1.500 MTU para o túnel e fragmentar de forma transparente os pacotes superdimensionados;
- ele poderia realizar a fixação TCP MSS nas conexões que vê;
- ele poderia relatar o MTU reduzido ao software cliente VPN para que seu sistema operacional já saiba antecipadamente como colocar o MSS correto em suas solicitações de conexão TCP.
Como cliente, suas opções são (dependendo do suporte do sistema operacional):
- Não use VPNs PPTP. (Não devido a problemas de MTU – o PPTP não é melhor nem pior do que outros tipos de VPN nesse aspecto – mas sim devido a problemas de segurança que o protocolo tem. Tanto a criptografia MPPE quanto a autenticação MSCHAP são muito fracas.)
- Reduza o MTU da interface VPN (por exemplo, para 1400 ou 1280) no sistema operacional cliente. Por exemplo, o Linux permite que você faça
ip link set ppp0 mtu <bytes>. Conseqüentemente, seu sistema anunciará um valor TCP MSS mais baixo para os servidores Rutracker. - Habilite a investigação TCP MTU no sistema operacional cliente. Por exemplo, o Linux possui
sysctl net.ipv4.tcp_mtu_probing=1. Isso funciona mesmo onde o ICMP PMTUD não funciona. - Configure o cliente VPNoufirewall do servidor VPN para realizar a fixação TCP MSS. (Isso pode ser feito em qualquer lugar ao longo do caminho.)
- Tente convencer os administradores do Rutracker de que eles tomaram uma decisão errada.