wireguard-docs

el
La documentación faltante de WireGuard: configuración, uso, configuración y un ejemplo completo de VPN de servidor a servidor con clientes móviles y pares públicos. 

La documentación de Wireguard que falta


Guía de referencia de la API para Wireguard, que incluye configuración, configuración y uso, con ejemplos.
Todo el crédito es para el proyecto WireGuard, zx2c4 , Edge Security y los colaboradores de código abierto para el software original. 
Este es mi único intento no oficial de proporcionar documentación, referencias API y ejemplos más completos.
Fuente de estos documentos, código de ejemplo y rastreador de problemas: https://github.com/pirate/wireguard-docs     Versión de la página HTML más sencilla: https://docs.sweeting.me/s/wireguard
WireGuard es una solución VPN de código abierto BETA / WIP escrita en C por Jason Donenfeld y otros , con el objetivo de solucionar muchos de los problemas que han plagado otras ofertas modernas de VPN de servidor a servidor como IPSec / IKEv2, OpenVPN o L2TP. Comparte algunas similitudes con otras ofertas modernas de VPN como Tinc y MeshBird , a saber, buenas suites de cifrado y configuración mínima.
Este es mi intento de escribir "The Missing Wireguard Documentation" para compensar los documentos oficiales un tanto escasos en una gran pieza de software.
Enlaces Oficiales
Metas de WireGuard
  • Seguridad fuerte y moderna por defecto.
  • configuración mínima y gestión de claves
  • Rápido, tanto de baja latencia como de alto ancho de banda
  • Internos simples y pequeña superficie de protocolo.
  • CLI simple y perfecta integración con la red del sistema

También es rápido como el infierno . Rutinariamente obtengo pings de menos de 0,5 ms y 900 Mbps en buenas conexiones. 
(Ver https://www.ckn.io/blog/2017/11/14/wireguard-vpn-typical-setup/ )

Tabla de contenido

Consulte https://github.com/pirate/wireguard-docs para obtener un código de ejemplo y una fuente de documentación.

Introducción

En los últimos 8 años, he probado una amplia gama de soluciones VPN. Algo por necesidad, ya que la ciudad en la que vivía estaba detrás de la Gran Muralla China. Todo, desde PPTP de la vieja escuela hasta configuraciones de proxy GoAgent AppEngine de todo el mundo, fueron comunes a principios de 2010 para romper el GFW, en estos días es principalmente OpenVPN, StealthVPN, IPSec / IKEv2 y otros. A partir de la recomendación de algunas personas de la comunidad de RC Zulip, decidí probar WireGuard y me sorprendió descubrir que estaba marcado en casi todas las casillas.

Mis requisitos personales para una solución VPN

  • Configuración mínima, área de superficie de configuración baja y pocos productos configurables expuestos.
  • la sobrecarga de administración de claves mínima, 1 o 2 claves o certificados previamente compartidos está bien, pero idealmente no ambos
  • capacidad de crear fácilmente una LAN como 10.0.0.0/24 entre todos mis servidores, cada par puede conectarse a cada par,
  • capacidad de atravesar los NAT con un servidor de señalización, enrutamiento de nat a nat en lugar de a través de un relé (estilo WebRTC)
  • retroceso al servidor de retransmisión cuando la eliminación de nat-to-nat no está disponible o no es confiable
  • capacidad para enrutar a una lista fija de ips / hosts con 1 par de llaves por host (no es necesario, pero es bueno tener: capacidad para enrutar tráfico local arbitrario o todo el tráfico de Internet a un host determinado)
  • Las robustas reconexiones automáticas después de los reinicios, el tiempo de inactividad de la red y la tabla de conexión NAT caen
  • rápido (la latencia más baja posible y el ancho de banda de velocidad de línea)
  • cifrado y seguro de forma predeterminada (no es necesario, es bueno tener: pares de claves de copia-pasables cortos)
  • idealmente, soporte para cualquier tipo de nivel 2 y control de tráfico, por ejemplo, ARP / DHCP / ICMP (o idealmente, tramas de Ethernet sin procesar), no solo TCP / HTTP
  • capacidad para unirse a la VPN de Ubuntu, FreeBSD, iOS, macOS (Windows / Android no es necesario pero estaría bien)
  • no es un requisito, pero lo ideal sería que fuera compatible con la ejecución de la ventana acoplable con un solo contenedor, archivo de configuración y clave previamente compartida en cada servidor, pero con una interfaz de red completa expuesta al sistema host (tal vez con tun / tap en el host que pasa el tráfico a el contenedor, pero idealmente solo un contenedor único + archivo de configuración sin dependencias externas)

Lista de posibles soluciones VPN

  • PPTP: antiguo, inflexible, inseguro, no resuelve todos los requisitos
  • L2TP: meh
  • SOCKS: túnel de proxy, no una VPN, no es ideal para este caso de uso
  • IPSec (IKEv2) / strongSwan: muchas configuraciones frágiles que son diferentes para cada sistema operativo, la configuración de NAT es muy manual e implica la actualización del servidor central y el inicio de todos los demás en el orden correcto, no es bueno para reconectarse después del tiempo de inactividad de la red, tenía que ser reiniciado manualmente a menudo
  • TINC : no lo he probado todavía, pero no funciona en iOS, en el peor de los casos, podría vivir con eso si es la única opción
  • OpenVPN : no me gusta de experiencias pasadas, pero podría convencerme si es la única opción
  • StealthVPN: no lo he probado
  • MeshBird : VPN / capa de red "nativa de la nube"
  • Algo : no lo he probado todavía, ¿debería?
  • Striesand : no lo he probado todavía, ¿cuál es la mejor configuración para probar?
  • SoftEther : no lo he probado todavía, ¿debería?
  • WireGuard : el tema de este post
  • ZeroTier : no lo he probado todavía, ¿debería?

Documentación de Wireguard

Glosario

Cuerdas de ejemplo

Estos son nombres de host de demostración, nombres de dominio, direcciones IP e intervalos utilizados en la documentación y las configuraciones de ejemplo.
  • Ejemplo de dominio: example-vpn.devse puede reemplazar con cualquier dominio de acceso público que controle
  • Ejemplo nombres de host: public-server1, public-server2, home-server, laptop, phonese puede cambiar a sus nombres de host del dispositivo
  • Direcciones IP y rangos: 10.0.0.1/24, 10.0.0.3, 10.0.0.3/32puede ser reemplazado con sus subredes y direcciones preferentes (por ejemplo 192.168.5.1/24)
Dondequiera que vea estas cadenas a continuación, solo se utilizan como valores de marcador de posición para ilustrar un ejemplo y no tienen un significado especial. Reemplácelos con sus valores preferidos cuando realice su propia configuración.

Par / Nodo / Dispositivo

Un host que se conecta a la VPN y tiene una dirección de subred VPN como 10.0.0.3 para sí mismo. Opcionalmente, también puede enrutar el tráfico para más de su propia (s) dirección (es) especificando rangos de subred en notación CIDR separada por comas.

Servidor de rebote

Un par / nodo accesible públicamente que sirve como respaldo para retransmitir el tráfico para otros pares VPN detrás de los NAT. Un servidor de rebote no es un tipo especial de servidor, es un par normal al igual que todos los demás, la única diferencia es que tiene una IP pública y tiene el reenvío de IP de nivel de kernel activado, lo que le permite rebotar el tráfico a través de la VPN a otros clientes.

Subred

Un grupo de direcciones IP separadas de la Internet pública, por ejemplo, 10.0.0.1-255 o 192.168.1.1/24. Por lo general, detrás de un NAT proporcionado por un enrutador, por ejemplo, en una LAN de Internet de la oficina o en una red WiFi doméstica.

Notación CIDR

Una forma de definir una subred y su tamaño con una "máscara", una máscara más pequeña = más bits de dirección utilizables por la subred y más IP en el rango. Los más comunes:
  • 10.0.0.1/32(una sola dirección IP, 10.0.0.1) netmask =255.255.255.255
  • 10.0.0.1/24(255 ips de 10.0.0.1- 255) netmask = 255.255.255.0
  • 10.0.0.1/16(65,536 ips de 10.0.0.0- 10.0.255.255) netmask =255.255.0.0
  • 10.0.0.1/8(16,777,216 ips desde 10.0.0.0- 10.255.255.255) máscara de red =255.0.0.0
  • 0.0.0.1/0(4,294,967,296 ips de 0.0.0.0- 255.255.255.255) máscara de red =0.0.0.0
  • La notación CIDR de IPv6 también es compatible, por ejemplo, fd42:42:42::1/64
Para las personas que recién comienzan, 10.0.0.1/32puede parecer una forma extraña y confusa de referirse a una única IP. Sin embargo, este diseño es agradable porque permite a los compañeros exponer varias IP si es necesario sin necesidad de múltiples notaciones. Solo debes saber que en cualquier lugar que veas algo como 10.0.0.3/32, realmente solo significa 10.0.0.3.

NAT

Una subred con direcciones IP privadas proporcionadas por un enrutador que se encuentra frente a ellas haciendo la traducción de direcciones de red, los nodos individuales no son accesibles públicamente desde Internet, en cambio, el enrutador realiza un seguimiento de las conexiones salientes y envía las respuestas a la IP interna correcta (por ejemplo, redes de oficina estándar). , redes wifi domésticas, redes wifi públicas gratuitas, etc)

