És WireGuard llest per a producció? La resposta no és el protocol

La gent pregunta si WireGuard està llest per a producció, cosa que sona com una pregunta sobre criptografia i en realitat és una pregunta sobre el vostre entorn. El protocol s'ha revisat durant anys; el desplegament encara ha de respondre si les vostres xarxes transporten el seu transport, qui inscriu i retira dispositius i qui pedaça el paquet a les dues bandes. Aquestes respostes difereixen entre dos servidors en un bastidor i mil ordinadors portàtils. El protocol és el mateix en tots dos casos; les operacions no.

La pregunta darrere de la pregunta

El que la gent sol voler saber és si poden comprometre's amb un disseny que no els faci quedar malament d'aquí a sis mesos. És una pregunta de desplegament amb quatre parts, i cada part pot fallar independentment de les altres. Respondre bé tres d'elles no compensa la quarta.

Un avís antic sobre una instantània prèvia al llançament és un fet sobre aquella instantània, no una etiqueta permanent a cada paquet posterior. Igualment, cap entrada de blog pot declarar llesta la vostra combinació concreta de nucli, client, xarxa i personal. La feina és fer explícita la combinació i comprovar-la.

Tracteu la preparació com un conjunt de portes que o bé passeu o bé anoteu com a obertes. Això converteix una discussió en una llista de verificació amb responsables. També fa visibles els elements oberts per a qui signa l'aprovació, en lloc d'enterrar-los en un informe pilot.

Porta u: el camí ha de portar UDP

WireGuard transporta el seu trànsit sobre UDP i documenta que no ofereix un mode TCP ni ofuscació de trànsit. Un disseny que depèn que sembli trànsit web corrent, o de canviar el port per obtenir comportament TCP, es basa en una suposició que el programari no admet.

Així, la primera porta és un estudi, no una prova en una sola màquina. Llisteu els entorns d'accés on els vostres usuaris treballen realment, verifiqueu després el camí UDP aprovat a cadascun i decidiu què passa quan no està disponible.

Una connexió que funciona des de l'oficina no demostra res sobre una xarxa d'hotel, un tallafoc de campus o un operador mòbil que tracta UDP de manera diferent. Aquests entorns són la raó per la qual els desplegaments d'accés remot fallen després d'un pilot reeixit. El pilot no estava equivocat; era estret. Eixamplar-lo és la porta.

Anoteu també el pla de reserva. Si la resposta és que no hi ha pla de reserva, és una decisió que val la pena declarar per endavant en lloc de descobrir-la durant un viatge de feina.

Porta dos: algú ha de posseir les claus

Els parells de WireGuard s'autentiquen amb claus, una parella per participant. És fàcil de descriure i exigent operativament, perquè res al protocol inscriu un dispositiu, fa el seguiment de qui té cada clau ni retira l'accés quan es perd un ordinador portàtil. El protocol assumeix que les claus ja són correctes, i la correcció és feina d'algú.

Nomenar la persona que inscriu un dispositiu, el registre que associa una clau pública a una persona i un dispositiu, i el procediment de retirada. Si la retirada depèn de recordar on es van instal·lar còpies d'un fitxer de configuració, el procediment no està acabat.

Trieu un dispositiu durant el pilot i retireu-lo de punta a punta. Aquest exercici produeix informació més útil que una altra prova de connectivitat, perquè exposa els buits dels vostres registres.

Porta tres: el paquet necessita un mantenidor

WireGuard pot arribar com a implementació dins del nucli, com a paquet de distribució o com a client d'espai d'usuari, i cadascun té el seu propi camí d'actualització. La pregunta operativa és quin executeu, d'on ve i qui aplica un avís de seguretat.

Utilitzem WireGuard no és un inventari. No identifica el paquet que necessita pegats, la versió a la passarel·la ni la persona que pot desfer una actualització dolenta.

Porta quatre: accepteu la càrrega de feina, no l'encaixada de mans

Els criteris d'acceptació haurien de descriure què fan els usuaris. Arribar a una aplicació interna, resoldre el seu nom privat, rebre una denegació per a una destinació no autoritzada i seguir el comportament definit quan el túnel està caigut són tots observables, i una encaixada de mans reeixida no és cap d'ells.

Executeu aquestes comprovacions a través d'un canvi de xarxa, d'un reinici del dispositiu i d'una finestra de manteniment de la passarel·la, perquè és en aquestes transicions on es trenquen els desplegaments.

Guardeu les proves al costat dels criteris, inclòs l'estat local que les va produir:

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

Una prova verda en una xarxa tranquil·la amb un sol ordinador portàtil és una observació inicial. No és una afirmació de fiabilitat, i tractar-la com a tal és com un disseny que funciona es converteix en un disseny en què es confia.