Home Linux WireGuard Acceso remoto a una LAN

WireGuard Acceso remoto a una LAN

by José Luis Sánchez Borque
wireguard

WireGuard® es una VPN extremadamente simple pero rápida y moderna que utiliza criptografía de última generación. Su objetivo es ser más rápido, más simple, más ágil y más útil que Ipsec. Tiene la intención de tener un rendimiento considerablemente mayor que OpenVPN. WireGuard está diseñado como una VPN de propósito general para ejecutarse en interfaces integradas y supercomputadoras por igual, aptas para muchas circunstancias diferentes. Lanzado inicialmente para el kernel de Linux, ahora es multiplataforma (Windows, macOS, BSD, iOS, Android) y se puede implementar ampliamente. Actualmente se encuentra en un gran desarrollo, pero ya podría considerarse como la solución VPN más segura, más fácil de usar y más simple de la industria.

El cifrado de WireGuard se basa en claves públicas y privadas para que los pares establezcan un túnel cifrado entre ellos. Cada versión de WireGuard utiliza un conjunto de cifrado criptográfico específico para garantizar la simplicidad, la seguridad y la compatibilidad con los pares.

En comparación, otro software VPN como OpenVPN e IPSec utilizan Transport Layer Security (TLS) y certificados para autenticar y establecer túneles cifrados entre sistemas. Las diferentes versiones de TLS incluyen soporte para cientos de suites y algoritmos criptográficos diferentes, y si bien esto permite una gran flexibilidad para admitir diferentes clientes, también hace que la configuración de una VPN que usa TLS sea más lenta, compleja y propensa a errores.

En este tutorial os enseñaré a configurar el típico montaje de acceso remoto a una oficina a través del enrutador de vuestro IPS: Telefóinca, Jazztell, Vodafone, etc… Siempre que tengáis los datos de acceso al router 😊

Para entornos empresariales con decenas o cientos de clientes os aconsejo buscar otras soluciones para la automatización del deploy de vuestra infraestructura. Una buena solución es:

NETMAKER WireGuard® Automation from Homelab to Enterprise

Empezaré como siempre mostrando el esquema del montaje para haceros una idea de lo que estamos haciendo:

Por motivos de seguridad obvios no os he puesto mi IP pública, sino la 80.56.22.77. Es decir, cada uno deberá dicha IP por la que corresponda de su router. Para aquellos que no disponéis de una IP pública estática, os recomiendo Duck DNS, un servidor DNS dinámico gratuito hospedado en AWS.

La configuración la haré en un Windows 10. Hacerlo desde un móvil es prácticamente igual.

Empecemos……

Paso 1 — Instalación de WireGuard y generación de un par de claves

Versión de Ubuntu que estoy utilizando:

$ sudo lsb_release -a

Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal

Os muestro también la configuración IP del servidor:

root@wgserver:/home/demo# ip -4 a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
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
inet 192.168.153.10/24 brd 192.168.153.255 scope global ens33
valid_lft forever preferred_lft forever

El primer paso es instalar WireGuard en el servidor interno, en mi caso el servidor con IP 192.168.153.10/24. La instalación en una distribución Ubuntu es sumamente sencilla:

$ sudo apt update

$ sudo apt install wireguard

Podemos ver la versión que tenemos instalada:

$ sudo apt list wireguard

Listando... Hecho
wireguard/focal-updates,focal-updates,now 1.0.20200513-1~20.04.2 all [instalado]

El siguiente paso es generar un par de claves privada y pública para el servidor. Utilizaremos los comandos integrados wg genkey y wg pubkey para crear las claves y, a continuación, agregar la clave privada al archivo de configuración de WireGuard.

Debido a que creará una clave privada que se utilizará para cifrar el tráfico en el servidor WireGuard, los permisos predeterminados que se aplican a los archivos nuevos deben ser cambiados para evitar “fugas” de seguridad, es decir, un chmod 600 no estaría de más.

Para crear la clave privada para WireGuard utilizamos el siguiente comando:

