WireGuard est-il prêt pour la production ? La réponse n'est pas le protocole

On demande si WireGuard est prêt pour la production, ce qui ressemble à une question de cryptographie et est en réalité une question sur votre environnement. Le protocole est examiné depuis des années ; le déploiement doit encore répondre si vos réseaux transportent son trafic, qui enrôle et retire les appareils et qui corrige le paquet aux deux extrémités. Ces réponses diffèrent entre deux serveurs dans une baie et mille ordinateurs portables. Le protocole est le même dans les deux cas ; les opérations ne le sont pas.

La question derrière la question

Ce que les gens veulent savoir, c'est s'ils peuvent s'engager sur une conception qui ne les mettra pas dans l'embarras dans six mois. C'est une question de déploiement en quatre parties, et chaque partie peut échouer indépendamment des autres. Bien répondre à trois d'entre elles ne compense pas la quatrième.

Un ancien avertissement sur un instantané de préversion est un fait sur cet instantané, pas une étiquette permanente sur chaque paquet ultérieur. De même, aucun billet de blog ne peut déclarer prête votre combinaison précise de noyau, de client, de réseau et de personnel. Le travail consiste à rendre la combinaison explicite et à la vérifier.

Traitez la maturité comme un ensemble de portes que vous passez ou que vous consignez comme ouvertes. Cela transforme un débat en liste de contrôle avec des responsables. Cela rend aussi les points ouverts visibles pour celui qui approuve, au lieu de les enfouir dans un rapport de pilote.

Porte un : le chemin doit transporter UDP

WireGuard transporte son trafic sur UDP et documente qu'il ne fournit ni mode TCP ni brouillage du trafic. Une conception qui compte sur une apparence de trafic web ordinaire, ou sur un changement de port pour obtenir un comportement TCP, repose sur une hypothèse que le logiciel ne prend pas en charge.

La première porte est donc un relevé, pas un test sur une seule machine. Listez les environnements d'accès dans lesquels vos utilisateurs travaillent réellement, puis vérifiez le chemin UDP approuvé dans chacun et décidez de ce qui se passe lorsqu'il est indisponible.

Une connexion qui fonctionne depuis le bureau ne prouve rien pour un réseau d'hôtel, un pare-feu de campus ou un opérateur mobile qui traite UDP autrement. Ces environnements sont la raison pour laquelle les déploiements d'accès distant échouent après un pilote réussi. Le pilote n'était pas faux ; il était étroit. L'élargir, voilà la porte.

Écrivez aussi le repli. Si la réponse est qu'il n'y a pas de repli, c'est une décision qui mérite d'être énoncée à l'avance plutôt que découverte pendant un déplacement professionnel.

Porte deux : quelqu'un doit posséder les clés

Les pairs WireGuard s'authentifient par clés, une paire par participant. C'est simple à décrire et exigeant à exploiter, car rien dans le protocole n'enrôle un appareil, ne suit qui détient quelle clé ni ne retire l'accès lorsqu'un ordinateur portable est perdu. Le protocole suppose que les clés sont déjà correctes, et l'exactitude est le travail de quelqu'un.

Nommez la personne qui enrôle un appareil, l'enregistrement qui associe une clé publique à une personne et à un appareil, et la procédure de retrait. Si le retrait dépend du souvenir de l'endroit où des copies d'un fichier de configuration ont été installées, la procédure n'est pas terminée.

Choisissez un appareil pendant le pilote et retirez-le de bout en bout. Cet exercice produit des informations plus utiles qu'un autre test de connectivité, car il expose les lacunes de vos registres.

Porte trois : le paquet a besoin d'un mainteneur

WireGuard peut arriver comme implémentation dans le noyau, comme paquet de distribution ou comme client en espace utilisateur, et chacun a son propre chemin de mise à jour. La question opérationnelle est laquelle vous exécutez, d'où elle vient et qui applique un avis de sécurité.

Nous utilisons WireGuard n'est pas un inventaire. Cela n'identifie ni le paquet à corriger, ni la version sur la passerelle, ni la personne capable de revenir sur une mauvaise mise à jour.

Porte quatre : acceptez la charge de travail, pas la poignée de main

Les critères d'acceptation devraient décrire ce que font les utilisateurs. Atteindre une application interne, résoudre son nom privé, être refusé vers une destination non autorisée et suivre le comportement défini lorsque le tunnel est en panne sont tous observables, et une poignée de main réussie n'en fait partie.

Faites passer ces contrôles par un changement de réseau, un redémarrage d'appareil et une fenêtre de maintenance de la passerelle, car c'est dans ces transitions que les déploiements cassent.

Conservez les preuves à côté des critères, y compris l'état local qui les a produites :

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

Un test au vert sur un réseau calme avec un seul ordinateur portable est une observation de départ. Ce n'est pas une affirmation de fiabilité, et la traiter comme telle est la façon dont une conception qui fonctionne devient une conception à laquelle on fait confiance.