Punto final público

La dirección de acceso público: puerto para un nodo, por ejemplo, 123.124.125.126:1234o some.domain.tld:1234(debe ser accesible a través de Internet, por lo general no puede ser una IP privada 10.0.0.1o, a 192.168.1.1menos que sea accesible directamente a través de otros pares en la misma subred).

Llave privada

Una clave privada de wireguard para un solo nodo, generada con: wg genkey > example.key (nunca deja el nodo en el que se genera)

Llave pública

Una clave pública de wireguard para un solo nodo, generada con: wg pubkey < example.key > example.key.pub(compartida con otros pares)

DNS

El Servidor de nombres de dominio, que se usa para resolver nombres de host a IP para clientes VPN, en lugar de permitir que las solicitudes de DNS se filtren fuera de la VPN y revelen el tráfico. Las fugas son verificables con http://dnsleak.com .

Cómo funciona WireGuard

Cómo funcionan los servidores de retransmisión públicos

Los relés públicos son solo pares VPN normales que pueden actuar como un servidor de relé intermedio entre cualquier cliente VPN detrás de los NAT, pueden reenviar cualquier tráfico de subred VPN que reciban al par correcto en el nivel del sistema (a WireGuard no le importa cómo suceda esto , es manejado por el kernel net.ipv4.ip_forward = 1y las reglas de enrutamiento de iptables).
Si todos los pares son de acceso público, no tiene que preocuparse por el tratamiento especial para hacer que uno de ellos sea un servidor de retransmisión, solo es necesario si tiene compañeros que se conectan desde detrás de un NAT.
Cada cliente solo necesita definir los servidores / pares accesibles públicamente en su configuración, cualquier tráfico vinculado a otros pares detrás de NAT irá a la subred VPN (por ejemplo 10.0.0.1/24) en la AllowedIPsruta de los relés públicos y se reenviará en consecuencia una vez que llegue al servidor de retransmisión .
En resumen: solo se deben configurar las conexiones directas entre los clientes, las conexiones que deben ser rechazadas no deben definirse como pares, ya que deben dirigirse al servidor de rebote primero y enrutarse desde allí hacia abajo desde la VPN al cliente correcto.

Cómo WireGuard enruta los paquetes

Definitivamente se pueden lograr topologías más complejas, pero estos son los métodos básicos de enrutamiento utilizados en las configuraciones típicas de WireGuard:
  • Directo nodo a nodo
    En el mejor de los casos, los nodos están en la misma LAN o ambos son de acceso público, y el tráfico se enrutará a través de paquetes UDP cifrados enviados directamente entre los nodos.
  • Nodo detrás de NAT local a nodo público
    Cuando 1 de las 2 partes está detrás de un NAT remoto (por ejemplo, cuando la computadora portátil detrás de un NAT se conecta public-server2), la conexión se abrirá desde NAT -> cliente público, entonces el tráfico se enrutará directamente entre ellos en ambos Instrucciones siempre y cuando la conexión se mantenga viva.
  • Nodo detrás de NAT local a nodo detrás de NAT remoto (a través de UDP perforado de NAT)
    "Perforación de agujeros" se refiere a la activación automática de las reglas de NAT de un enrutador para permitir el tráfico entrante. Cuando envía un paquete UDP, el enrutador (generalmente) crea una regla temporal que asigna su dirección y puerto de origen a la dirección y puerto de destino, y viceversa. Así es como la mayoría de las aplicaciones UDP funcionan detrás de los NAT (por ejemplo, Bittorent, Skype, etc.). Los paquetes UDP que regresan de la dirección de destino y el puerto (y ningún otro) se transfieren a la dirección de origen y al puerto originales (y ningún otro). Esta regla expirará luego de algunos minutos de inactividad, por lo que el cliente detrás de NAT debe enviar paquetes salientes regulares para mantenerla abierta (ver PersistentKeepalive).
    Hacer que esto funcione cuando ambos puntos finales están detrás de los NAT o los firewalls requeriría que ambos puntos finales se envíen paquetes entre sí aproximadamente al mismo tiempo. Esto significa que ambas partes deben conocer las direcciones IP públicas y los números de puerto de cada una y deben comunicarse entre sí por algún otro medio (en nuestro caso definiéndolos en wg0.conf). 
    WireGuard perfora agujeros en los NAT de forma nativa como un efecto secundario de su diseño basado en UDP, pero solo funciona si a ListenPortestá codificado para el par detrás del NAT. No busca un puerto de perforación dinámica dinámicamente como WebRTC / N2N, ya que no tiene el concepto de un servidor de señalización para comunicar el puerto al otro lado, solo funciona con un puerto codificado y PersistentKeepaliveestablecido en un valor no nulo.
  • Nodo detrás de NAT local a nodo detrás de NAT remoto (vía relé)
    En el peor de los casos, cuando ambas partes están detrás de NAT remotos, ambos abrirán una conexión public-server1y el tráfico se reenviará a través del servidor de rebote intermediario siempre y cuando las conexiones se mantengan vivas.
WireGuard controla automáticamente la elección del método de enrutamiento adecuado siempre que al menos un servidor actúe como un servicio público de relevo con net.ipv4.ip_forward = 1habilitado, y los clientes se hayan AllowIPs = 10.0.0.1/24configurado en el servidor de relevo [peer](para tomar tráfico para toda la subred).
Las rutas más específicas (también generalmente más directas) proporcionadas por otros pares tendrán prioridad cuando estén disponibles; de lo contrario, el tráfico volverá a la ruta menos específica y utilizará el 10.0.0.1/24catchall para reenviar el tráfico al servidor de rebote, donde a su vez será enrutado por la tabla de enrutamiento del sistema del servidor de retransmisión devuelve la VPN al par específico que está aceptando rutas para ese tráfico.
Puede averiguar qué método de enrutamiento utiliza WireGuard para una dirección determinada midiendo los tiempos de ping para calcular la longitud única de cada salto e inspeccionando la salida de:
wg show wg0

Cómo se ve el tráfico de WireGuard

WireGuard utiliza paquetes UDP encriptados para todo el tráfico, no ofrece garantías sobre la entrega o el pedido de paquetes, ya que esto se maneja mediante conexiones TCP dentro del túnel encriptado.
Otras lecturas:

Rendimiento de WireGuard

