GhostLinuxMódulo 109Examen 102-500

Fundamentos de redes

LPI 109.1 Protocolos de internetLPI 109.2 Configuración persistenteLPI 109.3 Resolución de problemasLPI 109.4 DNS de cliente

Este módulo no te convierte en administrador de redes, pero sí te deja con lo que cualquier administrador de sistemas necesita: entender direccionamiento IP, dejar la configuración de red de un servidor sobreviviendo a un reinicio, diagnosticar por qué algo no conecta, y resolver nombres de dominio desde el cliente.

Objetivos de la unidad

Manejar direccionamiento IPv4/IPv6, máscaras, notación CIDR y los puertos más comunes.
Configurar red de forma persistente con NetworkManager, netplan y systemd-networkd.
Diagnosticar problemas de conectividad con las herramientas estándar.
Configurar la resolución DNS del lado cliente.

1. LPI 109.1 — Fundamentos de protocolos de internet

1.1 Modelo OSI y TCP/IP

El examen espera que sepas situar un protocolo o un problema en la capa correcta. Si quieres repasar la encapsulación capa a capa de forma visual e interactiva antes de seguir, hazlo ahora:

🧰 Recursos relacionados (Ghost Academy)

Simulador visual — laboratorio interactivo de Ghost Academy: 📶 GHOSTOSI: modelo OSI, encapsulación por capas

Capa OSI	Ejemplo
7 Aplicación	HTTP, DNS, SSH
4 Transporte	TCP, UDP
3 Red	IP, ICMP
2 Enlace	Ethernet, ARP
1 Física	Cable, Wi-Fi

1.2 Direccionamiento IPv4

Concepto	Ejemplo
Dirección IPv4	192.168.1.10 — 32 bits, 4 octetos
Máscara de red	255.255.255.0 — separa parte de red de parte de host
Notación CIDR	`192.168.1.10/24` — el `/24` indica cuántos bits son de red (equivale a 255.255.255.0)
Dirección de red	`192.168.1.0/24` — todos los bits de host a 0
Dirección de broadcast	`192.168.1.255` — todos los bits de host a 1

Rango privado (RFC 1918)	CIDR	Uso típico
10.0.0.0 – 10.255.255.255	/8	Redes grandes, datacenters
172.16.0.0 – 172.31.255.255	/12	Redes medianas, Docker por defecto
192.168.0.0 – 192.168.255.255	/16	Redes domésticas/pequeña oficina — la que usa tu VM del módulo 00
127.0.0.0/8	/8	Loopback — `127.0.0.1` es "este mismo equipo"

Las direcciones privadas no se enrutan en internet público — por eso puedes tener 192.168.1.10 en tu VM de laboratorio y en la de medio mundo a la vez sin conflicto: solo tienen sentido dentro de su propia red local, detrás de un NAT.

1.3 IPv6, lo mínimo que pregunta el examen

Concepto	Ejemplo
Dirección completa	`2001:0db8:0000:0000:0000:ff00:0042:8329` — 128 bits, 8 grupos hexadecimales
Forma abreviada	`2001:db8::ff00:42:8329` — ceros a la izquierda de cada grupo se omiten, y un único `::` sustituye la secuencia más larga de grupos a cero
Loopback	`::1` — equivalente a `127.0.0.1` en IPv4
Link-local	`fe80::/10` — autoasignada en cada interfaz, válida solo en el segmento local

:: solo puede aparecer una vez en una dirección IPv6 — si apareciera dos veces no habría forma de saber cuántos grupos de ceros representa cada una. Es una pregunta de examen clásica detectar una dirección IPv6 mal abreviada por esta regla.

1.4 TCP vs UDP y puertos conocidos

	TCP	UDP
Conexión	Orientado a conexión (handshake previo)	Sin conexión, cada datagrama es independiente
Fiabilidad	Garantiza entrega y orden, retransmite si hace falta	No garantiza nada — más rápido, menos overhead
Uso típico	HTTP/HTTPS, SSH, bases de datos	DNS, DHCP, streaming, VoIP

root@lpic1:~#

$ grep -E '^(ssh|http|https|dns)\s' /etc/services
ssh		22/tcp
http		80/tcp
https		443/tcp
domain		53/tcp
domain		53/udp

Puerto	Servicio	Protocolo
22	SSH	TCP
25	SMTP (módulo 108)	TCP
53	DNS	TCP y UDP
67/68	DHCP (servidor/cliente)	UDP
80	HTTP	TCP
443	HTTPS	TCP
631	CUPS (módulo 108)	TCP/UDP

/etc/services es exactamente el fichero que traduce nombre de servicio a número de puerto que acabas de consultar — y /etc/protocols, su equivalente para protocolos IP a bajo nivel (tcp, udp, icmp...).

2. LPI 109.2 — Configuración persistente de red

