¿Puedo evitar que se agregue una ruta predeterminada al abrir una interfaz?

12

Tengo un sistema con dos NIC. Esta máquina y algunos dispositivos que lo acompañan se moverán y se conectarán a diferentes LAN o, a veces, se usará el acceso telefónico.

    eth0:
    - 10.x.x.x address space
    - no internet gateway
    - only a few devices

eth1 (when used):
- 172.16.x.x or 192.168.x.x or other address spaces
- access to the gateway from LAN to internet

ppp0 (when used):
- internet access through dialup using KPPP

Estoy usando ifconfig para subir o bajar interfaces (excepto con ppp0, que es manejado por KPPP).

Si primero menciono eth1, obtiene una dirección de su DHCP y obtiene la puerta de enlace y eso se agrega al enrutamiento para que no haya problemas para llegar a la LAN e Internet.

Si presento eth0 primero o segundo, obtiene su dirección y establece la puerta de enlace predeterminada dentro de su espacio de direcciones (en el rango de 10.xxx). Si saco eth0 primero y eth1 segundo, la puerta de enlace predeterminada todavía se mantiene dentro del rango 10.xxx.

Así que no importa lo que haga, eth0 anulará eth1 y "reclamará" la puerta de enlace en el enrutamiento.

¿Hay alguna manera de evitar que eth0 reclame la puerta de enlace o para asegurarse de que eth1 (si aparece el segundo) usa su puerta de enlace? ¿O puedo priorizar de alguna manera una clasificación de la puerta de enlace de la interfaz que se debe usar sobre las demás?

Básicamente quiero asegurarme de que se use la puerta de enlace del espacio de direcciones predeterminado de eth1 si está activa, y si no, se usa la puerta de enlace predeterminada de ppp0. Me gustaría poder evitar que eth0 tenga la puerta de enlace predeterminada.

Tango
fuente
Es extraño que el uso ifconfigcause cualquier tipo de interacción DHCP. Típicamente ifuphará esto, comenzando dhclient. ¿Es posible que sus interfaces eth * estén siendo activadas por el proceso de arranque del sistema, digamos /etc/init.d/network, o por NetworkManager?
Mark Plotnick
@ MarkPlotnick: Esto es después de haber arrancado y estoy usando "ifconfig eth1 up" (o down o eth0 ...). Supongo que la forma más simple de lo que quiero hacer sería abrir eth0 sin agregar ninguna ruta que no sea el espacio de direcciones 10.xxx.
Tango

Respuestas:

5

La configuración del servidor DHCP es incorrecta. No debe enviar una opción de puerta de enlace predeterminada cuando no puede proporcionar enrutamiento al resto del mundo. Si envía esa opción, cualquier cliente puede suponer que puede enviar paquetes para cualquier destino fuera de enlace a la puerta de enlace predeterminada especificada.

Por lo tanto, su casilla es correcta al usar la puerta de enlace predeterminada de eth0 si DHCP se lo indica. La solución es eliminar la mala opción de su servidor DHCP.

Sander Steffann
fuente
De acuerdo, eso tiene mucho sentido. Desafortunadamente, el servidor DHCP es un DLink DNS-321, que no permite muchas opciones de control. Parece requerir que incluya una puerta de enlace. Tendré que ver si puedo hackearlo de alguna manera y editar el archivo de configuración. Pero, otro problema: ¿por qué siempre toma la puerta de enlace del servidor 10.xxx DHCP y no siempre toma la puerta de enlace del otro servidor?
Tango
1
No estoy seguro de cómo Linux elige entre rutas idénticas. Probablemente se basa en la métrica. ¿Puede mostrar su tabla de enrutamiento cuando tiene varias rutas predeterminadas?
Sander Steffann
No permitirá múltiples rutas predeterminadas. La frustración es que, por alguna razón, eth0 siempre escucha el DHCP y actualiza la puerta de enlace. Con eth1, solo escucha y usa la puerta de enlace si es la primera y única interfaz que está activa. Si la puerta de entrada de eth0 no siempre anulara la de eth1, entonces simplemente escribiría un script para que cuando se mencionara eth0, se quitara eth1 y luego apareciera.
Tango
Casi suena como una rareza codificada en el cliente DHCP. Cual estas usando? Como alternativa: podría ser más fácil intercambiar eth0 y eth1;)
Sander Steffann
Está en un D-Link DNS-321. Pero he revisado / var / logs / syslog y puedo ver que el DHCP para eth1 también envía la puerta de enlace cada vez. Simplemente no puedo entender por qué eth1 siempre toma la puerta de enlace y la agrega a la ruta y eth1 no. Voy a intentar limitar el rango para el DHCP eth0 utiliza para comenzar en 10.0.0.3 y luego hacer eth0 estático, usando 10.0.0.2 y ver si eso lleva a ignorar ese rudo servidor DHCP.
Tango
16

Enfrenté un problema similar en Raspbian (supongo que la solución a continuación también será aplicable a Debian). Raspberry Pi 3 tiene 2 NIC integradas: Wi-Fi y Ethernet. Los uso a ambos, son wlan0 y eth0, respectivamente. wlan0 está conectado a la red Wi-Fi de mi hogar y el acceso a internet viene a través de esta interfaz. Obtiene su configuración a través de DHCP desde el enrutador de mi casa. eth0 está conectado directamente a mi PC con Windows y tiene asignada una IP estática . No había acceso a Internet a través de eth0, ya que no lo configuré en mi PC con Windows.

