Schrijf een VPN-ontwerpbrief die iemand echt kan beoordelen

De meeste ontwerpbeoordelingen lopen vast bij de eerste vraag, omdat het verzoek een product beschrijft en geen beslissing. Een brief die de stromen, de eigenaren en het faalgedrag benoemt, kan in één vergadering worden beantwoord. Een brief die zegt bouw een veilige VPN kan helemaal niet worden beantwoord. Werk de zes controles hieronder door voordat je iets verstuurt, en de beoordeling wordt een vergelijking in plaats van een debat.

Ten eerste, is de vraag een beslissing of een wens

Een beslissing heeft alternatieven en een observatie die daartussen zou kiezen. Als je niet kunt benoemen waar je naar zou kijken om er één te kiezen, is de vraag nog steeds een wens. Schrijf de alternatieven eerst op, ook als de lijst maar twee items heeft. Schrijf daarna de afweging op die ze scheidt.

Een wens verbergt ook graag het publiek. Zeg wie het ontwerp moet goedkeuren, omdat dezelfde brief anders wordt gelezen door een netwerkeigenaar, een beveiligingsbeoordelaar en een financiële goedkeurder.

Stop hier als het antwoord niemand is, want een beslissing zonder eigenaar wordt opnieuw gemaakt door wie het hardst klaagt. Dat is een bestuursprobleem en geen ontwerpprobleem.

Ten tweede, benoem de stromen en de weigeringen

Noem de bron, bestemming en toepassing voor elke stroom die moet werken. Noem daarna de stromen die moeten blijven falen, want een ontwerp dat ze stilzwijgend toestaat, heeft de eis gewijzigd zonder dat te zeggen. Adresoverlap en bereikbaarheid stroomopwaarts horen in deze lijst als beperkingen en niet als verrassingen.

Wees concreet over de richting. Een locatie die verbindingen naar het hoofdkantoor mag starten, is een ander ontwerp dan een die ze mag accepteren, en het verschil is zichtbaar in elke regel die u daarna schrijft.

Noteer ook de clients en hun beheerstatus, want een beheerd apparaat met een agent kan dingen doen die een zelf meegebrachte laptop niet kan.

Houd de lijst kort genoeg om te testen. Tien stromen die u kunt verifiëren zijn beter dan veertig die u niet kunt.

Controle 3: scheid feiten van aannames

Markeer elke uitspraak die u hebt geverifieerd, en markeer degene die u niet hebt. Openbare adressering, beschikbare doorvoer en beheerderstoegang zijn de drie aannames die het antwoord het vaakst veranderen. Als een ervan onbekend is, zeg dan hoe het ontwerp verandert wanneer die zich in een van beide richtingen aandient.

Een illustratief netwerk is prima zolang het gelabeld is. Het probleem is een hypothetische vestiging die stilzwijgend een tweede uplink of een openbare adresblok krijgt die het nooit heeft gehad.

Verifieer de aanname die u kunt controleren voor de beoordeling, want één gemeten feit verwijdert een hele tak van discussie.

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

Ten vierde, schrijf het faalcontract

Zeg wat er gebeurt als de tunnel platligt, en wees expliciet over de twee verschillende beloften. Nieuwe verbindingen herstellen na een herverbinding is makkelijk te beloven. Sessies behouden die al waren opgezet tijdens een storing is een veel sterkere eis, en die beperkt de technologiekeuze.

Bepaal daarna de terugval: blokkeer het verkeer, leid het via een andere goedgekeurde weg, of doe iets anders per toepassing. Een stille terugval naar een directe route is een ontwerpbeslissing ook wanneer niemand die heeft opgeschreven.

Voeg het hersteldoel in duidelijke taal toe, zoals hoe lang een locatie in verzwakte staat mag werken, en wie het incident uitroept.

Controle 5 en 6: kies de naad en leg de wijziging vast

Kies één naad om over te discussiëren, want een beoordeling die alles probeert te beslechten, beslecht niets. Routing, autorisatie en versleuteling zijn drie verschillende naden, en een brief moet zeggen over welke de vraag gaat. RFC 4301 is hier een nuttige herinnering, omdat het beleidsbeslissingen, beschermd verkeer en beveiligingsassociaties scheidt in plaats van ze als één object te behandelen.

Leg daarna vast wat er na de beslissing veranderde, inclusief de herziene aannames. Dat verslag is wat de volgende beoordeling korter maakt.

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

Een brief die alle zes controles doorstaat, levert een vraag met een antwoord op: het ontwerp voldoet aan de genoemde stromen en het faalcontract, of een benoemde beperking verhindert het. Wanneer de beperking later verandert, laat het verslag zien welke beslissing opnieuw moet worden bekeken en welke kan blijven staan. Dat maakt de oefening herbruikbaar in plaats van een eenmalig debat.