Comment puis-je faire en sorte que Ethernet soit prioritaire sur le wifi sur Ubuntu 18.04?

Objectif

Laissez Ethernet l'emporter sur le sans fil lorsque le câble Ethernet est branché

Méthode

Après avoir fait pas mal de recherches sur Google et lu, je suis arrivé à un point où je crois que ce que je devrais faire est quelque chose comme

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

où 200 est une valeur inférieure à la métrique sans fil, pour que Ethernet soit prioritaire sur le sans fil.

Résultats

Ce qui me rend perplexe, ce sont les rapports que je reçois route -naprès avoir exécuté les commandes ci-dessus et redémarré (pour faire bonne mesure), et le fait que cela ne semble pas équivaloir à atteindre mon objectif

$ 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

Les chiffres s'additionnent en ce qui concerne l'exécution de ma commande, mais pour les lignes qui disent

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 première ligne comporte 20 préfixes avant la valeur 200 que j'ai définie. Cela continue d'être appliqué de manière cohérente en fonction de ce que je lance; Si je modifie la valeur de la mesure nmclipour dire 500, route -nle rapport 20500. Pourquoi cela se produit-il? Cela ne semble certainement pas correct, car j'ai déclaré que je voulais 200 ou 500, et non 20200 et 20500.

La deuxième ligne a une valeur métrique dont je n'ai aucune idée d'où elle vient et je ne peux pas du tout l'affecter. Si quelqu'un peut faire la lumière là-dessus, je lui en suis reconnaissant.

Il ne semble pas que ces commandes aboutissent à quelque chose de tangible, à part affecter les métriques; Je ne peux pas dire que Ethernet est prioritaire, je suppose donc que non.

Autres constatations

Ce que j'ai trouvé curieux et qui semble fonctionner dans une certaine mesure, c'est l'utilisation de $ sudo ifmetric enp0s31f6 200. Cela fait deux à trois choses;

• Il affecte la métrique de l'interface ( route -nsignale que toutes les lignes avec l'Iface enp0s31f6ont la valeur 200)
• Cela affecte l'interface utilisateur dans Ubuntu (dans le coin supérieur droit, je verrai un commutateur visuel entre la commutation des icônes Ethernet et sans fil, en fonction des valeurs métriques que je fournis dans la ifmetriccommande)
• Cela me lance parfois une NETLINK: Error: File existserreur. Exécutions ultérieures du même ordre peuvent ou peuvent ne pas entraîner cette erreur

Quelques informations système

• EliteBook 850 G5
• Ubuntu 18.04
• Installation d'Ubuntu effectuée en laissant le programme d'installation utiliser l'intégralité du disque, le cryptage activé, les téléchargements tiers autorisés pour les pilotes, etc.

Mise à jour # 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

Vous avez empilé des problèmes ici:

• Votre LAN câblé et votre LAN sans fil sont un pont vers le même sous-réseau 123.456.89.0/24
• Vous aurez deux passerelles par défaut si vous vous connectez en même temps à ces réseaux (cela peut être résolu avec un routage avancé et ip rules)
• Ces passerelles ont LA MÊME ADRESSE, car vous avez un pont entre le wifi et la connexion câblée.

Vous devriez peut-être compter sur des scripts externes pour désactiver automatiquement le wifi lorsque Ethernet est branché comme celui-ci:

• Basculer automatiquement entre WiFi et Ethernet

Créez le script /etc/NetworkManager/dispatcher.d/70-wifi-wired-exclusive.sh. Contenu:

#!/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

Pour désactiver le script, exécutez simplement touch /etc/NetworkManager/.wifi-wired-exclusive

Je crois que c'est NetworkManager pénalisant les connexions qu'il pense être inaccessibles, en ajoutant 20000 à la valeur métrique. Dans le manuel NetworkManager.conf :

la route par défaut des appareils sans connectivité globale reçoit une pénalité de +20000 pour la métrique de la route

Solution 1

Vous pouvez essayer de désactiver la vérification de la connectivité en commentant l'option uri=ou en la laissant vide, dans NetworkManager.conf.

Solution 2

Mettre net.ipv4.conf.all.rp_filter = 2dans /etc/sysctl.confou le cas échéant dans votre distro. Méfiez-vous des vulnérabilités possibles de fuite d'informations .

Contexte

Le manuel NetworkManager.conf contient une petite explication sur les raisons pour lesquelles la vérification de la connectivité peut ne pas fonctionner correctement:

Notez que votre distribution peut définir / proc / sys / net / ipv4 / conf / * / rp_filter sur un filtrage strict . Cela fonctionne mal avec la vérification de la connectivité par appareil, qui utilise SO_BINDDEVICE pour envoyer des demandes sur tous les appareils. Un paramètre rp_filter strict rejettera toute réponse et la vérification de la connectivité sur tous, mais la meilleure route échouera.

Dans ma distribution, le filtrage strict est activé:

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

La valeur 1signifie un filtrage strict et cela est responsable de l'échec du contrôle de connectivité. Les gens de systemd ont changé cela en 2(filtrage lâche) avec un commit controversé qui a introduit des vulnérabilités , donc a été annulé par les distributions.