Заблокирован доступ в Интернет?

Заблокирован доступ в Интернет?

Я не уверен... но после обновления Ubuntu 22.04 и ее ядра, а также перезапуска, у меня заблокировался доступ в Интернет, хотя я подключен и могу получить доступ и войти в административные страницы маршрутизатора.

У моего смартфона, подключенного к той же сети Wi-Fi, проблем нет.

Произошло ли что-нибудь во время обновления, что заблокировало ноутбук?



Обновлять

Я не использую Ethernet, поскольку у меня сейчас нет кабеля Ethernet, поэтому на данный момент я не могу ничего по этому поводу сказать.

Мой чип Wi-Fi работает на основе команды:

$ 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


Обновление 2

При $ ping 8.8.4.4получении сообщения «Узел назначения недоступен»:

$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

Я вижу пакеты, передаваемые при подключении к интернету.

Также, при использовании модема:

$ 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

И только с Wi-Fi:

$ 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

Я вижу, что есть небольшая разница ip route show.

Похоже, пакеты не могут пройти через шлюз при использовании Wi-Fi (?).



Обновление 3

Wi-Fi работает нормально при использовании Live CD.

При обычной загрузке я не могу получить доступ к сети, используя только мобильную беспроводную точку доступа.

Что-то не так с настройками беспроводной сети в текущей версии Ubuntu?



Обновление 4

ядуматьVirtualBox установил мост, и я регулярно пользуюсь VirtualBox.

решение1

maan81 проделал довольно хорошую работу, изолировав эту проблему в таблице маршрутизации:

  1. Тестирование с помощью установочного диска исключило все аппаратные средства как причину - умный запуск.
  2. Подключение к беспроводному маршрутизатору подтвердило конфигурацию соединения wlan0.

Два очень хитрых шага. Так почему же вы можете подключиться к беспроводному маршрутизатору, но не можете подключиться к интернет-трафику?

Проблема становится очевидной в таблице маршрутизации maan81:

$ 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 

Маршрут через br0 (который никуда не ведет, потому что находится в состоянии linkdown) имеет более низкую метрику (100), чем маршрут wlan0 (600). Это означает, что он выигрывает весь трафиккромекоторый привязан к подсети 192.168.0.1. Интерфейс находится непосредственно в этой подсети, поэтому маршрутизация по умолчанию не применяется к этому трафику.

Кто здесь главный?

Первый шаг, который вам следует сделать, это определить, какой сетевой менеджер отвечает. В подавляющем большинстве случаев это будет NetworkManager.

К сожалению, maan81 и я пропустили этот шаг, предположив, что всем заправляет NetworkManager, и в течение двух дней нам пришлось развлекаться, поскольку мост br0 продолжал появляться при каждой перезагрузке.

# Determine network renderer
netplan get renderer

Если ваш рендерерNetworkMangerВы можете перейти к разделу «Методы устранения неполадок».

Если ваш рендерерсетевой, то вы используете netplan и все ваши проблемы в /etc/netplan/*.yaml. Пожалуйста, обратитесь кКанонический Netplanдля полной документации. Если вы намерены придерживатьсянетплан, часть из того, что будет написано ниже, может быть полезно, нонетпланэто слишком большая тема, чтобы рассматривать ее в рамках этого ответа.

maan81 действительно запустил netplan и решил вернуться к NetworkManager.

Вернуться из netplan в NetworkManager

Следующее выполняется как root. cat...EOFКоманда должна быть выполнена как непрерывный блок. Не перепутайте отступы в файле .yaml — netplan придирчив к таким вещам.

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

Это то, что в конечном итоге решило проблемы сети maan81. Ниже приведены некоторые из «инструментов», которые мы использовали для достижения этого решения.

Поиск неисправностей

Резервное копирование таблицы маршрутизации:

# Backup the route table
sudo ip route save > route.bin
# Recover the route table
sudo ip route restore < route.bin

Манипуляции с мостом:

# 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 

Изменить метрику соединения

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

Перезапись маршрута по умолчанию методом грубой силы

# 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 

Краткое содержание:

В профессиональном мире запуск нескольких маршрутов по умолчанию считается очень плохой практикой. В конце концов, «множественный» и «стандартный» — это противоречивые понятия.

Для пользовательских рабочих столов NetworkManager обрабатывает это автоматически, но не всегда делает это правильно. Если у вас есть более одного активного сетевого интерфейса, он создаст несколько маршрутов по умолчанию. Когда это происходит, метрика определяет, куда течет ваш интернет-трафик.

Связанный контент