Wie kann ich dafür sorgen, dass Ethernet unter Ubuntu 18.04 Vorrang vor WLAN hat?

Tor

Lassen Sie Ethernet Vorrang vor Wireless haben, wenn das Ethernet-Kabel eingesteckt ist

Methode

Nachdem ich ziemlich viel gegoogelt und gelesen habe, bin ich an einem Punkt angelangt, an dem ich glaube, dass ich etwas in der Art von tun sollte

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

Dabei ist 200 ein niedrigerer Wert als die drahtlose Metrik, damit das Ethernet Vorrang vor dem drahtlosen hat.

Ergebnisse

Was mich verwirrt, sind die Berichte, die ich erhalte, route -nnachdem ich die oben genannten Befehle ausgeführt und (aus gutem Grund) neu gestartet habe, und die Tatsache, dass dies nicht dem Erreichen meines Ziels gleichkommt

$ 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

Die Zahlen addieren sich in Bezug auf meine Befehlsausführung, aber für die Zeilen, die sagen

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

Der ersten Zeile wird 20 vor dem von mir festgelegten Wert von 200 vorangestellt. Dies wird basierend auf dem, was ich ausführe, konsequent angewendet. Wenn ich den Wert für die Metrik nmcliauf 500 route -nändere , wird 20500 gemeldet. Warum passiert das? Es sieht sicher nicht richtig aus, da ich angegeben habe, dass ich entweder 200 oder 500 wollte, nicht 20200 und 20500.

Die zweite Zeile hat einen metrischen Wert, von dem ich keine Ahnung habe, woher er kommt, und ich kann ihn anscheinend überhaupt nicht beeinflussen. Wenn jemand Licht ins Dunkel bringen kann, bin ich dankbar.

Es sieht nicht so aus, als würden diese Befehle in etwas Greifbarem enden, außer dass sie die Metriken beeinflussen. Ich kann nicht sagen, dass dieses Ethernet Vorrang hat, also gehe ich davon aus, dass dies nicht der Fall ist.

Weitere Befunde

Was ich neugierig gefunden habe und bis zu einem gewissen Grad zu funktionieren scheint , ist die Verwendung von $ sudo ifmetric enp0s31f6 200. Dies macht zwei bis drei Dinge;

• route -nDies wirkt sich auf die Metrik der Schnittstelle aus ( meldet, dass alle Zeilen mit dem Iface enp0s31f6den Wert 200 haben).
• Dies wirkt sich auf die Benutzeroberfläche in Ubuntu aus (In der oberen rechten Ecke wird ein visueller Wechsel zwischen Ethernet- und drahtlosen Symbolen angezeigt, abhängig von den im ifmetricBefehl angegebenen Metrikwerten.)
• Es wirft manchmal einen NETLINK: Error: File existsFehler auf mich. Nachfolgende Ausführungen desselben Befehls können zu diesem Fehler führen oder auch nicht

Einige Systeminformationen

• EliteBook 850 G5
• Ubuntu 18.04
• Die Ubuntu-Installation wurde durchgeführt, indem das Installationsprogramm die gesamte CD verwenden konnte, die Verschlüsselung aktiviert, Downloads von Drittanbietern für Treiber aktiviert usw.

Update Nr. 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

Sie haben hier Probleme gestapelt:

• Ihr Kabel-LAN und WLAN sind eine Brücke zum selben Subnetz 123.456.89.0/24
• Sie haben zwei Standard-Gateways, wenn Sie gleichzeitig eine Verbindung in diesen Netzwerken herstellen (dies kann mit etwas erweitertem Routing gelöst werden ip rules).
• Diese Gateways haben DIE GLEICHE ADRESSE, da Sie eine Brücke zwischen WLAN und Kabelverbindung haben.

Vielleicht sollten Sie sich auf externe Skripte verlassen, um WLAN automatisch zu deaktivieren, wenn Ethernet wie folgt angeschlossen ist:

• Automatisch zwischen WiFi und Ethernet wechseln

Erstellen Sie das Skript /etc/NetworkManager/dispatcher.d/70-wifi-wired-exclusive.sh. Inhalt:

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

Um das Skript zu deaktivieren, führen Sie es einfach aus touch /etc/NetworkManager/.wifi-wired-exclusive

Ich glaube, dies ist NetworkManager, der Verbindungen bestraft, die seiner Meinung nach nicht erreichbar sind, indem dem Metrikwert 20000 hinzugefügt werden. Aus dem Handbuch NetworkManager.conf :

Standardroute von Geräten ohne globale Konnektivität erhalten eine Strafe von +20000 für die Routenmetrik

Lösung 1

Sie können versuchen, die Konnektivitätsprüfung zu deaktivieren, indem Sie die Option auskommentieren uri=oder leer lassen NetworkManager.conf.

Lösung 2

Stellen Sie net.ipv4.conf.all.rp_filter = 2in /etc/sysctl.confoder gegebenenfalls in Ihrer Distribution ein. Achten Sie auf mögliche Sicherheitslücken bei Informationslecks .

Hintergrund

Das Handbuch NetworkManager.conf enthält eine kleine Erklärung, warum die Konnektivitätsprüfung möglicherweise nicht ordnungsgemäß funktioniert:

Beachten Sie, dass Ihre Distribution / proc / sys / net / ipv4 / conf / * / rp_filter möglicherweise auf strikte Filterung setzt . Dies funktioniert schlecht bei der Überprüfung der Konnektivität pro Gerät, bei der SO_BINDDEVICE zum Senden von Anforderungen auf allen Geräten verwendet wird. Eine strikte Einstellung von rp_filter lehnt jede Antwort ab und die Konnektivitätsprüfung für alle außer der besten Route schlägt fehl.

In meiner Distribution ist die strikte Filterung aktiviert:

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

Der Wert 1bedeutet strikte Filterung und ist dafür verantwortlich, dass die Konnektivitätsprüfung fehlschlägt. Die Leute von systemd änderten dies in 2(lose Filterung) mit einem kontroversen Commit , das Schwachstellen einführte und somit von Distributionen zurückgesetzt wurde.