O traceroute falha em um país e é bem-sucedido em outro

Question

Alugamos um servidor na República Tcheca, onde nosso site está funcionando.

Quando eu o rastreio dos EUA, Índia, Rússia ou Ucrânia tudo está funcionando bem, o log de rastreamento mostra que a consulta atinge o roteador da empresa de hospedagem. Portanto, o site é muito bem acessível em todos esses países.

No entanto, quando o rastreamento da Finlândia faz uma consulta, ele chega ao nó na República Tcheca (xe100-5.RT.STL.PRG.CZ.retn.net [87.245.233.182]) e para de exibir timeouts. Suponho que esse nó não tenha nada a ver com a empresa de hospedagem. Como resultado, os caras na Finlândia não são capazes de olhar para o nosso lindo site :)

Duas coisas me confundem:

Em primeiro lugar, o rastreamento da Índia passa pelo mesmo nó tcheco, e os endereços IP coincidem. No entanto, o rastreamento vai além e atinge o roteador da empresa de hospedagem, o que não é o caso da Finlândia. Como isso pode acontecer?

Em segundo lugar, os usuários na Finlândia realizaram o rastreamento dentro de sua rede corporativa. No entanto, quando um dos funcionários tentou fazê-lo em casa, o site estava acessível, por isso suponho que o rastreamento também estava bem.

O pior é que os helpdesks de ambos os lados me apontam um ao outro afirmando que o problema está além de sua área de responsabilidade.

ATUALIZAÇÃO:

Eu recebi uma resposta do RETN que controla o roteador RT.STL.PRG.CZ

As can be seen from our looking glass (http://lg.retn.net/), the next hop after RT.STL.PRG.CZ towards you IP address in Czech Republic would be GW1-HostTelecom.retn.net (87.245.246.98) — AS51248 border.

As can be seen from the second trace, they do not use us to reach the IP address in Finland.

I'd suggest looking into AS1759 for the source of the problem.

*second trace means trace back from the server in CR to the client's IP address in Finland

e agora imaginando como eles chegaram a uma conclusão de que o AS que transferiu com sucesso o tráfego pode ser responsável pelo problema, enquanto o roteador que bloqueou tudo não tem culpa.

A segunda pergunta é como eu posso entrar em contato com qualquer pessoa responsável relacionada ao AS1759, por favor me aponte para uma maneira comum de traduzir o ASN para o e-mail.

Finalmente, por que o RETN trata como um problema que o rastreio de retorno via rota diferente? É realmente um sintoma de problema de roteamento?

    

Answer 1

Possível causa rara: problemas de propagação do BGP

É possível que determinado sistema autônomo esteja inacessível a outro devido a erros de configuração, erros de filtragem ou < href="http://www.crn.com/news/networking/171204130/cogent-level-3-in-standoff-over-internet-access.htm"> um jogo de postura financeira . Eu só encontrei isso uma vez no meu link residencial, mas tenho certeza que meu ISP ficou um pouco confuso quando aumentei o suficiente para que alguém entendesse.

Veja alguns servidores de espelhos e veja se você pode encontrar algo estranho sobre como o sistema em questão é propagando seu endereço.

    

Answer 2

Embora isso seja estranho, lembre-se de que sua capacidade de traceroute ou ping não significa necessariamente que você não poderá acessar determinadas portas ou protocolos no servidor remoto. Uma ferramenta mais precisa para testar se algumas portas estão, de fato, sendo bloqueadas (e mais especificamente, em qual hop), tente usar traceproto . Geralmente não é instalado por padrão, mas é uma ferramenta bastante comum para ser facilmente instalável através do sistema de gerenciamento de pacotes da sua distro.

Para uma maneira mais rápida de testar a disponibilidade de portas e / ou serviços sem se preocupar com qual hop está descartando os pacotes, você pode usar apenas nmap .

Sugiro fornecer ao provedor da sua rede corporativa a saída do rastreamento, além de mostrar a saída do rastreamento de outra fonte que pode acessar o destino pelo mesmo salto. Eles devem ser capazes de fornecer um motivo e, caso contrário, você deve pedir que eles investiguem mais, pois é de seu interesse garantir que os intervalos de IP deles não sejam bloqueados em lugar algum.