$ sudo wg genkey | sudo tee /etc/wireguard/private.key
EBZV9pzN2CZNvykfPN1GSlcz8fskaiccY8u6C6A2XVQ=

Se visualiza por pantalla una sola línea de salida codificada en base64, que es la clave privada. Una copia de la salida también se almacena en el archivo /etc/wireguard/private.key para futuras referencias mediante el comando tee. Anotar cuidadosamente la clave privada que se genera, ya que deberá agregarla al archivo de configuración de WireGuard más adelante.

El siguiente paso es crear la clave pública correspondiente, que se deriva de la clave privada. Utilice el siguiente comando para crear el archivo de clave pública:

$ sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key
EKbGsMWye/VJMlXJmiftOuGL4Gx9Bt/IrqzLRHR7vAs=

Este comando consta de tres comandos individuales que se encadenan entre sí mediante el | (tubería) operador:

  • sudo cat /etc/wireguard/private.key: este comando lee el archivo de clave privada y lo envía al flujo de salida estándar.
  • wg pubkey: el segundo comando toma la salida del primer comando como su entrada estándar y la procesa para generar una clave pública.
  • sudo tee /etc/wireguard/public.key: el comando tee toma la salida del comando de generación de clave pública y la redirige al archivo llamado /etc/wireguard/public.key.

Cuando ejecute el comando, volverá a recibir una sola línea de salida codificada en base64, que es la clave pública de su WireGuard Server. Cópielo en algún lugar como referencia, ya que deberá distribuir la clave pública a cualquier par que se conecte al servidor.

Paso 2 — Elección de un rango IPv4

El servidor necesita un rango de direcciones IPv4 privadas para usar para los clientes y para su interfaz de túnel. Se puede elegir cualquier rango de direcciones IP de los siguientes bloques de direcciones reservadas (si desea obtener más información sobre cómo se asignan estos bloques, visite la especificación RFC 1918):

  • 10.0.0.0 a 10.255.255.255 (prefijo 10/8)
  • 172.16.0.0 a 172.31.255.255 (prefijo 172.16/12)
  • 192.168.0.0 a 192.168.255.255 (prefijo 192.168/16)

Para los fines de este tutorial, usaremos 10.8.0.0/24 como un bloque de direcciones IP del primer rango de IP reservadas. Este rango permitirá hasta 255 conexiones de pares diferentes y, por lo general, no debe tener direcciones superpuestas o en conflicto con otros rangos de IP privados. Evidentemente si en nuestra infraestructura ya está utilizado dicho rango bastará con elegir otro diferente.

WireGuard Server utilizará una única dirección IP del rango para su dirección IPv4 de túnel privado. Usaremos 10.8.0.1/24 aquí, pero se puede usar cualquier dirección en el rango de 10.8.0.1 a 10.8.0.254. Esta dirección IPv4 la utilizaremos al crear el fichero de configuración de nuestro servidor VPN.

Paso 3 — Creación de una configuración de WireGuard Server

Antes de crear la configuración de WireGuard Server, necesitaremos la siguiente información:

  1. La clave privada generada anteriormente.
  2. La dirección Ipv4 elegida para el servidor. En nuestro ejemplo 10.8.0.1/24.

Creamos a continuación el archivo de configuración con el editor que más guste a cada uno:

$ sudo nano /etc/wireguard/wg0.conf

Agregaremos las siguientes líneas al archivo, sustituyendo su clave privada en lugar del valor de base64_encoded_private_key_goes_here resaltado y las direcciones IP en la línea Dirección. También puede cambiar la línea ListenPort si desea que WireGuard esté disponible en un puerto diferente:

$ sudo nano /etc/wireguard/wg0.conf

[Interface]

PrivateKey = EBZV9pzN2CZNvykfPN1GSlcz8fskaiccY8u6C6A2XVQ=
Address = 10.8.0.1/24
ListenPort = 51820
SaveConfig = true

