Que debe responder a toda présa un pequeno manual de VPN

O responsable que colleu a quenda ás 02:00 non puido dicir se o servizo estaba san, porque o documento explicaba o deseño e nunca dicía que executar. Entregar o ficheiro a outra persoa e despois saír da sala é a única proba que importa. A maioría das notas pequenas de VPN suspéndena na segunda páxina. A forma de abaixo supera esa proba, e nada dela precisa ser longo.

Comece cun mapa que unha persoa cansa poida escanear

Anote o que alguén ten que consultar con présa: os nomes aos que se conectan os clientes, os portos nos que escoita o daemon, os rangos de enderezos que reparte, como se resolven os nomes dos clientes e que redes detrás do túnel deben ser accesibles. Engada o número de compilación que executa de verdade e nomee o compoñente que posúe cada peza móbil, porque as rutas, o filtro de paquetes e os perfís de cliente adoitan configurarse en tres lugares distintos. Anote tamén as dependencias externas: a conta de aloxamento, a ligazón ascendente, o provedor de identidade e as redes privadas do extremo oposto. Unha táboa ou un diagrama debuxado a man lévao mellor que os parágrafos, porque o lector folla en lugar de ler.

Despois nomee as persoas que poden autorizar un cambio de emerxencia, cunha vía de contacto que non dependa de que o túnel estea levantado. Unha liña de escalado sen respaldo é unha rúa sen saída xustamente no incidente que a necesita. Dous nomes e un teléfono abondan; o mapa non é un directorio de persoal.

Cada comprobación necesita a resposta que conta como san

Para cada servizo, poña a orde e a liña que significa que funcionou unha xunto á outra, para que o lector nunca teña que deducir unha da outra con présa. O estado do proceso e a accesibilidade de extremo a extremo están en capas distintas: unha mostra que o daemon aceptou a súa configuración, a outra que un cliente pode usar o que o túnel ofrece. Escriba as dúas liñas e diga que fallo atrapa cada unha, porque unha comprobación sen resultado declarado convértese nunha discusión sobre se a saída parece correcta.

systemctl status openvpn-server@lab
ss -lntu | grep 1194

Executar as dúas e tratalas como probas separadas en lugar dunha secuencia. Unha unidade verde pode estar xunto a un túnel que ninguén pode usar, e o contrario ocorre cando un oínte sobrevive a unha ruta rota. Declare a capa que observa cada liña, e o lector saberá en cal confiar cando non coincidan.

Tres fallos cobren a maioría das noites

Extremo inalcanzable, identidade rexeitada e conexión sen tráfico útil explican case todo o que esperta a alguén. Para cada un, enumere as dúas primeiras comprobacións e a persoa á que escalar, para que ninguén teña que inventar unha orde de diagnóstico ás 02:00. Inalcanzable adoita apuntar ao camiño ou ao oínte, unha identidade rexeitada a un certificado, un almacén de credenciais ou un reloxo, e unha conexión baleira a rutas, reenvío ou resolución de nomes. Eses tres pólas len rexistros distintos, e por iso a póla debe elixirse antes de abrir o rexistro.

Ligue a documentación de orixe en lugar de pegar ordes que non executou neste host. Unha orde non probada copiada doutro ambiente é peor que un punteiro, porque parece autorizada e falla en silencio.

Escriba o cambio como unha secuencia, non como un parágrafo

Para calquera cambio, anote o punto de control ao que pode volver, a comprobación que confirma o éxito e a condición que desencadea a reversión, nesa orde. Inclúa unha vía de volta que non pase polo túnel, porque o cambio que está a facer é xustamente o que pode pechalo. Anote como se restaurarían as revogacións actuais en lugar dunha instantánea máis antiga, porque unha lista obsoleta volve admitir en silencio credenciais que se retiraron esa mañá. Os pasos imperativos numerados sobreviven á presión; a prosa convértese en interpretación.

Ensaie esa vía de volta antes de necesitala, sempre que o cambio sexa abondo grande para importar. Unha reversión escrita de memoria é unha conxectura cunha data pegada.

As credenciais viven noutro sitio

Remita ao xestor de contrasinais, a caixa forte ou o sobre selado, e diga quen pode abrilo, en lugar de citar calquera material no ficheiro. As claves privadas, os códigos de recuperación dun só uso e os perfís que incrustan un segredo pertencen a un almacenamento protexido, e a páxina debería explicar como chega a eles un responsable autorizado ás 02:00. Nunca empregue un segredo vivo como exemplo, porque os exemplos péganse en tíckets e fíos de conversa. Un punteiro máis unha lista de permisos é todo o que o documento necesita.

Revise o ficheiro tras un cambio real ou un exercicio de recuperación, borre camiños que xa non existen e anote a quen lle toca a seguinte decisión de mantemento. Manteña ao final un rexistro de cambios de tres columnas: data, que cambiou, quen o verificou. Esa páxina é a que lle di ao seguinte lector se o resto está ao día, e a documentación de systemctl de systemd é unha ligazón mellor que unha paráfrase de ordes de servizo que acabarán derivando.