En Raspbian, el demonio dhcpcd es responsable de configurar las interfaces de red. Para configurar la IP estática en la interfaz eth0, se agregaron las siguientes líneas al final de /etc/dhcpcd.conf:

interface eth0

static ip_address=192.168.2.2/24
static routers=192.168.2.1
static domain_name_servers=192.168.2.1

Con esta configuración, dhcpcd creó 2 rutas predeterminadas y la ruta a través de eth0 tenía mayor prioridad que a través de wlan0:

pi@raspberrypi:~ $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.2.1     0.0.0.0         UG    202    0        0 eth0
default         192.168.1.254   0.0.0.0         UG    303    0        0 wlan0
192.168.1.0     *               255.255.255.0   U     303    0        0 wlan0
192.168.2.0     *               255.255.255.0   U     202    0        0 eth0

Así que no tenía acceso a Internet, porque el sistema intentó enrutarlo a través de eth0 y no tenía acceso a Internet, como mencioné anteriormente.

Para resolver el problema, utilicé la nogatewayopción en la /etc/dhcpcd.confinterfaz for eth0. Entonces, la configuración específica de eth0 comenzó a verse así:

interface eth0

static ip_address=192.168.2.2/24
static routers=192.168.2.1
static domain_name_servers=192.168.2.1
nogateway

Después de guardar esta configuración y reiniciar, no había una ruta predeterminada a través de eth0:

pi@raspberrypi:~ $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.254   0.0.0.0         UG    303    0        0 wlan0
192.168.1.0     *               255.255.255.0   U     303    0        0 wlan0
192.168.2.0     *               255.255.255.0   U     202    0        0 eth0

Apareció el acceso a Internet y se resolvió el problema.

Roman Me
fuente
1
Esta era exactamente mi situación, y esta era exactamente la solución.
PNDA
Gracias, nogatewayes el camino a seguir en las últimas distribuciones de Debian
Alessandro Dionisi
No te puedes imaginar lo complicado que es enfrentar este problema en el Raspbian Pi, y acabas de dar la solución más elegante y correcta. Gracias hombre.
TechNyquist
7

En RHEL6 / Fedora 22 se ha probado lo siguiente.

En / etc / sysconfig / network-scripts / ifcfg-eth1 agregue la línea:

DEFROUTE=no

Reemplace eth1 con el nombre de la interfaz donde no se desea el enrutamiento predeterminado.

Esto también se puede hacer a través de la GUI de Network Manager marcando la casilla "Usar esta conexión solo para recursos en su red" en la parte inferior de la pestaña IPv4.

DEFROUTE = no evita la adición de la ruta predeterminada (destino 0.0.0.0) a la tabla de enrutamiento cuando la interfaz está habilitada. es decir. No se agregará la siguiente entrada.

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         172.16.x.x      0.0.0.0         UG        0 0          0 eth1
usuario3489409
fuente
1
Por favor, explique por qué soluciona el problema. Y cuando funciona. Funcionará en distribuciones basadas en Debian (creo) pero no en distribuciones con diferentes nombres de interfaz (o distribuciones usando systemd para servicios de redes).
grochmal
1
Más parecido a Red Hat que a los sistemas basados ​​en Debian.
ilkkachu
4

ok, entonces lo que quiere es que la máquina nunca muestre una puerta de enlace predeterminada cuando aparezca eth0 y obtenga su dirección a través de DHCP.

Aquí está la solución:

Editar archivo:

/etc/dhcp/dhclient-up-hooks

y llenar con:

#!/bin/sh
## Prevent DHCP server on eth0 from forcing a default route on us

case ${interface} in
  eth0)
     printf "executing ip route delete default via $new_routers\n" 
     ip route delete default via $new_routers
  ;;
     *)
  ;;
esac

antes de:

[root@centos7lab dhcp]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.4.1     0.0.0.0         UG    20     0        0 eth0
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

después de ifdown eth0, ifup eth0:

[root@centos7lab dhcp]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
Ricardo
fuente
Esto elimina la ruta con la puerta de enlace una vez establecida, lo que significa que ya eliminó cualquier otra ruta con una puerta de enlace predeterminada. ¿O lo entiendo mal?
Tango
eliminará solo la puerta de enlace que el cliente DHCP creó cuando se lanzó eth0, no afectará a ninguna otra puerta de enlace que ya esté en el sistema. Según su descripción, supongo que su problema es que está obteniendo dos puertas de enlace predeterminadas simultáneas en algún momento (una en eth0 y otra en eth1) y necesita deshacerse de la de eth0 antes de que incluso se coloque en la tabla de enrutamiento. Si publica su ruta -n salida en el momento del problema, podría cambiar mi suposición.
Ricardo
1

Puede editar el archivo dhcpclient.conf y no solicitar ninguna ruta predeterminada del servidor DHCP remoto.

Una pequeña muestra de lo que he hecho y está funcionando para mi caso.

enviar nombre de host = "nombre de host aleatorio";

solicitar máscara de subred, dirección de difusión, desplazamiento de tiempo, interfaz-mtu, rutas estáticas sin clase rfc3442, servidores ntp;

Netboy
fuente