Após as sugestões dos queridos comentaristas, procurei ver se um problema de MTU poderia ser a causa.
O seguinte foi encontrado ao tentar conectar-se do "Site A" ao "Site B" de um sistema Fedora. Em um sistema Windows, tudo está funcionando perfeitamente - wireshark indica que o comprimento dos pacotes de saída nunca excede 1158 bytes, então o problema não é acionado lá.
Em resumo, se eu ler corretamente:
- Existe uma troca bem sucedida inicial de pequenos pacotes.
- Um pacote com tamanho 1900 é enviado. Eu suponho que a placa de rede
divida isso porque o MTU para a rede local é de 1500.
- Um roteador na rede ISP com endereço 10.10.80.7 nos diz "por favor
fragmentar o pacote para MTU 1492 ".
- Wilco! Um pacote com comprimento 1492 é enviado.
- Um roteador na rede ISP com endereço 10.10.80.7 nos diz para
"por favor, fragmentar o pacote para MTU 1492".
- As coisas desçam a partir daqui.
Parece que terei que abrir um ticket com o ISP (que é o POST Telecom Luxembourg, caso alguém pesquise problemas semelhantes).
Também sugere uma correção. Forçar o MTU para SITE_A a 1000:
ip route add $SITE_A_IP via $GATEWAY_IP dev $ETHDEV mtu lock 1000
De fato, isso resolve o problema.
Informação de referência
Use ping para testar o comportamento da MTU:
ping -c $COUNT -M $MTUDS -s $PPLSZ $HOST
onde
-
COUNT=1 : "Apenas um ping"
-
MTUDS=do : A estratégia de descoberta de MTU é "proibir a fragmentação, mesmo local", ou seja, definir o bit 'DF' (não fragmentar) (por que isso é 'do'? dunno). USE ESTE.
-
MTUDS=want : A estratégia de descoberta da MTU é "fazer descoberta do PMTU, fragmentar localmente quando o tamanho do pacote é grande", ou seja, definir o bit 'DF' e fragmentar localmente
-
MTUDS=dont : a estratégia de descoberta da MTU é "não defina o bit 'DF'", ou seja, fragmento conforme necessário
-
PPLSZ=1464 : tamanho do payload do pacote ping ICMP em byte.
Use tcpdump para monitorar todos os pacotes e pacotes ICMP de e para o "Site A":
tcpdump -vvv -n -nn icmp or '(' host $SITE_A_IP ')'
Isso é um pouco difícil de ler.
Veja o que o kernel pensa sobre o MTU para o "Site A".
watch ip route get to $SITE_A_IP
Observe que um MTU menor que o padrão será armazenado em cache com um TTL de 600 segundos após o primeiro ping com falha.
Cenário
Suponha que o tamanho máximo do pacote IP em byte (ou seja, o tamanho da carga Ethernet) seja 1492 (esse é o caso no Amazon EC2), então um tamanho interessante de carga útil seria 1465, porque o byte 28 usado para o IP e informações de cabeçalho ICMP dariam 1493, um byte pas no máximo.
Então ping -c 1 -M want -s 1465 $HOST_IP faz o seguinte:
No primeiro ping você recebe "Frag needed e DF set (mtu = 1492) 100% de perda de pacotes". tcpdump mostra a parte de solicitação de eco 1 (comprimento 1493) saindo e um roteador da rede de destino enviando de volta um "ICMP inacessível" com a solicitação para fragmentar a MTU 1492. Uma entrada em cache com MTU = 1492 aparece na rota do kernel cache.
Em pings subsequentes, você recebe "1 pacotes transmitidos, 1 recebido". tcpdump mostra a parte de pedido de eco 1 (comprimento 1492) e a parte de pedido de eco 2 (comprimento 21, deslocamento 1472) e a resposta de eco correspondente (comprimento 1493).
Ou você pode usar o traceroute
# traceroute --mtu SITE_A 1500
Tamanho do pacote de 1500. Traceroute nos diz que a rota 10.10.80.7 tem MTU 1492
traceroute to SITE_A (SITE_A_IP), 30 hops max, 1500 byte packets
1 gateway (192.168.10.1) 0.550 ms 0.536 ms 0.393 ms
2 192.168.178.1 (192.168.178.1) 1.458 ms 1.485 ms 1.344 ms
3 10.10.80.7 (10.10.80.7) 4.889 ms F=1492 2.968 ms 4.854 ms
4 10.10.80.7 (10.10.80.7) 4.955 ms !F-1492 3.559 ms !F-1492 5.022 ms !F-1492
Tente com 1492: mesmo problema!
traceroute to SITE_A (SITE_A_IP), 30 hops max, 1492 byte packets
1 gateway (192.168.10.1) 0.635 ms 0.554 ms 0.483 ms
2 192.168.178.1 (192.168.178.1) 1.510 ms 1.504 ms 1.311 ms
3 10.10.80.7 (10.10.80.7) 48.305 ms 17.436 ms 5.496 ms
4 10.10.80.7 (10.10.80.7) 5.963 ms !F-1492 6.865 ms !F-1492 4.887 ms !F-1492
Tente com 1491: o mesmo problema!
traceroute to SITE_A (SITE_A_IP), 30 hops max, 1491 byte packets
1 gateway (192.168.10.1) 0.594 ms 0.650 ms 0.492 ms
2 192.168.178.1 (192.168.178.1) 1.716 ms 1.782 ms 1.580 ms
3 10.10.80.7 (10.10.80.7) 7.327 ms 7.385 ms 4.775 ms
4 10.10.80.7 (10.10.80.7) 5.210 ms !F-1492 5.624 ms !F-1492 4.841 ms !F-1492
Tente com 1490: passamos. Não é obrigado a haver algum erro off-by-one lá.
traceroute to SITE_A (SITE_A_IP), 30 hops max, 1490 byte packets
1 gateway (192.168.10.1) 0.616 ms 0.688 ms 0.484 ms
2 192.168.178.1 (192.168.178.1) 1.712 ms 1.853 ms 1.611 ms
3 10.10.80.7 (10.10.80.7) 6.248 ms 7.008 ms 4.995 ms
4 SITE_A_IP.dyn.luxdsl.pt.lu (SITE_A_IP) 12.441 ms !X 9.641 ms !X 9.576 ms !X
Mais informações de interesse:
