Clave privada aquí, clave pública allá: las claves de WireGuard
Tu clave privada se queda en tu dispositivo; la entrada de peer contiene la clave pública del otro extremo. Comparte solo la mitad pública y da a cada dispositivo su propia identidad.
La mayoría de los fallos de WireGuard montados a mano se reducen a qué clave fue a parar a dónde. La sección de interfaz lleva la clave privada del dispositivo que estás configurando, mientras que una sección de peer lleva la clave pública de la máquina del otro extremo. Intercambiar esas mitades, o pegar la equivocada, produce un handshake que nunca se completa y un registro que nunca nombra una clave. Haz las cuatro comprobaciones siguientes en orden antes de tocar AllowedIPs o DNS.
Dos claves, dos direcciones
Una clave privada pertenece exactamente a un dispositivo y se queda en la sección de interfaz de ese dispositivo. Su mitad pública es lo que necesita cualquier otro peer para reconocer el dispositivo, y las herramientas la derivan en lugar de inventarla. En el servidor, la clave pública de tu dispositivo aparece como una entrada de peer; en tu dispositivo, ese papel lo ocupa la clave pública del servidor. Leer una configuración en voz alta con esos términos atrapa la mayoría de las confusiones antes de que lleguen a un handshake.
El comando wg imprime lo que la interfaz local está usando en realidad, incluidas las dos claves públicas. Eso lo convierte en la forma más rápida de separar un error de configuración de un problema de conectividad:
wg show
wg show interfacesLa primera salida lista cada peer con su clave pública, el extremo que usó por última vez y la antigüedad de su último handshake. Una antigüedad de handshake «nunca» en un lado y reciente en el otro apunta a una clave que solo un extremo aceptó. El segundo comando nombra las interfaces que puedes inspeccionar más a fondo.
Qué compartir y qué no compartir nunca
Una clave pública está pensada para entregarse, aunque sigue identificando una relación de dispositivo, por eso enviarla al administrador que la pidió no es lo mismo que publicarla. Una clave privada no sale nunca del dispositivo que la generó. Un perfil exportado o un código QR contiene toda la configuración, incluida esa clave privada, así que ninguno de los dos es seguro para hacerlo circular, y esconder el texto dentro de una imagen no cambia nada. Las claves precompartidas son opcionales e igual de secretas, y ambos extremos deben llevar el mismo valor o el handshake se detiene en esa etapa.
Otra distinción merece decirse sin rodeos: un extremo es una dirección y un puerto, nunca una clave. Pegar una clave pública en el campo del extremo, o una dirección en un campo de clave, produce un perfil que se analiza y luego no hace nada. Las herramientas no lo detectarán, porque ambos campos son solo cadenas. El inicio rápido de WireGuard muestra la cadena de generación y derivación en una línea.
Un dispositivo, una entrada de peer
Donde el servicio lo permita, cada dispositivo debe llevar su propia identidad de peer. Pegar el perfil completo de un portátil en un teléfono difumina qué dispositivo tiene esa identidad en el servidor y hace más difícil revocar un solo teléfono perdido. Si se filtra una clave privada, elimina la autorización antigua del peer en el servidor y consigue un reemplazo. Borrar el archivo local no elimina la entrada del servidor, y una clave de cliente nueva no ayuda a nadie hasta que el servidor conozca su mitad pública.
Mantén la correspondencia de dispositivo a clave pública junto a la lista de direcciones. Esa lista es lo que convierte una revocación en una tarea de dos minutos en lugar de una tarde entera.
Qué sigue fallando después del handshake
Los pares de claves identifican peers; no deciden el comportamiento de la red. AllowedIPs asocia rangos de direcciones con un peer, y el cliente o la herramienta de configuración gestiona las rutas alrededor. El síntoma suele decir qué capa hay que abrir a continuación:
| What you see | Which key problem it usually means | Where to look first |
|---|---|---|
| Handshake age stays at never on both ends | Peer public key missing, or an endpoint pointing at nothing | wg show, then the endpoint value |
| Handshake completes on one side only | The two ends hold different public keys for each other | wg show on both hosts |
| Handshake works, then no traffic | AllowedIPs or routes rather than keys | wg show and the route table |
| Worked until a key was regenerated | The peer entry still holds the old public key | Compare both public keys, then update the peer |
El DNS puede fallar después de que ambos peers se autentiquen correctamente, y una aplicación puede fallar mientras el túnel está sano, así que un handshake que funciona no es el final del diagnóstico. Las claves tampoco dicen nada sobre la práctica de registro de un operador ni sobre si un sitio web reconoce tu cuenta, y esas preguntas pertenecen a otro sitio. Pasa a las capas de red cuando las cuatro comprobaciones pasen, porque una clave ausente no es un problema de enrutamiento disfrazado.