Especificar la dirección IP para conexiones salientes en un host multi ip

Uno de mis servidores (Debian 5.0.6) tiene dos direcciones IP públicas en la misma interfaz. Esto solía funcionar bien durante meses, pero de repente está usando direcciones IP "incorrectas" para las conexiones salientes. Esto es un problema porque la búsqueda inversa no coincidirá y, por lo tanto, los correos electrónicos obtienen puntos de spam.

eth0      Link encap:Ethernet  Hardware Adresse 00:1b:21:14:8e:9c  
          inet Adresse:81.169.180.51  Bcast:81.169.180.51  Maske:255.255.255.255
          inet6-Adresse: fe80::21b:21ff:fe14:8e9c/64 Gültigkeitsbereich:Verbindung

eth0:0    Link encap:Ethernet  Hardware Adresse 00:1b:21:14:8e:9c  
          inet Adresse:85.214.157.120  Bcast:85.214.157.120  Maske:255.255.255.255


Kernel-IP-Routentabelle
Destination     Router          Genmask         Flags Metric Ref    Use Iface
81.169.180.1    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
0.0.0.0         81.169.180.1    0.0.0.0         UG    0      0        0 eth0

Actualmente está utilizando 85.214.157.120 para conexiones salientes. ¿Cómo consigo que use 81.169.180.51?

Editar : la máscara de red de 255.255.255.255 es coherente con la documentación y la respuesta de DHCP de la empresa de alojamiento. Llamar a /etc/init.d/networking restart varias veces eventualmente terminará con la dirección IP correcta para las conexiones de salida. Pero eso obviamente no es una solución estable. /Editar

Edición 2 : para asegurarme de que la ruta del host no esté relacionada con mi problema, configuro una red de prueba local:

eth0      inet Adresse:192.168.0.2  Bcast:192.168.0.255  Maske:255.255.255.0
eth0:0    inet Adresse:192.168.0.3  Bcast:192.168.0.255  Maske:255.255.255.0

192.168.0.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0        192.168.0.1     0.0.0.0         UG    0      0        0 eth0

Si alguien tiene una idea de cómo asegurarse de que la dirección IP de origen 192.168.0.2 se use en las conexiones TCP salientes, le agradecería. / Editar 2

Actualización predeterminada:

ip route change default via 81.169.180.1 src 81.169.180.51

Comprobar configuración:

ip route list

La respuesta de bindbn es buena, pero encontré algunas complicaciones.

1) Debe verificar la "lista de rutas ip" como dice bindbn. Alguna otra regla en la lista puede tener prioridad sobre la ruta predeterminada. Es posible que deba eliminar esa regla o crear una regla ligeramente diferente.

2) Todos los cambios realizados a través del comando ip solo funcionan hasta el próximo reinicio. Esta respuesta Agregar permanentemente las reglas de enrutamiento de la política de origen explica cómo hacerlo persistente.

En resumen, puede agregar el comando ip route que necesita ejecutar como una línea "hacia arriba" o "post-up" a / etc / network / interfaces. Puede agregar una línea "hacia abajo" correspondiente para eliminar la ruta.

Intenta cambiar

 allow-hotplug eth0

a

 auto eth0

Eso debería obligar a su interfaz física a aparecer primero. Es posible que también necesite o no cambiar la entrada allow-hotplug para eth0: 0.

Por curiosidad, ¿por qué sus direcciones IP tienen una máscara de red de 255.255.255.255? Eso realmente no es factible, ya que significaría que la dirección completa es la red. No hay espacio para los anfitriones. El hecho de que su dirección de transmisión sea la misma que su IP de host también es preocupante, pero probablemente debido al problema de la máscara de red. Parece que su máscara de red debería ser 255.255.255.0.

¿Se hizo esto para darle dos hosts en la misma subred? Puede ser preferible simplemente hacer un cambio para que cada interfaz esté en una subred diferente. 255.255.255.128 colocaría eth0 y su puerta de enlace (de 81.169.180.1) en la misma subred, con eth0: 0 en una subred separada. Sin embargo, eso significaría que eth0 solo podría comunicarse con 81.169.180.1-81.169.180.127. Y eth0: 0 pasando de 129-254. Pero dicho esto, realmente no puedo ver por qué su configuración actual funciona en absoluto.

Ahora, ¿esto causará los problemas que está viendo arriba? No puedo ver un enlace directo, pero es posible.
Ciertamente es algo que modificaría. Si eso no ayuda, tal vez puedas explicar por qué tienes las cosas configuradas de esta manera.

---

Editar: ¿Funcionaba bien en este host o era una máquina / sistema operativo diferente? ¿Alguna idea de lo que podría haber cambiado? La razón por la que pregunto es porque a Linux realmente no le gusta tener dos interfaces en la misma subred. Me ha vuelto loco tratar de hacer que esto funcione en mi propia red. Parece bastante posible que haya funcionado en la IP correcta, hasta que reinició / reinició los servicios de red. Luego surgió usando la interfaz incorrecta. Referencia: http://anders.com/cms/258

También puede probar ifdowneth0: 0, luego agregar la ruta y luego ifupvolver a ingresarla. Eso podría garantizar que se use la IP correcta.

Agregar manualmente dev eth0 podría ayudar, pero parece que la ruta se realizó correctamente.

---

Además Editar: Usted puede intentar utilizar las nuevas herramientas de gestión de PI en Debian, iproute 2. ( Enlace secundario ) Parece algo parecido a la
aparición de la interfaz: ip link set eth0 up

ip addr add 192.168.0.2/24 dev ethe0
ip addr add 192.168.0.3/24 dev eth0

Luego configurando la tabla de enrutamiento con -
ip route add 10.0.0.0/16 via 192.168.0.2


Christopher Karel

Su configuración actual no debería funcionar en absoluto. Como la máscara de red para ambas interfaces es 255.255.255.255, no hay espacio para una puerta de enlace. Sin embargo, para entregar tráfico significativo, su servidor necesita una puerta de enlace. El ISP que proporciona las dos direcciones IP públicas también debe proporcionarle la configuración de máscara de red y puerta de enlace para ambas direcciones IP.

Ejemplo (este es mi servidor privado y las direcciones IP son reales):

Tabla de enrutamiento IP del núcleo
Destino Gateway Banderas de Genmask Referencia métrica Uso Iface
217.10.144.208 0.0.0.0 255.255.255.248 U 0 0 0 eth0
0.0.0.0 217.10.144.209 0.0.0.0 UG 0 0 0 eth0

El servidor en sí está en 217.10.144.210, que se encuentra en la misma subred que la puerta de enlace (tiene que hacerlo, de lo contrario no se puede enrutar el tráfico). Presumiblemente, el ISP también proporciona la misma subred para algunos otros clientes.

Si está en ese servidor y realiza un ping a su puerta de enlace, debería recibir un mensaje de "no hay ruta al host".

Hable con el ISP y obtenga la configuración correcta, luego actualice la configuración de su interfaz, reinicie la red y vuelva a verificarla.