Resulta que romper tu sistema es muy fácil, si pones tu corazón y tu mente en ello. Este problema tiene un origen complicado y una solución bastante interesante, así que tengan paciencia conmigo. Da la casualidad de que era una noche oscura y lluviosa, y me puse a probar varios servicios de VPN. Uno de ellos:Mullvad. Funcionó bien por un tiempo, pero luego actualicé la versión de la aplicación de la compilación 2019.1 a la compilación 2019.8, y las cosas dejaron de funcionar bien. Cada vez que me conectaba a VPN, la resolución de DNS se detenía. Cuadro de prueba:Kubuntu 18.04.
No estaba seguro de si esto era específico de mi host o un problema más amplio, así que decidí probar también en KDE neón, que resulta ser una de las muchas distribuciones que he instalado en la computadora portátil G50. Uno o dos reinicios más tarde, muchas buenas actualizaciones de Plasma (hasta el 5.16.90 en el momento de escribir este artículo) y algunos pequeños ajustes, tenía Mullvad funcionando bien. Pero luego, el administrador de la red comenzó a quejarse de la conectividad limitada. A ver que da.
Más problemas, más detalles
Primero, quería entender POR QUÉ Mullvad no funcionaba bien en la instancia de Kubuntu. Después de una depuración mágica, me di cuenta de que había un conflicto con Pi-Hole, instalado localmente. Cuando se trata de DNS, solo puede haber uno. O algo. Y, por supuesto, systemd seguro que no ayuda con su miríada de enlaces simbólicos y registros ofuscados. Pero esa es una historia aparte.
En neón, tenía la conectividad VPN, pero aproximadamente un minuto después de la sesión, el signo de exclamación apareció repentinamente junto al icono de conexión inalámbrica. Curioso. Hice todo tipo de pruebas de velocidad y conectividad de la red, y todo funcionaba sin problemas. Sin embargo, el ícono permaneció, y nmcli general lo confirma en la línea de comando.
¿Qué dice el registro?
Bueno, revisar los registros del sistema nunca es una actividad divertida, pero esta mostró algo que no había visto antes. Errores relacionados con los adaptadores virtuales de VMware Workstation vmnet1 y vmnet8. Aparentemente, eran problemas con la funcionalidad de DHCP.
... dhcpcd[1042]:vmnet8:dhcp_sendpacket:Operación no permitida
... dhcpcd[1042]:vmnet1:dhcp_sendpacket:Operación no permitida
Como la configuración de la estación de trabajo era una versión de prueba caducada de todos modos, decidí desinstalar el programa y ver si esto realmente resolvería el problema. Y parece que lo hizo. El motivo real del problema fue que Mullvad está configurado para bloquear el tráfico de la red local de forma predeterminada cuando está conectado, lo que incluye los rangos locales utilizados por los adaptadores vmnet.
Por lo tanto, la solución al problema sería permitir el tráfico local en la aplicación VPN o, alternativamente, modificar el uso del software afectado. Por otra parte, el problema no es realmente uno a menos que deba usar ambos al mismo tiempo. Para la mayoría de las personas, esto nunca será relevante.
Entonces, ¿cuál es el mensaje aquí?
He visto docenas de informes sobre el "administrador de red + signo de exclamación" en la Web, y la mayoría de los usuarios creen que se trata de un error tonto, un comportamiento transitorio que se puede eliminar reiniciando el administrador de red o volviendo a conectar la red. pero en este caso particular, HABÍA una "especie de" problema real; sin embargo, se alinea con la palabra tonto. No era grande, cardinal o notorio a menos que necesitara tener máquinas virtuales ejecutándose en ese momento, pero existía, y el Administrador de red, de hecho, informó correctamente un estado degradado de funcionalidad, por lo tanto, conectividad limitada.
Conclusión
Los pequeños problemas aleatorios pueden ser muy molestos. Más aún cuando tiendes a querer ignorarlos como un error en el software, pero luego terminan siendo reales. No necesariamente cardinal, simplemente no un falso positivo. Es por eso que nunca debe diagnosticar problemas si su funcionalidad principal está ahí. Pero nos dimos cuenta de esto, así que todo está bien.
En un escenario como este, el siguiente paso lógico sería que el sistema operativo compartiera los detalles del problema en lugar de solo alertar y permitir que el usuario comprenda completamente las implicaciones y luego decida si hacer algo o ignorarlas. El signo de exclamación, sin ninguna explicación detallada, es innecesariamente alarmante, especialmente porque no tiene ningún efecto visible. Y seamos realistas, si Internet funciona, entonces no hay problema, ¡verdad! Bueno, si eres uno de los nerds que odian la aleatoriedad repentina, este podría calmar tus demonios del TOC muy levemente. Ahora, si el signo de exclamación vuelve a aparecer, hablaremos. Otra vez. Hemos terminado.