Ce trebuie să răspundă repede un mic manual de VPN

Persoana care a preluat tura la 02:00 nu a putut spune dacă serviciul era sănătos, pentru că documentul explica proiectarea și nu spunea niciodată ce trebuie rulat. Să dai fișierul altcuiva și apoi să pleci din cameră este singurul test care contează. Majoritatea notițelor mici despre VPN îl pică deja la a doua pagină. Forma de mai jos trece acel test, și nimic din ea nu trebuie să fie lung.

Începeți cu o hartă pe care o persoană obosită o poate parcurge din ochi

Notați ce trebuie să caute cineva în grabă: numele la care se conectează clienții, porturile pe care ascultă demonul, pool-urile de adrese pe care le distribuie, cum se rezolvă numele clienților și ce rețele din spatele tunelului trebuie să fie accesibile. Adăugați numărul de build pe care îl rulați efectiv și numiți componenta care deține fiecare parte mobilă, pentru că rutele, filtrul de pachete și profilurile de client sunt adesea configurate în trei locuri diferite. Notați și dependențele externe: contul de găzduire, legătura ascendentă, furnizorul de identitate și rețelele private de la capătul îndepărtat. Un tabel sau o schemă desenată de mână poartă mai bine acest lucru decât paragrafele, pentru că cititorul parcurge, nu citește.

Apoi numiți persoanele care pot autoriza o schimbare de urgență, cu o cale de contact care nu depinde de funcționarea tunelului. O linie de escaladare fără rezervă este o fundătură exact în incidentul care are nevoie de ea. Două nume și un număr de telefon sunt de ajuns; harta nu este o listă de personal.

Fiecare verificare are nevoie de răspunsul care contează ca sănătos

Pentru fiecare serviciu, puneți comanda și linia care înseamnă că a reușit una lângă alta, ca cititorul să nu trebuiască niciodată să deducă una din cealaltă în grabă. Starea procesului și accesibilitatea cap-la-cap stau pe straturi diferite: una arată că demonul și-a acceptat configurația, cealaltă că un client poate folosi ce oferă tunelul. Scrieți ambele linii și spuneți ce defecțiune prinde fiecare, pentru că o verificare fără rezultat declarat devine o dispută despre dacă ieșirea arată bine.

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

Rulați ambele și tratați-le ca dovezi separate, nu ca o secvență. O unitate verde poate sta lângă un tunel pe care nimeni nu-l poate folosi, iar inversul se întâmplă când un ascultător supraviețuiește unei rute rupte. Declarați stratul pe care îl observă fiecare linie, iar cititorul va ști în care să aibă încredere când nu sunt de acord.

Trei defecțiuni acoperă majoritatea nopților

Capăt inaccesibil, identitate respinsă și conectare fără trafic util explică aproape tot ce trezește pe cineva. Pentru fiecare, enumerați primele două verificări și persoana căreia i se escaladează, ca nimeni să nu inventeze o ordine de diagnostic la 02:00. Inaccesibilul indică de obicei calea sau ascultătorul, o identitate respinsă un certificat, un depozit de acreditări sau un ceas, iar o conexiune goală rutele, redirecționarea sau rezolvarea numelor. Cele trei ramuri citesc jurnale diferite, de aceea ramura trebuie aleasă înainte de a deschide jurnalul.

Legați documentația de mai sus în loc să lipiți comenzi pe care nu le-ați rulat pe acest host. O comandă netestată, copiată din alt mediu, este mai rea decât o indicare, pentru că pare autoritară și eșuează în tăcere.

Scrieți schimbarea ca secvență, nu ca paragraf

Pentru orice schimbare, notați punctul de control la care puteți reveni, verificarea care confirmă succesul și condiția care declanșează revenirea, în această ordine. Includeți o cale de întoarcere care nu trece prin tunel, fiindcă exact schimbarea pe care o faceți poate să-l închidă. Notați cum ar fi restaurate revocările actuale în locul unui instantaneu mai vechi, pentru că o listă învechită readmite în tăcere acreditările care fuseseră retrase în acea dimineață. Pașii imperativi numerotați rezistă la presiune; proza devine interpretare.

Exersați acea cale de întoarcere înainte de a avea nevoie de ea, ori de câte ori schimbarea este destul de mare încât să conteze. O revenire scrisă din memorie este o presupunere cu o dată atașată.

Acreditările locuiesc în altă parte

Faceți referire la managerul de parole, la seif sau la plicul sigilat și spuneți cine îl poate deschide, în loc să citați orice material din fișier. Cheile private, codurile de recuperare de unică folosință și profilurile care încorporează un secret aparțin stocării protejate, iar pagina ar trebui să explice cum ajunge la ele un responsabil autorizat la 02:00. Nu folosiți niciodată un secret viu ca exemplu, pentru că exemplele ajung lipite în tichete și fire de chat. O indicare plus o listă de permisiuni este tot ce are nevoie documentul.

Revizuiți fișierul după o schimbare reală sau un exercițiu de recuperare, ștergeți căile care nu mai există și notați a cui este următoarea decizie de întreținere. Țineți la final un jurnal de modificări cu trei coloane: data, ce s-a schimbat, cine a verificat. Această pagină este cea care îi spune următorului cititor dacă restul este actualizat, iar documentația systemctl de la systemd este o legătură mai bună decât o parafrază a comenzilor de serviciu care vor deriva.