Quien no se ha encontrado con el problema de cambio de versión de un sistema operativo, bien sea en Windows o cualquiera de las distribuciones Linux.

Suele haber una curva de aprendizaje dura los primeros días, que se manifiesta con:

Cambios de entornos gráfico
Rediseño de interficies
Cambios en la forma de configurar las cosas
Cambios en los ficheros de configuración
Actualización de nuevos paquetes
Nuevas mejoras
Software obsoleto

Todo eso suele «asustar» a los SYSADMINS, y muchas veces la solución pasa por seguir utilizando la versión que conocemos mejor, que es la anterior.

Un grave error, pues tenemos que recordar que recurrir a versiones anteriores acorta la vida útil del software. Recordemos que el software tiene un lifecycle, fuera de dicho periodo de tiempo nuestro aplicación o sistema operativo se queda sin mantenimiento…. y recordemos que un Sistema Operativo fuera de dicho periodo es un sistema TOTALMENTE INSEGURO.

En concreto si vemos el lifecycle de las versiones de Ubuntu, nos encontramos con el siguiente gráfico:

Hablando ya en entornos de Ubuntu, si recurrimos a la versión 16.04 tenemos un periodo de vida útil del Servidor de unos pocos años. Por experiencia puedo indicar, que mis alumnos suelen recurrir a la instalación de versiones Ubuntu 16.04 para evitar las dificultades de la curva de aprendizaje a la nueva versión de Ubuntu 18.04. Podemos encontrar en el siguiente enlace las principales características de Ubuntu 20.04

Ubuntu Server 20.04 LTS: stability, security and more

Uno de los principales aspectos de cambio entre la versión 16.04 y la versión 20.04 ( y 18.04 también ) es la manera de configurar la red, problema que trae de cabeza a muchos. Hay un cambio bastante profundo en la forma de configuración, así como en la desaparición de determinados paquetes de networking del paquete net-tools: ifconfig, traceroute, route… Vamos, un lio.

NETPLAN – Capa de abstracción de configuración de red.

Netplan es una utilidad para configurar fácilmente la red en un sistema Linux. Se basa en crear un fichero de texto siguiendo especifaciones YAML en la carpeta /etc/netplan.

Netplan admite dos formas de configurar la máquina

Básicamente NetworkManager la utilizaremos para entornos de escritorio gráficos, y Systemd-netwokd para entornos servidor.

El presente Post pretende ser una introducción para mejorar esa curva de aprendizaje del nuevo entorno… examinando algún nuevo comando y viendo dos configuraciones básicas con netplan.

Indicar que existes diferentes formas y abreviaturas de escribir los comandos y los valores del fichero de configuración de netplan. Por claridad utilizaré siempre el criterio más claro (al menos para mi ) y enfocado a la claridad, que no siempre es el más rápido, para los «ansias».

Comandos básicos de Networking, novedades

Empecemos por examinar la configuración ip de nuestro servidor con ip address show o ip link show:

root@ubuntu:~# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:0c:29:41:2a:18 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.50/24 brd 192.168.1.255 scope global ens33
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe41:2a18/64 scope link
valid_lft forever preferred_lft forever

Cabe destacar que tenemos activado ipv6…. que si no lo necesitamos lo suyo es desactivarlo… con la utilización de:

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1

Vemos en la siguiente captura respecto a la anterior, que la parte inet6 ya no aparece.

root@ubuntu:~# sysctl -w net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.all.disable_ipv6 = 1
root@ubuntu:~# sysctl -w net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6 = 1
root@ubuntu:~# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:0c:29:41:2a:18 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.50/24 brd 192.168.1.255 scope global ens33
valid_lft forever preferred_lft forever

Los cambios son temporales. Si queremos que los cambios sean permanentes después de un reboot del sistema tenemos que editar con permisos de administrador el fichero /etc/default/grub

Una vez editado con sudo nano /etc/default/grub debemos modificar la línea

GRUB_CMDLINE_LINUX_DEFAULT=""

Añadiendo:

GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1"

Una vez modificada la línea tenemos que actualizar el menú Grub mediante el comando:

sudo update-grub