La línea SaveConfig garantiza que cuando se apague una interfaz WireGuard, cualquier cambio se guardará en el archivo de configuración.  Con la directiva ListenPort especificamos el puerto UDP que utilizará el servidor. Debe estar libre evidentemente.

Podemos verificar los puertos que están siendo utilizados en nuestro servidor con la orden:

$ ss -lu

Paso 4 — Ajuste de la configuración de red del servidor WireGuard

Si estamos utilizando WireGuard para conectar un par (peer) al servidor WireGuard con el fin de acceder a los servicios en el servidor solamente, entonces no necesitarás los siguientes pasos de esta sección. Si desea enrutar el tráfico de Internet de su WireGuard Peer a través del servidor WireGuard, deberá configurar el reenvío de IP siguiendo esta sección del tutorial.

En nuestro caso si que lo necesitamos, pues los pares no solo tendrán acceso al servidor WireGuard, sino también a los PCs de la red interna 192.168.153.0.24.

Para configurar el reenvío, abra el archivo /etc/sysctl.conf usando nano o su editor preferido:

$ sudo nano /etc/sysctl.conf (descomentar la siguiente línea)

net.ipv4.ip_forward =1

Para que los cambios tengan efecto inmediato podemos ejecutar el comando:

$ sudo sysctl -p

Otra forma es reiniciar el servidor, algo fácil si no se trata de un entorno de producción 😊

Ahora el Servidor WireGuard podrá reenviar el tráfico entrante desde el dispositivo Ethernet VPN virtual a otras máquinas de la red local, 192.168.153.0/24, e incluso hacía Internet.

Sin embargo, antes de que el tráfico se pueda enrutar correctamente a través de su servidor, tenemos que configurar algunas reglas de firewall. Estas reglas garantizarán que el tráfico hacia y desde su Servidor WireGuard y Sus pares fluya correctamente.

Os muestro a continuación como queda el directorio a nivel de archivos y permisos, tal como os comentaba en puntos anteriores. Importante los permisos de los archivos, dado que si alguien tiene la clave privada... la liamos bien liada.


root@wgserver:/ # ls -l /etc/wireguard/
-rw------- 1 root root 45 ene 6 11:51 private.key
-rw------- 1 root root 45 ene 6 11:51 public.key
-rw------- 1 root root 377 ene 6 16:15 wg0.conf

Paso 5 — Configuración del firewall del servidor WireGuard

En esta sección, editaremos la configuración de WireGuard Server para agregar reglas de firewall que garantizarán que el tráfico hacia y desde el servidor y los clientes se enrute correctamente. Al igual que con la sección anterior, omita este paso si solo está utilizando su VPN de WireGuard para una conexión de máquina a máquina para acceder a los recursos que están restringidos a su VPN.

Para permitir el tráfico de WireGuard VPN a través del firewall del servidor, deberá habilitar el enmascaramiento, que es un concepto de iptables que proporciona traducción dinámica de direcciones de red (NAT) sobre la marcha para enrutar correctamente las conexiones del cliente.

Primero busque la interfaz de red pública de su WireGuard Server utilizando el subcomando de ruta ip:

$ ip route list default
default via 192.168.153.2 dev ens33 proto static

La interfaz de salida es la cadena que se encuentra dentro de la salida de este comando que sigue la palabra «dev». Por ejemplo, este resultado muestra la interfaz denominada ens33, que de hecho es la única que tiene el servidor. NO haría ni falta hacer esto, pero nunca se sabe si tenemos más de una tarjeta de red.

Anote el nombre de su dispositivo, ya que lo agregará a las reglas de iptables en el siguiente paso. Para agregar reglas de firewall a su Servidor WireGuard, abra el archivo /etc/wireguard/wg0.conf con nano o su editor preferido nuevamente.

$ sudo nano /etc/wireguard/wg0.conf

[Interface]

PrivateKey = EBZV9pzN2CZNvykfPN1GSlcz8fskaiccY8u6C6A2XVQ=
Address = 10.8.0.1/24
ListenPort = 51820
SaveConfig = true
PostUp = iptables -t nat -I POSTROUTING -o ens33 -j MASQUERADE
PreDown = iptables -t nat -D POSTROUTING -o ens33 -j MASQUERADE