WireGuard asegura un rendimiento más rápido que la mayoría de las otras soluciones de VPN de la competencia, aunque los números exactos a veces se debaten y pueden depender de si la aceleración a nivel de hardware está disponible para ciertos cifrados criptográficos.
Las mejoras en el rendimiento de WireGuard se logran manejando el enrutamiento en el nivel del kernel y utilizando modernos conjuntos de cifrado que se ejecutan en todos los núcleos para cifrar el tráfico. WireGuard también obtiene una ventaja significativa al utilizar UDP sin garantías de entrega / pedido (en comparación con las VPN que se ejecutan a través de TCP o implementan sus propios mecanismos de entrega garantizados).
Otras lecturas:

Modelo de seguridad de WireGuard

WireGuard utiliza los siguientes protocolos y primitivas para asegurar el tráfico:
  • ChaCha20 para cifrado simétrico, autenticado con Poly1305, utilizando la construcción AEAD de RFC7539
  • Curve25519 para ECDH
  • BLAKE2s para hashing y hashing codificado, descrito en RFC7693
  • SipHash24 para llaves hashtable
  • HKDF para derivación de clave, como se describe en RFC5869
La criptografía de WireGuard es esencialmente una instanciación del marco Noise de Trevor Perrin. Es moderno y, de nuevo, sencillo. Todas las demás opciones de VPN son un lío de negociación y de handshaking y máquinas de estado complicadas. WireGuard es como el Signal / Axolotl de las VPN, excepto que es mucho más simple y fácil de razonar (criptográficamente, en este caso) que los protocolos de mensajería de doble trinquete. Es básicamente el qmail del software VPN. Y son ~ 4000 líneas de código. Se trata de órdenes de magnitud plural más pequeños que sus competidores.
Otras lecturas:

Cómo WireGuard maneja las llaves

La autenticación en ambas direcciones se logra con un simple par de llaves público / privado para cada par. Cada interlocutor genera estas claves durante la fase de configuración y comparte solo la clave pública con otros interlocutores.
No se necesitan otros certificados o claves previamente compartidas más allá de las claves públicas / privadas para cada nodo.
La generación, distribución y revocación de claves se pueden manejar en implementaciones más grandes utilizando un servicio separado como Ansible o Kubernetes Secrets.
Algunos servicios que ayudan con la distribución e implementación de claves:
También puede leer las claves de un archivo o mediante un comando si no desea codificarlas de forma rígida wg0.conf, esto hace que la administración de claves a través del servicio de terceros sea mucho más fácil:
[Interfaz]
...
PostUp = wg set% i clave privada /etc/wireguard/wg0.key <(cat / some / path /% i / privkey)

Uso

Inicio rápido

Resumen del proceso general:
  1. Instalar apt install wireguardo pkg/brew install wireguard-toolsen cada nodo
  2. Generar claves públicas y privadas localmente en cada nodo wg genkey+wg pubkey
  3. Cree un wg0.confarchivo de configuración de wireguard en el servidor de retransmisión principal
    • [Interface] Asegúrese de especificar un rango CIDR para toda la subred de VPN cuando defina la dirección para la que el servidor acepta rutas Address = 10.0.0.1/24
    • [Peer] Cree una sección de pares para cada cliente que se una a la VPN, usando sus claves públicas remotas correspondientes
  4. Crear un wg0.confen cada nodo cliente
    • [Interface]Asegúrese de especificar solo una única IP para los pares del cliente que no transmiten el tráfico Address = 10.0.0.3/32.
    • [Peer]Cree una sección de pares para cada par público que no esté detrás de un NAT, asegúrese de especificar un rango CIDR para toda la subred de la VPN al definir el par remoto que actúa como servidor de rebote AllowedIPs = 10.0.0.1/24. Asegúrese de especificar direcciones IP individuales para pares remotos que no transmiten tráfico y solo actúan como clientes simples AllowedIPs = 10.0.0.3/32.
  5. Inicie wireguard en el servidor de retransmisión principal con wg-quick up /full/path/to/wg0.conf
  6. Iniciar wireguard en todos los compañeros del cliente con wg-quick up /full/path/to/wg0.conf
  7. El tráfico se enruta de igual a igual utilizando la ruta más óptima a través de la interfaz de WireGuard, por ejemplo, ping 10.0.0.3primero verifica la ruta directa local, luego la ruta a través de Internet pública y, finalmente, trata de enrutarse saltando a través del servidor de retransmisión pública.

Preparar

# instalar en Ubuntu
sudo add-apt-repository ppa: wireguard / wireguard
apt instalar wireguard

# instalar en macOS
brew install wireguard-tools

# instalar en FreeBSD
pkg instalar wireguard

# instale en iOS / Andoid usando Apple App Store / Google Play Store 
# instale en otros sistemas usando https://www.wireguard.com/install/#installation
# para habilitar la capacidad de retransmisión / reenvío del kernel en servidores de rebote 
echo  " net.ipv4.ip_forward = 1 "  >> /etc/sysctl.conf
 echo  " net.ipv4.conf.all.proxy_arp = 1 "  >> / etc / sysctl. conf
sudo sysctl -p /etc/sysctl.conf

# para agregar reglas de reenvío de iptables en servidores de rebote
iptables -A INPUT -m conntrack --ctstate RELACIONADO, ESTABLECIDO -j ACEPTAR
iptables -A FORWARD -m conntrack --ctstate RELACIONADO, ESTABLECIDO -j ACEPTAR
iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NUEVO -j ACEPTAR
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

Config Creacion

nano wg0.conf   # puede colocarse en cualquier lugar, se debe hacer referencia a la ruta absoluta

Generación de claves

# generar clave privada 
wg genkey > example.key

# generar una clave pública 
wg pubkey < example.key > example.key.pub

Iniciar / detener

wg-quick up /full/path/to/wg0.conf
wg-quick down /full/path/to/wg0.conf
# Nota: debe especificar la ruta absoluta a wg0.conf, las rutas relativas no funcionarán
# Arranque / parada VPN interfaz de red 
IP de enlace conjunto wg0 hasta
ip link set wg0 down

# registrar / 
cancelar registro VPN interfaz de red ip link add dev wg0 type wireguard
ip link delete dev wg0

# registrar / cancelar registro de la dirección VPN local
dirección ip add dev wg0 10.0.0.3/32
dirección ip borrar dev wg0 10.0.0.3/32

# registrar / cancelar registro de la ruta VPN
ip route add 10.0.0.3/32 dev wg0
ip route delete 10.0.0.3/32 dev wg0

Inspeccionar

Interfaces

# Mostrar interfaces de red LAN y WAN del sistema
ifconfig
mostrar dirección ip

# Mostrar interfaces de red VPN del sistema
ifconfig wg0
ip link show wg0

# mostrar las interfaces VPN wireguard
wg mostrar todo
wg show wg0

Direcciones

# mostrar la dirección IP pública
ifconfig eth0
dirección ip mostrar eth0
dig -4 + short myip.opendns.com @ resolver1.opendns.com

# show VPN ip address dirección 
ip show wg0

Rutas

# muestre la tabla de enrutamiento de wireguard y las conexiones entre pares
wg show
wg show wg0 allowed-ips

# Mostrar tabla de enrutamiento del sistema
ip ruta mostrar tabla principal
ip ruta mostrar tabla local

# muestra la ruta del sistema a una dirección específica 
ruta ip obtener 10.0.0.3

Pruebas

Velocidad de ping

# comprobar que el servidor de retransmisión principal es accesible directamente a través de Internet público
ping public-server1.example-vpn.dev

# comprobar que el servidor de retransmisión principal está disponible a través de VPN
ping 10.0.0.1

# comprobar que los pares públicos están disponibles a través de VPN
ping 10.0.0.2

# comprobar que los compañeros remotos de NAT-ed están disponibles a través de VPN
ping 10.0.0.3

# verifique que los compañeros de NAT-ed en su LAN local estén disponibles a través de VPN 
ping 10.0.0.4

Ancho de banda