Ahora los cambios YA SON PERMAMENTES… IPV6 está desactivado

Para saber el gateway de nuestra red ya no podemos recurrir ni a route ni a netstat.. La alternativa ip route show.

root@ubuntu:~# ip route show
default via 192.168.1.1 dev ens33 proto static
192.168.1.0/24 dev ens33 proto kernel scope link src 192.168.1.50

En este caso vemos como el gateway es la ip 192.168.1.1. Una mejora interesando es utilizar ip route get, que nos dice para una IP determinada la ruta que toma el paquete… Algo útil cuando nuestro servidor tiene múltiples rutas. En nuestro caso veamos dos ejemplos a IP de la red local 192.168.1.0/24 y otra externa 8.8.8.8

root@ubuntu:~# ip route get 192.168.1.1
192.168.1.1 dev ens33 src 192.168.1.50 uid 0
cache
root@ubuntu:~# ip route get 8.8.8.8
8.8.8.8 via 192.168.1.1 dev ens33 src 192.168.1.50 uid 0
cache

Vemos como en el caso de la red local 198.168.1.1 el paquete ip es enviado a traves de la nic ens33 al switch directamente, y en el caso del 8.8.8.8 al gateway de nuestra red 192.168.1.1

Podemos bajar administrativamente una nic utilizando ip link set «nic» down.

root@ubuntu:~# ip link set ens33 down
root@ubuntu:~# ip address show ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 00:0c:29:41:2a:18 brd ff:ff:ff:ff:ff:ff

Y la volvemos a activar con el UP correspondiente:

root@ubuntu:~# ip link set ens33 up
root@ubuntu:~# ip address show ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:0c:29:41:2a:18 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.50/24 brd 192.168.1.255 scope global ens33
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe41:2a18/64 scope link
valid_lft forever preferred_lft forever

Vemos la tabla ARP de nuestro servidor con ip neigh show.


root@ubuntu:~# ip neigh show
192.168.1.1 dev ens33 lladdr a8:9a:93:5a:88:70 STALE
192.168.1.100 dev ens33 lladdr 1c:1b:0d:92:9b:71 REACHABLE

Interesante poder añadir una entrada estática a nuestra tabla ARP apuntando al Gateway, de esta forma podemos evitar técnicas de MiTM para la redirección de nuestro tráfico de red.

root@ubuntu:~# ip neigh add 192.168.1.1 lladdr a8:9a:93:5a:88:70 nud permanent dev ens33
root@ubuntu:~# ip neigh show
192.168.1.1 dev ens33 lladdr a8:9a:93:5a:88:70 PERMANENT
192.168.1.100 dev ens33 lladdr 1c:1b:0d:92:9b:71 REACHABLE

Podemos tener estadísticas de los diferentes interfaces de red:

root@ubuntu:~# ip -s link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
432084 6084 0 0 0 0
TX: bytes packets errors dropped carrier collsns
432084 6084 0 0 0 0
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 00:0c:29:41:2a:18 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
339076 4606 0 136 0 0
TX: bytes packets errors dropped carrier collsns
191435 1323 0 0 0 0

Y otro comando básico… ¿Cómo podemos ver las conexiones de red de nuestra máquina? Pues con el comando Show Sockets.. En la captura podemos ver en rojo la conexión ssh entre mi máquina Windows 192.168.1.100 y el servidor Ubuntu 192.168.150

root@ubuntu:~# ss -ltpan
State Recv-Q Send-Q Local Address:Port Peer Address:Port 
LISTEN 0 128 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=404,fd=13))
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=482,fd=3))
ESTAB 0 64 192.168.1.50:22 192.168.1.100:6881 users:(("sshd",pid=750,fd=3),("sshd",pid=725,fd=3))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=482,fd=4))

Con los parámetros -ltpan especificamos lo siguiente:

-l, –listening
-a, –all
-n, –numeric
-t, –tcp
-p, –processes

Con el DNS es otro cantar… Si se pueden hacer las cosas diferentes, aquí han sacado matrícula de honor… Si examinamos el archivo de toda la vida /etc/resolf.conf nos encontramos con esto:

