¿Sabes cómo sabes que tienes un problema divertido de Linux? Cuando le lleva más tiempo pensar en un título adecuado para el artículo que la depuración real. Porque me encontré con un problema bastante extraño relacionado con la red, y pasé un tiempo tratando de averiguar qué sucede. Lo resolví y lo comparto ahora.
En esencia, esto es lo que sucedió. Me encontré probando algunos enrutadores nuevos. En mi instancia de neón de KDE, me conecté al nuevo punto de acceso inalámbrico e intenté navegar. Ninguna cosa. Probé con un cable con cable, y todo estaba bien. Luego, inicié una instancia de Linux diferente en esta máquina de ocho inicios y la conectividad inalámbrica funcionó sin problemas. Ambos sistemas estaban basados en Ubuntu y ambos usaban la línea de base 18.04. Bueno, es hora de descubrir por qué mi conexión inalámbrica no se comportaba como neón.
Problema con más detalle
Para comprender mejor el problema, traté de hacer un ping básico. Esto le dará una buena indicación de si realmente puede comunicarse con cualquier host remoto, además de ofrecerle una idea de que comprenderá si su DNS está configurado correctamente. Instantáneamente, noté un problema:
Desde 192.168.2.107 (192.168.2.107) icmp_seq=1 Host de destino inaccesible
Desde 192.168.2.107 (192.168.2.107) icmp_seq=2 Host de destino inaccesible
Desde 192.168.2.107 (192.168.2.mp_seq) ic Host de destino inalcanzable
Intentar hacer ping a CUALQUIER dirección (digamos dedoimedo.com) se resolvería en 192.168.2.107. Lo que lo empeora es que el rango del punto de acceso era 192.168.8.X. Entonces, algo estaba codificado en este rango interno diferente y estaba arruinando mi Internetz. Pude confirmar esto revisando la tabla de enrutamiento:
ruta
Tabla de enrutamiento de IP del núcleo
Puerta de enlace de destino Genmask Flags Métrica Ref Usar Iface
predeterminado 192.168.2.1 0.0.0.0 UG 303 0 0 wlp2s0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 wlp2s0
192.168.2.0 0.0.0.0 255.255.255.0 U 303 0 0 wlp2s0
192.168.8.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp2s0
Por alguna fea razón, cada vez que me conectaba a la red 192.168.8.0, la red 192.168.2.0 también se agregaba y se configuraba como la puerta de enlace predeterminada, lo que explica por qué no había conectividad. Pero esto solo sucedió con el adaptador inalámbrico y no con el cableado. Pista, ahí mismo. Pero primero, eliminemos algunas otras opciones.
Resolución del sistema
En este punto, o más bien, justo antes de este punto, me incliné a culpar a systemd. Pero resulta que no tiene nada de malo. Ahora, hubo / hay errores en él, por lo que aparece bastante alto si busca problemas de conectividad en Linux. Para asegurarme de que no era el culpable, lo deshabilité:
sudo systemctl inhabilitar systemd-resolved
sudo systemctl detener systemd-resolved
También eliminé el enlace simbólico /etc/resolv.conf y edité la configuración administrada por la red:
/etc/NetworkManager/NetworkManager.conf
En la sección [principal], agregué:
dns=predeterminado
Ninguna diferencia hasta ahora. Necesitamos avanzar.
Administrador de red
Otro posible villano puede ser el Network Manager. De hecho, para verificar que no estaba haciendo algo extraño, eliminé todas las configuraciones inalámbricas guardadas, eliminé su archivo de configuración, reinicié y comencé de nuevo. Esto tampoco hizo ninguna diferencia. Siguiente culpable.
Solución
Podemos ver que no podemos culpar a DNS o al administrador de red. También podemos ver que la puerta de enlace incorrecta está configurada cada vez que me conecto a la red que no es 192.168.2.0. Lo más probable es que esto indique algo en la configuración de DHCP:asignación automática (estática) de direcciones IP. De hecho, ¿quizás haya una regla estática en alguna parte? ¡He aquí que lo había! En /etc/dhcpcd.conf, tenía lo siguiente:
...
slaac privado
interfaz wlp2s0
static ip_address=192.168.2.107/24
static routers=192.168.2.1
static domain_name_servers=127.0.0.1
...
Algo, y estoy usando la frase vagamente, había configurado una dirección IP y un enrutador estáticos, de ahí el problema. Y entonces, pude recordar qué era ese algo. Había probado Pi-Hole en esta caja hace un tiempo. Y después de eliminarlo, aparentemente, la configuración no se limpió. Todos los diferentes bits y piezas se habían ido, pero no la configuración de DHCP. No es un problema cuando usa una red que coincide con el enrutamiento estático, pero sí lo es cuando prueba un rango diferente. ¡Tan pronto como eliminé las dos entradas para la interfaz inalámbrica, todo estuvo bien! Problema resuelto.
Conclusión
Es muy posible que nunca encuentre un problema como este. Pero si lo hace, saque conclusiones precipitadas que no debe, y debe trabajar con cuidado, metódicamente. Debo admitir que sospeché de systemd de inmediato, pero luego examiné lentamente los diferentes componentes en la pila de red, hasta que aislé al villano. Resulta que una pieza de software desinstalada había dejado cambios de configuración en el sistema, lo que causó el problema. Peor aún, esto sucedió muchos meses después, por lo que no siempre es trivial conectar los dos.
Es de esperar que haya obtenido una idea de cómo abordar los problemas de red. Comience de manera simple, verifique la conectividad básica, intente correlacionar la información y luego trabaje hasta llegar a la causa raíz. Aquí, tenía Internet per se, pero debido a rutas mal configuradas, realmente no podía llegar a los sitios web correctos o resolver las direcciones correctamente. Esto puede desviarlo del curso, pero luego, eliminé systemd de la ecuación, descubrí que no era el administrador de la red el que estaba haciendo algo mal y finalmente me centré en la asignación de ruta/IP estática de DHCP. Bueno, si esto ayuda, cómprame una bebida virtual de algún tipo en algún momento. hemos terminado RECONOCER.