¿Está WireGuard listo para producción? La respuesta no es el protocolo

La gente pregunta si WireGuard está listo para producción, lo que suena a una pregunta sobre criptografía y en realidad es una pregunta sobre su entorno. El protocolo lleva años siendo revisado; al despliegue todavía le toca responder si sus redes transportan su tráfico, quién inscribe y retira dispositivos y quién aplica parches al paquete en ambos extremos. Esas respuestas difieren entre dos servidores en un rack y mil portátiles. El protocolo es el mismo en ambos casos; las operaciones no.

La pregunta detrás de la pregunta

Lo que la gente suele querer saber es si puede comprometerse con un diseño que no la deje en evidencia dentro de seis meses. Es una pregunta de despliegue con cuatro partes, y cada parte puede fallar con independencia de las demás. Responder bien tres de ellas no compensa la cuarta.

Una advertencia antigua sobre una instantánea previa al lanzamiento es un hecho sobre esa instantánea, no una etiqueta permanente en cada paquete posterior. Del mismo modo, ninguna entrada de blog puede declarar listo su combinación concreta de núcleo, cliente, red y personal. El trabajo consiste en hacer explícita la combinación y comprobarla.

Trate la preparación como un conjunto de puertas que o bien se superan o bien se registran como abiertas. Eso convierte una discusión en una lista de verificación con responsables. También hace visibles los puntos abiertos para quien firma la aprobación, en lugar de enterrarlos en un informe piloto.

Puerta uno: la ruta debe transportar UDP

WireGuard transporta su tráfico sobre UDP y documenta que no ofrece un modo TCP ni ofuscación de tráfico. Un diseño que depende de que parezca tráfico web corriente, o de cambiar el puerto para obtener comportamiento TCP, se apoya en una suposición que el software no respalda.

Así que la primera puerta es un estudio, no una prueba en una sola máquina. Enumere los entornos de acceso en los que sus usuarios trabajan de verdad, luego verifique la ruta UDP aprobada en cada uno y decida qué ocurre cuando no está disponible.

Una conexión que funciona desde la oficina no demuestra nada sobre una red de hotel, un cortafuegos de campus o un operador móvil que trata UDP de otra manera. Esos entornos son la razón por la que los despliegues de acceso remoto fallan después de un piloto exitoso. El piloto no estaba equivocado; era estrecho. Ampliarlo es la puerta.

Anote también el plan alternativo. Si la respuesta es que no hay plan alternativo, es una decisión que conviene declarar por adelantado en lugar de descubrirla durante un viaje de trabajo.

Puerta dos: alguien debe ser dueño de las claves

Los pares de WireGuard se autentican con claves, un par por participante. Es fácil de describir y exigente en operación, porque nada en el protocolo inscribe un dispositivo, rastrea quién tiene cada clave ni retira el acceso cuando se pierde un portátil. El protocolo supone que las claves ya son correctas, y la corrección es trabajo de alguien.

Nombre a la persona que inscribe un dispositivo, el registro que asocia una clave pública a una persona y un dispositivo, y el procedimiento de retirada. Si la retirada depende de recordar dónde se instalaron copias de un archivo de configuración, el procedimiento no está terminado.

Elija un dispositivo durante el piloto y retírelo de principio a fin. Ese ejercicio produce información más útil que otra prueba de conectividad, porque expone los huecos en sus registros.

Puerta tres: el paquete necesita un mantenedor

WireGuard puede llegar como implementación en el núcleo, como paquete de distribución o como cliente en espacio de usuario, y cada uno tiene su propia ruta de actualización. La pregunta operativa es cuál ejecuta, de dónde vino y quién aplica un aviso de seguridad.

Usamos WireGuard no es un inventario. No identifica el paquete que hay que parchear, la versión en la puerta de enlace ni a la persona capaz de revertir una actualización defectuosa.

Puerta cuatro: acepte la carga de trabajo, no el apretón de manos

Los criterios de aceptación deberían describir qué hacen los usuarios. Alcanzar una aplicación interna, resolver su nombre privado, recibir un rechazo hacia un destino no autorizado y seguir el comportamiento definido cuando el túnel está caído son todos observables, y un apretón de manos correcto no es ninguno de ellos.

Ejecute esas comprobaciones a través de un cambio de red, un reinicio del dispositivo y una ventana de mantenimiento de la puerta de enlace, porque es en esas transiciones donde se rompen los despliegues.

Guarde la evidencia junto a los criterios, incluido el estado local que la produjo:

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

Una prueba en verde en una red tranquila con un solo portátil es una observación inicial. No es una afirmación de fiabilidad, y tratarla como tal es cómo un diseño que funciona se convierte en un diseño en el que se confía.