Escriviu un informe de disseny de VPN que algú pugui revisar de debò

La majoria de revisions de disseny s'encallen a la primera pregunta, perquè la petició descriu un producte i no una decisió. Un informe que anomena els fluxos, els responsables i el comportament davant de fallades es pot respondre en una sola reunió. Un informe que diu construïu una VPN segura no es pot respondre de cap manera. Passeu per les sis comprovacions següents abans d'enviar res, i la revisió es converteix en una comparació en lloc d'un debat.

Primer, la pregunta és una decisió o un desig

Una decisió té alternatives i una observació que triaria entre elles. Si no podeu anomenar què miraríeu per triar-ne una, la pregunta encara és un desig. Escriviu primer les alternatives, encara que la llista només tingui dos elements. Després escriviu el compromís que les separa.

Un desig també tendeix a amagar el públic. Digueu qui ha d'aprovar el disseny, perquè el mateix informe es llegeix de manera diferent per a un responsable de xarxa, un revisor de seguretat i un aprovador financer.

Atureu-vos aquí si la resposta és ningú, perquè una decisió sense propietari serà refeta per qui es queixi més fort. Això és un problema de governança, no un problema de disseny.

Segon, anomeneu els fluxos i les denegacions

Enumereu l'origen, la destinació i l'aplicació de cada flux que ha de funcionar. Després enumereu els fluxos que han de continuar fallant, perquè un disseny que els permet en silenci ha canviat el requisit sense dir-ho. El solapament d'adreces i l'abast cap amunt pertanyen a aquesta llista com a restriccions i no com a sorpreses.

Sigueu concrets sobre la direcció. Una seu que pot iniciar connexions a la central és un disseny diferent d'una que les pot acceptar, i la diferència apareix en cada regla que escriviu després.

Anoteu també els clients i el seu estat de gestió, perquè un dispositiu gestionat amb un agent pot fer coses que un portàtil portat per l'usuari no pot.

Manteniu la llista prou curta per provar-la. Deu fluxos que podeu verificar valen més que quaranta que no podeu.

Comprovació 3: separeu els fets de les suposicions

Marqueu cada afirmació que hàgiu verificat i marqueu les que no. L'adreçament públic, el cabal disponible i l'accés d'administrador són les tres suposicions que més sovint canvien la resposta. Si una d'elles és desconeguda, digueu com canvia el disseny quan resulti en qualsevol dels dos sentits.

Una xarxa il·lustrativa està bé sempre que estigui etiquetada. El problema és una branca hipotètica que adquireix en silenci un segon enllaç ascendent o un bloc d'adreces públiques que mai no havia tingut.

Verifiqueu la suposició que pugueu comprovar abans de la revisió, perquè un sol fet mesurat elimina una branca sencera de discussió.

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

Quart, escriviu el contracte de fallada

Digueu què passa quan el túnel està caigut i sigueu explícits sobre les dues promeses diferents. Restablir connexions noves després d'una reconnexió és fàcil de prometre. Preservar les sessions que ja estaven establertes durant una fallada és un requisit molt més fort i limita l'elecció de tecnologia.

Després decidiu el pla alternatiu: bloquegeu el trànsit, encamineu-lo per una altra via aprovada o feu una cosa diferent per aplicació. Una tornada silenciosa a un camí directe és una decisió de disseny encara que ningú l'hagi escrita.

Afegiu l'objectiu de recuperació en llenguatge planer, com quant de temps pot operar una seu en estat degradat i qui declara l'incident.

Comprovació 5 i 6: trieu la costura i registreu el canvi

Trieu una costura per discutir, perquè una revisió que intenta resoldre-ho tot no resol res. L'encaminament, l'autorització i el xifratge són tres costures diferents, i l'informe ha de dir de quina va la pregunta. RFC 4301 és un recordatori útil aquí, perquè separa les decisions de política, el trànsit protegit i les associacions de seguretat en lloc de tractar-les com un sol objecte.

Després registreu què va canviar després de la decisió, incloent-hi les suposicions revisades. Aquest registre és el que fa la propera revisió més curta.

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

Un informe que supera les sis comprovacions produeix una pregunta amb resposta: el disseny compleix els fluxos declarats i el contracte de fallada, o una restricció anomenada ho impedeix. Quan la restricció canvia més endavant, el registre mostra quina decisió s'ha de revisar i quina pot quedar-se. Això fa que l'exercici sigui reutilitzable i no un debat puntual.