Skriv en VPN-designbrief, som nogen faktisk kan gennemgå

De fleste designgennemgange går i stå ved det første spørgsmål, fordi anmodningen beskriver et produkt og ikke en beslutning. En brief, der navngiver flowene, ejerne og fejlopførslen, kan besvares på ét møde. En brief, der siger byg en sikker VPN, kan slet ikke besvares. Gå gennem de seks kontroller nedenfor, før du sender noget, og gennemgangen bliver en sammenligning i stedet for en debat.

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

En beslutning har alternativer og en observation, der ville vælge mellem dem. Hvis du ikke kan navngive, hvad du ville se på for at vælge et, er spørgsmålet stadig et ønske. Skriv alternativerne ned først, selv om listen kun har to punkter. Skriv derefter det kompromis, der adskiller dem.

Et ønske har også en tendens til at skjule publikum. Sig, hvem der skal godkende designet, fordi den samme brief læses forskelligt af en netværksejer, en sikkerhedsanmelder og en økonomisk godkender.

Stop her, hvis svaret er ingen, fordi en beslutning uden ejer vil blive lavet om af den, der klager højest. Det er et styringsproblem og ikke et designproblem.

Dernæst, navngiv flowene og afvisningerne

List kilden, destinationen og applikationen for hvert flow, der skal virke. List derefter de flow, der skal blive ved med at fejle, fordi et design, der stiltiende tillader dem, har ændret kravet uden at sige det. Adresseoverlap og opstrøms nåbarhed hører til på denne liste som begrænsninger og ikke som overraskelser.

Vær konkret om retningen. Et sted, der må starte forbindelser til hovedkvarteret, er et andet design end et, der må acceptere dem, og forskellen ses i hver regel, du skriver bagefter.

Bemærk også klienterne og deres administrationstilstand, fordi en administreret enhed med en agent kan gøre ting, som en medbragt bærbar computer ikke kan.

Hold listen kort nok til at teste. Ti flows, du kan verificere, er bedre end fyrre, du ikke kan.

Kontrol 3: adskil fakta fra antagelser

Markér hvert udsagn, du har verificeret, og markér dem, du ikke har. Offentlig adressering, tilgængelig gennemstrømning og administratoradgang er de tre antagelser, der oftest ændrer svaret. Hvis en af dem er ukendt, så sig, hvordan designet ændrer sig, når det viser sig den ene eller den anden vej.

Et illustrativt netværk er fint, så længe det er mærket. Problemet er en hypotetisk filial, der stiltiende får et andet uplink eller en offentlig adresseblok, som den aldrig har haft.

Verificér den antagelse, du kan kontrollere, før gennemgangen, fordi én målt kendsgerning fjerner en hel gren af diskussionen.

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 fejlkontrakten

Sig, hvad der sker, når tunnelen er nede, og vær tydelig om de to forskellige løfter. At genskabe nye forbindelser efter en genopkobling er let at love. At bevare sessioner, der allerede var etableret gennem en fejl, er et meget stærkere krav, og det begrænser teknologivalget.

Beslut derefter fallback: blokér trafikken, send den ad en anden godkendt vej, eller gør noget andet for hver applikation. Et stille fallback til en direkte vej er en designbeslutning, selv når ingen har skrevet den ned.

Tilføj genopretningsmålet i klart sprog, såsom hvor længe et sted må køre nedgraderet, og hvem der erklærer hændelsen.

Kontrol 5 og 6: vælg sømmen og registrér ændringen

Vælg én søm at diskutere, fordi en gennemgang, der prøver at afgøre alt, ikke afgør noget. Routing, autorisation og kryptering er tre forskellige sømme, og en brief bør sige, hvilken af dem spørgsmålet handler om. RFC 4301 er en nyttig påmindelse her, fordi den adskiller politiske beslutninger, beskyttet trafik og sikkerhedsassociationer i stedet for at behandle dem som ét objekt.

Registrér derefter, hvad der ændrede sig efter beslutningen, inklusive de reviderede antagelser. Den registrering er det, der gør den næste gennemgang kortere.

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

En brief, der består alle seks kontroller, giver et spørgsmål med et svar: designet opfylder de angivne flows og fejlkontrakten, eller en navngivet begrænsning forhindrer det. Når begrænsningen ændrer sig senere, viser registreringen, hvilken beslutning der skal genbesøges, og hvilken der kan stå. Det gør øvelsen genbrugelig i stedet for en enkeltstående diskussion.