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.
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?
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.
[@ 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]