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
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.
fuente
Intenta cambiar
a
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.
fuente
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 luegoifupvolver a ingresarla. Eso podría garantizar que se use la IP correcta.Agregar manualmente
dev eth0podrí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 laaparición de la interfaz:
ip link set eth0 upip addr add 192.168.0.2/24 dev ethe0ip addr add 192.168.0.3/24 dev eth0Luego configurando la tabla de enrutamiento con -
ip route add 10.0.0.0/16 via 192.168.0.2Christopher Karel
fuente
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):
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.
fuente