Pregunté esto en ingeniería de redes en intercambio de pila y fui redirigido aquí.
Tengo un par de servidores con la siguiente configuración.
servidor 1:
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 del servidor1 está conectado a una red L2 completamente diferente y está completamente aislado.
Las interfaces eno2 de ambos servidores están conectadas a la misma red L2. Ahora tengo que acceder a 127.15.0.1 desde el servidor2.
El servidor1 se implementó hace mucho tiempo y no tengo permisos para cambiar ningún tipo de configuración. No sé por qué alguien usó la subred 127.xxx con alcance global. No estoy seguro si es una configuración válida pero tengo que vivir con ella. Tengo control total sobre el servidor2 y puedo cambiar cualquier cosa.
Ambos servidores están basados en Linux.
La conectividad entre 5.0.0.1 <-> 5.0.0.2 es buena.
Mi primer intento fue agregar una ruta en el servidor2 como se muestra a continuación
ip r add 127.15.0.1/32 a través de 5.0.0.1 hizo ping a 127.15.0.1 desde el servidor2. Veo las solicitudes y respuestas de ping en tcpdump en el servidor 2, pero el comando ping muestra una pérdida del 100%.
Deshabilité 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 después de actualizar sysctl.conf
Y eliminé los iptables. (iptables-F)
Mismo resultado. Pensé que tal vez al servidor 2 no le gusta usar la serie 127.xxx. Entonces agregué la siguiente regla en el servidor 2
iptables -t nat -A OUTPUT -d 5.0.0.1 -j DNAT --to-destination 127.15.0.1
Se supone que esta regla reemplaza la IP de destino a 127.15.0.1 si el paquete está destinado a 5.0.0.1.
hizo ping a 5.0.0.1 desde el servidor2. Iptables reemplazó la IP de destino con 127.15.0.1 (confirmó esto en el tcpdump del servidor1). El servidor1 respondió pero las respuestas se eliminan nuevamente.
Me quedé sin ideas en este punto. Eliminé el servidor1 por mantenimiento y reemplacé 127.15.0.1/26 con 192.168.1.1/16. La conectividad funcionó bien en este caso (con y sin iptables). Ahora la pregunta es, ¿el problema se debe al uso de 127.xxx? En caso afirmativo, ¿hay alguna manera de solucionarlo? Si no, ¿qué más puedo intentar?
Nota: esta configuración funcionaba antes. Recientemente perdimos el servidor 2 (que tenía Linux antiguo) y lo estoy construyendo desde cero. Además, Windows no permite el uso de 127.xxx en otras interfaces que no sean loopback. No estoy seguro de por qué Linux lo permite en interfaces no bajas. ¡Puede que haya una razón!
Para resumir tengo estas preguntas:
- Windows rechaza rotundamente la configuración cuando intentamos configurar 127.xxx pero Linux lo permite y eso también con alcance global. ¿Existe un caso de uso para esto?
- En este caso, el servidor2 envía solicitudes destinadas a 127.xxx y el servidor1 en realidad envía respuestas. Si 127.xxx es sólointerno del host, ¿por qué envían paquetes a través del enlace?
Respuesta1
El sistema Linux marca en
/sys/net/ipv4/conf/*/route_localnet
permitir deshabilitar el tratamiento razonable para dichos paquetes.
route_localnet - BOOLEANO
No considere las direcciones de bucle invertido como origen o destino marciano durante el enrutamiento. Esto permite el uso de 127/8 para fines de enrutamiento local. predeterminado FALSO
Dado que pocas personas en su sano juicio harían algo así, esto puede que funcione o no hoy en día (lo probé por última vez hace unos años).
Por favor asigne cualquierreservado-para-este-propósito(posiblemente enlace local, pero no interno del host) opropiedadEspacio IP para las interfaces en cuestión.Continuar con esta extraña configuración sólo causará más problemas, especialmente cuando existen alternativas sencillas.