¿Cómo puedo hacer que Ethernet tenga prioridad sobre wifi en Ubuntu 18.04?

Objetivo

Deje que Ethernet tenga prioridad sobre la conexión inalámbrica cuando el cable de Ethernet esté enchufado

Método

Después de haber hecho una buena cantidad de Google y lectura, he llegado a un punto en el que creo que lo que debería estar haciendo es algo similar a

nmcli connection modify [id-of-ethernet-interface] ipv4.route-metric 200
nmcli connection modify [id-of-ethernet-interface] ipv6.route-metric 200

donde 200 es un valor más bajo que la métrica inalámbrica, para que Ethernet tenga prioridad sobre la inalámbrica.

Resultados

Lo que me deja perplejo son los informes que recibo route -ndespués de haber ejecutado los comandos anteriores y reiniciar (por si acaso), y el hecho de que esto no parece llegar a alcanzar mi objetivo

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         123.456.89.1    0.0.0.0         UG    600    0        0 wlp1s0
0.0.0.0         123.456.89.1    0.0.0.0         UG    20200  0        0 enp0s31f6
123.456.89.0    0.0.0.0         255.255.255.192 U     200    0        0 enp0s31f6
123.456.89.0    0.0.0.0         255.255.255.192 U     600    0        0 wlp1s0
654.321.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp0s31f6

Los números se suman con respecto a la ejecución de mi comando, pero para las líneas que dicen

0.0.0.0         123.456.89.1    0.0.0.0         UG    20200  0        0 enp0s31f6
654.321.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp0s31f6

La primera línea tiene 20 prefijos antes del valor 200 que configuré. Esto se sigue aplicando constantemente según lo que ejecuto; Si cambio el valor de la métrica nmclihasta decir 500, route -ninformaré 20500. ¿Por qué sucede esto? Seguro que no se ve bien, ya que dije que quería 200 o 500, no 20200 y 20500.

La segunda línea tiene un valor métrico que no tengo idea de dónde viene, y parece que no puedo afectarlo en absoluto. Si alguien puede arrojar luz sobre esto, estoy agradecido.

No parece que estos comandos terminen en algo tangible, aparte de afectar las métricas; No puedo decir que Ethernet tenga prioridad, así que supongo que no.

Otros hallazgos

Lo que he encontrado curioso, y parece estar funcionando hasta cierto punto, es el uso de $ sudo ifmetric enp0s31f6 200. Esto hace dos o tres cosas;

• Afecta la métrica de la interfaz ( route -ninforma que todas las líneas con Iface enp0s31f6tienen el valor 200)
• Afecta la interfaz de usuario en Ubuntu (en la esquina superior derecha veré un cambio visual entre Ethernet e iconos inalámbricos, dependiendo de los valores métricos que proporcione en el ifmetriccomando)
• A veces me arroja un NETLINK: Error: File existserror. Ejecuciones posteriores del mismo comando pueden o pueden no dar lugar a este error

Alguna información del sistema

• EliteBook 850 G5
• Ubuntu 18.04
• La instalación de Ubuntu se realiza permitiendo que el instalador use todo el disco, el cifrado habilitado, descargas de controladores de terceros habilitadas, etc.

Actualización n. ° 1

$ nmcli c show
NAME                UUID  TYPE      DEVICE    
Wired connection 2  [n/a] ethernet  enp0s31f6 
WiFi1               [n/a] wifi      wlp1s0

$ route -n
Destination     Gateway  Genmask         Flags Metric Ref    Use Iface
0.0.0.0         [n/a]    0.0.0.0         UG    600    0        0 wlp1s0
0.0.0.0         [n/a]    0.0.0.0         UG    20200  0        0 enp0s31f6
[n/a]           0.0.0.0  255.255.255.192 U     200    0        0 enp0s31f6
[n/a]           0.0.0.0  255.255.255.192 U     600    0        0 wlp1s0
[n/a]           0.0.0.0  255.255.0.0     U     1000   0        0 enp0s31f6

Has apilado problemas aquí:

• Su LAN por cable y LAN inalámbrica son un puente hacia la misma subred 123.456.89.0/24
• Tendrá dos puertas de enlace predeterminadas si se conecta al mismo tiempo en esas redes (esto se puede resolver con un enrutamiento avanzado y ip rules)
• Esas puertas de enlace tienen LA MISMA DIRECCIÓN, ya que tiene un puente entre wifi y conexión por cable.

Tal vez debería confiar en scripts externos para desactivar automáticamente wifi cuando ethernet está enchufado como este:

• Cambiar automáticamente entre WiFi y Ethernet

Crea el guión /etc/NetworkManager/dispatcher.d/70-wifi-wired-exclusive.sh. Contenido:

#!/usr/bin/env bash

name_tag="wifi-wired-exclusive"
syslog_tag="$name_tag"
skip_filename="/etc/NetworkManager/.$name_tag"

if [ -f "$skip_filename" ]; then
  exit 0
fi

interface="$1"
iface_mode="$2"
iface_type=$(nmcli dev | grep "$interface" | tr -s ' ' | cut -d' ' -f2)
iface_state=$(nmcli dev | grep "$interface" | tr -s ' ' | cut -d' ' -f3)

logger -i -t "$syslog_tag" "Interface: $interface = $iface_state ($iface_type) is $iface_mode"

enable_wifi() {
   logger -i -t "$syslog_tag" "Interface $interface ($iface_type) is down, enabling wifi ..."
   nmcli radio wifi on
}

disable_wifi() {
   logger -i -t "$syslog_tag" "Disabling wifi, ethernet connection detected."
   nmcli radio wifi off
}

if [ "$iface_type" = "ethernet" ] && [ "$iface_mode" = "down" ]; then
  enable_wifi
elif [ "$iface_type" = "ethernet" ] && [ "$iface_mode" = "up"  ] && [ "$iface_state" = "connected" ]; then
  disable_wifi
fi

Para deshabilitar el script, solo ejecute touch /etc/NetworkManager/.wifi-wired-exclusive

Creo que esto es NetworkManager que penaliza las conexiones que considera inalcanzables, al agregar 20000 al valor métrico. Del manual de NetworkManager.conf :

la ruta predeterminada de dispositivos sin conectividad global obtiene una penalización de +20000 a la métrica de ruta

Solución 1

Puede intentar deshabilitar la comprobación de conectividad comentando la opción uri=o dejándola en blanco NetworkManager.conf.

Solución 2

Establecer net.ipv4.conf.all.rp_filter = 2en /etc/sysctl.confo donde corresponda en su distribución. Tenga cuidado con las posibles vulnerabilidades de fuga de información .

Antecedentes

El manual de NetworkManager.conf tiene una pequeña explicación sobre por qué la comprobación de conectividad podría estar fallando:

Tenga en cuenta que su distribución puede establecer / proc / sys / net / ipv4 / conf / * / rp_filter para un filtrado estricto . Eso funciona mal con la comprobación de conectividad por dispositivo, que usa SO_BINDDEVICE para enviar solicitudes en todos los dispositivos. Una configuración estricta de rp_filter rechazará cualquier respuesta y la comprobación de conectividad en todos, pero la mejor ruta fallará.

En mi distribución, el filtrado estricto está habilitado:

$ /usr/sbin/sysctl net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 1

El valor 1significa un filtrado estricto y esto es responsable de la falla de la verificación de conectividad. La gente de systemd cambió esto a 2(filtrado suelto) con un compromiso controvertido que introdujo vulnerabilidades , por lo que fue revertido por las distribuciones.