Um pequeno quebra-cabeça sobre o roteamento

1

Este é um seguimento para esta questão que eu vi no SuperUser, para o qual não resposta foi fornecida.

Um usuário excluiu a segunda rota em sua tabela de roteamento,

# ip route show
  default via 192.168.73.1 dev eth0  proto static 
  192.168.73.0/24 dev eth0  scope link 

deixando apenas o padrão dele. Ele descobriu que poderia ping de outros PCs na rede, mas eles não poderiam ping voltar o pc com a tabela de roteamento incompleta.

Eu investiguei isso em uma rede real (em oposição à configuração original, virtual) por meio de tcpdump : Acontece que o pc incompleto envia uma resposta para o ping, mas isso não alcança o PC original e saudável.

Então, tentei abrir uma sessão ssh em ambas as direções e agora as duas tentativas falham. Esta é a captura de Wireshark da conexão com falha:

A presença do PUSH (PSH / ACK) e o grande número de retransmissões deixam claro que o pc é incapaz de alcançar o outro.

Alguém pode explicar por que, com algum detalhe?

    
por MariusMatutiae 17.11.2015 / 15:15

2 respostas

0

Suponho que você tenha esquecido a rota de volta no outro site. O pc do outro lado precisa configurar um gateway apropriado para alcançar a rede, ao invés disso, use o padrão gw.

    
por 17.11.2015 / 15:25
0

[@ moderators ecc, isso estava ficando muito longo nos comentários, então eu apostaria na minha resposta. Vou atualizar isso]

Sem a possibilidade de testá-lo totalmente agora, vou tentar adivinhar. A falta da rota na subnet da eth0 significa que tudo deve passar pelo gateway padrão.

Na verdade eu tentei na minha máquina de onde eu só posso pingar outro host e o gateway na mesma sub-rede, mas o que eu vejo parece estar de acordo com o que eu estava supondo.

Os pacotes da minha máquina (que está faltando a rota para a sub-rede local) vão com o IP que estou pingando, mas com o endereço arp do gateway. Verifique no seu sniff os endereços arp no wireshark para que possamos ter mais dados.

E faça um teste limpo, depois de limpar seu cache ARP e postar aqui ambas as suas descobertas.

O que eu acho que está acontecendo é que a rota no IP do cliente (nosubnet) é necessária para que a pilha de rede saiba onde "arp" livremente, uma vez que é reapropriada sem gateways.

Puxando isto, a única rota possível é o GW padrão e eu suponho que há somente uma interface de rede naquela máquina (sem sub-rede).

Agora, considerando que você está lançando pacotes arp para o gateway, significa enviar pacotes de endereços arp para um cliente com outro IP (o destino) na mesma sub-rede.

O GW os encaminha no endereço ARP do destino, o destino tendo a rota local configurada corretamente responde ao host de envio (aquele sem a sub-rede).

Roteamento assimétrico em suma.

O primeiro host, o remetente sem a rota de sub-rede local correta, vê isso como um pacote malformado (Alien) quando foi enviado para o endereço ARP do gateway.

[/ me hopping nenhum cara da rede vai me acertar com um pau grande para meus eventuais erros]

    
por 17.11.2015 / 22:43