Por que conexões TCP pequenas são bem-sucedidas, mas as grandes falhas?

3

Às vezes, no sistema Linux, vejo o seguinte comportamento estranho:

Eu consigo fazer ping e às vezes uso alguns serviços, mas a rede é muito ruim.

Por exemplo, agora eu roteei a conexão através do meu laptop ( -j MASQUERADE ) e observei o seguinte: Se eu faço pouca conexão TCP (o servidor envia poucos dados para mim), ele prossegue:

# nc 86.57.151.3 80
GET /404
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

/ proc / net / ip_conntrack tem tcp 6 431998 ESTABLISHED src=192.168.99.9 dst=86.57.151.3 sport=49104 dport=80 src=86.57.151.3 dst=93.125.21.218 sport= 80 dport=49104 [ASSURED] mark=0 use=2 antes de digitar "GET / 404".

Mas quando faço uma conexão grande:

root@localhost:~# nc 86.57.151.3 80
GET /

Paraliza. Antes de entrar "GET /", aparece ESTABLISHED ASSURED, como de costume, mas depois que eu pressionar Return, vai para tcp 6 0 CLOSE_WAIT src=192.168.99.9 dst=86.57.151.3 sport=56991 dport=80 src=86.57.151.3 dst=93.125.21.218 sport=80 dpo rt=56991 [ASSURED] mark=0 use=2 . Nenhum pacote com é recebido. Quando eu finalmente pressiono Ctrl + C, ele envia FIN para o servidor, e Wireshard reclama que o FIN do servidor está "fora de ordem". Como se a resposta estivesse em algum lugar.

Quando faço o mesmo nc 86.57.151.3 80 / GET / do roteador, funciona.

Como depurar o que está errado?

    
por Vi. 19.08.2011 / 21:01

1 resposta

4

Este é o problema com o MTU e as mensagens ICMP filtradas em algum lugar.

A solução alternativa é configurar o MTU no dispositivo cliente ou usar a fixação TCP MSS no roteador:

iptables -t mangle -A FORWARD -o ppp4 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
    
por 20.08.2011 / 00:17