Las líneas PostUp se ejecutarán cuando WireGuard Server inicie el túnel VPN virtual. En el ejemplo:

  • iptables -t nat -I POSTROUTING -o ens33 -j MASQUERADE – Esta regla configura el enmascaramiento y reescribe el tráfico IPv4 que entra en la interfaz VPN wg0 para que parezca que se origina directamente desde la dirección IPv4 pública del servidor WireGuard.

Las reglas de PreDown se ejecutan cuando WireGuard Server detiene el túnel VPN virtual. Estas reglas son la inversa de las reglas PostUp y funcionan para deshacer las reglas de reenvío y enmascaramiento para la interfaz VPN cuando se detiene la VPN.

Importante!!!! Debemos ajustar las reglas del firewall si lo hubiera en el servidor para permitir todo el tráfico que afecta a la configuración, bien sea mediante iptables o ufw.. En nuestro ejemplo no hay firewall alguno.

Paso 6 — Inicio del servidor WireGuard

WireGuard se puede configurar para que se ejecute como un servicio systemd utilizando su script wg-quick incorporado. Si bien puede usar manualmente el comando wg para crear el túnel cada vez que desee usar la VPN, hacerlo es un proceso manual que se vuelve repetitivo y propenso a errores. En su lugar, puede usar systemctl para administrar el túnel con la ayuda del script wg-quick.

El uso de un servicio systemd significa que puede configurar WireGuard para que se inicie en el arranque para que pueda conectarse a su VPN en cualquier momento mientras el servidor se esté ejecutando. Para ello, habilite el servicio wg-quick para el túnel wg0 que ha definido agregándolo a systemctl:

$ sudo systemctl enable wg-quick@wg0.service

Observe que el comando especifica el nombre del dispositivo wg0 del túnel como parte del nombre del servicio. Este nombre se asigna al archivo de configuración /etc/wireguard/wg0.conf. Este enfoque de nomenclatura significa que puede crear tantos túneles VPN separados como desee utilizando su servidor.

Por ejemplo, podría tener un dispositivo de túnel y el nombre de prod y su archivo de configuración sería /etc/wireguard/prod.conf. Cada configuración de túnel puede contener diferentes configuraciones de IPv4, IPv6 y firewall de cliente. De esta manera, puede admitir múltiples conexiones de pares diferentes, cada una con sus propias direcciones IP únicas y reglas de enrutamiento.

Ahora iniciamos el servicio:

$ sudo systemctl start wg-quick@wg0.service

Compruebe que el servicio WireGuard está activo con el siguiente comando. Debería ver activo (en ejecución) en la salida:

demo@wgserver:~$ sudo systemctl status wg-quick@wg0.service

● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0

Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)

