Perfil de WireGuard copiado: por qué fallan ambos dispositivos

El túnel funcionaba en el portátil, así que el archivo de configuración pasó al teléfono y a la tableta, y ahora los handshakes van y vienen en los tres. Nada se escribió mal y la configuración del servidor no se editó. Un perfil de WireGuard no es una cuenta con contraseña que varios dispositivos puedan usar; es un par de claves, y solo la mitad pública identifica a un par. Copiar el archivo copia la identidad, así que el servidor ahora intenta mantener una única relación de punto final para varios dispositivos que afirman ser el mismo. Desde el lado del servidor no hay un segundo dispositivo que notar, solo un par cuya dirección no deja de moverse.

Empiece por el registro de handshakes de cada dispositivo

Abra el cliente en cada dispositivo y anote la hora del último handshake y el punto final actual antes de cambiar nada. En una configuración sana esos valores se mantienen estables mientras el dispositivo está en uso; con una identidad duplicada las marcas de tiempo se alternan, y el punto final registrado en el servidor puede describir un dispositivo distinto del que tiene el perfil. Esa alternancia es la firma, y explica por qué el síntoma parece una conectividad inestable y no un error de configuración. Los dispositivos no están rotos; se interrumpen unos a otros.

Haga la lectura en los propios dispositivos, para que cada observación quede ligada a una máquina concreta. Una marca de tiempo copiada de un chat de soporte pierde ese vínculo y después vale muy poco.

Confirme si dos dispositivos comparten una identidad

Compare las claves públicas, nunca las privadas. La clave pública se deriva de la privada, así que dos perfiles con la misma clave privada producen la misma clave pública y son indistinguibles para el servidor. Si dos dispositivos informan de la misma clave pública, la cuestión queda resuelta y ningún ajuste de keepalive ayudará. Dos claves distintas con handshakes inestables apuntan a otro lugar por completo, y por eso la comparación debe llegar antes de cualquier cambio.

wg show wg0 public-key
wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Estos comandos solo imprimen material público y contadores, que es todo lo que necesita una conversación de soporte. Una entrada de par en el servidor con una clave pública y un punto final que no deja de moverse entre dos redes es el resultado esperado de la duplicación, porque un paquete autenticado de una fuente nueva actualiza a dónde se envía el tráfico. Ese comportamiento es el protocolo funcionando como se diseñó, y por eso se confunde tan fácilmente con una avería de red.

Aprovisione una segunda identidad correctamente

Genere un par de claves nuevo en el dispositivo que lo necesita y después añada la clave pública resultante al servidor como un par separado con sus propias direcciones permitidas. La clave privada debe crearse en el dispositivo y quedarse allí; una clave generada en otro sitio y pegada ha pasado por al menos un lugar adicional, y ese viaje ahora forma parte de la historia de confianza.

umask 077
wg genkey > newdevice.key
wg pubkey < newdevice.key

El lado del servidor necesita la clave pública y una asignación de dirección permitida que no choque con el dispositivo original. Un perfil que conserva la dirección de túnel antigua mientras presenta una clave nueva produce un par que el servidor puede aceptar y luego enrutar mal, lo que es un fallo más sutil que un handshake rechazado. Compruebe la asignación de dirección antes de conectar, no después de la primera pérdida de paquetes desconcertante.

Retire el duplicado sin romper el original

Cuando la nueva identidad funcione, quite el perfil copiado de los alrededores del dispositivo original en lugar de borrar la entrada del servidor que el original todavía usa. Si la copia puede haberse expuesto, revóquela de inmediato y vuelva a emitirla; la comodidad no es razón para dejar un secreto compartido en circulación.

Un servicio gestionado que de verdad admita varios dispositivos por suscripción se lo dirá y emitirá credenciales separadas desde su propia interfaz. La duplicación manual de un perfil nunca es ese modelo, aunque la marca del servicio sugiera dispositivos ilimitados.

Pruebe ambos dispositivos por separado y juntos

Verifique cada dispositivo por su cuenta primero: handshake, contadores de transferencia que se mueven y un destino al que solo el túnel llega. Luego ejecute ambos a la vez y observe cómo ve el servidor los puntos finales; dos claves distintas deberían producir dos entradas de par estables en lugar de una que salta.

Guarde las claves públicas nuevas con las notas de despliegue y anote qué dispositivo tiene cuál. Sin esa lista, la siguiente persona que copie un perfil repetirá el mismo fallo, y los handshakes alternos volverán a culparse a la red.