# instala iperf usando tu gestor de paquetes preferido
apt / brew / pkg install iperf

# verifique el ancho de banda a través de Internet pública al servidor de retransmisión 
iperf -s # en el servidor de retransmisión pública 
iperf -c public-server1.example-vpn.dev # en el cliente local

# verifique el ancho de banda a través de VPN para retransmitir el servidor 
iperf -s # en el servidor de retransmisión pública 
iperf -c 10.0.0.1 # en el cliente local

# verifique el ancho de banda a través de VPN al interlocutor público remoto 
iperf -s # en el interlocutor público remoto 
iperf -c 10.0.0.2 # en el cliente local

# verifique el ancho de banda a través de VPN a un par de NAT-ed remoto 
iperf -s # en un peer de NAT-ed remoto 
iperf -c 10.0.0.3 # en un cliente local

# verifique el ancho de banda a través de VPN a un par de NAT-ed local (en la misma LAN) 
iperf -s # en un peer de NAT-ed local 
iperf -c 10.0.0.4 # en un cliente local

DNS

Verifique si hay fugas de DNS en http://dnsleak.com , o revisando el resolvedor en una búsqueda:
cavar example.com A

Config Referencia

Visión general

La configuración de WireGuard se encuentra en la sintaxis INI, definida en un archivo que generalmente se llama wg0.conf. Puede colocarse en cualquier parte del sistema, pero a menudo se coloca en /etc/wireguard/wg0.conf.
La ruta de configuración se especifica como un argumento cuando se ejecuta cualquier wg-quickcomando, por ejemplo: 
wg-quick up /etc/wireguard/wg0.conf(siempre especifique la ruta completa y absoluta)
Los archivos de configuración pueden optar por utilizar el conjunto limitado de wgopciones de configuración, o las wg-quickopciones más extendidas , según el comando que se prefiera para iniciar WireGuard. Estos documentos recomiendan mantenerlo wg-quickya que proporciona una experiencia de configuración más potente y fácil de usar.
Saltar a definición:

[Interface]

Define la configuración de VPN para el nodo local.
Ejemplos
  • Node es un cliente que solo enruta el tráfico por sí mismo y solo expone una IP
[Interfaz] 
# Nombre = phone.example-vpn.dev 
Address = 10.0.0.5/32
 PrivateKey = <clave privada para phone.example-vpn.dev>
  • Node es un servidor de rebote público que puede retransmitir el tráfico a otros pares y expone la ruta para toda la subred de VPN
[Interfaz] 
# Nombre = public-server1.example-vpn.tld 
Address = 10.0.0.1/24
 ListenPort = 51820
 PrivateKey = <clave privada para public-server1.example-vpn.tld>
 DNS = 1.1.1.1

# Name

Esto es solo un comentario estándar en la sintaxis de INI que se utiliza para ayudar a mantener un registro de qué sección de configuración pertenece a qué nodo, WireGuard lo ignora por completo y no tiene ningún efecto en el comportamiento de VPN.

Address

Define para qué rango de direcciones el nodo local debe enrutar el tráfico. Dependiendo de si el nodo es un cliente simple que se une a la subred VPN, o un servidor de rebote que está retransmitiendo el tráfico entre múltiples clientes, esto puede configurarse a una única IP del propio nodo (especificado con notación CIDR), por ejemplo, 10.0.0.3/32 ), o un rango de subredes IPv4 / IPv6 para las cuales el nodo puede enrutar el tráfico.
Ejemplos
  • Node es un cliente que solo enruta el tráfico por sí mismo.
    Address = 10.0.0.3/32
  • Node es un servidor público de rebote que puede retransmitir el tráfico a otros interlocutores. 
    Cuando el nodo actúa como servidor público de rebote, debe establecer que sea la subred completa a la que puede enrutar el tráfico, no solo una única IP para sí mismo.
Address = 10.0.0.1/24
  • También puede especificar varias subredes o subredes IPv6 de la siguiente manera:
    Address = 10.0.0.1/24,fd42:42:42::1/64

ListenPort

Cuando el nodo actúa como un servidor público de rebote, debe codificar un puerto para escuchar las conexiones VPN entrantes desde la Internet pública. Los clientes que no actúan como relés no deben establecer este valor.
Ejemplos
  • Usando el puerto predeterminado de WireGuard
    ListenPort = 51820
  • Usando el puerto WireGuard personalizado
    ListenPort = 7000

PrivateKey

Esta es la clave privada para el nodo local, nunca compartida con otros servidores. Todos los nodos deben tener un conjunto de claves privadas, independientemente de si se trata de servidores de rebote públicos o de clientes simples que se unen a la VPN.
Esta clave se puede generar con wg genkey > example.key
Ejemplos
PrivateKey = somePrivateKeyAbcdAbcdAbcdAbcd=

DNS

El (los) servidor (es) DNS para anunciar a los clientes VPN a través de DHCP, la mayoría de los clientes usarán este servidor para las solicitudes de DNS a través de la VPN, pero los clientes también pueden anular este valor localmente en sus nodos
Ejemplos
  • El valor se puede dejar sin configurar para usar servidores DNS predeterminados del sistema
  • Se puede proporcionar un único servidor DNS
    DNS = 1.1.1.1
  • o se pueden proporcionar múltiples servidores DNS
    DNS = 1.1.1.1,8.8.8.8

Table

Opcionalmente, define qué tabla de enrutamiento usar para las rutas de WireGuard, no es necesario configurar para la mayoría de las configuraciones.
Hay dos valores especiales: 'off' desactiva la creación de rutas por completo, y 'auto' (predeterminado) agrega rutas a la tabla predeterminada y permite el manejo especial de las rutas predeterminadas.
Ejemplos
Tabla = 1234

MTU

Opcionalmente, define la unidad de transmisión máxima (MTU, también conocida como paquete / tamaño de trama) para usar cuando se conecta a un par, no es necesario configurarla para la mayoría de las configuraciones.
La MTU se determina automáticamente a partir de las direcciones de punto final o la ruta predeterminada del sistema, que suele ser una opción sensata.
Ejemplos
MTU = 1500

PreUp

Opcionalmente, ejecute un comando antes de que aparezca la interfaz. Esta opción se puede especificar varias veces, con los comandos ejecutados en el orden en que aparecen en el archivo.
Ejemplos
  • Añadir una ruta ip PreUp = ip rule add ipproto tcp dport 22 table 1234

PostUp

Opcionalmente, ejecute un comando después de que se active la interfaz. Esta opción puede aparecer varias veces, como con PreUp
Ejemplos
  • Leer en un valor de configuración de un archivo o la salida de algún comando
    PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command here)
  • Registrar una línea en un archivo
    PostUp = echo "$(date +%s) WireGuard Started" >> /var/log/wireguard.log
  • Pulsa un webhook en otro servidor.
    PostUp = curl https://events.example.dev/wireguard/started/?key=abcdefg
  • Agregar una ruta a la tabla de enrutamiento del sistema
    PostUp = ip rule add ipproto tcp dport 22 table 1234
  • Agregue una regla de iptables para habilitar el reenvío de paquetes en la interfaz de WireGuard
    PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  • Forzar a WireGuard a volver a resolver la dirección IP para el dominio de igual
    PostUp = resolvectl domain %i "~."; resolvectl dns %i 10.0.0.1; resolvectl dnssec %i yes

PreDown

Opcionalmente, ejecute un comando antes de desactivar la interfaz. Esta opción puede aparecer varias veces, como con PreUp
Ejemplos
  • Registrar una línea en un archivo
    PostDown = echo "$(date +%s) WireGuard Going Down" >> /var/log/wireguard.log
  • Pulsa un webhook en otro servidor.
    PostDown = curl https://events.example.dev/wireguard/stopping/?key=abcdefg

PostDown