Todo lo que configures con ip addr add o ip route add desaparece al reiniciar — son cambios en caliente. Para que sobrevivan, hace falta guardarlos donde el sistema correspondiente los relea al arrancar.

Sistema	Dónde se configura de forma persistente
Debian (ifupdown clásico)	`/etc/network/interfaces`
Ubuntu moderno	`netplan` — ficheros YAML en `/etc/netplan/*.yaml`, que por debajo generan configuración para NetworkManager o `systemd-networkd`
Con systemd-networkd directamente	`/etc/systemd/network/*.network`
Con NetworkManager (habitual en escritorio)	`nmcli` / `nmtui`, o la propia GUI

root@lpic1:~#

$ cat /etc/network/interfaces
auto eth0
iface eth0 inet static
    address 192.168.1.50
    netmask 255.255.255.0
    gateway 192.168.1.1

root@lpic1:~#

$ cat /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.1.50/24]
      gateway4: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]

root@lpic1:~#

$ netplan apply
# aplica la configuracion de los ficheros YAML sin reiniciar

root@lpic1:~#

$ nmcli device status
DEVICE  TYPE      STATE      CONNECTION
eth0    ethernet  connected  Cableada 1
lo      loopback  unmanaged  --

root@lpic1:~#

$ nmcli connection show "Cableada 1"
ipv4.method:    manual
ipv4.addresses: 192.168.1.50/24
ipv4.gateway:   192.168.1.1

Netplan no es un tercer sistema de red independiente — es una capa de abstracción: tú escribes YAML, y netplan genera por debajo la configuración real para NetworkManager o para systemd-networkd, según lo que indique renderer: en el propio YAML.

2.1 Nombre del equipo y resolución local

root@lpic1:~#

$ hostnamectl
   Static hostname: lpic1-lab
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 9f8e7d6c5b4a...
Operating System: Debian GNU/Linux 12 (bookworm)
            Kernel: Linux 6.1.0-18-amd64

root@lpic1:~#

$ hostnamectl set-hostname servidor-web

root@lpic1:~#

$ cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	lpic1-lab
192.168.1.20	servidor-bd.local servidor-bd

/etc/hosts resuelve nombres a IP de forma estática, sin consultar ningún DNS — tiene prioridad sobre el DNS en la configuración estándar (sección 4), y es la forma más rápida de forzar una resolución concreta en pruebas, sin tocar ningún servidor DNS real.

🧰 Recursos relacionados (Ghost Academy)

Practica más — labs ya publicados en Ghost Academy sobre este tema: 🌐 Comandos de red I (lab)

3. LPI 109.3 — Resolución básica de problemas de red

Comando	Para qué
`ip addr show`	Direcciones IP asignadas a cada interfaz ahora mismo
`ip link show`	Estado de las interfaces (UP/DOWN), independientemente de si tienen IP
`ip route show`	Tabla de rutas, incluida la puerta de enlace por defecto
`ping -c4 host`	Comprueba conectividad básica (ICMP) — `-c4` para no dejarlo corriendo indefinidamente
`traceroute host` / `tracepath host`	Muestra cada salto (router) por el que pasa el tráfico hasta el destino
`mtr host`	Combina `ping` y `traceroute` en una vista continua, salto a salto
`ss -tulpn`	Puertos en escucha y conexiones activas — el reemplazo moderno de `netstat`
`tcpdump -i eth0`	Captura el tráfico real que pasa por una interfaz, paquete a paquete

root@lpic1:~#

$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
    inet 192.168.1.50/24 brd 192.168.1.255 scope global eth0

root@lpic1:~#

$ ip route show
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50

root@lpic1:~#

$ ping -c4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=11.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=10.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=11.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=11.1 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss

root@lpic1:~#

$ traceroute 8.8.8.8
 1  192.168.1.1 (192.168.1.1)  0.412 ms
 2  10.20.0.1 (10.20.0.1)  3.221 ms
 3  * * *
 4  8.8.8.8 (8.8.8.8)  11.045 ms

root@lpic1:~#

$ ss -tulpn
Netid  State   Local Address:Port    Process
tcp    LISTEN  0.0.0.0:22            sshd
tcp    LISTEN  0.0.0.0:631           cupsd
udp    UNCONN  0.0.0.0:68            dhclient

Metodología de diagnóstico esperada en el examen, de dentro hacia fuera: 1) ip addr — ¿tengo IP?; 2) ip route — ¿tengo puerta de enlace?; 3) ping a la puerta de enlace — ¿llego al router?; 4) ping a una IP externa (8.8.8.8) — ¿sale a internet?; 5) ping/dig a un nombre de dominio — ¿resuelve DNS? (sección 4). Cada paso descarta una capa distinta del problema.

Herramientas legadas que todavía puedes encontrar mencionadas: ifconfig (sustituido por ip addr/ip link) y netstat (sustituido por ss) — forman parte del paquete net-tools, obsoleto pero aún presente en muchos sistemas por compatibilidad. El examen puede preguntarte por su equivalente en ip/ss.

