Como faço para diagnosticar corrupção de rede em um caminho da Internet?

Question

Eu executo alguns hosts na rede A que fazem solicitações a servidores (que eu não possuo) na rede B, em algum ponto da Internet. Infelizmente, muitos desses pedidos são corrompidos. Se eu fizer as solicitações por HTTP não criptografado, recebo erros estranhos que sugerem uma solicitação corrompida. Se eu fizer solicitações por HTTPS, obtenho erros no nível de SSL. Eu posso reproduzir o problema executando:

sh -e -c 'while true; do curl $SERVER > /dev/null; sleep 1; done'

Geralmente dentro de 20 solicitações, o curl falha com um erro como "Erro de protocolo SSL desconhecido" ou "erro de descriptografia de alerta tlsv1". Eu posso reproduzir isso em vários hosts na rede A, acessando vários servidores na rede B. Mas não consigo reproduzir da rede A para outros servidores ou de outros hosts para a rede B. Nesses casos, o loop é executado sem erros. / p>

Portanto, está bem claro que o fluxo de TCP está corrompido entre A e B. Isso já dura mais de 3 dias, a propósito.

Primeira pergunta: Como isso pode acontecer plausivelmente? O TCP tem checksums em nível de pacote, e pacotes corrompidos passando pela soma de verificação devem ser muito mais raros do que eu estou vendo. Além disso, se eu executar uma captura de rede, não vejo muitas retransmissões (de acordo com o filtro tcp.analysis.retransmit da wireshark), o que você esperaria se os pacotes estivessem sendo corrompidos e falhassem a soma de verificação TCP. Eu acho que algum roteador deve estar fazendo o maior nível de manipulação de dados (NAT? Proxy transparente?) E corrompendo os dados, mas corrigindo a soma de verificação?

Segunda pergunta: Existe alguma ferramenta que eu possa usar para isolar o problema? Eu não consigo encontrar nenhum. Se eu soubesse a topologia de rede e conseguisse encontrar servidores HTTPS por trás de cada salto entre A e B, eu poderia executar meu teste neles. Mas eu não sei. Que outro teste apareceria corrupção da rede?

Entrei em contato com os proprietários da rede A e da rede B, mas eles não foram úteis até agora.

Atualização: para qualquer um que sugira que tipo de dispositivo com bugs pode estar no caminho, existe alguma maneira de detectar isso além de entrar em contato com o proprietário?

    

Answer 1

Primeiro, seria útil ver se você pode replicar a corrupção de dados usando o ping, em vez de usar o TCP. O ping usa um eco ICMP, envia uma carga útil conhecida (que você pode especificar se precisar) e informará se a carga está corrompida quando retornada. Pelo menos, isso é o que a página de manual me diz.

Você provavelmente desejará usar um tamanho de pacote longo (talvez 1400 bytes ou mais) e ver se é possível especificar um intervalo baixo, talvez 0,1 segundos, para poder reproduzir o erro em um período de tempo razoável. Essas configurações geram aproximadamente 15 kB / s de tráfego para e do servidor. (1400 bytes / 0,1 segundo + sobrecarga)

Então, por que usar um ping em vez da conexão TCP? Como provavelmente você pode executar ping na maioria dos hosts no caminho entre o servidor e seu cliente e, portanto, é possível testar apenas parte do caminho .

Começando testando o caminho completo (até o seu servidor, para determinar se o teste reproduz seu problema). Armado com um traceroute, você pode testar apenas parte do caminho. Cada teste que você faz pode dividir seu espaço de busca pela metade e, após alguns testes, você poderá encontrar o salto que está causando seus problemas.

Ressalva: Isso não funcionará da maneira esperada se a corrupção estiver ocorrendo no caminho de retorno para a máquina de teste, e não no caminho a seguir. O traceroute só pode dizer a rota que seus pacotes estão levando para o servidor, não o caminho que os pacotes retornam, e esses caminhos não são necessariamente os mesmos. Ainda assim, deve ser o suficiente para você chegar a algum lugar.

Boa sorte!

    

Answer 2

Alguém ao longo da linha usa os Aceleradores de LAN / WAN? Essas peças de hardware às vezes estragam e precisam ser reiniciadas e podem ser a fonte de corrupção, bem como problemas de desempenho.

    

Answer 3

Poderia haver um IDS / IPS / proxy flakey em uma das redes que está distribuindo pacotes somente para / da outra rede? Isso explicaria por que não é reproduzível de ou para hosts diferentes.