Opcionalmente, ejecute un comando después de que la interfaz esté desactivada. Esta opción puede aparecer varias veces, como con PreUp
Ejemplos
  • Registrar una línea en un archivo
    PostDown = echo "$(date +%s) WireGuard Stopped" >> /var/log/wireguard.log
  • Pulsa un webhook en otro servidor.
    PostDown = curl https://events.example.dev/wireguard/stopped/?key=abcdefg
  • Elimine la regla de iptables que reenvía paquetes en la interfaz de WireGuard
    PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]

Define la configuración de VPN para un interlocutor remoto capaz de enrutar el tráfico para una o más direcciones (sí mismo y / u otros interlocutores). Los pares pueden ser un servidor público de rebote que retransmite el tráfico a otros pares, o un cliente con acceso directo a través de LAN / Internet que no está detrás de un NAT y solo enruta el tráfico por sí mismo.
Todos los clientes deben definirse como pares en el servidor de rebote público. Los clientes simples que solo enrutan el tráfico por sí mismos, solo necesitan definir pares para la retransmisión pública y cualquier otro nodo directamente accesible. Los nodos que están detrás de NAT independientes no deben definirse como pares fuera de la configuración del servidor público, ya que no hay una ruta directa disponible entre NAT independientes. En cambio, los nodos detrás de las NAT solo deben definir los servidores de retransmisión públicos y otros clientes públicos como sus pares, y deben especificar AllowedIPs = 10.0.0.1/24en el servidor público que acepte rutas y rebote el tráfico de la subred de la VPN a los pares remotos de NAT.
En resumen, todos los nodos deben definirse en el servidor de rebote principal. En los servidores cliente, solo los interlocutores a los que se puede acceder directamente desde un nodo deben definirse como interlocutores de ese nodo, todos los interlocutores que deben ser retransmitidos por un servidor de rebote deben omitirse y serán manejados por la ruta general del servidor de retransmisión.
En la configuración descrita en los documentos a continuación, un solo servidor public-server1actúa como el servidor de rebote de retransmisión para una combinación de clientes de acceso público y NAT-ed, y los pares se configuran en cada nodo en consecuencia:
  • en public-server1 wg0.conf(rebote servidor)
    [peer] la lista: public-server2, home-server, laptop,phone
  • en la lista public-server2 wg0.conf(cliente público simple)
    [peer] :public-server1
  • en home-server wg0.conf(simple cliente detrás de NAT)
    [peer] lista: public-server1,public-server2
  • en laptop wg0.conf(simple cliente detrás de NAT)
    [peer] lista: public-server1,public-server2
  • en phone wg0.conf(simple cliente detrás de NAT)
    [peer] lista: public-server1,public-server2
Ejemplos
  • Peer es un simple cliente público que solo enruta el tráfico por sí mismo.
[Peer] 
# Nombre = public-server2.example-vpn.dev 
Endpoint = public-server2.example-vpn.dev:51820
 PublicKey = <clave pública para public-server2.example-vpn.dev>
 AllowedIPs = 10.0.0.2/ 32
  • Peer es un cliente simple detrás de un NAT que solo enruta el tráfico por sí mismo
[Peer] 
# Nombre = home-server.example-vpn.dev 
Endpoint = home-server.example-vpn.dev:51820
 PublicKey = <clave pública para home-server.example-vpn.dev>
 AllowedIPs = 10.0.0.3/ 32
  • Peer es un servidor de rebote público que puede transmitir tráfico a otros peers.
[Peer] 
# Nombre = public-server1.example-vpn.tld 
Endpoint = public-server1.example-vpn.tld: 51820
 PublicKey = <clave pública para public-server1.example-vpn.tld>
 # enruta el tráfico hacia sí mismo y subred completa de iguales como servidor bounce 
AllowedIPs = 10.0.0.1/24
 PersistentKeepalive = 25

# Name

Esto es solo un comentario estándar en la sintaxis de INI que se utiliza para ayudar a mantener un registro de qué sección de configuración pertenece a qué nodo, WireGuard lo ignora por completo y no tiene ningún efecto en el comportamiento de VPN.

Endpoint

Define la dirección de acceso público para un par remoto. Esto se debe dejar fuera para los pares que están detrás de un NAT o que no tienen un par de IP: PORT de acceso público estable. Normalmente, esto solo necesita definirse en el servidor de rebote principal, pero también puede definirse en otros nodos públicos con IP estables, como public-server2en la configuración de ejemplo a continuación.
Ejemplos
  • El punto final es una dirección IP 
    Endpoint = 123.124.125.126:51820 (IPv6 también es compatible)
  • Punto final es un nombre de host / FQDN
    Endpoint = public-server1.example-vpn.tld:51820

AllowedIPs

Esto define los rangos de IP para los cuales un par dirigirá el tráfico. En los clientes simples, esta suele ser una dirección única (la dirección VPN del propio cliente simple). Para los servidores de rebote, este será un rango de las IP o subredes para las cuales el servidor de retransmisión es capaz de enrutar el tráfico. Se pueden especificar múltiples IP y subredes utilizando la notación CIDR de IPv4 o IPv6 separadas por comas (desde una única dirección / 32 o / 128, hasta 0.0.0.0/0e ::/0para indicar una ruta predeterminada para enviar todo el tráfico de Internet y VPN a través de ese par). Esta opción puede especificarse varias veces.
Al decidir cómo enrutar un paquete, el sistema elige primero la ruta más específica y recurre a rutas más amplias. Entonces, para un paquete destinado a 10.0.0.3, el sistema primero buscaría 10.0.0.3/32específicamente una publicidad de pares , y recurriría a una publicidad de pares 10.0.0.1/24o una gama más amplia como 0.0.0.0/0último recurso.
Ejemplos
  • peer es un cliente simple que solo acepta tráfico a / desde sí mismo
    AllowedIPs = 10.0.0.3/32
  • peer es un servidor de retransmisión que puede enviar tráfico VPN a todos los demás peers
    AllowedIPs = 10.0.0.1/24
  • peer es un servidor de retransmisión que rebota todo el tráfico de Internet y VPN (como un proxy), incluido IPv6
    AllowedIPs = 0.0.0.0/0,::/0
  • peer es un servidor de retransmisión que se enruta a sí mismo y solo a otro peer
    AllowedIPs = 10.0.0.3/32,10.0.0.4/32
  • peer es un servidor de retransmisión que se enruta a sí mismo y a todos los nodos en su LAN local
    AllowedIPs = 10.0.0.3/32,192.168.1.1/24

PublicKey

Esta es la clave pública para el nodo remoto, que se puede compartir con todos los pares. Todos los nodos deben tener un conjunto de claves públicas, independientemente de si se trata de servidores de rebote públicos o de clientes simples que se unen a la VPN.
Esta clave se puede generar con wg pubkey < example.key > example.key.pub. (ver más arriba para saber cómo generar la clave privada example.key)
Ejemplos
PublicKey = somePublicKeyAbcdAbcdAbcdAbcd=

PersistentKeepalive

Si la conexión va de un par NAT-ed a un par público, el nodo detrás del NAT debe enviar regularmente un ping saliente para mantener viva la conexión bidireccional en la tabla de conexión del enrutador NAT.
Ejemplos
  • nodo público local a nodo público remoto 
    Este valor debe dejarse sin definir ya que los pings persistentes no son necesarios.
  • nodo público local a nodo remoto NAT-ed 
    Este valor debe dejarse sin definir, ya que es responsabilidad del cliente mantener la conexión activa porque el servidor no puede volver a abrir una conexión muerta con el cliente si se agota el tiempo.
  • Este nodo local de NAT a un nodo público remoto 
    PersistentKeepalive = 25enviará un ping a cada 25 segundos, manteniendo la conexión abierta en la tabla de conexiones del enrutador NAT local.

Temas avanzados

IPv6

Los ejemplos en estos documentos utilizan principalmente IPv4, pero Wireguard admite de forma nativa la notación CIDR de IPv6 y las direcciones en todos los lugares en que es compatible con IPv4, simplemente agréguelos como lo haría con cualquier otro rango o dirección de subred.
Ejemplo
[Interfaz] 
AllowedIps = 10.0.0.3/24, fd42: 42: 42 :: 1/64

