Escriba un informe de deseño de VPN que alguén poida revisar de verdade

A maioría das revisións de deseño atascan na primeira pregunta, porque a solicitude describe un produto e non unha decisión. Un informe que nomea os fluxos, os responsables e o comportamento ante fallos pódese responder nunha reunión. Un informe que di construíd unha VPN segura non se pode responder en absoluto. Percorra as seis comprobacións seguintes antes de enviar nada, e a revisión convértese nunha comparación en lugar dun debate.

Primeiro, a pregunta é unha decisión ou un desexo

Unha decisión ten alternativas e unha observación que escollería entre elas. Se non pode nomear que miraría para escoller unha, a pregunta segue sendo un desexo. Escriba primeiro as alternativas, aínda que a lista só teña dous elementos. Despois escriba o compromiso que as separa.

Un desexo tamén tende a ocultar o público. Diga quen debe aprobar o deseño, porque o mesmo informe se le de forma distinta para un responsable de rede, un revisor de seguridade e un aprobador financeiro.

Deter aquí se a resposta é ninguén, porque unha decisión sen propietario será refeita por quen se queixe máis alto. Iso é un problema de gobernanza e non un problema de deseño.

Segundo, nomee os fluxos e as denegacións

Enumere a orixe, o destino e a aplicación de cada fluxo que debe funcionar. Despois enumere os fluxos que deben seguir fallando, porque un deseño que os permite en silencio cambiou o requisito sen dicilo. O solapamento de enderezos e o alcance augas arriba pertencen a esta lista como restricións e non como sorpresas.

Sexa concreto sobre a dirección. Unha sede que pode iniciar conexións cara á central é un deseño distinto dunha que pode aceptalas, e a diferenza aparece en cada regra que escriba despois.

Anote tamén os clientes e o seu estado de xestión, porque un dispositivo xestionado cun axente pode facer cousas que un portátil traído polo usuario non pode.

Manteña a lista o suficientemente curta para probala. Dez fluxos que pode verificar valen máis que corenta que non pode.

Comprobación 3: separe os feitos das suposicións

Marque cada afirmación que verificou e marque as que non. O enderezo público, o caudal dispoñible e o acceso de administrador son as tres suposicións que máis a miúdo cambian a resposta. Se unha delas é descoñecida, diga como cambia o deseño cando resulta en calquera dos dous sentidos.

Unha rede ilustrativa está ben sempre que estea etiquetada. O problema é unha sucursal hipotética que adquire en silencio un segundo enlace ascendente ou un bloque de enderezos públicos que nunca tivo.

Verifique a suposición que poida comprobar antes da revisión, porque un só feito medido elimina unha rama enteira de discusión.

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

Cuarto, escriba o contrato de fallo

Diga que ocorre cando o túnel está caído e sexa explícito sobre as dúas promesas distintas. Restaurar conexións novas tras unha reconexión é fácil de prometer. Preservar as sesións que xa estaban establecidas durante un fallo é un requisito moito máis forte, e limita a elección de tecnoloxía.

Logo decida o plan alternativo: bloquear o tráfico, encaminalo por outra vía aprobada ou facer algo distinto por aplicación. Unha volta silenciosa a un camiño directo é unha decisión de deseño aínda que ninguén a escribise.

Engada o obxectivo de recuperación en linguaxe clara, como canto tempo pode operar unha sede en estado degradado e quen declara o incidente.

Comprobación 5 e 6: escolla a costura e rexistre o cambio

Escolla unha costura para discutir, porque unha revisión que intenta resolvelo todo non resolve nada. O encamiñamento, a autorización e o cifrado son tres costuras distintas, e o informe debe dicir de cal vai a pregunta. RFC 4301 é un recordatorio útil aquí, porque separa as decisións de política, o tráfico protexido e as asociacións de seguridade en lugar de tratalas como un só obxecto.

Despois rexistre que cambiou tras a decisión, incluídas as suposicións revisadas. Ese rexistro é o que fai máis curta a seguinte revisión.

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

Un informe que supera as seis comprobacións produce unha pregunta con resposta: o deseño cumpre os fluxos declarados e o contrato de fallo, ou unha restrición nomeada o impide. Cando a restrición cambie máis adiante, o rexistro mostra que decisión hai que revisar e cal pode manterse. Iso fai que o exercicio sexa reutilizable e non un debate puntual.