Cuando trabajo con redes Linux, separo siempre la capa física de la lógica: interfaz, IP, DNS, puerta de enlace y, en WiFi, autenticación y radio. Esa división evita muchos diagnósticos erróneos y permite decidir rápido si el problema está en la configuración, en el router o en la señal. Aquí repaso los conceptos que sí importan y los pasos prácticos para configurar y revisar una conexión en portátiles, escritorios y equipos más sobrios.
Lo esencial para dejar una conexión Linux estable y fácil de mantener
- Linux no trata la red como un bloque único: interfaz, IP, rutas y DNS se gestionan por capas.
- NetworkManager suele ser la opción más cómoda en portátiles y escritorios; systemd-networkd encaja mejor en máquinas fijas y servidores.
- Con
nmcliynmtuipuedes conectar a WiFi, guardar perfiles y automatizar reconexiones sin depender de la interfaz gráfica. - Un chequeo básico con
ip a,ip route,nmcli dev statusy los logs del servicio resuelve la mayoría de incidencias. - En seguridad y privacidad, WPA3, contraseñas largas, WPS desactivado y un DNS bien elegido marcan más diferencia de la que parece.
Qué hay detrás de una conexión en Linux
Una interfaz de red es el punto de entrada del sistema al cable o al aire: enp3s0 para Ethernet, wlp2s0 para WiFi, o nombres predecibles similares. Sobre esa interfaz viajan la IP, la máscara, la puerta de enlace, el DNS y las rutas; si una de esas capas falla, la conexión puede parecer activa aunque no sirva para nada. La MTU, que es el tamaño máximo de paquete que puede circular sin fragmentarse, también importa cuando hay túneles, VPN o equipos antiguos.
En WiFi aparece otra capa más: SSID, BSSID, contraseña, cifrado y canal. El SSID es el nombre visible de la red y el BSSID identifica el punto de acceso concreto; por eso dos routers con el mismo nombre no son exactamente la misma red. Cuando entiendes esta diferencia, deja de sorprender que un portátil se conecte pero salte de un AP a otro o que un problema de DNS se confunda con un fallo de cobertura. Con esa base clara, la pregunta útil es qué componente debe gobernar la conexión en cada equipo.
Qué gestor de red conviene en cada caso
Mi regla práctica es simple: si el equipo cambia de red con frecuencia, uso NetworkManager; si es una máquina fija y quiero una configuración declarativa, prefiero systemd-networkd; si estoy en Ubuntu, netplan suele ser la capa que escribe la intención y delega en uno de los dos anteriores. Netplan no sustituye al gestor de fondo: solo decide cómo se aplica la configuración.
| Herramienta | Encaje ideal | Fortaleza | Límite |
|---|---|---|---|
| NetworkManager | Portátiles, escritorios, WiFi, VPN | Perfiles guardados, reconexión automática, GUI, TUI y CLI | Es más completo, así que no es el más minimalista |
| systemd-networkd | Servidores, máquinas fijas, contenedores | Ligero, predecible y muy cómodo con archivos .network
|
La experiencia WiFi es menos directa y suele requerir más piezas |
| netplan | Ubuntu y derivados | Configuración declarativa uniforme | No gestiona por sí mismo; depende del renderer que haya debajo |
Yo prefiero NetworkManager cuando el equipo tiene que moverse entre redes, usar VPN o cambiar de perfil a menudo. En un servidor con una sola interfaz y una vida tranquila, systemd-networkd suele ser suficiente y más limpio. Cuando eso está claro, configurar deja de ser una pelea y pasa a ser un trámite razonable.
Cómo configurar Ethernet y WiFi sin perder tiempo
Si me toca entrar por terminal, empiezo por comprobar si la radio está encendida y si la interfaz aparece administrada por NetworkManager. Para el uso diario, nmcli me parece más fiable que una GUI cuando quiero repetir un cambio; nmtui es mejor cuando alguien necesita un panel simple y no quiere memorizar comandos.
Con nmcli
Primero miro el estado de la radio y de la interfaz. Después escaneo redes, conecto y verifico que haya IP, ruta y DNS. La primera conexión crea un perfil guardado automáticamente, así que después puedes ajustar IP, DNS o prioridad sin volver a escribir la contraseña. Si vas a fijar una dirección estática, hazlo sobre ese perfil y no en una lista de archivos dispersos; te ahorras inconsistencias entre reinicios.
nmcli radio
nmcli radio wifi on
nmcli dev wifi list
nmcli dev wifi connect "NombreSSID" --ask
nmcli con show --activenmcli con mod "NombreSSID" ipv4.addresses 192.168.1.50/24 ipv4.gateway 192.168.1.1 ipv4.dns "1.1.1.1 9.9.9.9" ipv4.method manual
nmcli con up "NombreSSID"En Ethernet, el patrón es parecido, pero el problema habitual no es la radio sino el DHCP, el cable o el perfil mal definido. Si la red debe ser estable y repetible, DHCP con reserva en el router suele ser más limpio que clavar una IP estática en el cliente.
Con nmtui
Cuando no quiero pelearme con menús gráficos ni recordar opciones de consola, abro nmtui. Es útil en servidores con acceso local, en máquinas minimalistas o cuando la persona que administra el equipo solo necesita algo sencillo y visible.
- Ejecuta
nmtui. - Entra en
Activate a connectionoEdit a connection. - Elige la red WiFi, introduce la clave y guarda el perfil.
La diferencia real está en la disciplina: si guardas cada conexión con un nombre claro y no mezclas cambios hechos en varios sitios, el sistema se vuelve predecible. Y esa previsibilidad importa más que la herramienta concreta. Con la conexión ya levantada, toca afinar el comportamiento inalámbrico para que no dependa de suerte.
Ajustes de WiFi que sí cambian la experiencia
En WiFi, el problema rara vez es solo "la contraseña". Yo miro primero banda, cobertura y perfil de conexión. Un equipo puede autenticarse bien y seguir dando guerra si está en 2.4 GHz saturado, si el DNS del perfil es malo o si la red guarda demasiadas reglas de reconexión.
Cobertura y bandas
En 2.4 GHz, los canales 1, 6 y 11 son los que suelen evitar solaparse mejor; en 5 GHz y 6 GHz hay menos interferencia y más capacidad, siempre que el hardware lo soporte. Como referencia práctica, por encima de -60 dBm la señal suele ir holgada, alrededor de -67 dBm sigue siendo razonable para videollamadas y por debajo de -70 dBm empiezan las caídas y la latencia irregular. No es una ley física, pero sí una pista útil para no culpar al sistema operativo cuando el problema está en el aire.
También conviene recordar que ocultar el SSID no vuelve más segura una red. Solo la hace menos cómoda de administrar. Si el objetivo es estabilizar la conexión, yo prefiero un SSID visible, un canal sensato y un router con WPA3 cuando sea posible.
IP, DNS y perfiles
Si solo quieres que un equipo tenga "siempre la misma dirección", yo prefiero reservar la IP en el router antes que fijarla a mano en el cliente. DHCP resuelve mejor los cambios de red, evita conflictos y hace más fácil mover el portátil entre casa, trabajo y un punto de acceso temporal. La IP fija solo me parece imprescindible en servidores, impresoras o equipos que otros deben localizar sin ambigüedad.
También merece atención el DNS. Muchas veces el usuario cree que "no hay Internet" cuando en realidad hay conexión, pero el resolvedor apunta a un servidor lento o caído. En redes domésticas o pequeñas, un DNS fiable y consistente aporta más estabilidad que tocar parámetros exóticos que no resuelven el problema de fondo.
Lee también: Puerto WAN del router - Guía para evitar fallos de red
Privacidad en redes ajenas
En redes públicas, conviene desactivar la reconexión automática a SSID abiertos y usar una MAC aleatoria cuando la red no dependa de filtrado por hardware. Eso reduce el seguimiento básico, aunque puede romper portales cautivos o listas blancas basadas en MAC. Si la red es tuya y necesitas acceso estable, usa MAC fija y una VPN; si es ajena, prioriza higiene y no comodidad.
Yo también soy prudente con los perfiles guardados: si una red no es de confianza, no la dejo con autoconexión por defecto. Es una pequeña decisión de configuración que evita más exposición de la que parece. Si aun así algo falla, conviene aislar el problema por capas y dejar de adivinar.
Cómo diagnosticar cuando algo falla
Cuando algo falla, yo no empezaría por reinstalar nada. Primero separo el problema en tres preguntas: ¿ve la interfaz?, ¿obtiene IP?, ¿resuelve DNS? Esa secuencia reduce mucho el ruido, porque una conexión "verde" en la bandeja no significa que la pila de red esté completa.
| Síntoma | Lo más probable | Qué reviso primero |
|---|---|---|
| No aparecen redes | WiFi desactivado, bloqueo por software o firmware |
nmcli radio, estado de la radio y logs del arranque |
| Conecta pero no navega | DNS, puerta de enlace o portal cautivo |
ip route y resolvectl status
|
| Se corta al moverse | Cobertura pobre o canal saturado | Medir señal y probar 5 GHz o una posición distinta del AP |
La interfaz sale como unmanaged
|
Otro servicio la controla o el perfil está mal definido | Estado de NetworkManager y configuración de la distro |
| La IP cambia de forma extraña | DHCP conflictivo o perfil duplicado |
nmcli con show y el perfil activo |
Los cuatro comandos que más uso son nmcli dev status, ip a, ip route y journalctl -u NetworkManager -b. Si trabajas con systemd-networkd, cambia el último por journalctl -u systemd-networkd -b. Cuando los problemas son de WiFi puro, el historial del servicio suele decir más que cualquier intuición. Y una vez que ese diagnóstico básico funciona, la configuración deja de ser reactiva y pasa a ser preventiva.
Lo que dejaría listo en un equipo Linux nuevo
Si tuviera que dejar un portátil o una miniestación lista para no pensar en ella durante semanas, haría cinco cosas: elegir un único gestor, guardar perfiles bien nombrados, verificar DNS fiable, activar seguridad inalámbrica fuerte y documentar el comando de recuperación. Ese orden no hace magia, pero sí evita la clase de fallos pequeños que terminan en tiempo perdido.
- Usaría WPA3 si el router lo soporta; si no, WPA2 con una clave larga y única.
- Desactivaría WPS, porque añade superficie de ataque sin aportar demasiado a cambio.
- Separaría la red de invitados de la red principal cuando haya IoT, impresoras o equipos de trabajo.
- Actualizaría firmware y microcódigo antes de culpar al sistema operativo.
- Guardaré una nota con el perfil WiFi, el DNS y el comando de diagnóstico que realmente uso.
Con eso, la red deja de ser una caja negra y se convierte en un componente más del sistema, predecible y auditable. Y esa es la diferencia que más se nota cuando administras equipos Linux con frecuencia o cuando trabajas en entornos donde una conexión insegura cuesta más que unos minutos de configuración.