🧰 Recursos relacionados (Ghost Academy)

Practica más — labs ya publicados en Ghost Academy sobre este tema: 🌐 Comandos de red II (lab)

Valida lo aprendido — tests temáticos de Recursos: 🌐 Test: Red

4. LPI 109.4 — Configurar DNS de cliente

root@lpic1:~#

$ cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1
search local.lan
domain local.lan

Directiva	Significado
`nameserver`	IP de un servidor DNS a consultar — puede repetirse para tener varios, por orden de preferencia
`search`	Sufijos de dominio a probar automáticamente cuando buscas un nombre corto sin puntos
`domain`	Dominio local por defecto del equipo (forma más antigua, en gran parte sustituida por `search`)

En sistemas con systemd-resolved activo, /etc/resolv.conf suele ser un enlace simbólico generado automáticamente — editarlo a mano no sirve de nada porque se regenera. En ese caso la configuración real se consulta con resolvectl status y se gestiona desde netplan/NetworkManager, no editando el fichero directamente.

root@lpic1:~#

$ resolvectl status
Global
         Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 2 (eth0)
    Current Scopes: DNS
         DNS Servers: 8.8.8.8 1.1.1.1
          DNS Domain: local.lan

El orden en el que el sistema decide dónde buscar un nombre (primero /etc/hosts, luego DNS, ninguno, o al revés) no lo decide resolv.conf sino /etc/nsswitch.conf:

root@lpic1:~#

$ grep ^hosts /etc/nsswitch.conf
hosts:          files dns

Esa línea hosts: files dns es la que explica por qué /etc/hosts (sección 2.1, "files") siempre gana a una consulta DNS real si ambos tienen una respuesta distinta para el mismo nombre — el orden de palabras en la línea es literalmente el orden de prioridad.

Para probar resolución sin depender de ningún caché local:

root@lpic1:~#

$ host www.example.com
www.example.com has address 93.184.216.34

root@lpic1:~#

$ dig www.example.com +short
93.184.216.34

root@lpic1:~#

$ nslookup www.example.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Name:	www.example.com
Address: 93.184.216.34

Herramienta	Estado
`dig`	La más completa y la recomendada actualmente — muestra todos los detalles de la respuesta DNS
`host`	Salida mínima y directa, perfecta para scripts
`nslookup`	La más antigua de las tres, técnicamente "obsoleta" mucho tiempo pero todavía ampliamente usada

Práctica guiada

En tu VM: ejecuta ip addr show y calcula a mano la dirección de red y de broadcast de tu IP/máscara actual.
Revisa tu configuración persistente de red (/etc/network/interfaces o /etc/netplan/*.yaml según tu distro) y compárala con lo que ves en caliente con ip addr.
Sigue la metodología de diagnóstico de la sección 3 paso a paso: ip addr → ip route → ping a tu gateway → ping 8.8.8.8 → dig a un dominio real.
Ejecuta ss -tulpn y localiza en qué puerto escucha tu servidor SSH.
Añade una entrada de prueba en /etc/hosts apuntando un nombre inventado a 127.0.0.1, y comprueba con ping que se resuelve sin tocar ningún DNS.
Consulta tu /etc/resolv.conf (o resolvectl status si aplica) e identifica qué servidores DNS estás usando ahora mismo.

Resumen de comandos del módulo

Bloque	Comandos clave
109.1 Protocolos	`/etc/services`, `/etc/protocols`, CIDR, RFC 1918, TCP vs UDP
109.2 Config. persistente	`/etc/network/interfaces`, `netplan`, `nmcli`, `hostnamectl`, `/etc/hosts`
109.3 Troubleshooting	`ip addr`/`link`/`route`, `ping`, `traceroute`, `mtr`, `ss`, `tcpdump`
109.4 DNS cliente	`/etc/resolv.conf`, `/etc/nsswitch.conf`, `resolvectl`, `dig`/`host`/`nslookup`

Autoevaluación

¿Qué significa el /24 en 192.168.1.10/24, y cuál sería la dirección de broadcast de esa red?
¿Por qué una dirección IPv6 solo puede llevar :: una vez?
¿Qué diferencia fundamental hay entre TCP y UDP, y por qué DNS usa normalmente UDP?
Configuras una IP con ip addr add directamente en terminal y funciona, pero desaparece al reiniciar. ¿Por qué, y qué deberías haber hecho en su lugar?
Sigue la metodología de diagnóstico de la sección 3: tienes IP y ruta por defecto, el ping al gateway funciona, pero ping 8.8.8.8 falla. ¿Qué capa del problema acabas de aislar?
¿Por qué editar /etc/resolv.conf a mano puede no servir de nada en un sistema con systemd-resolved?
¿Qué línea de /etc/nsswitch.conf determina si /etc/hosts tiene prioridad sobre el DNS?

← 108 · Servicios esenciales Índice del curso 110 · Seguridad →