Jak mogę sprawić, aby Ethernet miał pierwszeństwo przed Wi-Fi na Ubuntu 18.04?

Cel

Niech ethernet ma pierwszeństwo przed bezprzewodowym, gdy kabel Ethernet jest podłączony

metoda

Po tym, jak zrobiłem sporo Google'a i przeczytałem, doszedłem do punktu, w którym uważam, że to , co powinienem robić, to coś

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

gdzie 200 jest wartością niższą niż metryka sieci bezprzewodowej, aby ethernet miał pierwszeństwo przed siecią bezprzewodową.

Wyniki

Niepokoi mnie to, że otrzymałem raporty route -npo wykonaniu powyższych poleceń i ponownym uruchomieniu (na wszelki wypadek) oraz fakt, że nie wydaje się to równoznaczne z osiągnięciem mojego celu

$ 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

Liczby sumują się w odniesieniu do mojego wykonania polecenia, ale dla linii, które mówią

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

Pierwszy wiersz ma 20 prefiksów przed ustawioną wartością 200. To jest konsekwentnie stosowane w oparciu o to, co uruchamiam; Jeśli zmienię wartość metryki nmclina 500, route -nzgłoś 20500. Dlaczego tak się dzieje? Z pewnością nie wygląda to dobrze, ponieważ powiedziałem, że chcę 200 lub 500, a nie 20200 i 20500.

Drugi wiersz ma wartość metryczną, o której nie mam pojęcia, skąd pochodzi, i wydaje mi się, że nie mam na to żadnego wpływu. Jeśli ktoś może rzucić na to światło, jestem wdzięczny.

Nie wygląda na to, że te polecenia kończą się na czymś namacalnym, poza wpływaniem na wskaźniki; Nie mogę powiedzieć, że Ethernet ma pierwszeństwo, więc zakładam, że tak nie jest.

Inne ustalenia

Ciekawe i wydaje mi się, że do pewnego stopnia działa, to wykorzystanie $ sudo ifmetric enp0s31f6 200. Robi to dwie do trzech rzeczy;

• Wpływa na metrykę interfejsu ( route -nzgłasza wszystkie linie za pomocą Iface'a, enp0s31f6aby mieć wartość 200)
• Wpływa na interfejs użytkownika w systemie Ubuntu (w prawym górnym rogu widzę przełączanie między przełączaniem ikon Ethernet i bezprzewodowych, w zależności od wartości metryki podanych w ifmetricpoleceniu)
• To czasami rzuca NETLINK: Error: File existsbłąd na mnie. Kolejne egzekucje tego samego polecenia może lub może nie doprowadzić do tego błędu

Niektóre informacje o systemie

• EliteBook 850 G5
• Ubuntu 18.04
• Instalacja Ubuntu polega na zezwoleniu instalatorowi na użycie całego dysku, włączonemu szyfrowaniu, włączonemu pobieraniu sterowników innych podmiotów itp.

Aktualizacja 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

Masz tutaj stosy problemów:

• Kablowa sieć LAN i bezprzewodowa sieć LAN stanowią pomost do tej samej podsieci 123.456.89.0/24
• Będziesz miał dwie domyślne bramy, jeśli połączysz się w tych samych sieciach (można to rozwiązać za pomocą zaawansowanego routingu i ip rules)
• Te bramy mają TEN SAM ADRES, ponieważ masz pomost między Wi-Fi a połączeniem kablowym.

Może powinieneś polegać na zewnętrznych skryptach, aby automatycznie dezaktywować Wi-Fi, gdy Ethernet jest podłączony tak:

• Automatycznie przełączaj między Wi-Fi i Ethernet

Utwórz skrypt /etc/NetworkManager/dispatcher.d/70-wifi-wired-exclusive.sh. Zawartość:

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

Aby wyłączyć skrypt, po prostu uruchom touch /etc/NetworkManager/.wifi-wired-exclusive

Wierzę, że jest to NetworkManager penalizujący połączenia, które jego zdaniem są nieosiągalne, poprzez dodanie 20000 do wartości metryki. Z podręcznika NetworkManager.conf :

domyślna trasa urządzeń bez globalnej łączności otrzymuje karę w wysokości +20000 do metryki trasy

Rozwiązanie 1

Możesz spróbować wyłączyć sprawdzanie łączności, komentując opcję uri=lub pozostawiając ją pustą, w NetworkManager.conf.

Rozwiązanie 2

Ustaw net.ipv4.conf.all.rp_filter = 2w /etc/sysctl.conflub w stosownych przypadkach w swojej dystrybucji. Uważaj na potencjalne luki związane z wyciekiem informacji .

tło

Podręcznik NetworkManager.conf zawiera małe wyjaśnienie, dlaczego sprawdzanie łączności może działać nieprawidłowo:

Zauważ, że twoja dystrybucja może ustawić / proc / sys / net / ipv4 / conf / * / rp_filter na ścisłe filtrowanie . Działa to źle przy sprawdzaniu łączności dla poszczególnych urządzeń, które używają SO_BINDDEVICE do wysyłania żądań na wszystkie urządzenia. Ścisłe ustawienie rp_filter odrzuci każdą odpowiedź, a sprawdzenie łączności na wszystkich trasach oprócz najlepszej nie powiedzie się.

W mojej dystrybucji włączone jest ścisłe filtrowanie:

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

Wartość 1oznacza ścisłe filtrowanie, a to odpowiada za niepowodzenie sprawdzania łączności. Systematyczni ludzie zmienili to na 2(luźne filtrowanie) z kontrowersyjnym zatwierdzeniem, które wprowadziło luki , a zatem zostało przywrócone przez dystrybucje.