Saltar al contenido
sudoquest@root
Linux

Redes en Linux

Tu dirección y tus rutas (ip), quién contesta (ping), el DNS, quién escucha en cada puerto (ss, curl, nc), netplan y el cortafuegos (ufw).

30 min de lectura

Para hablar con otras máquinas, un servidor necesita cuatro cosas: su dirección IP (y de qué tamaño es su red), la puerta de enlace (el router por el que sale todo lo que no es de su red), un DNS (quien traduce nombres a direcciones) y, para ofrecer algo, un programa escuchando en un puerto. Casi todos los problemas de red son una de las cuatro.

En este tema aprendes a mirar cada una, a probarlas, a dejar la red fija con netplan y a cerrar lo que no hace falta con el cortafuegos. Los ejemplos son de srv-oficina, el servidor de una gestoría pequeña: su red es la 192.168.50.0/24, el router es el .1, el NAS el .30 y la impresora el .40.

Tu dirección: ip a

ip a (address) enseña las interfaces de red y sus direcciones. Con -br, una línea por interfaz:

tecnico@srv-oficina:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens18            UP             192.168.50.10/24 fe80::be24:11ff:fe3c:500a/64

lo es la de loopback: la máquina hablando consigo misma (127.0.0.1, también llamada localhost). ens18 es la tarjeta de red de verdad: está levantada (UP) y tiene la dirección 192.168.50.10. El /24 dice el tamaño de su red: los tres primeros números son la red (192.168.50) y el último, la máquina. Todo lo que empiece por 192.168.50. está en la misma red y se le habla directamente; lo demás, a través del router. La dirección fe80::… es la de IPv6 de enlace local, que la tarjeta se pone sola.

Por dónde sale: ip r

ip r (route) enseña la tabla de rutas:

tecnico@srv-oficina:~$ ip r
default via 192.168.50.1 dev ens18 proto static
192.168.50.0/24 dev ens18 proto kernel scope link src 192.168.50.10

La segunda línea sale sola de la dirección: la red 192.168.50.0/24 está al otro lado de ens18. La primera, default via 192.168.50.1, es la puerta de enlace: lo que no es de ninguna otra ruta va al router. ip r get dice por dónde iría un paquete concreto:

tecnico@srv-oficina:~$ ip r get 1.1.1.1
1.1.1.1 via 192.168.50.1 dev ens18 src 192.168.50.10 uid 1000
  cache

Ejercicio

Tu dirección y tus rutas: ip

Acabas de llegar a la gestoría. Antes de tocar nada, mira cómo está conectado srv-oficina a la red.

Preparando la máquina…

Quién contesta: ping

ping manda un paquete y espera la respuesta. Sin -c no para nunca (en un servidor de verdad, hasta que pulsas Ctrl+C), así que casi siempre se usa con -c y un número:

tecnico@srv-oficina:~$ ping -c 3 192.168.50.1
PING 192.168.50.1 (192.168.50.1) 56(84) bytes of data.
64 bytes from 192.168.50.1: icmp_seq=1 ttl=64 time=0.504 ms
64 bytes from 192.168.50.1: icmp_seq=2 ttl=64 time=0.605 ms
64 bytes from 192.168.50.1: icmp_seq=3 ttl=64 time=0.294 ms

--- 192.168.50.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2021ms
rtt min/avg/max/mdev = 0.294/0.468/0.605/0.130 ms

Lo que dice cuando no contesta también es una pista:

  • Destination Host Unreachable: la dirección es de tu red, pero nadie la tiene (o la puerta de enlace no existe). Nadie contesta a “¿quién es el .99?”.
  • Network is unreachable: no hay ninguna ruta por la que mandarlo (falta la ruta por defecto, o la interfaz no tiene dirección).
  • Temporary failure in name resolution: ni siquiera ha salido: no ha podido traducir el nombre. Eso es el DNS.
tecnico@srv-oficina:~$ ping -c 2 192.168.50.99
PING 192.168.50.99 (192.168.50.99) 56(84) bytes of data.
From 192.168.50.10 icmp_seq=1 Destination Host Unreachable
From 192.168.50.10 icmp_seq=2 Destination Host Unreachable

--- 192.168.50.99 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1065ms
pipe 2

Ejercicio

¿Quién contesta?: ping

Comprueba quién responde en la red de la oficina: el router, el NAS por su nombre y una dirección donde no hay nadie.

Preparando la máquina…

Los nombres: el DNS

Los programas preguntan los nombres a quien diga /etc/resolv.conf. En Ubuntu, casi siempre es 127.0.0.53: systemd-resolved, un servicio de la propia máquina que pregunta a su vez a los DNS de verdad (los que se configuran en netplan). resolvectl status dice cuáles son:

tecnico@srv-oficina:~$ resolvectl status
Global
     Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens18)
  Current Scopes: DNS
       Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.50.1
     DNS Servers: 192.168.50.1

dig pregunta al DNS directamente y enseña la respuesta entera (con +short, solo la dirección):

tecnico@srv-oficina:~$ dig +short nas.oficina.lan
192.168.50.30

