Configuración de WireGuard en Windows
Esta guía explica cómo configurar un túnel VPN WireGuard entre dos equipos Windows: un servidor WireGuard que se ejecuta en un host Windows remoto, por ejemplo un VPS con Windows, y un cliente WireGuard que se ejecuta en su equipo Windows local. Una vez activo el túnel, ambos equipos intercambian datos a través de una conexión privada cifrada y, opcionalmente, puede enrutar todo el tráfico del cliente a través del servidor.
La configuración básica crea un túnel entre el servidor y el cliente. Para enrutar todo el tráfico de Internet del cliente a través del servidor también se necesita NAT en el servidor; consulte «Configuración de NAT en el servidor para el túnel completo».
Para simplificar la generación de claves, esta guía crea tanto la configuración del servidor como la del cliente dentro de una misma aplicación WireGuard y, después, despliega cada archivo de configuración en el equipo al que corresponde. La configuración del servidor se ejecuta en el servidor y la del cliente, en el cliente. El servidor y el cliente son siempre equipos distintos. Se utiliza el mismo proceso para añadir cualquier número de clientes adicionales.
Antes de empezar, instale la última versión de WireGuard desde la página de instalación de WireGuard tanto en el servidor como en el cliente y asegúrese de tener derechos de administrador en cada equipo.
La configuración de esta guía tiene el siguiente aspecto:
Servidor (IP pública, escuchando en UDP 51820) Dirección del túnel 10.0.0.1/24 | | túnel WireGuard cifrado | Cliente Dirección del túnel 10.0.0.2/32
Creación de la configuración del servidor
Ejecute C:\Program Files\WireGuard\wireguard.exe, haga clic en Add tunnel y elija Add empty tunnel. WireGuard genera automáticamente un par de claves. La clave pública que aparece en la parte superior de la ventana es la clave pública del servidor. La necesitará más adelante al configurar el cliente.
Asigne un nombre al túnel y rellene la sección Interface con la clave privada del servidor, el puerto en el que escuchará WireGuard y la dirección interna que usará el servidor dentro del túnel.
[Interface] PrivateKey = # clave privada del servidor WireGuard ListenPort = # puerto en el que escuchará WireGuard Address = # dirección IP interna del servidor WireGuard, por ejemplo 10.0.0.1/24
Utilice una subred privada para la red del túnel y mantenga el servidor y todos los clientes en el mismo rango. Una elección habitual es 10.0.0.1/24 para el servidor y 10.0.0.2/32, 10.0.0.3/32, etc., para cada cliente. El servidor usa el prefijo /24 para tratar todo el rango del túnel como accesible a través de la interfaz WireGuard. Cada cliente usa /32, porque un cliente representa una única dirección y no una subred. Un cliente configurado con /24 asumiría que todo el rango está en su propia interfaz y no enviaría por el túnel el tráfico destinado a otras direcciones del túnel.
La configuración del servidor no muestra la casilla Block untunneled traffic (kill-switch). Esta opción solo aparece en una configuración de cliente que enruta todo el tráfico a través del túnel; consulte «Creación de la configuración del cliente».
Para añadir una capa extra de seguridad, puede agregar una clave precompartida a cada peer. Genérela una sola vez y añada la misma línea a la sección [Peer] correspondiente, tanto en el servidor como en el cliente:
PresharedKey = # clave precompartida, idéntica en el servidor y en el cliente
Puede generar la clave con la herramienta wg que se incluye con WireGuard:
"C:\Program Files\WireGuard\wg.exe" genpsk
Creación de la configuración del cliente
Haga clic en Add tunnel y elija Add empty tunnel por segunda vez, ahora para el cliente. La clave pública que se muestra para este túnel es la clave pública del cliente, que el servidor necesita para aceptar al cliente.
Rellene la configuración del cliente:
[Interface] PrivateKey = # clave privada del cliente WireGuard Address = # dirección IP interna del cliente WireGuard, por ejemplo 10.0.0.2/32 DNS = 1.1.1.1, 1.0.0.1 [Peer] PublicKey = # clave pública del servidor WireGuard AllowedIPs = # 0.0.0.0/0 para túnel completo o 10.0.0.0/24 para túnel dividido Endpoint = # dirección IP pública y puerto del servidor WireGuard PersistentKeepalive = 25
El valor de Endpoint debe ser la dirección IP pública real del servidor junto con el puerto definido en ListenPort del servidor, no la dirección interna del túnel. Para elegir el valor de AllowedIPs, consulte la sección «Comprender AllowedIPs» más abajo.
Las líneas DNS y PersistentKeepalive son opcionales. DNS define los servidores DNS que se usan mientras el túnel está activo, lo que ayuda a evitar problemas de resolución de nombres tras la conexión. Puede usar resolutores públicos como 1.1.1.1, 1.0.0.1 o 8.8.8.8, 8.8.4.4, o el propio servidor DNS de la red VPN. PersistentKeepalive = 25 envía un paquete pequeño cada 25 segundos y ayuda a mantener abierta la conexión cuando el cliente está detrás de NAT.
Cuando la configuración del cliente tiene un único [Peer] y su AllowedIPs contiene 0.0.0.0/0 (o ::/0), el editor de túneles muestra la casilla Block untunneled traffic (kill-switch) debajo del campo de configuración. Con un túnel dividido, por ejemplo AllowedIPs = 10.0.0.0/24, la casilla no aparece.
El kill-switch está habilitado de forma predeterminada en cuanto introduce 0.0.0.0/0. Mientras el túnel está activo, las reglas del firewall solo permiten el tráfico que pasa por el túnel, el tráfico de loopback, DHCP y el descubrimiento de vecinos IPv6. Todo lo demás se bloquea, incluidos los dispositivos de su red local, como impresoras y NAS. Si se define la línea DNS, las consultas DNS solo se permiten hacia los servidores indicados allí.
Desmarcar la casilla no equivale simplemente a desactivar un ajuste. El editor reescribe AllowedIPs: 0.0.0.0/0 pasa a ser 0.0.0.0/1, 128.0.0.0/1 y ::/0 pasa a ser ::/1, 8000::/1. Todo el tráfico de Internet sigue pasando por el túnel, pero no se crean las reglas de firewall de bloqueo. Al volver a marcar la casilla se restaura 0.0.0.0/0.
Copie las claves y el Endpoint con mucho cuidado. Una clave mal escrita o un Endpoint incorrecto es la causa más frecuente de que un túnel no se conecte.
Adición del cliente al servidor
Abra de nuevo la configuración del servidor y añada una sección [Peer] para el cliente, utilizando la clave pública del cliente obtenida en el paso anterior.
[Peer] PublicKey = # clave pública del cliente WireGuard AllowedIPs = # dirección IP interna del cliente
En la configuración del servidor, AllowedIPs tiene dos funciones. Indica al servidor qué dirección del túnel pertenece a este cliente y actúa como lista de enrutamiento: cualquier paquete dirigido a esos rangos se cifra y se envía a este peer. Para un único cliente, es su dirección del túnel, por ejemplo 10.0.0.2/32. Si el cliente también debe hacer accesible una red local a través del túnel, añada esa subred aquí también, por ejemplo 10.0.0.2/32, 192.168.1.0/24. Repita este paso para cada cliente adicional.
Configuración del Firewall de Windows en el servidor
El servidor debe aceptar el tráfico WireGuard entrante en su puerto UDP. Abra Firewall de Windows Defender con seguridad avanzada, seleccione Reglas de entrada y haga clic en Nueva regla. Elija Puerto y haga clic en Siguiente. Seleccione UDP, introduzca el puerto de WireGuard, por ejemplo 51820, y haga clic en Siguiente. Si utiliza más de un puerto, sepárelos con comas, por ejemplo 51820, 51821. Seleccione Permitir la conexión y haga clic en Siguiente. Seleccione los perfiles a los que se aplica la regla. Si el servidor está alojado en un centro de datos, normalmente basta con el perfil Público; en caso contrario, deje seleccionados los perfiles Dominio, Privado y Público. Haga clic en Siguiente, asigne a la regla un nombre claro como WireGuard UDP 51820 y haga clic en Finalizar.
Esta regla de entrada solo es necesaria en el servidor, porque es el lado que recibe las conexiones entrantes. En un VPS, asegúrese además de que su proveedor de alojamiento permita el tráfico UDP entrante en este puerto a nivel de red, y no solo en el Firewall de Windows.
Exportación e implementación de las configuraciones
Cuando ambas configuraciones estén listas, haga clic en Export all tunnels to zip, elija una ubicación y guarde.
Abra el archivo comprimido para encontrar los archivos de configuración de todos los túneles. Coloque la configuración del servidor en el servidor y entregue a cada cliente su propio archivo de configuración. Si el equipo contiene muchos túneles, también puede exportar un único túnel desde su menú contextual. Exportar a un archivo zip es cómodo cuando ambos túneles se crearon en el mismo equipo, como en esta guía. Si crea cada configuración directamente en su propio host, no es necesario exportar y puede copiar el archivo de configuración manualmente.
En el servidor, seleccione la configuración del servidor y haga clic en Activate.
En el cliente, haga clic en Add Tunnel, seleccione el archivo de configuración del cliente y ábralo.
A continuación, haga clic en Activate.
El primer cliente ya está configurado. Añada más clientes de la misma forma: cree un nuevo túnel vacío para cada cliente y agregue a la configuración del servidor una sección [Peer] correspondiente con la clave pública y la dirección del túnel de ese cliente, tal como se describe en «Adición del cliente al servidor».
Si configura WireGuard en un servidor remoto a través de una sesión RDP, lea la sección «Comprender AllowedIPs» antes de activar un túnel que enrute todo el tráfico. Una configuración con AllowedIPs = 0.0.0.0/0 puede redirigir el propio tráfico del servidor al túnel y cortar su conexión RDP.
Verificación de la conexión
Tras activar el túnel, Windows puede mostrar el adaptador WireGuard como «Sin acceso a la red» o «Sin acceso a Internet» en el Centro de redes y recursos compartidos. Es un comportamiento esperado, porque Windows no trata los adaptadores de túnel VPN como conexiones estándar a Internet, y no afecta al túnel. Windows determina este estado mediante su comprobación de conectividad, que sondea direcciones URL concretas de Microsoft, por lo que la advertencia también puede aparecer si esos sondeos están bloqueados o su DNS no los resuelve, aunque el túnel funcione.
Para confirmar que el túnel funciona, compruebe su estado en el cliente WireGuard. Un túnel activo muestra el estado Active junto con contadores de transferencia de datos. Si los contadores aumentan, el túnel está pasando tráfico.
En el servidor también puede confirmar que WireGuard está escuchando en su puerto UDP mientras el túnel está activo:
netstat -ano | findstr 51820
En PowerShell, el equivalente es:
Get-NetUDPEndpoint -LocalPort 51820
Sustituya 51820 por su puerto de WireGuard. Si no se devuelve nada, el túnel no está activo o el puerto es distinto del definido en la configuración del servidor.
A continuación, abra el Símbolo del sistema y haga ping a la dirección interna del túnel del servidor:
ping 10.0.0.1
Sustituya 10.0.0.1 por la IP interna real que definió para el servidor. Si el servidor responde, el tráfico pasa por el túnel. Si no hay respuesta, compruebe primero el handshake: el Firewall de Windows en Windows Server bloquea el ping entrante de forma predeterminada, por lo que la ausencia de respuesta no siempre significa que el túnel esté caído.
Si el cliente usa AllowedIPs = 0.0.0.0/0, también puede confirmar que el tráfico se enruta a través del túnel:
tracert 8.8.8.8
El primer salto debe ser la dirección IP interna del servidor WireGuard.
Comprobación del handshake de WireGuard
El handshake es el indicador más útil para diagnosticar una conexión WireGuard. En la aplicación WireGuard, abra el túnel y observe el campo Latest handshake. En un túnel que funciona, el handshake aparece a los pocos segundos de la activación y luego se actualiza periódicamente mientras se transfieren datos. Si el túnel está inactivo, puede pasar algún tiempo entre handshakes, por lo que un breve intervalo es normal. Si el campo permanece vacío, los peers no pueden alcanzarse, lo que suele apuntar a un Endpoint incorrecto, un puerto UDP cerrado o claves que no coinciden.
También puede comprobar el handshake desde la línea de comandos con la herramienta wg incluida con WireGuard:
wg show
La salida muestra cada peer junto con la hora de su último handshake y sus contadores de transferencia.
Comprender AllowedIPs
El valor de AllowedIPs en la configuración del cliente determina qué tráfico se envía por el túnel. En resumen, en el cliente AllowedIPs define qué paquetes se envían al túnel, mientras que en el servidor define qué paquetes se aceptan de un cliente determinado y hacia dónde se enrutan.
Un valor de 0.0.0.0/0 enruta todo el tráfico por el túnel, incluida la navegación normal por Internet. Úselo cuando desee protección total del tráfico. Para que este tráfico llegue a Internet, el servidor debe traducirlo. Consulte «Configuración de NAT en el servidor para el túnel completo» más abajo.
Un valor como 10.0.0.0/24 enruta por el túnel solo el tráfico de la red interna, mientras que el tráfico normal de Internet sigue usando la conexión habitual. Úselo cuando solo necesite acceder a recursos concretos de la red remota.
Puede indicar varias subredes separadas por comas, por ejemplo 10.0.0.0/24, 192.168.1.0/24.
La opción Block untunneled traffic (kill-switch) del editor de túneles surte pleno efecto con AllowedIPs = 0.0.0.0/0. Bloquea todo lo que viajaría fuera del túnel, lo que también bloquea la red local. Si necesita acceso a impresoras u otros dispositivos de la LAN, deje el kill-switch desactivado.
Definir AllowedIPs = 0.0.0.0/0 envía todas las conexiones por el túnel. Si lo aplica en un servidor remoto que administra por RDP, la sesión RDP puede cortarse en cuanto el túnel se active, porque el tráfico del servidor se redirige. En un servidor al que se accede por RDP, enrute solo las subredes que necesite y pruebe con un valor de AllowedIPs restringido antes de cambiar a 0.0.0.0/0.
Acceso a la red local mientras el túnel está activo
Con un túnel dividido, por ejemplo AllowedIPs = 10.0.0.0/24, la red local sigue funcionando con normalidad y no es necesario cambiar nada. Los pasos siguientes se aplican a un túnel completo.
La opción más sencilla es desmarcar la casilla Block untunneled traffic (kill-switch) en el editor de túneles del cliente. El editor sustituye 0.0.0.0/0 por 0.0.0.0/1, 128.0.0.0/1. Su subred local, por ejemplo 192.168.1.0/24, tiene una ruta más específica a través del adaptador físico, de modo que Windows envía el tráfico de la LAN directamente a la red local, mientras que el tráfico de Internet sigue pasando por el túnel. La contrapartida es que nada bloquea el tráfico si el túnel se cae.
Si desea asegurarse de que el tráfico de la LAN nunca entre en el túnel, excluya explícitamente el rango local de AllowedIPs. Por ejemplo, el siguiente valor cubre todas las direcciones IPv4 excepto 192.168.0.0/16:
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3
Si su red local usa un rango distinto, como 10.x.x.x o 172.16.x.x, calcule la lista para ese rango con una calculadora de AllowedIPs y asegúrese de que la subred del túnel siga incluida. Como este valor no contiene una ruta /0, el kill-switch no está disponible con él.
Info Evite usar la misma subred para el túnel y para la red local. Si su red doméstica es 10.0.0.0/24, elija otro rango para el túnel, por ejemplo 10.8.0.0/24.
Para acceder a una red situada detrás del servidor, por ejemplo una LAN de oficina 192.168.10.0/24, el servidor no necesita ninguna entrada adicional, ya que ya dispone de una ruta a su propia LAN. En el cliente, añádala a AllowedIPs en la sección [Peer], por ejemplo AllowedIPs = 10.0.0.0/24, 192.168.10.0/24. El servidor también debe reenviar y traducir este tráfico; consulte «Configuración de NAT en el servidor para el túnel completo». Los dispositivos de esa LAN responden a la dirección LAN del servidor, por lo que el NAT en el servidor es la forma más sencilla de lograr que las respuestas vuelvan por el túnel.
Configuración de NAT en el servidor para el túnel completo
Si los clientes usan AllowedIPs = 0.0.0.0/0 y desea que su tráfico llegue realmente a Internet a través del servidor, este debe traducir las direcciones internas de WireGuard a su propia dirección externa. En Windows esto se hace con el comando New-NetNat, y no con los scripts PostUp y PostDown que se usan en Linux.
Abra PowerShell como administrador en el servidor y ejecute lo siguiente, usando la subred del túnel que asignó al servidor:
New-NetNat -Name WireGuardNAT -InternalIPInterfaceAddressPrefix 10.0.0.0/24
Sustituya 10.0.0.0/24 por la subred de su túnel y asegúrese de que el prefijo cubra todas las direcciones de cliente que asigne. Un cliente fuera de este rango, por ejemplo 10.0.1.2, no coincidiría con esta regla. Puede revisar las reglas activas en cualquier momento:
Get-NetNat
Para eliminar la regla NAT más adelante, ejecute:
Remove-NetNat -Name WireGuardNAT
Si los clientes se conectan y el handshake se completa, pero su tráfico de Internet sigue sin pasar por el servidor, habilite el reenvío de IP en las interfaces implicadas en el enrutamiento y vuelva a probar. La forma exacta depende de la versión de Windows, por ejemplo:
Set-NetIPInterface -InterfaceAlias "Ethernet" -Forwarding Enabled
Aplíquelo a la interfaz externa que transporta el tráfico de Internet y a la interfaz de WireGuard, usando sus nombres reales obtenidos con Get-NetIPInterface.
New-NetNat requiere Windows 10, Windows 11 o Windows Server 2016 y posteriores, y en algunos sistemas necesita que la característica Hyper-V esté habilitada aunque no use Hyper-V para nada más. En algunos planes de VPS no se puede habilitar Hyper-V, lo que impide usar este método. Que New-NetNat sea suficiente por sí solo o que también deba habilitarse el reenvío de IP puede depender de la versión de Windows, así que compruébelo en su servidor cuando el túnel completo no funcione.
Solución de problemas
El túnel está activo, pero no hay conexión con el servidor. Compruebe que el puerto UDP de WireGuard, por ejemplo 51820, esté abierto en el firewall del servidor. Confirme que las claves públicas se han copiado correctamente entre las configuraciones del servidor y del cliente. Asegúrese de que el Endpoint de la configuración del cliente apunte a la dirección IP pública real del servidor, no a la dirección interna del túnel.
El DNS no funciona tras conectarse. Añada un servidor DNS a la sección Interface del cliente:
[Interface] PrivateKey = ... Address = ... DNS = 1.1.1.1, 1.0.0.1
Los contadores de paquetes no aumentan. El túnel no está transmitiendo datos. Compruebe que AllowedIPs esté correctamente definido en ambos lados, que las direcciones internas de WireGuard no entren en conflicto con la red local existente y que el ListenPort no esté ya en uso por otra aplicación.
La casilla del kill-switch no se puede desmarcar. El editor solo reescribe AllowedIPs cuando puede leer toda la configuración. Compruebe que la sección [Peer] contenga una clave pública válida copiada del servidor y que cada ajuste esté en su propia línea, e inténtelo de nuevo.
Necesita más detalles para diagnosticar un problema. Abra el túnel en la aplicación WireGuard y consulte la pestaña Log, que registra handshakes, errores y eventos de conexión a medida que ocurren. Desde allí puede exportar el registro si necesita compartirlo.
Inicio automático de WireGuard tras reiniciar el servidor
Para que el túnel siga funcionando tras los reinicios, instálelo como servicio de Windows. Cuando un túnel se instala como servicio, se inicia automáticamente tras un reinicio. Abra el Símbolo del sistema o PowerShell como administrador y ejecute lo siguiente, usando la ruta del archivo de configuración de su servidor:
wireguard /installtunnelservice "C:\Program Files\WireGuard\wg_server.conf"
Ejecute este comando solo una vez, no en cada inicio. Activar el túnel desde la aplicación WireGuard normalmente instala el mismo servicio, por lo que en muchos casos basta con activarlo una vez. Para eliminar el servicio más adelante, use el nombre del túnel, que es el nombre del archivo de configuración sin la extensión .conf.
wireguard /uninstalltunnelservice wg_server
Para reiniciar el servicio, por ejemplo tras editar la configuración, ejecute el comando de desinstalación y, a continuación, el de instalación de nuevo.
Como el túnel se ejecuta como servicio, no es necesaria una tarea independiente en el Programador de tareas.
Reinicie el servidor y compruebe que el túnel se inicia por sí solo.
