Skriv en VPN-designbrief som någon faktiskt kan granska

De flesta designgranskningar fastnar på den första frågan, eftersom förfrågan beskriver en produkt och inte ett beslut. En brief som namnger flödena, ägarna och felbeteendet kan besvaras på ett möte. En brief som säger bygg ett säkert VPN kan inte besvaras alls. Gå igenom de sex kontrollerna nedan innan du skickar något, och granskningen blir en jämförelse i stället för en debatt.

Först, är frågan ett beslut eller en önskan

Ett beslut har alternativ och en observation som skulle välja mellan dem. Om du inte kan namnge vad du skulle titta på för att välja ett, är frågan fortfarande en önskan. Skriv ner alternativen först, även om listan bara har två punkter. Skriv sedan ner kompromissen som skiljer dem.

En önskan tenderar också att dölja publiken. Säg vem som måste godkänna designen, eftersom samma brief läses olika av en nätverksägare, en säkerhetsgranskare och en ekonomigodkännare.

Stanna här om svaret är ingen, eftersom ett beslut utan ägare görs om av den som klagar högst. Det är ett styrproblem och inte ett designproblem.

Därefter, namnge flödena och avvisningarna

Lista källan, destinationen och applikationen för varje flöde som måste fungera. Lista sedan de flöden som måste fortsätta att misslyckas, eftersom en design som tyst tillåter dem har ändrat kravet utan att säga det. Adressöverlapp och uppströms nåbarhet hör hemma i den här listan som begränsningar och inte som överraskningar.

Var konkret om riktningen. En plats som får starta anslutningar till huvudkontoret är en annan design än en som får ta emot dem, och skillnaden syns i varje regel du skriver efteråt.

Notera också klienterna och deras hanteringsstatus, eftersom en hanterad enhet med en agent kan göra saker som en medtagen bärbar dator inte kan.

Håll listan kort nog att testas. Tio flöden du kan verifiera är bättre än fyrtio du inte kan.

Kontroll 3: skilj fakta från antaganden

Markera varje påstående du har verifierat, och markera dem du inte har. Offentlig adressering, tillgänglig genomströmning och administratörsåtkomst är de tre antaganden som oftast ändrar svaret. Om ett av dem är okänt, säg hur designen ändras när det visar sig i ena eller andra riktningen.

Ett illustrativt nätverk är okej så länge det är märkt. Problemet är en hypotetisk filial som tyst får en andra uppströmsförbindelse eller ett offentligt adressblock som den aldrig har haft.

Verifiera antagandet du kan kontrollera före granskningen, eftersom ett uppmätt faktum tar bort en hel gren av diskussionen.

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

För det fjärde, skriv felkontraktet

Säg vad som händer när tunneln ligger nere, och var tydlig med de två olika löftena. Att återställa nya anslutningar efter en återanslutning är lätt att lova. Att bevara sessioner som redan var etablerade genom ett fel är ett mycket starkare krav, och det begränsar teknikvalet.

Bestäm sedan reservvägen: blockera trafiken, routa den via en annan godkänd väg, eller gör något annat per applikation. Ett tyst återfall till en direkt väg är ett designbeslut även när ingen har skrivit ner det.

Lägg till återställningsmålet i klart språk, till exempel hur länge en plats får drivas nedsatt, och vem som utlyser incidenten.

Kontroll 5 och 6: välj sömmen och registrera ändringen

Välj en söm att diskutera, eftersom en granskning som försöker avgöra allt inte avgör något. Ruttning, auktorisering och kryptering är tre olika sömmar, och briefen bör säga vilken av dem frågan gäller. RFC 4301 är en användbar påminnelse här, eftersom den skiljer policybeslut, skyddad trafik och säkerhetsassociationer i stället för att behandla dem som ett objekt.

Registrera sedan vad som ändrades efter beslutet, inklusive de reviderade antagandena. Den registreringen är det som gör nästa granskning kortare.

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

En brief som klarar alla sex kontroller ger en fråga med ett svar: designen uppfyller de angivna flödena och felkontraktet, eller så hindrar en namngiven begränsning det. När begränsningen ändras senare visar registreringen vilket beslut som måste ses över och vilket som kan stå kvar. Det gör övningen återanvändbar i stället för en engångsdebatt.