Come posso fare in modo che Ethernet abbia la precedenza sul wifi su Ubuntu 18.04?

Obbiettivo

Lascia che Ethernet abbia la precedenza sul wireless quando è collegato il cavo Ethernet

Metodo

Dopo aver fatto una buona parte di Google e leggere sono arrivato al punto in cui credo che ciò che dovrei fare è qualcosa sulla falsariga di

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

dove 200 ha un valore inferiore rispetto alla metrica wireless, per fare in modo che la rete Ethernet abbia la precedenza sulla rete wireless.

risultati

Ciò che mi lascia perplesso sono i rapporti che ricevo route -ndopo che ho eseguito i comandi sopra e riavviato (per buona misura), e il fatto che questo non sembra equivalere a raggiungere il mio obiettivo

$ 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

I numeri si sommano per quanto riguarda l'esecuzione del mio comando, ma per le righe che dicono

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 prima riga ha 20 prefissati prima del valore 200 che ho impostato. Questo continua ad essere applicato in modo coerente in base a ciò che eseguo; Se cambio il valore della metrica nmcliper dire 500, route -nriporterò 20500. Perché succede? Di sicuro non sembra giusto, dal momento che ho affermato che volevo 200 o 500, non 20200 e 20500.

La seconda riga ha un valore metrico di cui non ho idea da dove provenga e non riesco a influenzarlo affatto. Se qualcuno può far luce su questo, sono grato.

Non sembra che questi comandi finiscano in qualcosa di tangibile, oltre a influenzare le metriche; Non posso dire che Ethernet stia avendo la precedenza, quindi presumo che non lo sia.

Altri risultati

Quello che ho trovato curioso, e sembra funzionare in una certa misura, è l'uso di $ sudo ifmetric enp0s31f6 200. Questo fa due o tre cose;

• Influisce sulla metrica dell'interfaccia ( route -nriporta tutte le righe con Iface enp0s31f6per avere il valore 200)
• Influisce sull'interfaccia utente di Ubuntu (nell'angolo in alto a destra vedrò un passaggio visivo tra la commutazione di icone Ethernet e wireless, a seconda dei valori metrici forniti nel ifmetriccomando)
• A volte mi dà un NETLINK: Error: File existserrore. Le esecuzioni successive dello stesso comando possono o potrebbero non risultare in questo errore

Alcune informazioni di sistema

• EliteBook 850 G5
• Ubuntu 18.04
• Installazione di Ubuntu fatta consentendo all'installatore di utilizzare l'intero disco, abilitare la crittografia, i download di terze parti abilitati per i driver, ecc.

Aggiornamento 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

Hai problemi impilati qui:

• La LAN via cavo e LAN wireless sono un bridge per la stessa sottorete 123.456.89.0/24
• Avrai due gateway predefiniti se ti connetti contemporaneamente a quelle reti (questo può essere risolto con un routing avanzato un ip rules)
• Quei gateway hanno LO STESSO INDIRIZZO, dal momento che hai un ponte tra wifi e connessione cablata.

Forse dovresti fare affidamento su script esterni per disattivare automaticamente il wifi quando Ethernet è collegata come questa:

• Passa automaticamente da WiFi a Ethernet

Crea lo script /etc/NetworkManager/dispatcher.d/70-wifi-wired-exclusive.sh. Contenuti:

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

Per disabilitare lo script, basta eseguire touch /etc/NetworkManager/.wifi-wired-exclusive

Credo che NetworkManager penalizzi le connessioni che ritiene irraggiungibili, aggiungendo 20000 al valore della metrica. Dal manuale NetworkManager.conf :

la route predefinita dei dispositivi senza connettività globale riceve una penalità di +20000 per la metrica della route

Soluzione 1

Puoi provare a disabilitare il controllo della connettività commentando l'opzione uri=o lasciandola vuota, dentro NetworkManager.conf.

Soluzione 2

Situato net.ipv4.conf.all.rp_filter = 2in /etc/sysctl.confo, se del caso nella vostra distro. Attenzione alle possibili vulnerabilità di perdita di informazioni .

sfondo

Il manuale NetworkManager.conf ha una piccola spiegazione del perché il controllo della connettività potrebbe non funzionare correttamente:

Nota che la tua distribuzione potrebbe impostare / proc / sys / net / ipv4 / conf / * / rp_filter su un filtro rigoroso . Funziona male con il controllo della connettività per dispositivo, che utilizza SO_BINDDEVICE per inviare richieste su tutti i dispositivi. Un'impostazione rigida di rp_filter rifiuterà qualsiasi risposta e il controllo di connettività su tutti, ma il percorso migliore fallirà.

Nella mia distribuzione è abilitato il filtro rigoroso:

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

Il valore 1indica un filtro rigoroso e questo è responsabile del fallimento del controllo della connettività. La gente del sistema ha cambiato questo in 2(filtro libero) con un controverso impegno che ha introdotto vulnerabilità , quindi è stato ripristinato dalle distro.