Rédigez un brief de conception VPN que quelqu’un peut vraiment relire

La plupart des revues de conception bloquent sur la première question, parce que la demande décrit un produit plutôt qu’une décision. Un brief qui nomme les flux, les responsables et le comportement en cas de panne se traite en une réunion. Un brief qui dit construisez un VPN sûr ne se traite pas du tout. Passez les six contrôles ci-dessous avant d’envoyer quoi que ce soit, et la revue devient une comparaison plutôt qu’un débat.

D’abord, la question est-elle une décision ou un souhait

Une décision a des alternatives et une observation qui choisirait entre elles. Si vous ne pouvez pas nommer ce que vous regarderiez pour en choisir une, la question reste un souhait. Écrivez d’abord les alternatives, même si la liste ne compte que deux éléments. Puis écrivez le compromis qui les sépare.

Un souhait a aussi tendance à cacher le public. Dites qui doit approuver la conception, car le même brief se lit différemment pour un responsable réseau, un relecteur sécurité et un approbateur financier.

Arrêtez-vous ici si la réponse est personne, car une décision sans propriétaire sera refaite par celui qui se plaint le plus fort. C’est un problème de gouvernance et non un problème de conception.

Ensuite, nommez les flux et les refus

Listez la source, la destination et l’application de chaque flux qui doit fonctionner. Listez ensuite les flux qui doivent continuer d’échouer, car une conception qui les autorise en silence a changé l’exigence sans le dire. Le chevauchement d’adresses et l’accessibilité en amont font partie de cette liste comme contraintes et non comme surprises.

Soyez précis sur la direction. Un site qui peut initier des connexions vers le siège est une conception différente de celui qui peut les accepter, et la différence apparaît dans chaque règle que vous écrivez ensuite.

Notez aussi les clients et leur état de gestion, car un appareil géré avec un agent peut faire des choses qu’un ordinateur portable apporté par l’utilisateur ne peut pas.

Gardez la liste assez courte pour être testée. Dix flux que vous pouvez vérifier valent mieux que quarante que vous ne pouvez pas.

Contrôle 3 : séparez les faits des hypothèses

Marquez chaque affirmation que vous avez vérifiée, et marquez celles que vous ne l’avez pas. L’adressage public, le débit disponible et l’accès administrateur sont les trois hypothèses qui changent le plus souvent la réponse. Si l’une d’elles est inconnue, dites comment la conception change lorsqu’elle se révèle dans un sens ou dans l’autre.

Un réseau illustratif convient tant qu’il est étiqueté. Le problème est une succursale hypothétique qui acquiert en silence un second lien amont ou un bloc d’adresses publiques qu’elle n’a jamais eu.

Vérifiez l’hypothèse que vous pouvez contrôler avant la revue, car un seul fait mesuré supprime une branche entière de discussion.

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

Quatrièmement, écrivez le contrat de panne

Dites ce qui se passe quand le tunnel est en panne, et soyez explicite sur les deux promesses différentes. Rétablir de nouvelles connexions après une reconnexion est facile à promettre. Préserver les sessions déjà établies à travers une panne est une exigence bien plus forte, et elle contraint le choix de technologie.

Décidez ensuite le repli : bloquer le trafic, le router par un autre chemin approuvé ou faire autre chose par application. Un repli silencieux vers un chemin direct est une décision de conception même quand personne ne l’a écrite.

Ajoutez l’objectif de rétablissement en langage clair, par exemple combien de temps un site peut fonctionner en mode dégradé, et qui déclare l’incident.

Contrôle 5 et 6 : choisissez la couture et consignez le changement

Choisissez une couture à débattre, car une revue qui tente de tout régler ne règle rien. Le routage, l’autorisation et le chiffrement sont trois coutures différentes, et un brief doit dire de laquelle la question parle. RFC 4301 est un rappel utile ici, car il sépare les décisions de politique, le trafic protégé et les associations de sécurité au lieu de les traiter comme un seul objet.

Consignez ensuite ce qui a changé après la décision, y compris les hypothèses révisées. C’est cette trace qui rend la revue suivante plus courte.

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

Un brief qui passe les six contrôles produit une question avec une réponse : la conception respecte les flux énoncés et le contrat de panne, ou une contrainte nommée l’empêche. Quand la contrainte change plus tard, la trace montre quelle décision doit être revue et laquelle peut rester. C’est ce qui rend l’exercice réutilisable plutôt qu’un débat unique.