Está WireGuard listo para produción? A resposta non é o protocolo

A xente pregunta se WireGuard está listo para produción, o que soa a unha pregunta sobre criptografía e en realidade é unha pregunta sobre o seu contorno. O protocolo leva anos a ser revisado; ao despregamento aínda lle toca responder se as súas redes transportan o seu tráfico, quen inscribe e retira dispositivos e quen aplica parches ao paquete nos dous extremos. Esas respostas difiren entre dous servidores nun rack e mil portátiles. O protocolo é o mesmo en ambos os casos; as operacións non.

A pregunta detrás da pregunta

O que a xente adoita querer saber é se pode comprometerse cun deseño que non a deixe en evidencia dentro de seis meses. É unha pregunta de despregamento con catro partes, e cada parte pode fallar con independencia das demais. Responder ben tres delas non compensa a cuarta.

Un aviso antigo sobre unha instantánea previa ao lanzamento é un feito sobre esa instantánea, non unha etiqueta permanente en cada paquete posterior. Do mesmo xeito, ningunha entrada de blog pode declarar listo a súa combinación concreta de núcleo, cliente, rede e persoal. O traballo consiste en facer explícita a combinación e comprobala.

Trate a preparación como un conxunto de portas que ou ben se superan ou ben se rexistran como abertas. Iso converte unha discusión nunha lista de verificación con responsables. Tamén fai visibles os puntos abertos para quen asina a aprobación, en lugar de enterralos nun informe piloto.

Porta un: a ruta debe transportar UDP

WireGuard transporta o seu tráfico sobre UDP e documenta que non ofrece un modo TCP nin ofuscación de tráfico. Un deseño que depende de que pareza tráfico web corrente, ou de cambiar o porto para obter comportamento TCP, apóiase nunha suposición que o software non admite.

Así que a primeira porta é un estudo, non unha proba nunha soa máquina. Enumere os contornos de acceso nos que os seus usuarios traballan de verdade, logo verifique a ruta UDP aprobada en cada un e decida que ocorre cando non está dispoñible.

Unha conexión que funciona desde a oficina non demostra nada sobre unha rede de hotel, un cortalumes de campus ou un operador móbil que trata UDP doutro xeito. Eses contornos son a razón pola que os despregamentos de acceso remoto fallan despois dun piloto exitoso. O piloto non estaba equivocado; era estreito. Amplialo é a porta.

Anote tamén o plan alternativo. Se a resposta é que non hai plan alternativo, é unha decisión que cómpre declarar por adiantado en lugar de descubrila durante unha viaxe de traballo.

Porta dous: alguén debe ser dono das claves

Os pares de WireGuard autentícanse con claves, un par por participante. É fácil de describir e esixente en operación, porque nada no protocolo inscribe un dispositivo, rastrexa quen ten cada clave nin retira o acceso cando se perde un portátil. O protocolo supón que as claves xa son correctas, e a corrección é traballo de alguén.

Nomee a persoa que inscribe un dispositivo, o rexistro que asocia unha clave pública a unha persoa e a un dispositivo, e o procedemento de retirada. Se a retirada depende de recordar onde se instalaron copias dun ficheiro de configuración, o procedemento non está rematado.

Escolla un dispositivo durante o piloto e retíreo de principio a fin. Ese exercicio produce información máis útil que outra proba de conectividade, porque expón os ocos nos seus rexistros.

Porta tres: o paquete necesita un mantedor

WireGuard pode chegar como implementación no núcleo, como paquete de distribución ou como cliente no espazo de usuario, e cada un ten a súa propia ruta de actualización. A pregunta operativa é cal executa, de onde veu e quen aplica un aviso de seguridade.

Usamos WireGuard non é un inventario. Non identifica o paquete que hai que parchear, a versión na pasarela nin a persoa capaz de reverter unha actualización defectuosa.

Porta catro: acepte a carga de traballo, non o aperto de mans

Os criterios de aceptación deberían describir que fan os usuarios. Alcanzar unha aplicación interna, resolver o seu nome privado, recibir un rexeitamento nun destino non autorizado e seguir o comportamento definido cando o túnel está caído son todos observables, e un aperto de mans correcto non é ningún deles.

Execute esas comprobacións a través dun cambio de rede, un reinicio do dispositivo e unha xanela de mantemento da pasarela, porque é nesas transicións onde se rompen os despregamentos.

Garde a evidencia xunto aos criterios, incluído o estado local que a produciu:

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

Unha proba en verde nunha rede tranquila cun só portátil é unha observación inicial. Non é unha afirmación de fiabilidade, e tratala como tal é como un deseño que funciona se converte nun deseño no que se confía.