VPNs para los grupos clase
Tradicionalmente los alumnos de un grupo estaban en clase junto al docente y todas sus máquinas —físicas o virtuales— se encontraban en una misma LAN. Así comunicarse, interaccionar o colaborar no resultaba demasiado difícil.
En la situación actual algunos alumnos están en clase, otros en su casa y se utilizan MVs lanzadas en el equipo local o en una herramienta como IsardVDI o algún proveedor de la nube. En este caso comunicarse, interaccionar y colaborar resulta todo un reto.
Para paliar esta situación se ha preparado un servicio de VPNs (redes privadas virtuales) para que, independientemente de dónde se encuentren las máquinas de los miembros de un grupo clase se puedan comunicar.
WireGuard al rescate
WireGuard es una herramienta libre y moderna para implementar VPNs. Para tener una idea básica de cómo preparar una VPN entre dos equipos se puede leer: Introducción a Wireguard.
Cuando se configura WireGuard para participar en una VPN en el equipo aparecerá una nueva interfaz de red —si es la primera con el nombre wg0— que conecta con la red virtual.
Para el SO y las aplicaciones del usuario la nueva interfaz de red no tiene nada de particular, a través de ella se puede enviar y recibir tráfico. La gracia está en que todo el tráfico saliente de esta interfaz se cifra y se envía encapsulado en datagramas UDP a través de alguna de las interfaces físicas de la máquina. De la misma manera cuando llega tráfico UDP correspondiente a la VPN, Wireguard extrae los datos de los datagramas UDP, los descifra y recrea los paquetes virtuales que se entregan a wg0 como si se hubieran recibido allí a través de un enlace mágico.
Ejemplo de uso de WireGuard
Para demostrar el funcionamiento de WireGuard podemos ver lo que sucede en un contenedor LXD que está configurado para participar en la VPN que corresponde al grupo clase SMX1A.
El contenedor tiene una interfaz de red wg0:
root@smx1a:~# ip -c a
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: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.0.101.2/24 scope global wg0
valid_lft forever preferred_lft forever
7: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:16:3e:29:2c:e6 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.118.10.117/24 brd 10.118.10.255 scope global dynamic eth0
valid_lft 1806sec preferred_lft 1806sec
inet6 fd42:1ae:4953:be2f:216:3eff:fe29:2ce6/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 3595sec preferred_lft 3595sec
inet6 fe80::216:3eff:fe29:2ce6/64 scope link
valid_lft forever preferred_lft forever
root@smx1a:~#
En este caso el equipo tiene la dirección 10.0.101.2/24 en la interfaz de red wg0. El equipo remoto tiene la dirección 10.0.101.1/24 y se puede comprobar con la herramienta ping el correcto funcionamiento de la VPN.
root@smx1a:~# ping -c 3 10.0.101.1 PING 10.0.101.1 (10.0.101.1) 56(84) bytes of data. 64 bytes from 10.0.101.1: icmp_seq=1 ttl=64 time=45.1 ms 64 bytes from 10.0.101.1: icmp_seq=2 ttl=64 time=45.7 ms 64 bytes from 10.0.101.1: icmp_seq=3 ttl=64 time=45.4 ms --- 10.0.101.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 45.125/45.429/45.716/0.241 ms root@smx1a:~#
Para cada uno de los tres paquetes ICMP echo request que ha transmitido nuestro equipo, WireGuard ha cifrado los paquetes y los ha enviado al equipo remoto encapsulados en datagramas UDP. Las respuestas ICMP echo reply que ha contestado el equipo remoto se han procesado de la misma manera y el extremo local de WireGuard los ha procesado de manera inversa para recrear los paquetes que ha recibido la herramienta ping.
La herramienta wg —que permite gestionar las interfaces de WireGuard— nos puede mostrar información sobre la VPN.
root@smx1a:~# wg show interface: wg0 public key: 8ckAQezKEFzgnglfEY6aV/TFI3m4bf8YNrPI0SNNfzE= private key: (hidden) listening port: 60071 peer: ax1R1KE6JQUBtkkcV0HfD2w4ckgu1uwyWgGF0A6lwn4= endpoint: 145.239.68.121:40001 allowed ips: 10.0.101.0/24 latest handshake: 1 minute, 1 second ago transfer: 21.08 KiB received, 24.61 KiB sent persistent keepalive: every 25 seconds root@smx1a:~#
En la salida del comando wg show se puede apreciar:
- La interfaz
wg0con:- La clave pública. Se utilizará esta clave pública en los equipos remotos con los que deba conectar. Esta es la clave pública que se ha añadido a la configuración del servidor WireGuard para que permita el acceso de este equipo.
- La herramienta
wg showomite la clave privada de la interfaz por seguridad, pero esta clave se utiliza en el fichero de configuración de WireGuard. - El puerto UDP que se utiliza en este lado del enlace. El servidor debe tener una dirección IP y un puerto conocidos por los clientes pero el cliente utilizará cualquier puerto UDP libre.
- Un
peer- Cada interfaz puede admitir enlaces con diferentes pares. Cada uno de ellos identificado por su clave pública, en este caso:
ax1R1KE6JQUBtkkcV0HfD2w4ckgu1uwyWgGF0A6lwn4=. - La directiva
endpointindicando la IP y el puerto UDP físicos en los que atiende el servidor. - La directiva
allowed ipstiene dos funciones:- Limitar como una ACL las direcciones de la VPN que puede utilizar el otro par para conectar.
- Servir como tabla de rutas para indicar qué bloque de direcciones se puede alcanzar a través de este peer.
- Estadísticas sobre la actividad del enlace.
- Finalmente
persistent keepalive: every 25 secondsindica que el cliente enviará un paquete a través de la VPN cada 25 segundos en caso de que el túnel no transmita nada para que los routers y cortafuegos intermedios —que probablemente mantengan tablas NAT— no cierren la conexión.
- Cada interfaz puede admitir enlaces con diferentes pares. Cada uno de ellos identificado por su clave pública, en este caso:
Configuración de un cliente de la VPN
Un cliente que quiera participar en la VPN mantenida por un servidor WireGuard deberá conocer:
- Clave privada propia.
- IP que debe utilizar en la interfaz de la VPN.
- Dirección IP pública del servidor.
- Puerto UDP en el que escucha el servidor.
- Clave pública del servidor.
- Bloque de direcciones que se utilizará en la VPN.
- Si es necesario el valor para
PersistentKeepalive.
Todos estos parámetros los facilitará el profesor para cada una de las máquinas que el alumno deba configurar.
Con estos datos —una vez instalado el paquete wireguard-tools— el alumno generará un fichero de configuración /etc/wireguard/wg0.conf similar a:
[Interface] PrivateKey = AaAa... Address = 10.0.101.2/24 [Peer] Endpoint = wireguard.elpuig.xeill.net:40001 PublicKey = ZzZz... AllowedIPs = 10.0.101.0/24 PersistentKeepalive = 25
Después, para activar la interfaz en cada arranque se deberá ejecutar:
systemctl enable wg-quick@wg0
Y si ahora se quiere activar el servicio:
systemctl start wg-quick@wg0