[Mirar]
...
AllowIPs = 0.0.0.0/0, :: / 0

Reenviando todo el tráfico

Si desea reenviar todo el tráfico de Internet a través de la VPN, y no solo usarlo como una subred de servidor a servidor, puede agregar 0.0.0.0/0, ::/0a la AllowedIPsdefinición del par al que desea canalizar el tráfico.
Asegúrese de especificar también un catchall de IPv6 incluso cuando solo reenvíe el tráfico de IPv4 para evitar perder paquetes de IPv6 fuera de la VPN, consulte: 
https://www.reddit.com/r/WireGuard/comments/b0m5g2/ipv6_leaks_psa_for_anyone_using_using_wireguard_to/
Ejemplo
[Interfaz] 
# Nombre = phone.example-vpn.dev 
Address = 10.0.0.3/32
 PrivateKey = <clave privada para phone.example-vpn.dev>

[Peer] 
# Nombre = public-server1.example-vpn.dev 
PublicKey = <clave pública para public-server1.example-vpn.dev>
 Endpoint = public-server1.example-vpn.dev:51820
 AllowedIPs = 0.0.0.0/ 0, :: / 0

Conexiones NAT a NAT

WireGuard puede realizar conexiones nativas entre dos clientes detrás de NAT, sin necesidad de un servidor de retransmisión público.
Requerimientos
  • Al menos un compañero debe tener un código Endpointdefinido, de acceso directo definido. Si ambos están detrás de los NAT sin direcciones IP estables, entonces deberá usar el DNS de Dynammic u otra solución para tener un dominio / IP estable y de acceso público para al menos un par
  • Al menos un igual debe tener ListenPortdefinido un UDP codificado , y su enrutador NAT no debe realizar la asignación aleatoria del puerto de origen UDP; de lo contrario, ListenPortel enrutador enviará los paquetes devueltos al enrutado, en lugar de usar el puerto aleatorio asignado por el NAT en el paquete saliente
  • Todos los interlocutores NAT'ed deben estar PersistentKeepalivehabilitados en todos los demás interlocutores, para que envíen continuamente pings salientes para mantener las conexiones persistentes en la tabla de enrutamiento de su NAT.
Las conexiones NAT-a-NAT no son posibles a menos que al menos un host tenga una dirección estable, ya sea utilizando un FQDN actualizado con un DNS dnymaic o una IP pública estática, cualquier cosa funciona siempre que todos los pares puedan comunicarse de antemano.
Nota: Algunos usuarios informan que tienen que reiniciar WireGuard para forzarlo a volver a controlar los nombres de host DNS dinámicos para pares Endpoint. Es posible que desee utilizar un PostUpgancho para facilitar este proceso.
Las conexiones de NAT a NAT no son posibles si todos los puntos finales están detrás de los NAT con una aleatorización de puerto de origen UDP estricta (por ejemplo, la mayoría de las redes de datos celulares). Dado que ninguno de los dos lados puede codificar ListenPorty garantizar que su NAT aceptará el tráfico en ese puerto después del ping saliente, no puede coordinar un puerto para el perforado inicial entre pares y las conexiones fallarán. Por esta razón, por lo general no puede hacer conexiones de teléfono a teléfono en redes LTE / 3g, pero es posible que pueda hacer teléfono a oficina o teléfono a casa donde la oficina o el hogar tengan una IP pública estable y no la tengan. No hagas aleatorización de puertos de origen.
El proceso de conexión se ve así:
  1. Peer1 envía un paquete UDP a Peer2, el enrutador NAT de Peer2 se rechaza de inmediato, pero está bien, el único propósito era que el NAT de Peer1 comenzara a reenviar las respuestas UDP esperadas a Peer1 detrás de su NAT
  2. Peer2 envía un paquete UDP a Peer1, se acepta y se envía a Peer1 ya que el servidor NAT de Peer1 ya está esperando respuestas de Peer2 debido al paquete saliente inicial
  3. Peer1 envía una respuesta UDP al paquete de Peer2, es aceptado y reenviado por el servidor NAT de Peer2, ya que también espera respuestas debido al paquete saliente inicial
Este proceso de enviar un paquete inicial que se rechaza, y luego usar el hecho de que el enrutador ahora ha creado una regla de reenvío para aceptar respuestas, se denomina "taladrado UDP".
Cuando envía un paquete UDP, el enrutador (generalmente) crea una regla temporal que asigna su dirección y puerto de origen a la dirección y puerto de destino, y viceversa. Los paquetes UDP que regresan de la dirección de destino y el puerto (y ningún otro) se transfieren a la dirección de origen y al puerto originales (y ningún otro). Así es como la mayoría de las aplicaciones UDP funcionan detrás de los NAT (por ejemplo, Bittorent, Skype, etc.). Esta regla expirará luego de algunos minutos de inactividad, por lo que el cliente detrás de NAT debe enviar paquetes salientes regulares para mantenerla abierta (ver PersistentKeepalive).
Hacer que esto funcione cuando ambos puntos finales están detrás de los NAT o los firewalls requeriría que ambos puntos finales se envíen paquetes entre sí aproximadamente al mismo tiempo. Esto significa que ambas partes deben conocer las direcciones IP públicas y los números de puerto de cada una y deben comunicarse entre sí por algún otro medio (en nuestro caso, codificándolos por wg0.confadelantado). WebRTC requiere un servidor de señalización STUN para comunicar el puerto de perforación de agujeros porque sería imposible para los navegadores codificar los puertos de escucha para todas las conexiones posibles de antemano.
WireGuard perfora agujeros en los NAT de forma nativa como un efecto secundario de su diseño basado en UDP, pero solo funciona si a ListenPortestá codificado para el par detrás del NAT. No busca un puerto de perforación dinámica dinámicamente como WebRTC / N2N ya que no tiene el concepto de un servidor de señalización para comunicar el puerto al otro lado, solo funciona con un puerto codificado y PersistentKeepaliveestablecido en un valor no nulo en ambos lados
Este enfoque tiene algunas limitaciones, por lo que aún se recomienda tener un servidor de retransmisión pública alternativa, consulte:
Ejemplo
Peer1:
[Interfaz]
...
ListenPort 12000

[Mirar]
...
Punto final = peer2.example-vpn.dev:12000
 PersistentKeepalive = 25
Peer2:
[Interfaz]
...
ListenPort 12000

[Mirar]
...
Punto final = peer1.example-vpn.dev:12000
 PersistentKeepalive = 25

Asignación dinámica de IP

La asignación dinámica de IP (en lugar de tener solo pares fijos) se está desarrollando, la implementación de WIP está disponible aquí: https://github.com/WireGuard/wg-dynamic
También puede crear un sistema de asignación dinámica usted mismo leyendo los valores de IP de los archivos en tiempo de ejecución utilizando PostUp(consulte a continuación).
Ejemplo
[Interfaz]
...
PostUp = wg set% i allowed-ips /etc/wireguard/wg0.key <(algún comando)

Otras implementaciones de WireGuard

Todas las implementaciones en el espacio de usuario son más lentas que la versión C nativa que se ejecuta en kernel-land, pero ofrecen otros beneficios al ejecutarse en la zona de usuario (por ejemplo, una contenedorización más fácil, compatibilidad, etc.).

Herramientas de configuración de WireGuard

Estas son algunas herramientas de GUI y CLI que envuelven WireGuard para ayudar con la configuración, la implementación, la administración de claves y la conexión.

Configura los atajos

El crédito por estos accesos directos va a: https://www.ericlight.com/new-things-i-didnt-know-about-wireguard.html

Compartiendo un solo archivo peers.conf