Active: active (exited) since Thu 2022-01-06 16:16:22 CET; 39min ago

Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 729 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
Main PID: 729 (code=exited, status=0/SUCCESS)
ene 06 16:16:22 wgserver systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
ene 06 16:16:22 wgserver wg-quick[729]: [#] ip link add wg0 type wireguard
ene 06 16:16:22 wgserver wg-quick[729]: [#] wg setconf wg0 /dev/fd/63
ene 06 16:16:22 wgserver wg-quick[729]: [#] ip -4 address add 10.8.0.1/24 dev wg0
ene 06 16:16:22 wgserver wg-quick[729]: [#] ip link set mtu 1420 up dev wg0
ene 06 16:16:22 wgserver wg-quick[729]: [#] iptables -t nat -I POSTROUTING -o ens33 -j MASQUERADE
ene 06 16:16:22 wgserver systemd[1]: Finished WireGuard via wg-quick(8) for wg0.

Con el servidor configurado y en ejecución, el siguiente paso es configurar su máquina cliente como WireGuard Peer y conectarse al Servidor WireGuard.

Paso 7 — Configuración de un par wireguard: Máquina Windows 10

En primer lugar descargamos el cliente de la página oficial https://www.wireguard.com/install :

Interfaz de usuario gráfica, Aplicación

Descripción generada automáticamente

Una vez instalado (no tiene misterio) tenemos la aplicación instalada en nuestra máquina Windows:

Interfaz de usuario gráfica

Descripción generada automáticamente

Al ejecutarla aparece la siguiente pantalla donde tendremos que añadir un nuevo túnel vacio:

Nos aparece una pantalla donde hay que darle un nombre al túnel, en nuestro caso MYTPCIP, y por defecto nos aparece una clave privada generada con su correspondiente clave pública. Debemos tomar nota de dicha clave, pues la necesitaremos para generar el peer posteriormente en el servidor.

Interfaz de usuario gráfica, Texto, Aplicación, Correo electrónico

Descripción generada automáticamente

Una vez creado, lo podemos volver a editar con pulsando botón derecho sobre MYTCPIP:

Interfaz de usuario gráfica, Aplicación, Word

Descripción generada automáticamente

Solo tendremos que rellenar las directivas adecuadamente:

Interfaz de usuario gráfica, Texto, Aplicación, Correo electrónico

Descripción generada automáticamente

Os lo añado en texto también:

[Interface]

PrivateKey = cMmFKoaYWyvVC3Unj9jU4/SaPr4UIJgFqDAdjVOYG0w=
Address = 10.8.0.10/24

[Peer]

PublicKey = EKbGsMWye/VJMlXJmiftOuGL4Gx9Bt/IrqzLRHR7vAs=
AllowedIPs = 10.8.0.0/24, 192.168.153.0/24
Endpoint = 1.2.3.4:51820

Los parámetros importantes son:

  • Address:, la IP que le damos al extremos del tuner del peer. Es decir, el servidor tiene la 10.8.0.1 y este cliente tendrá la 10.8.0.10.
  • PublicKey: La clave pública del servidor WireGuard que hemos generado al principio.
  • AllowedIPs: Las IP’s que el peer pasará por el túnel. En nuestro caso podrá conectarse con cualquier dispositivo de la red 10.8.0.0/24, es decir, todos los peers que se conecten contra el servidor si los hubiera, y a todos los dispositivos de la red 192.168.153.0/24. Podemos limitar el acceso poniendo solo las IPs de los dispositivos a los que queremos que se conecte. Por ejemplo:

AllowedIPs: 10.8.0.1, 192.168.153.10

  • EndPoint: La IP pública del enrutador. En nuestro caso 1.2.3.4.. Recordad que no es real, he sustituido la mía real por esta IP aleatoria que no tiene sentido alguno. Debéis poner la vuestra.

Interfaz de usuario gráfica, Texto, Aplicación

Descripción generada automáticamente

Paso 8 — Autorizar el Peer creado en el servidor.

Antes de activar el túnel, queda un paso muy importante. Hay que autorizar el Peer en el servidor. Eso es tan fácil como ejecutar la siguiente orden en el servidor WireGuard:

sudo wg set wg0 peer PpY6DgTnh7xelGByLHW+Wp5AtS7TEwvRPAsogBUwv3g= allowed-ips 10.8.0.10

Con esta orden permitimos en el servidor que el Peer, cuya clave pública estamos añadiendo, se conecte. Así mismo con la directiva allowed-ips estamos diciendo que el cliente solo puede utilizar dicha IP, es decir, la que tiene: 10.8.0.10. Si el cliente se la cambia no tendrá acceso. Comprobad bien las claves con la información que os he ido dando para no equivocaros si intentáis reproducir el laboratorio.

Si queremos modificarla bastará con reescribir la orden con los nuevos parámetros.

Si queremos borrar el peer podemos utilizar la siguiente orden:

sudo wg set wg0 peer PpY6DgTnh7xelGByLHW+Wp5AtS7TEwvRPAsogBUwv3g= remove

Paso 9 — NAT en el enrutador

Nos queda un paso crucial para que todo esto funcione. Hay que recordar que la única IP pública que conocen los clientes es la de nuestro enrutador. La podéis obtener visitando la web https://ipinfo.io

De nuevo insistir que he puesto 1.2.3.4 a mano, para evitar mostrar mi IP pública. En mi router Livebox Fibra he añadido una regla que permite “mapear” el puerto UDP 51820, al mismo puerto del servidor interno que tiene la IP 192.168.153.10. Cada router tendrá esta opción donde toque, así que os toca tirar de manual o google.

Interfaz de usuario gráfica

Descripción generada automáticamente

Paso 10 — Pruebas de conexión.

Finalmente ya podemos darle al botón de Activar y la conexión se realizará correctamente. En la barra de notificaciones del Windows 10 aparece que el túnel ha sido establecido correctamente:

Texto

Descripción generada automáticamente

Y vemos también en la pantalla de la aplicación que la conexión es correcta.

Qué podemos verificar? En primer lugar que tenemos el adaptador en nuestro Windows 10 con la IP que hemos especificado: 10.8.0.10 mediante el cmdLet de powershell get-netipconfiguration, o ipconfig en su defecto desde el mítico cmd.

Texto

Descripción generada automáticamente

Ahora nos toca en el lado del peer cliente, hacer las pruebas de conectividad contra las IPs que hayamos permitido evidentemente. En nuestro ejemplo:

  • 10.8.0.1: ip del tuner del WireGuard Server
  • 192.168.153.10: ip local del WireGuard Server
  • 192.168.153.128: ip local de una máquina corriendo un servidor Web en la red local.
  • 10.8.0.2: ip de otro peer que tengo configurado

Vemos que todos se realizan sin problema:

PS C:\> ping 10.8.0.1 -n 1

Haciendo ping a 10.8.0.1 con 32 bytes de datos:

Respuesta desde 10.8.0.1: bytes=32 tiempo=3ms TTL=64
Estadísticas de ping para 10.8.0.1:
Paquetes: enviados = 1, recibidos = 1, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 3ms, Máximo = 3ms, Media = 3ms

PS C:\> ping 192.168.153.10 -n 1

Haciendo ping a 192.168.153.10 con 32 bytes de datos:
Respuesta desde 192.168.153.10: bytes=32 tiempo=1ms TTL=64
Estadísticas de ping para 192.168.153.10:
Paquetes: enviados = 1, recibidos = 1, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 1ms, Máximo = 1ms, Media = 1ms

PS C:\> ping 192.168.153.128 -n 1

Haciendo ping a 192.168.153.128 con 32 bytes de datos:
Respuesta desde 192.168.153.128: bytes=32 tiempo=3ms TTL=63
Estadísticas de ping para 192.168.153.128:
Paquetes: enviados = 1, recibidos = 1, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 3ms, Máximo = 3ms, Media = 3ms

PS C:\> ping 10.8.0.2 -n 1

Haciendo ping a 10.8.0.2 con 32 bytes de datos:
Respuesta desde 10.8.0.2: bytes=32 tiempo=6ms TTL=63
Estadísticas de ping para 10.8.0.2:
Paquetes: enviados = 1, recibidos = 1, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 6ms, Máximo = 6ms, Media = 6ms

En el servidor podemos utilizar la orden wg para ver los peer’s:

root@wgserver:/home/demo# wg

interface: wg0

public key: EKbGsMWye/VJMlXJmiftOuGL4Gx9Bt/IrqzLRHR7vAs=
private key: (hidden)
listening port: 51820

peer: PpY6DgTnh7xelGByLHW+Wp5AtS7TEwvRPAsogBUwv3g=

endpoint: 80.25.63.25:60568
allowed ips: 10.8.0.10/32
latest handshake: 1 minute, 5 seconds ago
transfer: 62.49 KiB received, 14.35 KiB sent

peer: wVyWeNSpgLqJKruBJQ1tFn16coLlfw//CpKJy5kCOUw=

endpoint: 80.25.63.25:37773
allowed ips: 10.8.0.2/32
latest handshake: 3 minutes ago
transfer: 181.41 KiB received, 172.20 KiB sent

La IP 80.25.63.25 es la IP pública de otra red desde donde me estoy conectado a mi casa.

Podemos ver también un tracer desde cmd y con powershell, donde se ve claramente los saltos que da el paquete icmp antes de llegar a destino:

PS C:\> tracert -d 192.168.153.128

Traza a 192.168.153.128 sobre caminos de 30 saltos como máximo. 1 1 ms 1 ms 1 ms 10.8.0.1 2 3 ms 3 ms 3 ms 192.168.153.128 Traza completa.
PS C:\> Test-NetConnection 192.168.153.128 -TraceRoute

ComputerName : 192.168.153.128
RemoteAddress : 192.168.153.128
InterfaceAlias : MYTCPIP
SourceAddress : 10.8.0.10
PingSucceeded : True
PingReplyDetails (RTT) : 1 ms
TraceRoute : 10.8.0.1
             192.168.153.128

Así mismo recordar ya para terminar que en todo momento podemos desconectar el interface wg0 en el servidor mediante el comando:

root@wgserver:/# wg-quick down wg0

[#] iptables -t nat -D POSTROUTING -o ens33 -j MASQUERADE

[#] wg showconf wg0

[#] ip link delete dev wg0

root@wgserver:/# wg

Tal como os indiqué al inicio, hacer la configuración desde un móvil es prácticamente igual. Basta con descargar el cliente para Android o Iphone y seguir los mismos pasos.

Interfaz de usuario gráfica, Aplicación

Descripción generada automáticamente Interfaz de usuario gráfica, Texto, Aplicación

Descripción generada automáticamente

Espero os haya gustado. NO dudéis en preguntarme cualquier duda o consulta al respecto. Intentaré en breve hacer otro tutorial con WireGuard con una configuracion Site to Site.

You may also like

6 comments

Antonio agosto 13, 2022 - 9:14 am

hola como estas?? excelente la informacion
pero tengo una pequeña duda, hay alguna forma de crear la red que sea de tipo «multicast», en internet encontre este comando
ip link set wg0 multilcast on
el problema es que eso no sirve con windows como cliente

Reply
José Luis Sánchez Borque agosto 26, 2022 - 10:42 am

Hola Antonio,

perdona retraso, pero estoy offline (de vacaciones vamos… ). Mira este enlace para ver si te sirve y me dices algo:

https://an0n-r0.medium.com/making-dlna-through-site-to-site-vpn-work-f393629f4ce0

Slds

Reply
Rodrigo julio 18, 2022 - 3:00 pm

Hola , muy buena info , la tengo implementada hace un año , pero no logro poder acceder desde la red donde se encuentra el servidor WG , hacia el Peer. O sea , de manera inversa, ya que desde los Peers entro bien a los servicios que tengo en casa central.
Escenario
RED A – WG – Servidores SQL – WEB
RED B peer
RED C peer
desde B y C , acceso a A ,
desde A no puedo acceder a B y C

Gracias por lo que puedan aportar.

saludos

Reply
José Luis Sánchez Borque julio 20, 2022 - 5:49 pm

Hola Rodrigo,

Tengo poca información como para responderte con calidad, pero por lo que comentas podría ser las redes que permites que tanto el servidor como los peers vean. Es decir, el parámetro AllowedIPs

Mira que en todos los sitios estén autorizadas todas las redes.

Ya me dices.

Saludos.

Reply
Eva enero 10, 2022 - 3:42 pm

Muchas gracias por el aporte. He descubierto estas Navidades tu canal y blog y la verdad es que he aprendido mucho de PowerShell y Active Directory.

Reply
José Luis Sánchez Borque enero 10, 2022 - 8:46 pm

Gracias Eva. Espero seguir cumpliendo las expectativas.

Saludos.

Reply

Responder a Rodrigo Cancel Reply