Perguntei isso em engenharia de rede na troca de pilha e fui redirecionado aqui.
Eu tenho alguns servidores com a configuração abaixo
servidor1:
eno1: 127.15.0.1/16 scope global
eno2: 5.0.0.1/24
servidor2:
lo: 127.0.0.1/16 (it had /8. I changed the subnet mask using 'ip addr del 127.0.0.1/8 dev lo; ip addr add 127.0.0.1/16 dev lo')
eno2: 5.0.0.2/24
eno1 do server1 está conectado a uma rede L2 completamente diferente e está completamente isolado.
As interfaces eno2 de ambos os servidores estão conectadas à mesma rede L2. Agora tenho que acessar 127.15.0.1 do server2.
O Server1 foi implantado há muito tempo e não tenho permissão para alterar qualquer tipo de configuração. Não sei por que alguém usou a sub-rede 127.xxx com escopo global. Não tenho certeza se é uma configuração válida, mas tenho que conviver com isso. Tenho controle total do server2 e posso mudar qualquer coisa.
Ambos os servidores são baseados em Linux.
a conectividade entre 5.0.0.1 <-> 5.0.0.2 é boa.
Minha primeira tentativa foi adicionar uma rota no server2 conforme abaixo
ip r add 127.15.0.1/32 via 5.0.0.1 pingou 127.15.0.1 do servidor2. Vejo as solicitações e respostas de ping no tcpdump no server2, mas o comando ping está mostrando 100% de perda.
Desativei rp_filters
sysctl.cnf:
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.lo.rp_filter=0
net.ipv4.conf.eno2.rp_filter=0
reiniciado após atualizar o sysctl.conf
E eu limpei o iptables. (iptables-F)
Mesmo resultado. Achei que o servidor2 não gosta de usar a série 127.xxx. Então adicionei a regra abaixo no servidor 2
iptables -t nat -A OUTPUT -d 5.0.0.1 -j DNAT --to-destination 127.15.0.1
esta regra deve substituir o IP de destino para 127.15.0.1 se o pacote for destinado a 5.0.0.1.
pingado 5.0.0.1 do servidor2. O Iptables substituiu o IP de destino por 127.15.0.1 (confirmou isso no server1 tcpdump). Server1 respondeu, mas as respostas foram descartadas novamente.
Fiquei sem ideias neste momento. Desativei o server1 para manutenção e substituí 127.15.0.1/26 por 192.168.1.1/16. A conectividade funcionou bem neste caso (com e sem iptables). Agora a questão é: o problema é devido ao uso de 127.xxx? Se sim, existe uma saída?? Se não, o que mais posso tentar?
Nota: Esta configuração estava funcionando antes. Recentemente perdemos o server2 (que tinha Linux antigo) e estou construindo-o do zero. Além disso, o Windows não permite o uso de 127.xxx para interfaces diferentes de loopback. Não sei por que o Linux permite isso em interfaces não baixas. pode haver uma justificativa!
Para resumir, tenho estas perguntas:
- O Windows rejeita completamente a configuração quando tentamos configurar 127.xxx, mas o Linux permite isso e isso também com escopo global. Existe um caso de uso para isso?
- Nesse caso, o servidor2 envia solicitações destinadas a 127.xxx e o servidor1 está, na verdade, enviando respostas de volta. Se 127.xxx for apenasinterno do host, por que eles estão enviando pacotes no link?
Responder1
O sysctl do Linux sinaliza em
/sys/net/ipv4/conf/*/route_localnet
permitir desabilitar o tratamento razoável para tais pacotes.
route_localnet - BOOLEAN
Não considere endereços de loopback como origem ou destino marciano durante o roteamento. Isso permite o uso de 127/8 para fins de roteamento local. padrão FALSO
Como poucas pessoas sãs fariam tal coisa, isso pode ou não funcionar hoje em dia (eu testei pela última vez há alguns anos).
Por favor, atribua qualquerreservado para este fim(possivelmente link-local, mas não interno do host) oucontroladoEspaço IP para as interfaces em questão.Continuar com essa configuração estranha só causará mais problemas, especialmente quando existem alternativas fáceis.