Schreiben Sie ein VPN-Design-Briefing, das jemand wirklich prüfen kann

Die meisten Design-Reviews bleiben bei der ersten Frage hängen, weil die Anfrage ein Produkt und keine Entscheidung beschreibt. Ein Briefing, das die Flüsse, die Verantwortlichen und das Fehlerverhalten benennt, lässt sich in einer Sitzung beantworten. Ein Briefing mit den Worten bauen Sie ein sicheres VPN lässt sich überhaupt nicht beantworten. Gehen Sie die sechs Prüfungen unten durch, bevor Sie etwas senden, und das Review wird zu einem Vergleich statt zu einer Debatte.

Erstens, ist die Frage eine Entscheidung oder ein Wunsch

Eine Entscheidung hat Alternativen und eine Beobachtung, die zwischen ihnen wählen würde. Wenn Sie nicht benennen können, was Sie ansehen würden, um eine auszuwählen, ist die Frage noch ein Wunsch. Schreiben Sie die Alternativen zuerst auf, auch wenn die Liste nur zwei Punkte hat. Schreiben Sie dann den Kompromiss auf, der sie trennt.

Ein Wunsch neigt auch dazu, das Publikum zu verbergen. Sagen Sie, wer das Design genehmigen muss, weil dasselbe Briefing für einen Netzwerkverantwortlichen, einen Sicherheitsprüfer und einen Finanzgenehmiger anders gelesen wird.

Halten Sie hier an, wenn die Antwort niemand lautet, denn eine Entscheidung ohne Eigentümer wird von demjenigen neu getroffen, der am lautesten klagt. Das ist ein Governance-Problem und kein Designproblem.

Zweitens, benennen Sie die Flüsse und die Ablehnungen

Listen Sie Quelle, Ziel und Anwendung für jeden Fluss auf, der funktionieren muss. Listen Sie dann die Flüsse auf, die weiterhin scheitern müssen, denn ein Design, das sie stillschweigend erlaubt, hat die Anforderung geändert, ohne es zu sagen. Adressüberlappung und Erreichbarkeit stromaufwärts gehören als Einschränkungen in diese Liste und nicht als Überraschungen.

Seien Sie konkret bei der Richtung. Ein Standort, der Verbindungen zur Zentrale aufbauen darf, ist ein anderes Design als einer, der sie annehmen darf, und der Unterschied zeigt sich in jeder Regel, die Sie danach schreiben.

Notieren Sie auch die Clients und ihren Verwaltungsstatus, denn ein verwaltetes Gerät mit einem Agenten kann Dinge tun, die ein mitgebrachter Laptop nicht kann.

Halten Sie die Liste kurz genug zum Testen. Zehn Flüsse, die Sie prüfen können, sind besser als vierzig, die Sie nicht prüfen können.

Prüfung 3: Fakten von Annahmen trennen

Markieren Sie jede Aussage, die Sie überprüft haben, und markieren Sie die, die Sie nicht überprüft haben. Öffentliche Adressierung, verfügbarer Durchsatz und Administratorzugriff sind die drei Annahmen, die die Antwort am häufigsten ändern. Ist eine davon unbekannt, sagen Sie, wie sich das Design ändert, wenn sie sich in die eine oder andere Richtung herausstellt.

Ein illustratives Netzwerk ist in Ordnung, solange es gekennzeichnet ist. Das Problem ist eine hypothetische Filiale, die stillschweigend eine zweite Uplink-Verbindung oder einen öffentlichen Adressblock erwirbt, den sie nie hatte.

Prüfen Sie die Annahme, die Sie prüfen können, vor dem Review, denn eine gemessene Tatsache beseitigt einen ganzen Diskussionszweig.

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

Viertens, schreiben Sie den Fehlervertrag

Sagen Sie, was passiert, wenn der Tunnel ausgefallen ist, und seien Sie explizit bei den zwei verschiedenen Versprechen. Neue Verbindungen nach einem Wiederverbinden wiederherzustellen ist leicht zu versprechen. Sitzungen zu erhalten, die bereits über einen Ausfall hinweg aufgebaut waren, ist eine viel stärkere Anforderung, und sie schränkt die Technologiewahl ein.

Dann entscheiden Sie den Rückfall: den Verkehr blockieren, ihn über einen anderen genehmigten Weg leiten oder pro Anwendung etwas anderes tun. Ein stiller Rückfall auf einen direkten Pfad ist eine Designentscheidung, auch wenn niemand sie aufgeschrieben hat.

Fügen Sie das Wiederherstellungsziel in klarer Sprache hinzu, etwa wie lange ein Standort eingeschränkt betrieben werden darf und wer den Vorfall erklärt.

Prüfung 5 und 6: die Naht wählen und die Änderung festhalten

Wählen Sie eine Naht, über die gestritten wird, denn ein Review, das alles klären will, klärt nichts. Routing, Autorisierung und Verschlüsselung sind drei verschiedene Nähte, und ein Briefing sollte sagen, um welche es in der Frage geht. RFC 4301 ist hier eine nützliche Erinnerung, denn sie trennt Richtlinienentscheidungen, geschützten Verkehr und Sicherheitsassoziationen, statt sie als ein Objekt zu behandeln.

Halten Sie dann fest, was sich nach der Entscheidung geändert hat, einschließlich der überarbeiteten Annahmen. Dieser Eintrag ist es, der das nächste Review kürzer macht.

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

Ein Briefing, das alle sechs Prüfungen besteht, erzeugt eine Frage mit einer Antwort: Das Design erfüllt die genannten Flüsse und den Fehlervertrag, oder eine benannte Einschränkung verhindert es. Ändert sich die Einschränkung später, zeigt der Eintrag, welche Entscheidung erneut betrachtet werden muss und welche bestehen bleiben kann. Das macht die Übung wiederverwendbar und nicht zu einer einmaligen Debatte.