WireGuard ignorará a un par cuya clave pública coincida con la clave privada de la interfaz. Por lo tanto, puede distribuir una única lista de pares en todas partes y solo definir la lista por [Interface]separado en cada servidor.
Puedes combinar esto con wg addconfesto:
  • Cada par tiene su propio /etc/wireguard/wg0.confarchivo, que solo contiene su [Interface]sección.
  • Cada par también tiene un /etc/wireguard/peers.confarchivo compartido , que contiene todos los compañeros.
  • El wg0.confarchivo también tiene un PostUpgancho: PostUp = wg addconf /etc/wireguard/peers.conf.
Depende de usted decidir cómo quiere compartir la información peers.conf, ya sea a través de una plataforma de orquestación adecuada, algo mucho más peatonal como Dropbox, o algo un poco salvaje como Ceph. No lo sé, pero es bastante bueno que puedas moverte violentamente en una sección de pares, sin preocuparte de si es lo mismo que la interfaz.

Configuración de valores de configuración desde archivos o comandos de salida.

Puede establecer valores de configuración a partir de comandos arbitrarios o al leer los valores de los archivos, esto hace que la administración e implementación de claves sea mucho más fácil, ya que puede leer las claves en tiempo de ejecución de un servicio de terceros como Kubernetes Secrets o AWS KMS.
Ejemplo
Puedes leer en un archivo como PrivateKeyhaciendo algo como:
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command)

Contenedorización

WireGuard se puede ejecutar en Docker con diversos grados de facilidad. En el caso más simple, --privilegedy --cap-add=allargumentos pueden ser añadidos a los comandos de la ventana acoplable para permitir la carga del módulo del núcleo.
Las configuraciones pueden ser algo complejas, ya que dependen en gran medida de lo que intenta lograr. Puede hacer que WireGuard se ejecute en un contenedor y exponer una interfaz de red al host, o puede hacer que WireGuard se ejecute en el host exponiendo una interfaz a contenedores específicos.
Otras lecturas

Ejemplo de configuración de servidor a servidor con dispositivos móviles

La configuración de ejemplo completa para la configuración a continuación se puede encontrar aquí: https://github.com/pirate/wireguard-docs/tree/master/full-example (ADVERTENCIA: no la use en sus dispositivos sin cambiar la configuración pública / privada ¡llaves!).

Visión general

Topología de la red

Estos 5 dispositivos se usan en nuestra configuración de ejemplo para explicar cómo WireGuard admite la conexión en puente a través de una variedad de condiciones de red, todos están bajo un dominio de ejemplo example-vpn.dev, con los siguientes nombres de host cortos:
  • public-server1 (no detrás de un NAT, actúa como el principal servidor de rebote de VPN)
  • public-server2 (no detrás de un NAT, se une como un par sin rebotar el tráfico)
  • home-server (detrás de un NAT, se une como un par sin rebotar el tráfico)
  • laptop (detrás de NAT, algunas veces compartido con el servidor de casa / teléfono, a veces con roaming)
  • phone (detrás de NAT, a veces compartido con home-server / laptop, a veces roaming)

Explicación

Esta configuración VPN simula la configuración de una pequeña subred VPN 10.0.0.1/24compartida por 5 nodos. Dos de los nodos (public-server1 y public-server2) son instancias de VPS que viven en una nube en algún lugar, con IP públicas accesibles a Internet. home-server es un nodo estacionario que vive detrás de un NAT con una IP dinámica, pero no cambia con frecuencia. El teléfono y la computadora portátil son nodos móviles, que pueden estar en casa en la misma LAN que el servidor de la casa, o usar el servicio público de wifi o celular para conectarse a la VPN.
Siempre que sea posible, los nodos deben conectarse directamente entre sí, dependiendo de si los nodos son directamente accesibles o los NAT están entre ellos, el tráfico se enrutará en consecuencia:

El relevo publico

public-server1actúa como un servidor de retransmisión intermedio entre cualquier cliente VPN detrás de NAT, reenviará cualquier tráfico 10.0.0.1/24 que reciba al par correcto en el nivel del sistema (a WireGuard no le importa cómo suceda esto, es manejado por el kernel net.ipv4.ip_forward = 1y el reglas de enrutamiento de iptables).
Cada cliente solo necesita definir los servidores / compañeros accesibles públicamente en su configuración, cualquier tráfico vinculado a otros pares detrás de los NAT irá a la recepción 10.0.0.1/24del servidor y se reenviará en consecuencia una vez que llegue al servidor principal.
En resumen: solo se deben configurar las conexiones directas entre los clientes, las conexiones que deben ser rechazadas no deben definirse como pares, ya que deben dirigirse al servidor de rebote primero y enrutarse desde allí hacia abajo desde la VPN al cliente correcto.

Código de ejemplo completo

Para ejecutar este ejemplo completo, simplemente copie la full wg0.conf config file for nodesección de cada nodo en cada servidor, habilite el reenvío de IP en la retransmisión pública y luego inicie WireGuard en todas las máquinas.
Para obtener instrucciones más detalladas, consulte la guía de inicio rápido y la referencia de API anteriores. También puede descargar la configuración de ejemplo completa aquí: https://github.com/pirate/wireguard-docs/tree/master/full-example (ADVERTENCIA: ¡no la use en sus dispositivos sin cambiar las claves públicas / privadas!) .

Config. Nodo

public-server1.example-vpn.tld

  • punto final público: public-server1.example-vpn.tld:51820
  • Dirección IP de vpn propia: 10.0.0.1
  • puede aceptar tráfico para ips: 10.0.0.1/24
  • clave privada: <private key for public-server1.example-vpn.tld>
  • clave de pub: <public key for public-server1.example-vpn.tld>
  • configuración requerida:
    1. instalar wireguard
    2. generar par de llaves públicas / privadas
    3. crear wg0.conf (ver más abajo)
    4. habilitar el reenvío de ip & arp del kernel, agregar reglas de reenvío de iptables
    5. iniciar wireguard
  • config como par remoto
[Peer] 
# Nombre = public-server1.example-vpn.tld 
Endpoint = public-server1.example-vpn.tld: 51820
 PublicKey = <clave pública para public-server1.example-vpn.tld>
 # enruta el tráfico hacia sí mismo y subred completa de iguales como servidor bounce 
AllowedIPs = 10.0.0.1/24
 PersistentKeepalive = 25
  • config como interfaz local:
[Interfaz] 
# Nombre = public-server1.example-vpn.tld 
Address = 10.0.0.1/24
 ListenPort = 51820
 PrivateKey = <clave privada para public-server1.example-vpn.tld>
 DNS = 1.1.1.1
  • compañeros: public-server2, home-server, laptop, phone
  • wg0.confarchivo de configuración completo para el nodo:
[Interfaz] 
# Nombre = public-server1.example-vpn.tld 
Address = 10.0.0.1/24
 ListenPort = 51820
 PrivateKey = <clave privada para public-server1.example-vpn.tld>
 DNS = 1.1.1.1

[Peer] 
# Nombre = public-server2.example-vpn.dev 
Endpoint = public-server2.example-vpn.dev:51820
 PublicKey = <clave pública para public-server2.example-vpn.dev>
 AllowedIPs = 10.0.0.2/ 32

[Peer] 
# Nombre = home-server.example-vpn.dev 
Endpoint = home-server.example-vpn.dev:51820
 PublicKey = <clave pública para home-server.example-vpn.dev>
 AllowedIPs = 10.0.0.3/ 32

[Peer] 
# Nombre = laptop.example-vpn.dev 
PublicKey = <clave pública para laptop.example-vpn.dev>
 AllowedIPs = 10.0.0.4/32

[Peer] 
# phone.example-vpn.dev 
PublicKey = <clave pública para phone.example-vpn.dev>
 AllowedIPs = 10.0.0.5/32