root@ubuntu:~# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0
search mytcpip.local

Resumiendo que ahora las peticiones dns se canalizan a través de un servidor DNS interno de la propia máquina que está a la escucha de las peticiones como cliente en la IP 127.0.0.53. Con un nmap podemos ver que es así

root@ubuntu:~# nmap -sU -sS 127.0.0.53 -p 53

Starting Nmap 7.60 ( https://nmap.org ) at 2019-05-05 01:56 PDT
Nmap scan report for localhost (127.0.0.53)
Host is up (0.000033s latency).

PORT STATE SERVICE
53/tcp open domain
53/udp open|filtered domain

Podemos utilizar las órden systemd-resolve –status para ver el estado

root@ubuntu:~# systemd-resolve --status
Global
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test

Link 2 (ens33)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.1.1
DNS Domain: mytcpip.local

Vemos que cuando se realiza una petición de resolución de nombres DNS, esta petición se envía a nuestra propia máquina y esta se encarga de preguntarle al DNS que hayamos especificado en la configuración TCP/IP. Esta entrada queda cacheada durante un tiempo establecido por el TTL por si la volvemos a necesitar. Vemos en estas capturas de pantalla este concepto. En rojo la parte importante a observar:

root@ubuntu:~# ping www.mytcpip.com -c 1
PING mytcpip.com (146.66.85.161) 56(84) bytes of data.
64 bytes from ip-146-66-85-161.siteground.com (146.66.85.161): icmp_seq=1 ttl=51 time=40.3 ms

--- mytcpip.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 40.397/40.397/40.397/0.000 ms

root@ubuntu:~# dig www.mytcip.com

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> www.mytcip.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51028
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.mytcip.com. IN A

;; Query time: 26 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun May 05 02:02:17 PDT 2019
;; MSG SIZE rcvd: 43

Con las órdenes systemd-resolve –statistics y systemd-resolve –flush-caches podemos visualizar información importante de dicho servicio:

root@ubuntu:~# systemd-resolve --statistics
DNSSEC supported by current servers: no

Transactions
Current Transactions: 0
Total Transactions: 35

Cache
Current Cache Size: 7
Cache Hits: 14
Cache Misses: 21

DNSSEC Verdicts
Secure: 0
Insecure: 0
Bogus: 0
Indeterminate: 0

Si queremos borrar la cache local de nuestro servidor DNS utilizamos la siguiente órden:

root@ubuntu:~# systemd-resolve --flush-caches
root@ubuntu:~# systemd-resolve --statistics
DNSSEC supported by current servers: no

Transactions
Current Transactions: 0
Total Transactions: 35

Cache
Current Cache Size: 0
Cache Hits: 14
Cache Misses: 21

DNSSEC Verdicts
Secure: 0
Insecure: 0
Bogus: 0
Indeterminate: 0

Vemos como las entradas de la cache se han queado a 0.

Configuración NETPLAN con direccionamiento estático/manual

Como hemos mencionado anteriormente, y al tratarse de un servidor sin entorno gráfico DEBEMOS optar por utilizar el render Systemd-networkd

Esto es lo que hace la línea que vemos más adelante de :

 renderer: networkd

En la carpeta /etc/netplan están el/los archivo(s) de configuración, 01-netcfg.yaml en nuestro caso. Observar la extensión… yaml y el comentario mencionado anteriormente… Es un estándar.. YAML

root@ubuntu:~# ls /etc/netplan/
01-netcfg.yaml

Veamos el siguiente ejemplo típico:

Datos configuración:

IP 192.168.1.50/24
Gateway: 192.168.1.1
DNS: 192.168.1.1
Search Domain: mytcpip.local

Bastará con añadir las siguientes líneas al archivo /etc/netplan/01-netcfg.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    ens33:
      addresses: [192.168.1.50/24]
      gateway4: 192.168.1.1
      nameservers:
        search: [mytcpip.local]
        addresses: [192.168.1.1]

Para aplicar los cambios bastará con ejecutar netplan apply

root@ubuntu:~# netplan apply

Recordaros que veréis tutoriales con especificaciones algo diferentes añadiendo comillas, etc. Todas son válidad. Yo adopto un criterio, el mio 🙂

Desgraciadamente las especifaciones YAML no son muy amigas de los tabuladores, espacios de más y de menos, etc… Es imposible transmitir en este pequeño Post las diferentes normativas, hay que tirar de experiencia… Pero tenedlo en cuenta. Evitar tabuladores y jugar con la sangría del texto adecuadamente.

Siempre tenemos netplan –debug generate para ayudarnos con los errores:

root@ubuntu:~# netplan --debug generate
DEBUG:command generate: running ['/lib/netplan/generate']
** (generate:1728): DEBUG: 02:17:41.461: Processing input file /etc/netplan/01-netcfg.yaml..
** (generate:1728): DEBUG: 02:17:41.461: starting new processing pass
** (generate:1728): DEBUG: 02:17:41.461: ens33: setting default backend to 1
** (generate:1728): DEBUG: 02:17:41.461: Generating output files..
** (generate:1728): DEBUG: 02:17:41.462: NetworkManager: definition ens33 is not for us (backend 1)

Configuración NETPLAN con direccionamiento estático/manual CAMBIANDO el nombre del adaptador de red de ens33 a lan

En este ejemplo renombraremos el interface ens33 por el de lan, un nombre más adecuado a su función: es el adaptador que cuelga de la red LAN. Si queréis saber algo más sobre el porqué de los nombres ens33… podéis ir al siguiente en link Nombres predecibles en las interfaces de red

El cambio es muy sencillo.. Bastará con asignar el nombre lan a la «MAC» del interface ens33. Veamos el fichero de configuración /etc/netplan/01-netcfg.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    lan:
      match:
         macaddress: "00:0c:29:41:2a:18"
      set-name: lan
      addresses: [192.168.1.50/24]
      gateway4: 192.168.1.1
      nameservers:
         search: [mytcpip.local]
         addresses: [192.168.1.1]

Veamos que ahora el interface se llama… LAN. Un nombre más lógico y adecuado a su función que ens33

root@mytcpip:~# ip address show lan
2: lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:0c:29:41:2a:18 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.50/24 brd 192.168.1.255 scope global lan
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe41:2a18/64 scope link
valid_lft forever preferred_lft forever

Si nuestro servidor tuviera dos tarjetas de red, la configuración es también muy sencilla. Vamos a imaginar que queremos llamar a la interface externa wan. El fichero sería:

network:
  version: 2
  renderer: networkd
  ethernets:
   lan:
     match:
        macaddress: "00:0c:29:41:2a:18"
     set-name: lan
     addresses: [192.168.1.50/24]
   wan:
     match:
        macaddress: "00:0c:29:bb:aa:cc"
     set-name: wan
     addresses: [172.17.7.222/1624]
     gateway4: 172.17.0.100
     nameservers:
        search: [mytcpip.local]
        addresses: [172.17.0.100]

Configuración NETPLAN por DHCP

La configuración por DHCP es sumamente sencilla…

network:
  version: 2
  renderer: networkd
  ethernets:
    ens33:
      dhcp4: true

Por razones de simplicidad, no hace falta ningún comentario al respecto.

3 comments

Roberto diciembre 9, 2019 - 10:09 pm

Si, por eso mucha gente se hincha y se decanta por distros que aún usan SysV init a la vieja usanza como AntiX o Devuan por ejemplo.

javi septiembre 10, 2019 - 12:38 pm

Muy util y bien explaicado JL, sigue asi!

José Luis Sánchez Borque septiembre 23, 2019 - 9:36 am

Gracias!!

Comments are closed.

Ubuntu 20.04 y NETPLAN. Tutorial rápido de los cambios de NETWORKING

NETPLAN – Capa de abstracción de configuración de red.

Comandos básicos de Networking, novedades

Configuración NETPLAN con direccionamiento estático/manual

Configuración NETPLAN con direccionamiento estático/manual CAMBIANDO el nombre del adaptador de red de ens33 a lan

Configuración NETPLAN por DHCP

Hashes de archivos en Windows y Linux

Instalar Microsoft SQL en un Ubuntu 18.04 con Docker

You may also like

3 comments