Plantillas de configuración WireGuard 2026 (listas para usar)

Instalaste WireGuard en tu VPS. Leíste tres tutoriales contradictorios. El wg0.conf que pegas no hace ping, o sí pero el DNS se filtra, o el kill switch corta tu máquina entera al desconectar el túnel. La causa es casi siempre la misma: una plantilla copiada sin entender su contexto original.

Esta guía propone 8 plantillas wg0.conf probadas en producción sobre Contabo VPS S, con el caso de uso, las trampas conocidas y las 4 líneas a adaptar. Eliges la que coincide con tu escenario, ajustas claves, te conectas. Cinco minutos.

Convenciones comunes

Todas las plantillas siguen las mismas reglas — simplifica tu mental model:

• Subred cliente: 10.66.66.0/24 (peers .2 → .254)
• Interfaz pública servidor: eth0 (comprueba con ip route | awk '/default/ {print $5}')
• Puerto UDP: 51820 (modificable, ver plantilla 7 ofuscación)
• Claves: generadas con wg genkey | tee server.key | wg pubkey > server.pub
• Sysctl: net.ipv4.ip_forward=1 activado en servidor (/etc/sysctl.conf)
• MTU: 1420 por defecto, ajustado cuando sea necesario

Los bloques PrivateKey son placeholders — reemplaza por los tuyos. Nunca commitees estos ficheros en un repo público.

Plantilla 1 — Servidor WireGuard estándar (1 cliente roadwarrior)

El caso más común: tu VPS Contabo expone un túnel para tu MacBook de viaje.