public-server2.example-vpn.dev

  • punto final público: public-server2.example-vpn.dev:51820
  • Dirección IP de vpn propia: 10.0.0.2
  • puede aceptar tráfico para ips: 10.0.0.2/32
  • clave privada: <private key for public-server2.example-vpn.dev>
  • clave de pub: <public key for public-server2.example-vpn.dev>
  • configuración requerida:
    1. instalar wireguard
    2. generar par de llaves públicas / privadas
    3. crear wg0.conf (ver más abajo)
    4. confirmar que el servidor principal de retransmisión pública es directamente accesible
    5. iniciar wireguard
  • config como interfaz local:
[Interfaz] 
# Nombre = public-server2.example-vpn.dev 
Address = 10.0.0.2/32
 ListenPort = 51820
 PrivateKey = <clave privada para public-server2.example-vpn.dev>
 DNS = 1.1.1.1
  • config as peer
[Peer] 
# Nombre = public-server2.example-vpn.dev 
Endpoint = public-server2.example-vpn.dev:51820
 PublicKey = <clave pública para public-server2.example-vpn.dev>
 AllowedIPs = 10.0.0.2/ 32
  • compañeros: public-server1
  • wg0.confarchivo de configuración completo para el nodo:
[Interfaz] 
# Nombre = public-server2.example-vpn.dev 
Address = 10.0.0.2/32
 ListenPort = 51820
 PrivateKey = <clave privada para public-server2.example-vpn.dev>
 DNS = 1.1.1.1

[Peer] 
# Nombre = public-server1.example-vpn.tld 
Endpoint = public-server1.example-vpn.tld: 51820
 PublicKey = <clave pública para public-server1.example-vpn.tld>
 # enruta el tráfico hacia sí mismo y subred completa de iguales como servidor bounce 
AllowedIPs = 10.0.0.1/24
 PersistentKeepalive = 25

home-server.example-vpn.dev

  • punto final público: (ninguno, detrás de NAT)
  • Dirección IP de vpn propia: 10.0.0.3
  • puede aceptar tráfico para ips: 10.0.0.3/32
  • clave privada: <private key for home-server.example-vpn.dev>
  • clave de pub: <public key for home-server.example-vpn.dev>
  • configuración requerida:
    1. instalar wireguard
    2. generar par de llaves públicas / privadas
    3. crear wg0.conf (ver más abajo)
    4. confirmar que el servidor principal de retransmisión pública es directamente accesible
    5. iniciar wireguard
  • config como interfaz local:
[Interfaz] 
# Nombre = home-server.example-vpn.dev 
Address = 10.0.0.3/32
 ListenPort = 51820
 PrivateKey = <clave privada para home-server.example-vpn.dev>
 DNS = 1.1.1.1
  • config as peer
[Peer] 
# Nombre = home-server.example-vpn.dev 
Endpoint = home-server.example-vpn.dev:51820
 PublicKey = <clave pública para home-server.example-vpn.dev>
 AllowedIPs = 10.0.0.3/ 32
  • compañeros: public-server1
  • wg0.confarchivo de configuración completo para el nodo:
[Interfaz] 
# Nombre = home-server.example-vpn.dev 
Address = 10.0.0.3/32
 ListenPort = 51820
 PrivateKey = <clave privada para home-server.example-vpn.dev>
 DNS = 1.1.1.1

[Peer] 
# Nombre = public-server1.example-vpn.tld 
Endpoint = public-server1.example-vpn.tld: 51820
 PublicKey = <clave pública para public-server1.example-vpn.tld>
 # enruta el tráfico hacia sí mismo y subred completa de iguales como servidor bounce 
AllowedIPs = 10.0.0.1/24
 PersistentKeepalive = 25

laptop.example-vpn.dev

  • punto final público: (ninguno, detrás de NAT)
  • Dirección IP de vpn propia: 10.0.0.4
  • puede aceptar tráfico para ips: 10.0.0.4/32
  • clave privada: <private key for laptop.example-vpn.dev>
  • clave de pub: <public key for laptop.example-vpn.dev>
  • configuración requerida:
    1. instalar wireguard
    2. generar par de llaves públicas / privadas
    3. crear wg0.conf (ver más abajo)
    4. confirmar que el servidor principal de retransmisión pública es directamente accesible
    5. iniciar wireguard
  • config como interfaz local:
[Interfaz] 
# Nombre = laptop.example-vpn.dev 
Address = 10.0.0.4/32
 PrivateKey = <clave privada para laptop.example-vpn.dev>
 DNS = 1.1.1.1
  • config as peer
[Peer] 
# Nombre = laptop.example-vpn.dev 
PublicKey = <clave pública para laptop.example-vpn.dev>
 AllowedIPs = 10.0.0.4/32
  • compañeros: public-server1
  • wg0.confarchivo de configuración completo para el nodo:
[Interfaz] 
# Nombre = laptop.example-vpn.dev 
Address = 10.0.0.4/32
 PrivateKey = <clave privada para laptop.example-vpn.dev>
 DNS = 1.1.1.1

[Peer] 
# Nombre = public-server1.example-vpn.tld 
Endpoint = public-server1.example-vpn.tld: 51820
 PublicKey = <clave pública para public-server1.example-vpn.tld>
 # enruta el tráfico hacia sí mismo y subred completa de iguales como servidor bounce 
AllowedIPs = 10.0.0.1/24
 PersistentKeepalive = 25

teléfono.ejemplo-vpn.dev

  • punto final público: (ninguno, detrás de NAT)
  • Dirección IP de vpn propia: 10.0.0.5
  • puede aceptar tráfico para ips: 10.0.0.5/32
  • clave privada: <private key for phone.example-vpn.dev>
  • clave de pub: <public key for phone.example-vpn.dev>
  • configuración requerida:
    1. instalar wireguard
    2. generar par de llaves públicas / privadas
    3. crear wg0.conf (ver más abajo)
    4. confirmar que el servidor principal de retransmisión pública es directamente accesible
    5. iniciar wireguard
  • config como interfaz local:
[Interfaz] 
# Nombre = phone.example-vpn.dev 
Address = 10.0.0.5/32
 PrivateKey = <clave privada para phone.example-vpn.dev>
 DNS = 1.1.1.1
  • config as peer
[Peer] 
# phone.example-vpn.dev 
PublicKey = <clave pública para phone.example-vpn.dev>
 AllowedIPs = 10.0.0.5/32
  • compañeros: public-server1
  • wg0.confarchivo de configuración completo para el nodo:
[Interfaz] 
# Nombre = phone.example-vpn.dev 
Address = 10.0.0.5/32
 PrivateKey = <clave privada para phone.example-vpn.dev>
 DNS = 1.1.1.1

[Peer] 
# Nombre = public-server1.example-vpn.tld 
Endpoint = public-server1.example-vpn.tld: 51820
 PublicKey = <clave pública para public-server1.example-vpn.tld>
 # enruta el tráfico hacia sí mismo y subred completa de iguales como servidor bounce 
AllowedIPs = 10.0.0.1/24
 PersistentKeepalive = 25

Otras lecturas

Documentos de referencia

Tutoriales

Artículos, artículos y charlas

Proyectos relacionados

Estibador

Otro

Los debates

Para obtener instrucciones más detalladas, consulte la guía de inicio rápido y la referencia de API anteriores. También puede descargar la configuración de ejemplo completa aquí: https://github.com/pirate/wireguard-example .

Comentarios

Publicar un comentario

Todos sus comentarios seran bienvenidos, no se admiten insultos todo con el debido respeto que se merece cada persona, o de lo contrario seran eliminado cada comentario inrespetuoso hacia los demas. y autores del blog tambien puedes seguirnos en:

Facebook: https://www.facebook.com/groups/HackingTeamCyber/

Grupo de Telegram: https://t.me/TheHackForceOfficial

Canal de Youtube: https://www.youtube.com/channel/UCXy8Lg28OuGuI5Z-2EWJaNA?view_as=subscriber

Canal Vimeo: https://vimeo.com/403136547?activityReferer=1

Red Social Twitter: https://twitter.com/TheHackForce