HTTP Serviços inacessíveis de alguns ISPs

2

Eu tenho um problema muito estranho e não sei mais o que fazer. Todos os meus problemas começaram há algumas semanas.

Um esquema básico da minha rede está disponível na seguinte imagem:

Configuraçãobásica:

ServiçosM1:

  • Apachenaporta80
  • RoR com WEBrick na porta 4321
  • SSH na porta 22

Serviços M2:

Encaminhar encaminhamento de porta (Extern [E:] para interno)

  • E: 81 a M1: 80
  • E: 4321 a M1: 4321
  • E: 8080 para o roteador: 8080
  • E: 8081 a M2: 8080
  • E: 22 a M1: 22 (ssh)
  • E: 10000 a M1: 10000 (https webmin)
  • E: 3389 para M2: 3389 (rdc)

O problema:

Na porta 4321, tenho um tráfego de entrada bastante pesado. Meu problema começou quando percebi que meus serviços de HTTPD no M1 eram acessíveis apenas de alguns ISPs.

Meu provedor de serviços de Internet está me fornecendo um endereço IP estático (188.26.X.XXX), com base em uma conexão PPPOE e é chamado de RDS. Outros ISPs nesta discussão são ROMTELECOM, ORANGE, UPC e INTERSAT.

Após alguns testes, o problema foi o seguinte:

E: 81, E: 4321, E: 8080, E: 10000 não estava carregando do RDS (minha própria rede), ROMTELECOM, INTERSAT. E: 81, E: 4321, E: 8080, E: 10000 estava carregando de ROMTELECOM (região geográfica diferente), UPC e redes móveis como LARANJA.

E: 8081, E: 3389 e E: 22 era acessível de qualquer lugar.

Todos os serviços disponíveis na LAN.

Etapas de solução de problemas

  1. Desativando qualquer tipo de firewall no roteador e no M1.
    • Resultado: o mesmo problema.
  2. Alterando os endereços IP e MAC da LAN para Roteador (wan) e M1
    • Resultado: o mesmo problema.
  3. Alterando o Roteador Asus WL-520GU executando o DD-WRT com um WRT54GL executando o firmware padrão e depois o Tomato.
    • Resultado: o mesmo problema.
  4. Removendo o M1 da rede e instalando duas máquinas virtuais, VM1 e VM2 no M2. A VM1 tem a mesma configuração que o M1. A VM2 era para fins de teste e estava executando o WINDOWS XP com RoR para Windows e USBWebServer.
    • Resultado: VM1 mesmo cenário que M1 (ssh OK. RoR e apache não OK). VM2 inacessível.
  5. Removendo o roteador da rede e conectando diretamente ao M2. Encaminhando portas para VM1 e VM2.
    • Resultado: o mesmo problema.
  6. Freaking out.
    • Resultado: o mesmo problema.
  7. Chamando o suporte do ISP e enviando um email. Uma conversa telefônica foi feita e o problema foi explicado. Não há problemas conhecidos deles. Nenhuma alteração de tráfego do meu provedor.
    • Resultado: o mesmo problema.
  8. Repetindo etapas acima em ordem aleatória ...

Outros testes que fiz

Usando o WFetch, percebi que minha solicitação das redes afetadas foi recebida pelo meu servidor, mas a resposta foi frisada após alguns bytes. Usando o meu E: 81 com _h5ai como um serviço para as minhas imagens e outros propósitos de compartilhamento de arquivos, eu removi todos os arquivos e fiz um index.html com 1 caractere. Testando novamente o E: 81 das redes afetadas, o serviço ficou acessível e o conteúdo do index.html foi recebido. Adicionando caracteres ao arquivo, descobri que um index.html com ~ 1499 caracteres foi recebido sucessivamente. Adicionando mais um caractere, o efeito não responderá como descrito. Não há tempo limite do navegador, apenas esperando por uma resposta. Infelizmente, este buffer não era o mesmo na WEBrick. Uma resposta maior do meu servidor (~ 3k caracteres) foi necessária para reproduzir o problema. O E: 8081 estava acessível o tempo todo em todas as redes.

Além disso, percebi que, se eu solicito uma página não existente: 81 / xyz ou: 4321 / xyz, recebo o erro 404. Dos servidores HTTP, apache2 e WEBrick. Isso tem a ver com a quantidade máxima de dados permitidos como resposta.

Reproduzindo o problema

Minha configuração atual contém a VM1. M1 e VM2 foram removidos. Tente acessar 188.26.X.XXX:4321 e 188.26.X.XXX:81 pelo navegador e, se não estiver funcionando, por WFetch .

Obrigado e espero que tenha esclarecido meu problema.

    
por andySF 09.07.2012 / 13:15

2 respostas

2

I discovered that a index.html with ~1499 characters was successively received. Adding one more character the effect will become unresponsive as described.

Isso sugeriria um problema de MTU (link da Wikipedia) no qual seu roteador está enviando pacotes grandes que outro roteador não é capaz de manuseio.

Em termos laymans, toda a comunicação através da rede / internet é dividida em pequenos pacotes, mas o tamanho do pacote não é fixo. O MTU (unidade de transmissão máxima) é o tamanho máximo que um dispositivo (por exemplo, seu roteador) deve enviar. Se você tentar enviar um pacote maior, seu dispositivo deverá dividir o pacote em dois pacotes e enviá-los separadamente.

Mas um problema pode ocorrer se o seu roteador envia um pacote grande para outro roteador que não é capaz de lidar. Nessa situação, o roteador assumirá que o pacote foi perdido e o enviará novamente, e, como isso também falhará, ele será enviado repetidas vezes até que desista).

Reduzir o MTU em seu roteador significaria que seu roteador enviaria pacotes menores que o outro roteador pode aceitar e tudo começa a funcionar.

Então, por que nem todos usam uma pequena configuração de MTU que todos podem aceitar. Bem, todo pacote enviado tem uma sobrecarga, por exemplo, informações sobre de quem é o pacote e para quem ele deve ser enviado, e também deve receber uma resposta indicando que o pacote foi recebido corretamente. Portanto, quanto menor o tamanho do pacote, mais pacotes você precisa enviar e maior a sobrecarga e isso atrasa a conexão. (Por exemplo, por motivos de desempenho, entendo que o XBOX ao vivo requer um MTU de pelo menos 1364)

Portanto, a recomendação normal é usar as configurações padrão, exceto quando houver problemas e, nesse caso, você continuará reduzindo as configurações de MTU (em etapas de 10) até encontrar um valor que funcione de forma confiável.

A configuração padrão pode depender do tipo de conexão de rede que você está usando. Por exemplo, o padrão em uma rede interna do Windows é 1500, enquanto o padrão para conexões à Internet usando PPPoE é 1492.

    
por 10.07.2012 / 15:55
0

De acordo com SANS , a porta 4321 foi usada pelo trojan BoBo. Como você não especificou UDP ou TCP, gostaria de saber se é possível que essa porta tenha sido desligada por alguns ISPs?!?! Você também pode querer olhar para este site para informações adicionais sobre a porta 4321. Além disso, meu entendimento é de muitos Os ISPs desaprovam as pessoas que executam seus servidores da web, a menos que seja um negócio com um contrato comercial com o ISP.

    
por 09.07.2012 / 14:06