☰

¿Se le ha bloqueado el acceso a Internet?

tag-icon • tag-icon networking kernel updates 22.04
¿Se le ha bloqueado el acceso a Internet?

No estoy seguro... pero cuando actualicé Ubuntu 22.04 y su kernel y reinicié, se me bloqueó el acceso a Internet; aunque estoy conectado y puedo acceder e iniciar sesión en las páginas de administración del enrutador.

Mi smartphone que está en el mismo wifi no tiene problemas.

¿Pasó algo durante la actualización que bloqueó la computadora portátil?

Actualizar

No estoy usando Ethernet porque no tengo el cable Ethernet en este momento, por lo que no puedo comentar al respecto en este momento.

Mi chip wifi basado en el 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

Actualización 2

Con $ ping 8.8.4.4Obtengo Host de destino inalcanzable:

$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

Veo paquetes transmitidos durante la conexión.

Además, cuando está 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

Y solo con 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

Veo que hay una ligera diferencia en ip route show.

Parece que los paquetes no pueden pasar la puerta de enlace cuando usan wifi (?).

Actualización 3

Wifi funciona bien cuando se usa un CD en vivo.

Cuando inicio normalmente, no puedo acceder a la red utilizando únicamente el punto de acceso inalámbrico móvil.

¿Algo anda mal con la configuración inalámbrica del Ubuntu actual?

Actualización 4

IpensarVirtualBox había instalado el puente y lo uso con regularidad.

Respuesta1

maan81 hizo un buen trabajo al aislar este problema en la tabla de rutas:

  1. Las pruebas con el disco de instalación eliminaron todo el hardware como causa: inicio inteligente.
  2. La conexión al enrutador inalámbrico validó la configuración de la conexión wlan0.

Dos pasos muy inteligentes. Entonces, ¿por qué puede conectarse al enrutador inalámbrico pero no puede hacerlo el tráfico destinado a Internet?

El problema se hace evidente en la tabla de rutas de 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

La ruta vía br0 (que no va a ninguna parte porque está en estado de enlace inactivo) tiene una métrica más baja (100) que la ruta wlan0 (600). Esto significa que gana todo el tráfico.exceptoque se dirige a la subred 192.168.0.1. Hay una interfaz directamente en esa subred, por lo que el enrutamiento predeterminado no se aplica a ese tráfico.

¿Quién está a cargo aquí?

El primer paso que debe dar es determinar qué administrador de red está a cargo. En la gran mayoría de los casos será NetworkManager.

Lamentablemente, maan81 y yo nos saltamos este paso asumiendo que NetworkManager estaba ejecutando el programa y fuimos llevados a una alegre persecución durante dos días mientras el puente br0 seguía apareciendo con cada reinicio.

# Determine network renderer
netplan get renderer

Si su renderizador esAdministrador de redpuedes pasar a Técnicas de solución de problemas.

Si su renderizador esen red, entonces está ejecutando netplan y todos sus problemas están en /etc/netplan/*.yaml. Por favor refiérase aPlan de red canónicopara documentación completa. Si tiene la intención de seguir conplan de red, algo de lo que sigue puede ser útil peroplan de redEs un tema demasiado amplio para tratarlo en el alcance de esta respuesta.

De hecho, maan81 estaba ejecutando netplan y optó por volver a NetworkManager.

Revertir de netplan a NetworkManager

Lo siguiente se realiza como root. El cat...EOFcomando debe ejecutarse como un bloque contiguo. Tenga en cuenta que no estropee las sangrías del archivo .yaml; netplan es exigente con esas cosas.

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

Esto es lo que finalmente resolvió los problemas de red de maan81. Lo que sigue son algunas de las "herramientas" que utilizamos para llegar a esta solución.

Solución de problemas

Copia de seguridad de su tabla de rutas:

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

Manipulación de puentes:

# 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

Cambiar métrica de conexión

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

Sobrescritura por fuerza bruta de la ruta predeterminada

# 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

Resumen:

En el mundo profesional, ejecutar varias rutas predeterminadas se considera una muy mala práctica. Después de todo, "múltiple" y "predeterminado" son conceptos contradictorios.

Para los escritorios de los usuarios, NetworkManager maneja esto automáticamente, pero no siempre lo hace bien. Si tiene más de una interfaz de red activa, se crearán varias rutas predeterminadas. Cuando eso sucede, la métrica determina hacia dónde fluye su tráfico de Internet.

información relacionada