Antes de preguntar al DNS, ping, curl y el navegador miran /etc/hosts: una línea ahí (una IP y un nombre) manda sobre el DNS, y dig no la ve. Si dig y ping no llevan un nombre a la misma dirección, mira cat /etc/hosts.

Ejercicio

Nombres y direcciones: dig y resolv.conf

Averigua cómo traduce srv-oficina los nombres a direcciones, y quién se lo dice.

Preparando la máquina…

Quién escucha: ss, curl y nc

Un servicio espera conexiones en un puerto (ssh en el 22, una web en el 80 o el 443…). ss -tlnp lista los puertos TCP (t) que escuchan (l), en números (n) y con su programa (p, que con sudo enseña también los de otros usuarios):

tecnico@srv-oficina:~$ sudo ss -tlnp
State     Recv-Q    Send-Q       Local Address:Port        Peer Address:Port    Process
LISTEN    0         2048               0.0.0.0:8080             0.0.0.0:*        users:(("intranet",pid=400,fd=5))
LISTEN    0         4096         127.0.0.53%lo:53               0.0.0.0:*        users:(("systemd-resolve",pid=102,fd=4))
LISTEN    0         128                0.0.0.0:22               0.0.0.0:*        users:(("sshd",pid=141,fd=3))
LISTEN    0         128                   [::]:22                  [::]:*        users:(("sshd",pid=141,fd=4))

Fíjate en la dirección de delante del puerto: 0.0.0.0 es “en todas mis direcciones” (se puede llegar desde fuera); 127.0.0.1 es “solo desde esta misma máquina”. Un servicio que escucha en 127.0.0.1 funciona en el servidor y no se ve desde ningún otro sitio, por mucho que abras el cortafuegos. Para probarlo, curl pide la página y nc -zv solo prueba si el puerto contesta:

tecnico@srv-oficina:~$ nc -zv 192.168.50.30 80
nc: connect to 192.168.50.30 port 80 (tcp) failed: Connection refused

Connection refused es que la máquina está pero nadie escucha en ese puerto. Si en cambio se queda esperando hasta timed out, algo (un cortafuegos) tira los paquetes sin contestar.

Un puerto solo lo puede tener un programa: si ya es de otro, el servicio no arranca (su journalctl dice Connection in use).

Ejercicio

Quién escucha: ss, curl y nc

Mira qué servicios atienden en srv-oficina y en qué puertos, prueba la intranet y comprueba si el NAS tiene ssh.

Preparando la máquina…

La red fija: netplan

Lo que pongas con ip addr add o ip route add no dura: se pierde al reiniciar (o al aplicar netplan). En Ubuntu Server, la configuración de verdad está en /etc/netplan/, en YAML:

tecnico@srv-oficina:~$ sudo cat /etc/netplan/00-installer-config.yaml
# This is the network config written by 'subiquity'
network:
ethernets:
  ens18:
    addresses:
    - 192.168.50.10/24
    nameservers:
      addresses:
      - 192.168.50.1
      search: []
    routes:
    - to: default
      via: 192.168.50.1
version: 2

La dirección con su /24, los DNS (nameservers) y la ruta por defecto (routes, to: default por el router). En YAML la sangría importa y va con espacios, nunca con tabuladores. Antes de aplicar, sudo netplan generate comprueba el archivo; si algo está mal, dice la línea y la columna:

tecnico@srv-oficina:~$ sudo netplan generate
/etc/netplan/00-installer-config.yaml:7:7: Error in network definition: unknown key 'nameserver'
    nameserver:
    ^

Y sudo netplan apply lo aplica: deja la red exactamente como dice el archivo (lo puesto a mano, fuera). Si no dice nada, ha ido bien.

Ejercicio

netplan: encontrar el error y aplicar

Alguien ha tocado /etc/netplan/00-installer-config.yaml y dice que "ya no aplica". Encuentra el error, arréglalo y aplica la configuración.

Preparando la máquina…

El cortafuegos: ufw

ufw (uncomplicated firewall) decide qué conexiones pueden entrar. Lo normal: cerrar todo lo que entra (deny (incoming)) y abrir solo lo que hace falta. El orden importa: primero se deja pasar ssh y luego se activa, o te cortas tu propia conexión:

tecnico@srv-oficina:~$ sudo ufw allow OpenSSH
tecnico@srv-oficina:~$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Se abre un puerto (sudo ufw allow 8080/tcp) o un puerto solo para una red o una sola máquina (sudo ufw allow from 192.168.50.40 to any port 8081 proto tcp), y ufw status numbered enseña las reglas con su número (para borrar una: sudo ufw delete 2):

tecnico@srv-oficina:~$ sudo ufw status numbered
Status: active

   To                         Action      From
   --                         ------      ----
[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] 8080/tcp                   ALLOW IN    192.168.50.0/24
[ 3] OpenSSH (v6)               ALLOW IN    Anywhere (v6)

Ejercicio

El cortafuegos, sin quedarte fuera: ufw

srv-oficina no tiene cortafuegos. Actívalo sin cortar tu propia conexión (ssh) y deja la intranet abierta solo a la red de la oficina.

Preparando la máquina…