# /etc/wireguard/wg0.conf (servidor)
[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820
MTU = 1420

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# MacBook Eric
PublicKey = CLIENT_PUBLIC_KEY_HERE
AllowedIPs = 10.66.66.2/32

Lado cliente:

# /etc/wireguard/wg0.conf (cliente macOS/Linux)
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9, 149.112.112.112
MTU = 1420

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Puntos a vigilar:

• AllowedIPs = 0.0.0.0/0, ::/0 enruta TODO el tráfico cliente vía el VPS.
• PersistentKeepalive = 25 obligatorio si el cliente está detrás de NAT (hotel, 4G) — sin esto, el túnel muere tras ~3 min de inactividad.
• DNS = 9.9.9.9 fuerza resolución Quad9 — si no, el cliente usa DNS local y tus queries se filtran.

Plantilla 2 — VPN casa (split-tunnel: LAN local excluida)

Quieres VPN para tu tráfico web pero mantener acceso al LAN local (impresora, NAS) sin pasar por el túnel.

# Cliente casa
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1420

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Todo salvo RFC1918 LAN + multicast + APIPA
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/3, 224.0.0.0/4, 240.0.0.0/5, 248.0.0.0/6, 252.0.0.0/7, 254.0.0.0/8, 255.0.0.0/9
PersistentKeepalive = 25

El truco de las subredes fragmentadas (en lugar de 0.0.0.0/0) hace que WireGuard añada rutas específicas que no pisan la ruta por defecto. Tu 192.168.x.x y 10.x.x.x LAN quedan accesibles directamente.

Plantilla 3 — VPN viaje con kill switch netfilter estricto

Viajas a China, Irán, Rusia. Si el túnel cae, nada debe filtrarse. Solución: kill switch netfilter que descarta todo salvo tráfico vía wg0 y el handshake servidor.

# Cliente viaje kill-switch
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1280

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PostUp = ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Estas 4 líneas PostUp/PreDown son el verdadero kill switch — no un popup de aplicación. Mientras wg-quick down wg0 no se ejecute, ningún paquete sale de la interfaz que no esté marcado por WireGuard.

MTU a 1280 para redes caprichosas (hoteles, 3G). Mejor perder 1% de débito que tener un túnel inestable.

Plantilla 4 — Multi-peer (5 dispositivos, mismo usuario)

Tienes MacBook, iPhone, iPad, VPS de trabajo, Raspberry Pi. Los quieres enrutar todos por el mismo VPN con subredes separadas para monitoring.

[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# MacBook
PublicKey = MAC_PUBKEY
AllowedIPs = 10.66.66.2/32

[Peer]
# iPhone
PublicKey = IPHONE_PUBKEY
AllowedIPs = 10.66.66.3/32

[Peer]
# iPad
PublicKey = IPAD_PUBKEY
AllowedIPs = 10.66.66.4/32

[Peer]
# Worker VPS (Hetzner)
PublicKey = WORKER_PUBKEY
AllowedIPs = 10.66.66.5/32

[Peer]
# Raspberry Pi home
PublicKey = RPI_PUBKEY
AllowedIPs = 10.66.66.6/32

Cada peer tiene IP fija en la subred 10.66.66.0/24. Si monitorizas vía Prometheus (ver guía monitoring), puedes etiquetar por IP y saber quién consume cuánto.

Plantilla 5 — Hub-and-spoke (peer-to-peer entre clientes)

Por defecto WireGuard no enruta entre peers. Si quieres que tu iPhone hable con tu Raspberry Pi por el hub servidor:

En el servidor, añade:

sysctl -w net.ipv4.ip_forward=1

Y en los bloques [Peer] del servidor, pon AllowedIPs = 10.66.66.X/32 (IP única del peer).

En los clientes, modifica AllowedIPs:

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Subred entera, no solo 0.0.0.0/0
AllowedIPs = 10.66.66.0/24

Con esto, desde tu iPhone (10.66.66.3) puedes ssh pi@10.66.66.6 directamente — el hub reenvía.

Plantilla 6 — Restricción de salida por peer (allowlist)

Caso avanzado: un peer (tu hijo, un invitado, un servicio automatizado) debe poder conectarse al túnel pero solo hacia ciertos dominios/IP.

Añade en el PostUp del servidor (además del MASQUERADE):

iptables -A FORWARD -s 10.66.66.50/32 -d 1.1.1.1 -j ACCEPT
iptables -A FORWARD -s 10.66.66.50/32 -d 142.250.0.0/15 -j ACCEPT  # Google
iptables -A FORWARD -s 10.66.66.50/32 -j REJECT

El peer 10.66.66.50 solo puede alcanzar 1.1.1.1 (DNS) e IPs Google. Todo lo demás se rechaza.

Plantilla 7 — Ofuscación puerto 443 vía udp2raw

Algunos firewalls corporativos bloquean UDP saliente. Solución: encapsular WireGuard en fake TCP/443 vía udp2raw.

Lado servidor:

udp2raw_amd64 -s -l 0.0.0.0:443 -r 127.0.0.1:51820 -k "p@ssw0rd_long" --raw-mode faketcp

Lado cliente:

udp2raw_amd64 -c -l 127.0.0.1:50000 -r vpn.example.com:443 -k "p@ssw0rd_long" --raw-mode faketcp

En el wg0.conf cliente, cambia Endpoint:

Endpoint = 127.0.0.1:50000

El débito cae (~30% overhead) pero atraviesa casi cualquier DPI corporativo.

Plantilla 8 — Site-to-site (dos LANs unidas)

Dos casas, dos Raspberry Pi pasarela, un VPS Contabo como hub. Cada LAN ve la otra como si fuera local.

Servidor (VPS hub):

[Interface]
PrivateKey = HUB_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Sitio A (LAN 192.168.10.0/24)
PublicKey = SITE_A_PUBKEY
AllowedIPs = 10.66.66.10/32, 192.168.10.0/24

[Peer]
# Sitio B (LAN 192.168.20.0/24)
PublicKey = SITE_B_PUBKEY
AllowedIPs = 10.66.66.20/32, 192.168.20.0/24

Sitio A (Raspberry Pi):

[Interface]
PrivateKey = SITE_A_PRIVATE_KEY_HERE
Address = 10.66.66.10/24

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

[Peer]
PublicKey = HUB_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 10.66.66.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Activa ip_forward en ambos Raspberry y añade ruta estática en otras máquinas LAN si deben responder desde el otro sitio.

Diagnóstico rápido cuando nada funciona

Pegaste la plantilla, lanzas wg-quick up wg0, arranca — pero ping falla. Checklist en este orden:

• wg show: ¿último handshake reciente? Si "never" → handshake KO, verifica Endpoint, puerto UDP en firewall servidor.
• ip route en cliente: ¿ruta hacia subred VPN existe? Si no → AllowedIPs cliente mal configurado.
• dig @9.9.9.9 ifconfig.me +short desde cliente conectado: ¿devuelve IP del VPS? Si no → MASQUERADE ausente en servidor, o ip_forward = 0.
• tcpdump -i wg0 en servidor: ¿ves paquetes llegar? Si sí pero nada sale por eth0 → regla FORWARD/MASQUERADE ausente.
• MTU: ping -M do -s 1400 1.1.1.1 desde cliente. Si "Frag needed" → reduce MTU en wg0.conf a 1380 o 1280.

Si partes de cero, la guía Contabo paso a paso cubre la instalación completa desde el SSH inicial.

En producción: lo que estas plantillas no cubren

Son intencionadamente mínimas. Para uso prod long-term, prevé:

• Backup regular de /etc/wireguard/
• Rotación de claves cada 12-18 meses
• Monitoring vía Prometheus + wireguard_exporter (ver guía monitoring)
• Fail2ban en puerto UDP 51820 si ves intentos de port scan
• Límite por peer vía tc (Linux traffic control)

Y sobre todo: nunca commitees un wg0.conf real en repo, ni privado.

Para profundizar

Si quieres entender por qué WireGuard es más rápido que OpenVPN a CPU equivalente, comparativa técnica detallada con benchmarks iperf3 reales sobre Contabo, kernel module vs userspace y perfil batería iPhone.

Y para la parte anti-fuga, la guía kill switch Linux iptables + systemd muestra cómo garantizar cero fugas incluso si WireGuard crashea.

Todas las plantillas anteriores están en uso aquí desde hace 14 meses sobre Contabo VPS S a 4,99 €/mes (/go/contabo). Cero outage de túnel no planificado.