Lea una configuración de WireGuard línea por línea, de Interface a Peer

La mayoría de las configuraciones de WireGuard rotas no se equivocan en un valor; ponen el valor correcto en el lado equivocado. Una clave privada pertenece a esta máquina, un peer lleva la clave pública de la otra máquina, y una dirección se sienta en el bloque de interface aunque describe dónde vive el túnel. Lea el archivo como dos direcciones que se encuentran y luego compruebe qué añadió encima el script auxiliar. El protocolo en sí tiene menos campos que el archivo, y los extra merece la pena conocerlos por separado.

Las claves de interface describen esta máquina

El bloque de interface guarda la identidad propia de este extremo. PrivateKey es esa identidad y nunca sale del host; la clave pública correspondiente se deriva de ella y es lo que enumeran los demás peers. ListenPort es donde este lado recibe los handshakes, así que dos clientes tras una misma dirección necesitan puertos distintos.

Address es la dirección del túnel a la que responde este host, escrita con una longitud de prefijo porque también es el origen que usará. Equivocar el prefijo aquí cambia qué destinos el host cree que están enlazados directamente, lo que produce fallos que parecen de enrutamiento y no de configuración.

Todo lo demás en un [Interface] bloque con un cliente real suele añadirlo wg-quick: DNS, MTU, Table, y las líneas de gancho. No son campos del protocolo, y una instalación wg desnuda los ignora por completo.

Cada entrada de peer describe un lado más

Un [Peer] bloque es la parte remota. PublicKey es la clave derivada de esa parte, nunca su clave privada, y PresharedKey es un secreto extra opcional que ambos lados deben tener idéntico. Endpoint es adónde enviar, y PersistentKeepalive pide a este host que envíe un paquete tras el intervalo cuando no sale nada más.

Dos errores explican la mayor parte de la confusión aquí. Copiar tu propia clave privada en un bloque peer hace que los dos extremos compartan una identidad, y el handshake falla de una forma que se registra mal. Dejar Endpoint fuera en un cliente suele ser intencionado, porque el servidor aprende la dirección del handshake entrante; dejarlo fuera en un servidor que debe iniciar no lo es. Recuerda también que keepalive mantiene abierta una asignación NAT, y no mejora el rendimiento ni reduce la latencia, así que treinta segundos de paquetes extra no compran nada cuando el tráfico ya fluye.

AllowedIPs es enrutamiento, no una lista de permisos

AllowedIPs es el enrutamiento por clave criptográfica de WireGuard. De salida, decide qué peer recibe un paquete según su destino. De entrada, decide si se acepta un paquete que llega de ese peer según su origen. El mismo campo hace ambas tareas, por eso no es una lista de control de acceso ni una lista de sitios permitidos.

Un AllowedIPs estrecho en el servidor para un cliente significa que el servidor solo aceptará paquetes que declaren esos orígenes y solo enviará esos destinos a ese cliente. Amplía un lado sin ampliar el otro y obtendrás un túnel que sube y no pasa nada.

Qué añade wg-quick alrededor del protocolo

wg-quick lee el mismo archivo y realiza los pasos de red que el protocolo deja al sistema operativo. Asigna la dirección de la interfaz, añade rutas derivadas de AllowedIPs, escribe la configuración del resolutor y ejecuta las órdenes de gancho en orden.

Esa capa explica la asimetría clásica. Un archivo con 0.0.0.0/0 y una línea DNS da al cliente una ruta por defecto y un resolutor, y no hace absolutamente nada a las reglas de reenvío ni de NAT del servidor. Esas pertenecen a la configuración del propio servidor, y ningún archivo de cliente puede aportarlas.

Mantén un solo propietario del archivo. Editarlo a mano mientras SaveConfig está activado significa que tu edición desaparece la próxima vez que la interfaz baje, y la interfaz no te dirá que ha pasado.

Comprueba el estado aplicado, no el archivo

El archivo es una intención. El estado aplicado es lo que mantiene el núcleo, y divergen siempre que un auxiliar, un drop-in o un gancho ha editado algo tras la activación.

Lee el estado vivo y el direccionamiento juntos y luego compara ambos con lo que escribiste:

sudo wg show
ip -4 addr show dev wg0
ip -4 route show dev wg0
grep -v "^#" /etc/wireguard/wg0.conf

Si la lista de peers está vacía, la interfaz se creó sin que se aplicara su configuración. Si existen direcciones y rutas pero los contadores siguen a cero, el archivo se cargó y el handshake falla, lo que es un problema de clave o de extremo y no de orden de secciones. Compara las dos vistas antes de editar, porque la diferencia entre ellas suele ser el fallo real.