☰

Bloqueado de acessar a internet?

tag-icon • tag-icon networking kernel updates 22.04
Bloqueado de acessar a internet?

Não tenho certeza ... mas como atualizei o Ubuntu 22.04 e seu kernel e reiniciei, estou sendo impedido de acessar a Internet; embora eu esteja conectado e possa acessar e fazer login nas páginas de administração do roteador.

Meu smartphone que está no mesmo wifi não tem problemas.

Aconteceu alguma coisa durante a atualização que bloqueou o laptop?

Atualizar

Não estou usando Ethernet porque não tenho o cabo Ethernet no momento, então não posso comentar sobre isso no momento.

Meu chip wifi baseado no comando:

$ 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

Atualização 2

Com $ ping 8.8.4.4recebo 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

Vejo pacotes transmitidos durante o tethering.

Além disso, quando com 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

E apenas com Wifi:

$ 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

Vejo que há uma pequena diferença ip route show.

Parece que os pacotes não conseguem passar pelo gateway ao usar wifi (?) .

Atualização 3

Wifi funciona bem ao usar um live cd.

Ao inicializar normalmente, não consigo acessar a rede usando apenas o hotspot móvel sem fio.

Algo errado com as configurações sem fio do Ubuntu atual?

Atualização 4

EUpensarO VirtualBox instalou a ponte e eu uso o VirtualBox regularmente.

Responder1

maan81 fez um bom trabalho isolando esse problema na tabela de rotas:

  1. O teste com o disco de instalação eliminou todo o hardware como causa - início inteligente.
  2. A conexão ao roteador sem fio validou a configuração da conexão wlan0.

Duas etapas muito inteligentes. Então, por que você consegue se conectar ao roteador sem fio, mas nenhum tráfego vinculado à Internet consegue?

O problema fica aparente na tabela de rotas do 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

A rota via br0 (que não leva a lugar nenhum porque está em estado de linkdown) tem uma métrica mais baixa (100) do que a rota wlan0 (600). Isso significa que ele ganha todo o tráfegoexcetoaquele vinculado à sub-rede 192.168.0.1. Há uma interface diretamente nessa sub-rede, portanto o roteamento padrão não se aplica a esse tráfego.

Quem está no comando aqui?

O primeiro passo que você deve realizar é determinar qual gerente de rede está responsável. Na grande maioria dos casos será NetworkManager.

Infelizmente, maan81 e eu pulamos esta etapa presumindo que o NetworkManager estava comandando o show e fomos conduzidos a uma alegre perseguição por dois dias enquanto a ponte br0 continuava aparecendo a cada reinicialização.

# Determine network renderer
netplan get renderer

Se o seu renderizador forGerenciador de redevocê pode pular para técnicas de solução de problemas.

Se o seu renderizador forrede, então você está executando o netplan e todos os seus problemas estão em /etc/netplan/*.yaml. ConsulteNetplan canônicopara documentação completa. Se você pretende ficar complano de rede, algumas das coisas a seguir podem ser úteis, masplano de redeé um assunto muito grande para ser tratado no escopo desta resposta.

maan81 estava de fato executando o netplan e optou por reverter para o NetworkManager.

Reverter do netplan para o NetworkManager

O seguinte é executado como root. O cat...EOFcomando deve ser executado como um bloco contíguo. Lembre-se de não bagunçar os recuos no arquivo .yaml - o netplan é exigente com essas coisas.

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

Foi isso que resolveu os problemas de rede do maan81. A seguir estão algumas das “ferramentas” que usamos para chegar a esta solução.

Solução de problemas

Fazendo backup de sua tabela de rotas:

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

Manipulação de ponte:

# 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

Alterar métrica de conexão

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

Substituição de força bruta da rota padrão

# 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

Resumo:

No mundo profissional, executar múltiplas rotas padrão é considerado uma prática muito ruim. Afinal, “múltiplo” e “padrão” são conceitos contraditórios.

Para desktops de usuários, o NetworkManager cuida disso automaticamente para você, mas nem sempre acerta. Se você tiver mais de uma interface de rede ativa, várias rotas padrão serão criadas. Quando isso acontece, a métrica determina para onde flui o tráfego da Internet.

informação relacionada