wireguard docs
1.0.0
Guía de referencia de API para WireGuard que incluye instalación, configuración y uso, con ejemplos.
Todo el crédito es para el proyecto WireGuard, zx2c4 y los contribuyentes de código abierto para el software original,
Este es mi único intento no oficial de proporcionar documentación, referencias de 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 página HTML más agradable: https://docs.sweeting.me/s/wireguard
WireGuard es una solución VPN de código abierto escrita en C por Jason Donenfeld y otros, cuyo objetivo es solucionar muchos de los problemas que han afectado a otras ofertas modernas de VPN de servidor a servidor como IPSec/IKEv2, OpenVPN o L2TP. Comparte algunas similitudes con otras ofertas de VPN modernas como Tinc y MeshBird, es decir, buenos conjuntos de cifrado y configuración mínima. A partir del 2020-01, se fusionó con la versión 5.6 del kernel de Linux, lo que significa que se enviará con la mayoría de los sistemas Linux listos para usar.
Enlaces oficiales
wg , wg-quickObjetivos de WireGuard
Consulte https://github.com/pirate/wireguard-docs para ver un ejemplo de código y fuente de documentación.
Ya sea que viva detrás de la Gran Muralla China o simplemente intente formar una red entre sus servidores, WireGuard es una excelente opción y sirve como un "bloque de Lego" para construir redes (de la misma manera que ZFS es un bloque de Lego para construir sistemas de archivos). ).
Cosas que WireGuard no hace:
Pero puedes escribir tus propias soluciones para estos problemas usando WireGuard bajo el capó (como Tailscale o AltheaNet).
Estos son nombres de host de demostración, nombres de dominio, direcciones IP y rangos utilizados en la documentación y configuraciones de ejemplo. Reemplácelos con sus valores preferidos cuando realice su propia configuración.
example-vpn.dev se puede reemplazar con cualquier dominio de acceso público que usted controlepublic-server1 , public-server2 , home-server , laptop , phone se pueden cambiar a los nombres de host de su dispositivo192.0.2.1/24 , 192.0.2.3 , 192.0.2.3/32 , 2001:DB8::/64 se pueden reemplazar con sus subredes y direcciones preferidas (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 ningún significado especial.
¡Asegúrate de cambiar las direcciones IP en tus configuraciones! Los bloques utilizados en estos documentos están reservados para fines de ejemplo por parte del IETF y nunca deben usarse en configuraciones de red reales.
192.0.2.0/24 (TEST-NET-1) Rango de ejemplo de IPv4 RFC57372001:DB8::/32 Rango de ejemplo de IPv6 RFC3849 Puede usar cualquier rango privado que desee para sus propias configuraciones, por ejemplo, 10.0.44.0/24 , solo asegúrese de que no entren en conflicto con ninguno de los rangos de subred LAN en los que se encuentran sus pares.
Un host que se conecta a la VPN y registra una dirección de subred VPN como 192.0.2.3 . Opcionalmente, también puede enrutar el tráfico a más direcciones además de sus propias direcciones especificando rangos de subred en notación CIDR separados por comas.
Un nodo/par accesible públicamente que sirve como respaldo para retransmitir el tráfico a otros pares VPN detrás de NAT. Un servidor de rebote no es un tipo especial de servidor, es un par normal como todos los demás, la única diferencia es que tiene una IP pública y tiene activado el reenvío de IP a nivel de kernel, lo que le permite rebotar el tráfico hacia la VPN. a otros clientes.
Ver más: https://tailscale.com/blog/how-nat-traversal-works/ (Tailscale usa Wireguard debajo del capó)
Un grupo de IP separadas de la Internet pública, por ejemplo, 192.0.2.1-255 o 192.168.1.1/24. Generalmente detrás de una NAT proporcionada por un enrutador, por ejemplo, en la LAN de Internet de la oficina o en una red Wi-Fi doméstica.
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:
192.0.2.1/32 (una única dirección IP, 192.0.2.1 ) máscara de red = 255.255.255.255192.0.2.1/24 (255 IP de 192.0.2.0 - 192.0.2.255 ) máscara de red = 255.255.255.0192.0.2.1/16 (65.536 IP de 192.0.0.0 - 192.0.255.255 ) máscara de red = 255.255.0.0192.0.2.1/8 (16.777.216 IP de 192.0.0.0 - 192.255.255.255 ) máscara de red = 255.0.0.00.0.0.1/0 (4.294.967.296 IP de 0.0.0.0 - 255.255.255.255 ) máscara de red = 0.0.0.02001:DB8::/64https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Para las personas que recién comienzan, 192.0.2.1/32 puede parecer una forma extraña y confusa de referirse a una única IP. Sin embargo, este diseño es bueno porque permite a los pares exponer múltiples IP si es necesario sin necesidad de múltiples notaciones. Solo debes saber que en cualquier lugar donde veas algo como 192.0.2.3/32 , en realidad solo significa 192.0.2.3 .
Una subred con IP privadas proporcionadas por un enrutador ubicado frente a ellos que realiza 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 reenví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)
La dirección:puerto de acceso público para un nodo, por ejemplo, 123.124.125.126:1234 o some.domain.tld:1234 (debe ser accesible a través de Internet público, generalmente no puede ser una IP privada como 192.0.2.1 o 192.168.1.1 a menos que otros pares en la misma subred pueden acceder directamente usando esa dirección).
Una clave privada de WireGuard para un único nodo, generada con: wg genkey > example.key (nunca abandona el nodo en el que se genera)
Una clave pública WireGuard para un único nodo, generada con: wg pubkey < example.key > example.key.pub (compartida con otros pares)
Servidor de nombres de dominio, utilizado para resolver nombres de host en 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 se pueden comprobar con http://dnsleak.com.
Los retransmisiones públicas son simplemente pares VPN normales que pueden actuar como un servidor de retransmisión intermedio entre cualquier cliente VPN detrás de 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 sucede esto , lo maneja el kernel net.ipv4.ip_forward = 1 y las reglas de enrutamiento de iptables).
Si todos los pares son de acceso público, no tiene que preocuparse por un tratamiento especial para convertir a uno de ellos en un servidor de retransmisión; solo es necesario si tiene pares conectados desde detrás de una NAT.
Cada cliente solo necesita definir los servidores/pares de acceso público en su configuración, cualquier tráfico vinculado a otros pares detrás de NAT irá a la subred VPN general (por ejemplo, 192.0.2.1/24 ) en la ruta de retransmisiones públicas AllowedIPs y se reenviará en consecuencia. una vez que llega al servidor de retransmisión.
En resumen: solo se deben configurar conexiones directas entre clientes, cualquier conexión que deba rebotarse no debe definirse como igual, ya que debe dirigirse primero al servidor de rebote y desde allí volver a enrutarse por la vpn hasta el cliente correcto.
Definitivamente se pueden lograr topologías más complejas, pero estos son los métodos de enrutamiento básicos utilizados en las configuraciones típicas de WireGuard:
Endpoint codificados para que WireGuard pueda conectarse directamente al puerto abierto y enrutar paquetes UDP sin saltos intermedios.public-server2 ), defina el nodo de acceso público con un Endpoint codificado y el nodo con NAT sin él. La conexión se abrirá desde el cliente NAT -> cliente público, luego el tráfico se enrutará directamente entre ellos en ambas direcciones siempre que la conexión se mantenga activa mediante pings salientes PersistentKeepalive desde el cliente NAT.public-server1 y el tráfico se reenviará a través del servidor de rebote intermediario siempre que las conexiones se mantienen vivos. 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 comodín 192.0.2.1/24 para reenviar el tráfico al servidor de rebote, donde en a su vez, ser enrutado por la tabla de enrutamiento del sistema del servidor de retransmisión ( net.ipv4.ip_forward = 1 ) regresa por la VPN al par específico que acepta rutas para ese tráfico. WireGuard no encuentra automáticamente la ruta más rápida ni intenta formar conexiones directas entre pares si aún no están definidas, simplemente va de la ruta más específica en [Peers] a la menos específica.
Puede determinar qué método de enrutamiento está utilizando WireGuard para una dirección determinada midiendo los tiempos de ping para determinar la longitud única de cada salto e inspeccionando la salida de:
wg show wg0WireGuard utiliza paquetes UDP cifrados para todo el tráfico; no ofrece garantías sobre la entrega o el pedido de paquetes, ya que eso lo manejan las conexiones TCP dentro del túnel cifrado.
Lectura adicional:
WireGuard afirma tener un rendimiento más rápido que la mayoría de las otras soluciones VPN de la competencia, aunque las cifras exactas 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 de rendimiento de WireGuard se logran manejando el enrutamiento a 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 funcionan sobre TCP o implementan sus propios mecanismos de entrega garantizados).
Lectura adicional:
WireGuard utiliza los siguientes protocolos y primitivas para proteger el tráfico:
La criptografía de WireGuard es esencialmente una instanciación del marco Noise de Trevor Perrin. Es moderno y, nuevamente, simple. Cualquier otra opción de VPN es un lío de negociaciones, apretones de manos y complicadas máquinas de estado. 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. Es varios órdenes de magnitud más pequeño que sus competidores.
https://news.ycombinator.com/item?id=14599834
Lectura adicional:
La autenticación en ambas direcciones se logra con un simple par de claves pública/privada para cada par. Cada par genera estas claves durante la fase de configuración y comparte solo la clave pública con otros pares.
No se necesitan otros certificados ni claves precompartidas más allá de las claves públicas/privadas de cada nodo.
La generación, distribución y revocación de claves se pueden gestionar en implementaciones más grandes utilizando un servicio independiente como Ansible o Kubernetes Secrets.
Algunos servicios que ayudan con la distribución e implementación de claves:
También puede leer las claves desde un archivo o mediante un comando si no desea codificarlas en wg0.conf , esto hace que la administración de claves a través de un servicio de terceros sea mucho más fácil:
[Interface]
...
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privkey)Técnicamente, varios servidores pueden compartir la misma clave privada siempre que los clientes no estén conectados a dos servidores con la misma clave simultáneamente. Un ejemplo de un escenario en el que esta es una configuración razonable es si está utilizando DNS por turnos para equilibrar la carga de las conexiones entre dos servidores que pretenden ser un solo servidor. Sin embargo, la mayoría de las veces, cada par debe tener su propio par de claves pública/privada para que los pares no puedan leer el tráfico de los demás y puedan ser revocados individualmente.
Resumen del proceso general:
apt install wireguard o pkg/brew install wireguard-tools en cada nodowg genkey + wg pubkeywg0.conf WireGuard en el servidor de retransmisión principal[Interface] Asegúrese de especificar un rango CIDR para toda la subred VPN al definir la dirección para la que el servidor acepta rutas Address = 192.0.2.1/24[Peer] Cree una sección de pares para cada cliente que se una a la VPN, utilizando sus claves públicas remotas correspondientes.wg0.conf en cada nodo cliente[Interface] Asegúrese de especificar solo una IP para los pares de clientes que no retransmiten tráfico Address = 192.0.2.3/32 .[Peer] Cree una sección de par para cada par público que no esté detrás de una NAT; asegúrese de especificar un rango CIDR para toda la subred VPN al definir el par remoto que actúa como servidor de rebote AllowedIPs = 192.0.2.1/24 . Asegúrese de especificar direcciones IP individuales para pares remotos que no retransmiten tráfico y solo actúan como clientes simples AllowedIPs = 192.0.2.3/32 .wg-quick up /full/path/to/wg0.confwg-quick up /full/path/to/wg0.confping 192.0.2.3 busca una ruta directa a un igual con AllowedIPs = 192.0.2.3/32 primero y luego recurre a un servidor de retransmisión que acepta IP. en toda la subred # install on Ubuntu
sudo add-apt-repository ppa:wireguard/wireguard
apt install wireguard
# install on macOS
brew install wireguard-tools
# install on FreeBSD
pkg install wireguard
# install on iOS/Android using Apple App Store/Google Play Store
# install on other systems using https://www.wireguard.com/install/#installation # to enable the kernel relaying/forwarding ability on bounce servers
echo " net.ipv4.ip_forward = 1 " | sudo tee -a /etc/sysctl.conf
echo " net.ipv4.conf.all.proxy_arp = 1 " | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf
# to add iptables forwarding rules on bounce servers
sudo iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADEnano wg0.conf # can be placed anywhere, must be referred to using absolute path (usually placed in /etc/wireguard/wg0.conf on most Linux systems) # generate private key
wg genkey > example.key
# generate public key
wg pubkey < example.key > example.key.pubwg-quick up /full/path/to/wg0.conf
wg-quick down /full/path/to/wg0.conf
# Note: you must specify the absolute path to wg0.conf, relative paths won't work
# If wg0.conf is in /etc/wireguard you can use the simpler:
wg-quick up wg0 # start/stop VPN network interface
ip link set wg0 up
ip link set wg0 down
# register/unregister VPN network interface
ip link add dev wg0 type wireguard
ip link delete dev wg0
# register/unregister local VPN address
ip address add dev wg0 192.0.2.3/32
ip address delete dev wg0 192.0.2.3/32
# register/unregister VPN route
ip route add 192.0.2.3/32 dev wg0
ip route delete 192.0.2.3/32 dev wg0 # show system LAN and WAN network interfaces
ip address show
# or if ip is not available:
ifconfig
# show system VPN network interfaces
ip link show wg0
# or
ifconfig wg0
# show WireGuard VPN interfaces
wg show all
wg show wg0 # show public IP address
ip address show eth0
# or
ifconfig eth0
# or
dig -4 +short myip.opendns.com @resolver1.opendns.com
# show VPN IP address
ip address show wg0 # show WireGuard routing table and peer connections
wg show
wg show wg0 allowed-ips
# show system routing table
ip route show table main
ip route show table local
# show system route to specific address
ip route get 192.0.2.3Para habilitar la ejecución de registro adicional:
modprobe wireguard
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/controlPara seguir registros:
dmesg -wHLos sistemas con kernel moderno y arranque seguro pueden requerir deshabilitar la verificación de firma DKMS de arranque seguro para permitir el acceso a los registros del kernel.
mokutil --disable-verification
reboot # check that the main relay server is accessible directly via public internet
ping public-server1.example-vpn.dev
# check that the main relay server is available via VPN
ping 192.0.2.1
# check that public peers are available via VPN
ping 192.0.2.2
# check that remote NAT-ed peers are available via VPN
ping 192.0.2.3
# check that NAT-ed peers in your local LAN are available via VPN
ping 192.0.2.4 # install iperf using your preferred package manager
apt/brew/pkg/opkg install iperf
# check bandwidth over public internet to relay server
iperf -s # on public relay server
iperf -c public-server1.example-vpn.dev # on local client
# check bandwidth over VPN to relay server
iperf -s # on public relay server
iperf -c 192.0.2.1 # on local client
# check bandwidth over VPN to remote public peer
iperf -s # on remote public peer
iperf -c 192.0.2.2 # on local client
# check bandwidth over VPN to remote NAT-ed peer
iperf -s # on remote NAT-ed peer
iperf -c 192.0.2.3 # on local client
# check bandwidth over VPN to local NAT-ed peer (on same LAN)
iperf -s # on local NAT-ed peer
iperf -c 192.0.2.4 # on local client Verifique si hay fugas de DNS usando http://dnsleak.com o verificando el solucionador en una búsqueda:
dig example.com A La configuración de WireGuard está en sintaxis INI, definida en un archivo generalmente llamado wg0.conf . Se puede colocar en cualquier parte del sistema, pero a menudo se coloca en /etc/wireguard/wg0.conf .
La ruta de configuración se especifica como argumento cuando se ejecuta cualquier comando wg-quick , por ejemplo:
wg-quick up /etc/wireguard/wg0.conf (especifique siempre la ruta completa y absoluta)
El nombre del archivo de configuración debe tener el formato ${name of the new WireGuard interface}.conf . Los nombres de las interfaces WireGuard generalmente tienen el prefijo wg y están numerados comenzando en 0 , pero puede usar cualquier nombre que coincida con la expresión regular ^[a-zA-Z0-9_=+.-]{1,15}$ .
Los archivos de configuración pueden optar por utilizar el conjunto limitado de opciones de configuración wg o las opciones más extendidas wg-quick , según el comando que se prefiera para iniciar WireGuard. Estos documentos recomiendan seguir con wg-quick , ya que proporciona una experiencia de configuración más potente y fácil de usar.
Saltar a la definición:
¶ [Interface]
¶ # Name = node1.example.tld
¶ Address = 192.0.2.3/32
¶ ListenPort = 51820
¶ PrivateKey = localPrivateKeyAbcAbcAbc=
¶ DNS = 1.1.1.1,8.8.8.8
¶ Table = 12345
¶ MTU = 1500
¶ PreUp = /bin/example arg1 arg2 %i
¶ PostUp = /bin/example arg1 arg2 %i
¶ PreDown = /bin/example arg1 arg2 %i
¶ PostDown = /bin/example arg1 arg2 %i
¶ [Peer]
¶ # Name = node2-node.example.tld
¶ AllowedIPs = 192.0.2.1/24
¶ Endpoint = node1.example.tld:51820
¶ PublicKey = remotePublicKeyAbcAbcAbc=
¶ PersistentKeepalive = 25
[Interface]Define la configuración de VPN para el nodo local.
Ejemplos
[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.5/32
PrivateKey = <private key for phone.example-vpn.dev> [Interface]
# Name = public-server1.example-vpn.tld
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = <private key for public-server1.example-vpn.tld>
DNS = 1.1.1.1# NameEste es solo un comentario estándar en la sintaxis INI que se utiliza para ayudar a realizar un seguimiento 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.
NOTA: Ciertas operaciones y aplicaciones eliminan todos los comentarios, incluido # Name , de los archivos .conf. Si necesita identificar pares, considere usar un generador de claves personalizadas de Wireguard, como wireguard-vanity-keygen o wireguard-vanity-address, que le permitirá incluir el nombre del host en la clave pública del host. La generación de claves puede tardar minutos (4 caracteres), horas (5 caracteres) o más, así que considere usar una abreviatura para hosts con nombres más largos.
AddressDefine para qué rango de direcciones el nodo local debe enrutar el tráfico. Dependiendo de si el nodo es un simple cliente que se une a la subred VPN o un servidor de rebote que transmite tráfico entre varios clientes, esto se puede configurar en una única IP del propio nodo (especificada con notación CIDR), por ejemplo, 192.0.2.3/32. ), o un rango de subredes IPv4/IPv6 para las que el nodo puede enrutar el tráfico.
Ejemplos
Node es un cliente que solo enruta el tráfico por sí mismo
Address = 192.0.2.3/32
Node es un servidor de rebote público que puede transmitir tráfico a otros pares
Cuando el nodo actúa como servidor de rebote público, debe configurarlo para que sea toda la subred a la que puede enrutar el tráfico, no solo una única IP para sí mismo.
Address = 192.0.2.1/24
Address = 192.0.2.1/24,2001:DB8::/64ListenPortCuando el nodo actúa como un servidor de rebote público, debe codificar un puerto para escuchar las conexiones VPN entrantes desde la Internet pública. Los clientes que no actúan como retransmisores no deben establecer este valor.
Ejemplos
ListenPort = 51820ListenPort = 7000PrivateKeyEsta es la clave privada para el nodo local, nunca compartida con otros servidores. Todos los nodos deben tener una clave privada configurada, independientemente de si son servidores de rebote públicos que transmiten tráfico o simples clientes que se unen a la VPN.
Esta clave se puede generar con wg genkey > example.key
Ejemplos
PrivateKey = somePrivateKeyAbcdAbcdAbcdAbcd=
DNSLos servidores DNS para anunciar a los clientes VPN a través de DHCP; la mayoría de los clientes usarán este servidor para solicitudes de DNS a través de la VPN, pero los clientes también pueden anular este valor localmente en sus nodos.
Ejemplos
DNS = 1.1.1.1DNS = 1.1.1.1,8.8.8.8TableOpcionalmente, define qué tabla de enrutamiento usar para las rutas WireGuard; no es necesario configurarla para la mayoría de las configuraciones.
Hay dos valores especiales: 'off' deshabilita la creación de rutas por completo y 'auto' (el valor predeterminado) agrega rutas a la tabla predeterminada y habilita un manejo especial de las rutas predeterminadas.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
Ejemplos
Table = 1234MTUOpcionalmente, define la unidad de transmisión máxima (MTU, también conocida como tamaño de paquete/trama) que se usará al conectarse al par, no es necesario configurarla para la mayoría de las configuraciones.
La MTU se determina automáticamente a partir de las direcciones de los puntos finales o de la ruta predeterminada del sistema, lo que suele ser una opción sensata.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
Ejemplos
MTU = 1500PreUpOpcionalmente, ejecute un comando antes de que se abra la interfaz. Esta opción se puede especificar varias veces y los comandos se ejecutan en el orden en que aparecen en el archivo.
Ejemplos
PreUp = ip rule add ipproto tcp dport 22 table 1234 PostUpOpcionalmente, ejecute un comando después de que se abra la interfaz. Esta opción puede aparecer varias veces, como ocurre con PreUp
Ejemplos
Leer 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
Haga clic en 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 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 del mismo nivel
PostUp = resolvectl domain %i "~."; resolvectl dns %i 192.0.2.1; resolvectl dnssec %i yes
PreDownOpcionalmente, ejecute un comando antes de que se cierre la interfaz. Esta opción puede aparecer varias veces, como ocurre con PreUp
Ejemplos
Registrar una línea en un archivo
PostDown = echo "$(date +%s) WireGuard Going Down" >> /var/log/wireguard.log
Haga clic en un webhook en otro servidor
PostDown = curl https://events.example.dev/wireguard/stopping/?key=abcdefg
PostDownOpcionalmente, ejecute un comando después de que se cierre la interfaz. Esta opción puede aparecer varias veces, como ocurre con PreUp
Ejemplos
Registrar una línea en un archivo
PostDown = echo "$(date +%s) WireGuard Stopped" >> /var/log/wireguard.log
Haga clic en 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 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 par remoto capaz de enrutar el tráfico para una o más direcciones (él mismo y/o otros pares). Los pares pueden ser un servidor de rebote público que transmite el tráfico a otros pares o un cliente al que se puede acceder directamente a través de LAN/Internet que no está detrás de una NAT y solo enruta el tráfico para sí mismo.
Todos los clientes deben estar definidos como pares en el servidor de rebote público. Los clientes simples que solo enrutan el tráfico para ellos 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 ninguna ruta directa disponible entre NAT independientes. En cambio, los nodos detrás de NAT solo deben definir los servidores de retransmisión públicos y otros clientes públicos como sus pares, y deben especificar AllowedIPs = 192.0.2.1/24 en el servidor público que acepta rutas y rebota el tráfico de la subred VPN al servidor NAT remoto. colegas.
En resumen, todos los nodos deben estar definidos en el servidor de rebote principal. En los servidores cliente, solo los pares a los que se puede acceder directamente desde un nodo deben definirse como pares de ese nodo; cualquier par que deba ser retransmitido por un servidor de rebote debe quedar fuera y será manejado por la ruta general del servidor de retransmisión.
En la configuración descrita en los documentos a continuación, un único servidor public-server1 actúa como servidor de rebote de retransmisión para una combinación de clientes NAT y de acceso público, y los pares se configuran en cada nodo en consecuencia:
en public-server1 wg0.conf (servidor de rebote)
Lista [peer] : public-server2 , home-server , laptop , phone
en public-server2 wg0.conf (cliente público simple)
Lista [peer] : public-server1
en home-server wg0.conf (cliente simple detrás de NAT)
Lista [peer] : public-server1 , public-server2
en laptop wg0.conf (cliente simple detrás de NAT)
Lista [peer] : public-server1 , public-server2
en phone wg0.conf (cliente simple detrás de NAT)
Lista [peer] : public-server1 , public-server2
Ejemplos
[Peer]
# Name = public-server2.example-vpn.dev
Endpoint = public-server2.example-vpn.dev:51820
PublicKey = <public key for public-server2.example-vpn.dev>
AllowedIPs = 192.0.2.2/32 [Peer]
# Name = home-server.example-vpn.dev
Endpoint = home-server.example-vpn.dev:51820
PublicKey = <public key for home-server.example-vpn.dev>
AllowedIPs = 192.0.2.3/32 [Peer]
# Name = public-server1.example-vpn.tld
Endpoint = public-server1.example-vpn.tld:51820
PublicKey = <public key for public-server1.example-vpn.tld>
# routes traffic to itself and entire subnet of peers as bounce server
AllowedIPs = 192.0.2.1/24
PersistentKeepalive = 25# NameEste es solo un comentario estándar en la sintaxis INI que se utiliza para ayudar a realizar un seguimiento 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 debe omitirse para los pares detrás de una NAT o los pares que no tienen un par IP:PUERTO estable y de acceso público. Por lo general, esto solo debe definirse en el servidor de rebote principal, pero también se puede definir en otros nodos públicos con IP estables como public-server2 en la configuración de ejemplo a continuación.
Ejemplos
Endpoint = 123.124.125.126:51820 (también se admite IPv6)Endpoint = public-server1.example-vpn.tld:51820AllowedIPs Esto define los rangos de IP para los cuales un par enrutará el tráfico. En clientes simples, suele ser una dirección única (la dirección VPN del propio cliente simple). Para los servidores de rebote, este será un rango de IP o subredes para las que el servidor de retransmisión es capaz de enrutar el tráfico. Se pueden especificar varias IP y subredes utilizando notación CIDR IPv4 o IPv6 separadas por comas (desde una única dirección /32 o /128, hasta 0.0.0.0/0 y ::/0 para indicar una ruta predeterminada para enviar todos tráfico de Internet y VPN a través de ese par). Esta opción se puede especificar 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 192.0.2.3 , el sistema primero buscaría un par que anuncie 192.0.2.3/32 específicamente, y recurriría a un par que anuncie 192.0.2.1/24 o un rango mayor como 0.0.0.0/0 como un último recurso.
Ejemplos
peer es un cliente simple que sólo acepta tráfico hacia/desde sí mismo
AllowedIPs = 192.0.2.3/32
peer es un servidor de retransmisión que puede rebotar el tráfico VPN a todos los demás peers
AllowedIPs = 192.0.2.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 sólo a otro peer
AllowedIPs = 192.0.2.3/32,192.0.2.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 = 192.0.2.3/32,192.168.1.1/24
PublicKeyEsta es la clave pública para el nodo remoto, que se puede compartir con todos los pares. Todos los nodos deben tener una clave pública configurada, independientemente de si son servidores de rebote públicos que retransmiten tráfico o simples clientes que se unen a la VPN.
Esta clave se puede generar con wg pubkey < example.key > example.key.pub . (consulte arriba para saber cómo generar la clave privada example.key )
Ejemplos
PublicKey = somePublicKeyAbcdAbcdAbcdAbcd=
PersistentKeepaliveSi la conexión va de un par con NAT a un par público, el nodo detrás de NAT debe enviar periódicamente un ping saliente para mantener activa la conexión bidireccional en la tabla de conexiones del enrutador NAT.
Ejemplos
nodo público local a nodo público remoto
Este valor debe dejarse sin definir ya que no se necesitan pings persistentes.
nodo público local a nodo remoto con NAT
Este valor debe dejarse sin definir ya que es responsabilidad del cliente mantener activa la conexión porque el servidor no puede reabrir una conexión inactiva con el cliente si se agota el tiempo de espera.
Nodo local con NAT a nodo público remoto
PersistentKeepalive = 25 esto enviará un ping cada 25 segundos manteniendo la conexión abierta en la tabla de conexiones del enrutador NAT local.
Los ejemplos en estos documentos usan principalmente IPv4, pero WireGuard admite nativamente la notación y direcciones IPv6 CIDR en todas partes que admite IPv4, simplemente agréguelos como lo haría con cualquier otro rango o dirección de la subred.
Ejemplo
[Interface]
Address = 192.0.2.3/24, 2001:DB8::/64
[Peer]
...
AllowedIPs = 0.0.0.0/0, ::/0 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, ::/0 a la definición AllowedIPs de la pareja que desea tuve su tráfico a través de.
Asegúrese de especificar también un IPv6 Catchall incluso cuando solo reenvíe el tráfico IPv4 para evitar fugas de paquetes IPv6 fuera de la VPN, consulte:
https://www.reddit.com/r/wireguard/comments/b0m5g2/ipv6_leaks_psa_for_anyone_here_using_wireguard_to/
Ejemplo
[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.3/32
PrivateKey = <private key for phone.example-vpn.dev>
[Peer]
# Name = public-server1.example-vpn.dev
PublicKey = <public key for public-server1.example-vpn.dev>
Endpoint = public-server1.example-vpn.dev:51820
AllowedIPs = 0.0.0.0/0, ::/0WireGuard a veces puede hacer conexiones de forma nativa entre dos clientes detrás de NAT sin la necesidad de un servidor de retransmisión público, pero en la mayoría de los casos esto no es posible. Las conexiones NAT-to-Nat solo son posibles si al menos un host tiene una dirección IP estable y de acceso público: par de puertos que puede codificarse con anticipación, ya sea que esté utilizando un FQDN actualizado con DNS dinámico o una IP estática con IP estática con Un puerto NAT no aleatorizado abierto por paquetes salientes, cualquier cosa funciona siempre que todos los pares puedan comunicarlo de antemano y no cambia una vez que se inicia la conexión.
Un puerto y una dirección conocidos deben configurarse con anticipación porque WireGuard no tiene una capa de señalización o servidores públicos de aturdimiento que se puedan usar para buscar otros hosts dinámicamente. WEBRTC es un ejemplo de un protocolo que puede configurar dinámicamente una conexión entre dos NATS, pero lo hace mediante el uso de un servidor de señalización fuera de banda para detectar la combinación IP: puerto de cada host. WireGuard no tiene esto, por lo que solo funciona con un Endpoint codificado + ListenPort (y PersistentKeepalive para que no caiga después de la inactividad).
Obtenga más información de la Biblia de Tailscale de Nat Traversal: https://tailscale.com/blog/how-nat-traversal-works/
Endpoint codificado, directamente accesible definido. Si ambos están detrás de NATS sin direcciones IP estables, entonces necesitará usar DNS dinámico u otra solución para tener un dominio/IP estable, de acceso público para al menos un parListenPort definido por código duro, y su enrutador nat no debe hacer la aleatorización del puerto de origen UDP, de lo contrario, los paquetes de devolución se enviarán a la ListenPort codificada y se lanzarán por el enrutador, en lugar de usar el puerto aleatorio asignado por el Nat en el paquete salientePersistentKeepalive habilitado en todos los demás compañeros, de modo que envíen continuamente pings salientes para mantener las conexiones persistidas en la mesa de enrutamiento de su NAT Este proceso de enviar un paquete inicial que se rechaza, luego utilizando el hecho de que el enrutador ahora ha creado una regla de reenvío para aceptar respuestas se llama "golpe de agujeros UDP".
Cuando envía un paquete UDP, el enrutador (generalmente) crea una regla temporal que asigna su dirección de origen y puerto a la dirección y puerto de destino, y viceversa. Los paquetes UDP que regresan desde la dirección de destino y el puerto (y ningún otro) se pasan a la dirección y el puerto de origen original (y no otro). Así es como la mayoría de las aplicaciones UDP funcionan detrás de NATS (por ejemplo, BitTorrent, Skype, etc.). Esta regla se espera que después de unos minutos de inactividad, por lo que el cliente detrás del NAT debe enviar paquetes salientes regulares para mantenerlo abierto (ver PersistentKeepalive ).
Hacer que esto funcione cuando ambos puntos finales están detrás de NATS o firewalls requiere que ambos puntos finales envíen paquetes a otro aproximadamente al mismo tiempo. Esto significa que ambas partes necesitan conocer las direcciones IP públicas de cada uno y los números de puerto con anticipación, en el caso de WireGuard, esto se logra mediante la codificación de puertos predefinidos para ambos lados en wg0.conf .
A partir de 2019, muchos de los viejos métodos de golpe de agujeros utilizados que solían funcionar ya no son efectivos. Un ejemplo fue un método novedoso pionero por Pwnat que fingió un tiempo ICMP excedió la respuesta desde fuera del NAT para recuperar un paquete hasta un compañero Nat, filtrando así su propio puerto fuente. Los puertos UDP codificantes y las IP públicas para ambos lados de una conexión Nat a Nat (como se describió anteriormente) todavía funciona en un pequeño porcentaje de redes. En general, cuanta más "empresa" sea una red, menos probabilidades de poder perforar puertos UDP públicos (Wi-Fi público comercial y datos celulares a menudo no funcionan, por ejemplo).
Las conexiones NAT-to-NAT no son posibles si todos los puntos finales están detrás de NAT con la estricta aleatorización del puerto de origen UDP (por ejemplo, la mayoría de las redes de datos celulares). Dado que ninguno de los lados puede codificar un ListenPort y garantizar que su NAT aceptará el tráfico en ese puerto después del ping saliente, no puede coordinar un puerto para el golpe inicial entre pares y las conexiones fallarán. Por esta razón, generalmente no puede hacer conexiones de teléfono a teléfono en redes LTE/3G, pero es posible que pueda hacer un teléfono a oficina o de teléfono a casa donde la oficina o la casa tienen una IP pública estable y no lo hace. 'T DO ARMOTORACIÓN DE PORTO DE FUENTE.
Las conexiones NAT-TO-NAT desde detrás de NATS con una estricta aleatorización de puerto de origen es posible, solo necesita un servidor de señalización para indicar a cada lado la tupla IP: puerto del otro. Aquí hay algunas implementaciones que logran esto con WireGuard:
Muchos usuarios informan que tienen que reiniciar WireGuard cada vez que cambia una IP dinámica, ya que solo resuelve los nombres de host en el inicio. Para obligar a WireGuard a volver a solucionar los nombres de host Endpoint DNS DNS con más frecuencia, es posible que desee usar un gancho PostUp para reiniciar WireGuard cada pocos minutos o horas.
Puede ver si una configuración de salto de agujeros es factible utilizando NetCat en el cliente y el servidor para ver qué puertos y el pedido de conexión funcionan para abrir una conexión bidireccional: ejecute nc -v -u -p 51820 <address of peer2> 51820 ( en Peer1) y nc -v -u -l 0.0.0.0 51820 (en Peer2), luego escriba ambas ventanas para ver si puede poner en marcha el tráfico bidireccional. Si no funciona independientemente de qué par envíe el paquete inicial, entonces WireGuard no podrá trabajar entre los compañeros sin un servidor de retransmisión público.
Las conexiones NAT-to-Nat a menudo son más inestables y tienen otras limitaciones, por lo que todavía se recomienda tener un servidor de retransmisión público de retroceso.
Ejemplo
Peer1:
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer2.example-vpn.dev:12000
PersistentKeepalive = 25Peer2:
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer1.example-vpn.dev:12000
PersistentKeepalive = 25 Nota: Esta sección trata sobre IP de pares dinámicos dentro de la subred VPN, no las direcciones dinámicas Endpoint público .
Se está desarrollando una asignación dinámica de IP de par (en lugar de solo tener pares fijos), la implementación de WIP está disponible aquí: https://github.com/wireguard/wg-dynamic
También puede construir un sistema de asignación dinámica usted mismo leyendo en valores IP a partir de archivos en tiempo de ejecución usando PostUp (ver más abajo).
Ejemplo
[Interface]
...
PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command) https://git.zx2c4.com/wireguard-go/about/
Una implementación compatible de Userland WireGuard escrita en GO.
https://git.zx2c4.com/wireguard-rs/about/
Una implementación incompleta e insegura del espacio de usuario de WireGuard escrita en Rust (no listo para el público).
https://git.zx2c4.com/wireguard-hs/about/
Una implementación incompleta e insegura del espacio de usuario de WireGuard escrita en Haskell (no listo para el público).
https://github.com/cloudflare/boringtun
Una implementación de WireGuard independiente no conforme escrita en Rust (una bifurcación separada escrita por CloudFlare). Ver https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/
Aplicaciones de control de alambre específicas de la plataforma
https://git.zx2c4.com/wireguard-ios/about/
https://git.zx2c4.com/wireguard-doid/about/
https://git.zx2c4.com/wireguard-windows/about/
Todas las implementaciones del espacio de usuario son más lentas que la versión n nativa que se ejecuta en land de kernel, pero proporciona otros beneficios ejecutándose en Userland (por ejemplo, un contenedor más fácil, compatibilidad, etc.).
Estas son algunas herramientas de GUI e CLI que envuelven WireGuard para ayudar con la configuración, la implementación, la administración de claves y la conexión.
El crédito por estos atajos se destina a: https://www.ericlight.com/new-things-i-didnt-know-bout-wireguard.html
WireGuard ignorará un compañero cuya clave pública coincide con la clave privada de la interfaz. Por lo tanto, puede distribuir una sola lista de pares en todas partes, y solo definir la [Interface] por separado en cada servidor.
Ver: https://lists.zx2c4.com/pipermail/wireguard/2018-december/003703.html
Puede combinar esto con wg addconf así:
Cada par tiene el archivo /etc/wireguard/wg0.conf , que solo contiene su sección [Interface] .
Cada par también tiene un archivo compartido /etc/wireguard/peers.conf , que contiene todos los pares.
El archivo wg0.conf también tiene un gancho PostUp : PostUp = wg addconf /etc/wireguard/peers.conf .
Depende de usted decidir cómo desea compartir los peers.conf . No sé, pero es bastante bueno que puedas lanzar una sección de pares, sin preocuparte si es lo mismo que la interfaz.
Puede establecer valores de configuración de comandos arbitrarios o leyendo en valores de archivos, esto hace que la administración de claves y la implementación sean mucho más fáciles, ya que puede leer en claves en tiempo de ejecución desde un servicio de terceros como Kubernetes Secrets o AWS KMS.
Ver: https://lists.zx2c4.com/pipermail/wireguard/2018-december/003702.html
Ejemplo
Puede leer en un archivo como PrivateKey haciendo algo como:
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command)
WireGuard se puede ejecutar en Docker con diversos grados de facilidad. En el caso más simple, --privileged y --cap-add=all los argumentos se pueden agregar a los comandos Docker para habilitar la carga del módulo del kernel.
Las configuraciones pueden ser algo complejas y dependen en gran medida de lo que esté tratando de 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 que exponga una interfaz a contenedores específicos.
Consulte a continuación un ejemplo de un contenedor Docker vpn_test enrutando todo su tráfico a través de un servidor de relé de WireGuard.
version : ' 3 '
services :
wireguard :
image : linuxserver/wireguard
ports :
- 51820:51820/udp
cap_add :
- NET_ADMIN
- SYS_MODULE
volumes :
- /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro wg0.conf :
[Interface]
# Name = relay1.wg.example.com
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = oJpRt2Oq27vIB5/ UVb7BRqCwad2YMReQgH5tlxz8YmI =
DNS = 1.1.1.1,8.8.8.8
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT ; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT ; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
# Name = peer1.wg.example.com
PublicKey = I+hXRAJOG/UE2IQvIHsou2zTgkUyPve2pzvHTnd/ 2Gg =
AllowedIPs = 192.0.2.2/32 En este ejemplo, todo el tráfico desde el interior del contenedor speedtest pasará por la VPN de WireGuard. Para enrutar solo algo de tráfico, reemplace 0.0.0.0/0 en wg0.conf a continuación con los rangos de subred que desea enrutar a través de la VPN.
docker-compose.yml :
version : ' 3 '
services :
wireguard :
image : linuxserver/wireguard
cap_add :
- NET_ADMIN
- SYS_MODULE
volumes :
- /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro
vpn_test :
image : curlimages/curl
entrypoint : curl -s http://whatismyip.akamai.com/
network_mode : ' service:wireguard ' wg0.conf :
[Interface]
# Name = peer1.wg.example.com
Address = 192.0.2.2/32
PrivateKey = YCW76edD4W7nZrPbWZxPZhcs32CsBLIi1sEhsV/ sgk8 =
DNS = 1.1.1.1,8.8.8.8
[Peer]
# Name = relay1.wg.example.com
Endpoint = relay1.wg.example.com:51820
PublicKey = zJNKewtL3gcHdG62V3GaBkErFtapJWsAx+ 2um0c0B1s =
AllowedIPs = 192.0.2.1/24,0.0.0.0/0
PersistentKeepalive = 21Para obtener más detalles, consulte la sección de lectura adicional: Docker a continuación.
Para obtener instrucciones más detalladas, consulte la guía QuickStart y la referencia de API arriba. También puede descargar la configuración de ejemplo completa aquí: https://github.com/pirate/wireguard-example.
Sugerir cambios: https://github.com/pirate/wireguard-docs/issues
