Guía completa de redes en Linux: comandos, diagnóstico, configuración y solución de problemas

Idea central: en Linux moderno, el diagnóstico de red empieza con ip, nmcli, resolvectl, ss, tcpdump y los logs del sistema. Ya no conviene depender únicamente de comandos antiguos como ifconfig o netstat.

ip addr
ip link
ip -br addr
ip -br link

ip route
ip route show default
ip route get 8.8.8.8

Diagnóstico rápido: si hay IP pero no hay ruta predeterminada, el servidor puede comunicarse con su red local, pero no sabrá cómo salir hacia otras redes.

sudo ip addr add 192.168.1.50/24 dev ens33
sudo ip link set ens33 up
sudo ip route add default via 192.168.1.1

sudo ip addr del 192.168.1.50/24 dev ens33

Importante: usa configuración temporal solo para diagnóstico. Para producción, configura la red con Netplan, NetworkManager o el método oficial de tu distribución.

network:
  version: 2
  ethernets:
    ens33:
      dhcp4: no
      addresses:
        - 192.168.1.50/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

sudo netplan try
sudo netplan apply

Precaución: si estás conectado por SSH, usa netplan try. Si la configuración rompe la conectividad, podrás revertir antes de quedar fuera del servidor.

nmcli device status
nmcli connection show
nmcli general status

sudo nmcli connection modify "System ens33" \
  ipv4.addresses 192.168.1.50/24 \
  ipv4.gateway 192.168.1.1 \
  ipv4.dns "1.1.1.1 8.8.8.8" \
  ipv4.method manual

sudo nmcli connection up "System ens33"

sudo nmcli connection modify "System ens33" ipv4.method auto
sudo nmcli connection up "System ens33"

ip -br addr
ip route
ping -c 4 192.168.1.1
ping -c 4 8.8.8.8
resolvectl query somoslibres.org

resolvectl status
resolvectl query google.com
resolvectl dns
resolvectl domain

cat /etc/resolv.conf

Pista útil: si ping 8.8.8.8 funciona, pero resolvectl query dominio.com falla, el problema no es la salida a Internet, sino DNS.

sudo ss -tulpn
ss -tunap
ss -s

sudo tcpdump -i ens33
sudo tcpdump -i ens33 port 53
sudo tcpdump -i ens33 host 192.168.1.10
sudo tcpdump -i ens33 -nn

sudo tcpdump -i ens33 -w diagnostico-red.pcap

Privacidad: una captura de red puede contener datos sensibles. Guárdala cifrada, compártela solo con personal autorizado y elimínala cuando ya no sea necesaria.

sudo ethtool ens33
sudo ethtool -S ens33 | head

flush ruleset

table inet filter {
chain input {
type filter hook input priority 0;
policy drop;

```
iif lo accept
ct state established,related accept

tcp dport 22 accept
tcp dport {80, 443} accept

ip protocol icmp accept
ip6 nexthdr ipv6-icmp accept
```

}

chain forward {
type filter hook forward priority 0;
policy drop;
}

chain output {
type filter hook output priority 0;
policy accept;
}
}

sudo nft -f /etc/nftables.conf
sudo nft list ruleset
sudo systemctl enable --now nftables

Precaución: si administras por SSH, valida que el puerto 22 esté permitido antes de aplicar una política de entrada en DROP.

journalctl -u NetworkManager --since "1 hour ago"
journalctl -u systemd-networkd --since "1 hour ago"
journalctl -u systemd-resolved --since "1 hour ago"
journalctl -p err -xb

1. Verificar si la interfaz existe: ip link.
2. Confirmar si tiene IP: ip addr.
3. Revisar gateway: ip route.
4. Probar red local: ping gateway.
5. Probar salida IP: ping 8.8.8.8.
6. Probar DNS: resolvectl query dominio.
7. Ver puertos: ss -tulpn.
8. Revisar firewall: nft list ruleset.
9. Analizar tráfico: tcpdump.
10. Revisar logs: journalctl.

• Documentar IP, máscara, gateway, DNS, VLAN y función del servidor.
• Evitar cambios manuales no documentados en producción.
• Usar Netplan o NetworkManager según la distribución.
• No editar varias herramientas de red a la vez sin entender cuál controla la interfaz.
• Probar cambios de red antes de aplicarlos definitivamente.
• Permitir solo puertos necesarios en el firewall.
• Centralizar logs de red y seguridad.
• Monitorear disponibilidad, latencia, errores, drops y consumo de ancho de banda.
• Separar redes de administración, usuarios, aplicaciones, bases de datos y backups.
• Usar nombres de interfaz consistentes en documentación y automatización.

• Configurar IP temporal y creer que será permanente.
• Editar Netplan y NetworkManager al mismo tiempo sin saber cuál aplica.
• Olvidar la ruta predeterminada.
• Confundir problema de DNS con problema de Internet.
• Aplicar firewall sin permitir SSH.
• No revisar logs después de un cambio.
• No probar configuración antes de reiniciar red en servidores remotos.
• No documentar VLAN, gateway o DNS.
• Dejar servicios escuchando en todas las interfaces sin necesidad.
• No monitorear errores físicos de la interfaz.

¿Qué comando reemplaza a ifconfig?

En Linux moderno se recomienda usar ip, especialmente ip addr, ip link e ip route.

¿Qué comando reemplaza a netstat?

Para revisar sockets, puertos y conexiones se recomienda ss, que forma parte del ecosistema iproute2.

¿Ubuntu usa Netplan o NetworkManager?

Ubuntu Server usa Netplan para describir la configuración de red, aunque Netplan puede trabajar con distintos backends, como systemd-networkd o NetworkManager.

¿RHEL, Rocky y AlmaLinux usan nmcli?

Sí. En sistemas de la familia RHEL, NetworkManager y nmcli son herramientas habituales para administrar conexiones de red desde consola.

¿Cómo sé si el problema es DNS?

Si puedes llegar a una IP pública, pero no puedes resolver nombres de dominio, el problema probablemente está en DNS. Revisa con resolvectl status y resolvectl query.

¿Cuándo usar tcpdump?

Cuando necesitas confirmar si los paquetes realmente entran o salen por una interfaz. Es muy útil para DNS, firewall, rutas, puertos y problemas difíciles de conectividad.

• Guía práctica para aprender redes en Linux utilizando herramientas open source.
• Comandos básicos que debes aprender para administrar tu servidor Linux.
• Guía definitiva para administrar servidores Linux: instalación, rendimiento, seguridad y mantenimiento.
• Cómo proteger servidores Linux mediante Zero Trust, MFA y auditoría continua.

Conclusión editorial

Las redes en Linux no se resuelven con adivinanzas. Se resuelven con método, comandos correctos y evidencia. Un buen administrador no solo sabe configurar una IP: sabe demostrar por dónde viaja el tráfico, qué servicio escucha, qué regla bloquea, qué DNS responde y qué log confirma la causa real del problema.