Problema de roteamento estranho

2

Estou tendo alguns problemas estranhos na internet no campus. Eu sei que é algo simples, mas é um caso em que preciso de outro par de olhos. Acho que posso explicar melhor o problema postando um tracert:

Tracing route to google.com [74.125.45.147]
over a maximum of 30 hops:

  1     3 ms     3 ms     3 ms  192.168.8.1 
  2     1 ms     1 ms     1 ms  elissaemily-pc.york.edu [192.168.10.5] 
  3     2 ms     2 ms     2 ms  rrcs-76-79-19-33.west.biz.rr.com [76.79.19.33] 
  4    31 ms     3 ms     2 ms  ge-1-1-0.lnclne00-mx41.neb.rr.com [76.85.220.109] 
  5    20 ms    17 ms    17 ms  ge-7-3-0.chcgill3-rtr1.kc.rr.com [76.85.220.137] 
  6    20 ms    20 ms    19 ms  ae-5-0.cr0.chi30.tbone.rr.com [66.109.6.112] 
  7    19 ms    19 ms    24 ms  ae-1-0.pr0.chi10.tbone.rr.com [66.109.6.155] 
  8    26 ms    24 ms    24 ms  74.125.48.109 
  9    23 ms    24 ms    21 ms  216.239.46.246 
 10    39 ms    39 ms    55 ms  209.85.242.215 
 11    39 ms    39 ms    39 ms  209.85.254.243 
 12    39 ms    40 ms    96 ms  209.85.253.145 
 13    39 ms    39 ms    39 ms  yx-in-f147.1e100.net [74.125.45.147] 

Trace complete.

Observe a segunda entrada lá. Não apenas o nome do host é um computador student , mas o endereço IP não existe. Dhcp mostra que o host tem um endereço diferente e você não pode pingar nenhum 192.168.10.5. No entanto, de alguma forma, é roteamento de pacotes para nós (e também não muito bem - as coisas estão lentas agora). O resto do tracert parece bem (nós temos uma conexão de fibra de 20Mb do road tripner). Um tracert da vlan admin (sub-rede 10.x.x.x) mostra os resultados esperados.

A tabela de roteamento de rede básica é assim:

Destination     Subnet Mask     Gateway
---------------------------------------
Default Route   --              10.1.1.5 (our firewall)
10.0.0.0        255.0.0.0       --
192.168.8.0     255.255.252.0   --

Atualização / resultado
Aqui está toda a história para os curiosos.

Várias semanas atrás, aumentamos o intervalo de IP para os alunos de 192.168.8.0/23 a 192.168.8.0/22. Para tornar isso possível, tivemos que remover um intervalo 192.168.10.0/24 antigo e não utilizado do servidor dhcp e da interface correspondente do nosso comutador principal. Nós terminamos este projeto e as coisas pareciam funcionar por um tempo.

Infelizmente, perdemos um detalhe no firewall. Ele tinha uma interface configurada para 192.168.10.5/24 que estava lá para servir o antigo intervalo (o roteador de mistério, exatamente onde deveria estar). De início, funcionou porque a maioria dos dispositivos na rede de alunos ainda obtinha IPs na primeira parte do intervalo. Se alguém reclamou, no momento em que fizemos o check-out, eles reiniciam o computador e obtêm um endereço IP de trabalho.

Nós realmente não tivemos problemas até depois das férias de primavera, quando todos os alunos voltaram ao mesmo tempo. Houve alguns conflitos de DHCP, alguns dispositivos novos e eu reconfigurei alguns roteadores sem fio de consumo que tenho que usar para funcionar como pontos de acesso. De repente, tivemos muitos outros dispositivos recebendo endereços 192.168.10.x. O suficiente para confundir o firewall e causar lentidão no campus, se você pudesse se conectar.

Fico feliz em ter este fixo, deixe-me dizer-lhe.

    
por Joel Coel 30.03.2010 / 15:30

4 respostas

1

Verifique a entrada reversa do ponteiro DNS para 192.168.10.5, é provável que aponte para o nome do host desse PC. Não significa que os pacotes estão indo para esse PC, apenas que o DNS reverso está errado.

Muitos roteadores têm firewall para não responder a solicitações diretas de fora de sua sub-rede. Então, se você estiver na sub-rede 192.168.8.x, e ela estiver na sub-rede 192.168.10.x, provavelmente ela não responderá às suas solicitações (mesmo que apenas para executá-lo).

Verifique a tabela de roteamento em 192.168.8.1 e a tabela em seu roteador padrão. Portanto, se 192.168.8.1 estiver configurado com uma rota padrão de 192.168.n.m, vá para esse roteador e verifique sua tabela para a entrada 192.168.10.5 (provavelmente é o caso).

Se você está tendo problemas para localizar o roteador, o roteador 192.168.8.1 terá o endereço MAC do roteador. Você pode usar uma consulta MAC para obter o fornecedor do dispositivo. Seus switches (se gerenciados) saberão em que número de porta o dispositivo está conectado (localize-o novamente pelo endereço MAC).

    
por 30.03.2010 / 15:41
1

Talvez possamos descobrir mais sobre o seguinte:

  1. Gostaria de verificar se você obteve a tabela de roteamento do seu computador pessoal. Seria ótimo se pudéssemos visualizar os valores das métricas de roteamento também.
  2. Seria possível se você pudesse fornecer sua saída "ipconfig / ifconfig", por exemplo, IPv4 + subnet mask + gateway "?
  3. Sua máquina também recebeu um nome de host DNS similar? Você é capaz de fazer alguém pingar sua máquina com seu nome de host como parâmetro?
  4. A sua máquina é o único terminal afetado pelos resultados traceroute acima? Seus colegas que estão utilizando a mesma rede também são afetados?

Se você disser "Sim" para o Ponto # 4 - minha reação imediata será tentar configurar um sniffer de pacotes, como Ethereal / Wireshark para detectar anomalias em todos os pacotes de entrada / saída do terminal afetado.

Felicidades!

    
por 30.03.2010 / 15:55
0

Eu fiz isso uma vez e estava testando algo e adicionei uma entrada ao arquivo hosts assim que mais tarde toda vez que eu pingasse via ip o roteador ele mostraria esse nome de host estranho .. demorei um pouco para lembrar que eu tinha editado o arquivo hosts! mudo ....

    
por 30.03.2010 / 16:04
0

A primeira coisa que eu gostaria de fazer é ping 192.168.10.5 de 192.168.8.1 (o interruptor principal). Depois disso, ele deve estar visível na tabela ARP do switch (para obtê-lo sob o IOS, basta digitar sh arp | i 192.168.10.5 ). Isso deve permitir que você encontre o fabricante da placa de rede ( Essa URL é um bom ponto de partida) e também permite que você encontre qual porta de switch de saída é para esse MAC (novamente, sob IOS, sh mac-address address MACgoesHERE ) e isso deve fornecer informações suficientes para prosseguir.

Não é impossível que o dispositivo tenha enviado redirecionamentos de ICMP para uma variedade de endereços IP, apontando para si mesmo em vez de para qualquer que seja o próximo salto.

    
por 30.03.2010 / 16:39

Tags