Skriv en VPN-designbrief som noen faktisk kan gjennomgå

De fleste designgjennomganger stopper på det første spørsmålet, fordi forespørselen beskriver et produkt og ikke en beslutning. En brief som navngir strømmene, eierne og feilatferden, kan besvares i ett møte. En brief som sier bygg en sikker VPN kan ikke besvares i det hele tatt. Gå gjennom de seks kontrollene nedenfor før du sender noe, og gjennomgangen blir en sammenligning i stedet for en debatt.

Først, er spørsmålet en beslutning eller et ønske

En beslutning har alternativer og en observasjon som ville velge mellom dem. Hvis du ikke kan navngi hva du ville se på for å velge ett, er spørsmålet fortsatt et ønske. Skriv alternativene ned først, selv om listen bare har to punkter. Skriv deretter kompromisset som skiller dem.

Et ønske har også en tendens til å skjule publikum. Si hvem som må godkjenne designet, fordi den samme brieffen leses forskjellig av en nettverkseier, en sikkerhetsgjennomgåer og en finansgodkjenner.

Stopp her hvis svaret er ingen, fordi en beslutning uten eier vil bli gjort på nytt av den som klager høyest. Det er et styringsproblem og ikke et designproblem.

Deretter, navngi strømmene og avvisningene

List opp kilden, destinasjonen og applikasjonen for hver strøm som må fungere. Deretter lister du opp strømmene som må fortsette å feile, fordi et design som stilltiende tillater dem, har endret kravet uten å si det. Adresseoverlapp og oppstrøms nåbarhet hører hjemme på denne listen som begrensninger og ikke som overraskelser.

Vær konkret om retningen. Et sted som kan starte forbindelser til hovedkvarteret, er et annet design enn et som kan akseptere dem, og forskjellen vises i hver regel du skriver etterpå.

Legg merke til klientene og deres administrasjonstilstand også, fordi en administrert enhet med en agent kan gjøre ting en medbrakt bærbar ikke kan.

Hold listen kort nok til å testes. Ti strømmer du kan verifisere, er bedre enn førti du ikke kan.

Kontroll 3: skill fakta fra antakelser

Merk hver påstand du har verifisert, og merk dem du ikke har. Offentlig adressering, tilgjengelig gjennomstrømning og administrator tilgang er de tre antakelsene som oftest endrer svaret. Hvis en av dem er ukjent, si hvordan designet endres når den viser seg i den ene eller andre retningen.

Et illustrativt nettverk er greit så lenge det er merket. Problemet er en hypotetisk filial som stilltiende får en annen oppstrømsforbindelse eller en offentlig adresseblokk den aldri har hatt.

Verifiser antakelsen du kan kontrollere før gjennomgangen, fordi ett målt faktum fjerner en hel gren av diskusjonen.

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

For det fjerde, skriv feilkontrakten

Si hva som skjer når tunnelen er nede, og vær tydelig på de to forskjellige løftene. Å gjenopprette nye forbindelser etter en gjenoppkobling er lett å love. Å bevare økter som allerede var etablert gjennom en feil, er et mye sterkere krav, og det begrenser teknologivalget.

Deretter bestemmer du reserveveien: blokker trafikken, rut den via en annen godkjent vei, eller gjør noe annet per applikasjon. En stille tilbakefall til en direkte vei er en designbeslutning selv når ingen har skrevet den ned.

Legg til gjenopprettingsmålet i klart språk, for eksempel hvor lenge et sted kan drives degradert, og hvem som erklærer hendelsen.

Kontroll 5 og 6: velg sømmen og registrer endringen

Velg én søm å diskutere, fordi en gjennomgang som prøver å avgjøre alt, ikke avgjør noe. Ruting, autorisasjon og kryptering er tre forskjellige sømmer, og brieffen bør si hvilken av dem spørsmålet gjelder. RFC 4301 er en nyttig påminnelse her, fordi den skiller policybeslutninger, beskyttet trafikk og sikkerhetsassosiasjoner i stedet for å behandle dem som ett objekt.

Registrer deretter hva som endret seg etter beslutningen, inkludert antakelsene som ble revidert. Den registreringen er det som gjør den neste gjennomgangen kortere.

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

En brief som består alle seks kontrollene, gir et spørsmål med et svar: designet oppfyller de angitte strømmene og feilkontrakten, eller en navngitt begrensning forhindrer det. Når begrensningen endres senere, viser registreringen hvilken beslutning som må vurderes på nytt, og hvilken som kan stå. Det gjør øvelsen gjenbrukbar i stedet for en engangsdebatt.