Ich bin nicht sicher … aber seit ich Ubuntu 22.04 und seinen Kernel aktualisiert und neu gestartet habe, wird mir der Internetzugriff verweigert; ich bin jedoch verbunden und kann auf die Admin-Seiten des Routers zugreifen und mich dort anmelden.
Mein Smartphone, das im selben WLAN ist, hat keine Probleme.
Ist beim Aktualisieren etwas passiert, das den Laptop blockiert hat?
Aktualisieren
Ich verwende kein Ethernet, da ich gerade kein Ethernet-Kabel habe. Daher kann ich dazu momentan nichts sagen.
Mein WLAN-Chip basiert auf dem Befehl:
$ lspci -knn | grep Net -A2
02:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:02b1] (rev 73)
Subsystem: Intel Corporation Wireless-N 7260 [8086:4462]
Kernel driver in use: iwlwifi
Aktualisierung 2
Ich $ ping 8.8.4.4erhalte die Meldung „Destination Host Unreachable“:
$ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
From 192.168.1.162 icmp_seq=1 Destination Host Unreachable
From 192.168.1.162 icmp_seq=2 Destination Host Unreachable
From 192.168.1.162 icmp_seq=3 Destination Host Unreachable
Ich sehe beim Tethering übertragene Pakete.
Auch bei Verwendung von Tethering:
$ ip route show
default via 192.168.1.1 dev br0 proto static metric 100 linkdown
default via 192.168.42.129 dev usb0 proto dhcp metric 100
default via 192.168.0.1 dev wlan0 proto dhcp metric 600
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.109 metric 600
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.162 linkdown
192.168.42.0/24 dev usb0 proto kernel scope link src 192.168.42.167 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
$ dig google.com
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13107
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 285 IN A 142.250.196.46
;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Nov 23 17:04:43 +0545 2022
;; MSG SIZE rcvd: 55
Und nur mit WLAN:
$ ip route show
default via 192.168.1.1 dev br0 proto static metric 100 linkdown
default via 192.168.0.1 dev wlan0 proto dhcp metric 600
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.109 metric 600
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.162 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
$ dig google.com
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45316
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 102 IN A 142.250.196.46
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Nov 23 17:12:16 +0545 2022
;; MSG SIZE rcvd: 55
Ich sehe, dass es da einen kleinen Unterschied gibt ip route show.
Es scheint, dass die Pakete bei Verwendung von WLAN (?) nicht am Gateway vorbeikommen.
Aktualisierung 3
Bei Verwendung einer Live-CD funktioniert WLAN einwandfrei.
Beim normalen Booten kann ich nicht allein über den drahtlosen mobilen Hotspot auf das Internet zugreifen.
Stimmt etwas mit den WLAN-Einstellungen des aktuellen Ubuntu nicht?
Aktualisierung 4
ICHdenkenVirtualBox hat die Bridge installiert und ich verwende VirtualBox regelmäßig.
Antwort1
maan81 hat dieses Problem ziemlich gut auf die Routentabelle eingegrenzt:
- Durch Tests mit der Installationsdiskette wurde die Hardware als Ursache vollständig ausgeschlossen – Smart Start.
- Durch die Verbindung mit dem WLAN-Router wurde die WLAN0-Verbindungskonfiguration validiert.
Zwei sehr kluge Schritte. Warum können Sie also eine Verbindung zum WLAN-Router herstellen, aber kein Internetverkehr?
Das Problem wird in der Routentabelle von maan81 deutlich:
$ ip route show
default via 192.168.1.1 dev br0 proto static metric 100 linkdown
default via 192.168.0.1 dev wlan0 proto dhcp metric 600
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.109 metric 600
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.162 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Die Route über br0 (die nirgendwohin führt, weil sie sich im Linkdown-Zustand befindet) hat eine niedrigere Metrik (100) als die Route wlan0 (600). Das bedeutet, dass sie den gesamten Verkehr gewinntaußerdas für das Subnetz 192.168.0.1 bestimmt ist. Es gibt eine Schnittstelle direkt in diesem Subnetz, daher gilt das Standardrouting nicht für diesen Datenverkehr.
Wer hat hier das Sagen?
Als ersten Schritt sollten Sie feststellen, welcher Netzwerkmanager zuständig ist. In den allermeisten Fällen wird es NetworkManager sein.
Leider haben maan81 und ich diesen Schritt übersprungen, weil wir davon ausgingen, dass NetworkManager das Sagen hat, und wurden zwei Tage lang auf eine wilde Jagd geführt, da die Bridge br0 bei jedem Neustart immer wieder auftauchte.
# Determine network renderer
netplan get renderer
Wenn Ihr RendererNetzwerkManagerSie können direkt zu den Techniken zur Fehlerbehebung springen.
Wenn Ihr Renderervernetzt, dann führen Sie netplan aus und alle Ihre Probleme befinden sich in /etc/netplan/*.yaml. Bitte beachten SieKanonischer Netzplanfür die vollständige Dokumentation. Wenn Sie dabei bleiben möchtenNetzplanEiniges von dem, was folgt, mag nützlich sein, aberNetzplanist ein zu großes Thema, um im Rahmen dieser Antwort behandelt zu werden.
maan81 hat tatsächlich Netplan ausgeführt und sich entschieden, zu NetworkManager zurückzukehren.
Von Netplan zu NetworkManager zurückkehren
Das Folgende wird als Root ausgeführt. Der cat...EOFBefehl muss als zusammenhängender Block ausgeführt werden. Achten Sie darauf, die Einrückungen in der YAML-Datei nicht durcheinander zu bringen – Netplan ist in solchen Dingen sehr pingelig.
mkdir /etc/netplan/old
mv /etc/netplan/*.yaml /etc/netplan/old
cat << 'EOF' > /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
EOF
netplan generate && netplan apply && shutdown -r now
Damit wurden die Netzwerkprobleme von maan81 letztendlich gelöst. Nachfolgend sind einige der „Tools“ aufgeführt, die wir zur Lösung verwendet haben.
Fehlerbehebung
Sichern Ihrer Routentabelle:
# Backup the route table
sudo ip route save > route.bin
# Recover the route table
sudo ip route restore < route.bin
Brückenmanipulation:
# take bridge br0 down
sudo ip link set br0 down
# bring up bridge br0
sudo ip link set br0 up
# delete bridge br0 (requires bridge-utils)
sudo ip link set br0 down && sudo brctl delbr br0
Verbindungsmetrik ändern
# list connections
nmcli connection
# list devices
nmcli device
# set connection metric # requires link dn/up to take effect
nmcli connection modify <name> ipv4.route-metric <metric>
Brute-Force-Überschreiben der Standardroute
# Delete the default routes
sudo ip route del default
# Recreate new route to wireless router IP
sudo ip route add default via 192.168.0.1 metric 50
Zusammenfassung:
In der Berufswelt gilt das Ausführen mehrerer Standardrouten als sehr schlechte Praxis. Schließlich sind „mehrere“ und „Standard“ widersprüchliche Konzepte.
Bei Benutzer-Desktops übernimmt NetworkManager dies automatisch für Sie, aber es funktioniert nicht immer richtig. Wenn Sie mehr als eine aktive Netzwerkschnittstelle haben, werden mehrere Standardrouten erstellt. In diesem Fall bestimmt die Metrik, wohin Ihr Internetverkehr fließt.