Este WireGuard pregătit pentru producție? Răspunsul nu este protocolul

Oamenii întreabă dacă WireGuard este pregătit pentru producție, ceea ce sună ca o întrebare despre criptografie și este de fapt o întrebare despre mediul tău. Protocolul este analizat de ani de zile; implementarea trebuie încă să răspundă dacă rețelele tale transportă traficul lui, cine înrolează și retrage dispozitive și cine aplică patch-uri pachetului la ambele capete. Aceste răspunsuri diferă între două servere într-un rack și o mie de laptopuri. Protocolul este același în ambele cazuri; operațiunile nu.

Întrebarea din spatele întrebării

Ce vor oamenii de obicei să știe este dacă se pot angaja la un design care nu le va face rușine peste șase luni. Este o întrebare de implementare cu patru părți, iar fiecare parte poate eșua independent de celelalte. Răspunsurile bune la trei nu compensează a patra.

Un avertisment vechi despre o versiune preliminară este un fapt despre acea versiune, nu o etichetă permanentă pe fiecare pachet ulterior. La fel, niciun articol de blog nu poate declara gata combinația ta specifică de kernel, client, rețea și personal. Munca este să faci combinația explicită și să o verifici.

Tratează pregătirea ca pe un set de porți pe care fie le treci, fie le înregistrezi ca deschise. Asta transformă o dezbatere într-o listă de verificare cu responsabili. De asemenea face elementele deschise vizibile pentru cine aprobă, în loc să fie îngropate într-un raport pilot.

Prima poartă: calea trebuie să transporte UDP

WireGuard își transportă traficul prin UDP și documentează că nu oferă un mod TCP sau ofuscare a traficului. Un design care se bazează pe faptul că va arăta ca trafic web obișnuit, sau pe schimbarea portului pentru a obține comportament TCP, se sprijină pe o presupunere pe care software-ul nu o susține.

Așadar prima poartă este o anchetă, nu un test pe o singură mașină. Enumeră mediile de acces în care utilizatorii tăi lucrează efectiv, apoi verifică calea UDP aprobată în fiecare și decide ce se întâmplă când nu este disponibilă.

O conexiune care funcționează din birou nu dovedește nimic despre o rețea de hotel, un firewall de campus sau un operator mobil care tratează UDP diferit. Acele medii sunt motivul pentru care implementările de acces la distanță eșuează după un pilot reușit. Pilotul nu a fost greșit; a fost îngust. Lărgirea lui este poarta.

Notează și calea de rezervă. Dacă răspunsul este că nu există cale de rezervă, aceasta este o decizie care merită declarată dinainte, în loc să fie descoperită în timpul unei călătorii de afaceri.

A doua poartă: cineva trebuie să dețină cheile

Peerii WireGuard se autentifică cu chei, o pereche per participant. Este ușor de descris și solicitant operațional, pentru că nimic din protocol nu înrolează un dispozitiv, nu urmărește cine deține ce cheie și nu retrage accesul când un laptop se pierde. Protocolul presupune că cheile sunt deja corecte, iar corectitudinea este munca cuiva.

Numiți persoana care înrolează un dispozitiv, înregistrarea care asociază o cheie publică cu o persoană și un dispozitiv, și procedura de retragere. Dacă retragerea depinde de a-ți aminti unde au fost instalate copii ale unui fișier de configurare, procedura nu este terminată.

Alege un dispozitiv în timpul pilotului și retrage-l de la început până la sfârșit. Exercițiul acela produce informații mai utile decât un alt test de conectivitate, pentru că expune golurile din evidențele tale.

A treia poartă: pachetul are nevoie de un întreținător

WireGuard poate veni ca implementare în kernel, ca pachet de distribuție sau ca client în spațiul utilizatorului, iar fiecare are propria cale de actualizare. Întrebarea operațională este pe care o rulezi, de unde a venit și cine aplică un buletin de securitate.

Folosim WireGuard nu este un inventar. Nu identifică pachetul de patch-uit, versiunea de pe gateway sau persoana care poate reveni asupra unei actualizări proaste.

A patra poartă: acceptă volumul de muncă, nu strângerea de mână

Criteriile de acceptare ar trebui să descrie ce fac utilizatorii. A ajunge la o aplicație internă, a rezolva numele ei privat, a fi refuzat la o destinație neautorizată și a urma comportamentul definit când tunelul este căzut sunt toate observabile, iar o strângere de mână reușită nu este niciuna dintre ele.

Rulează aceste verificări printr-o schimbare de rețea, o repornire a dispozitivului și o fereastră de mentenanță a gateway-ului, pentru că exact în aceste tranziții se rup implementările.

Păstrează dovezile lângă criterii, inclusiv starea locală care le-a produs:

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

Un test verde pe o rețea liniștită cu un singur laptop este o observație inițială. Nu este o afirmație despre fiabilitate, iar tratarea lui ca atare este felul în care un design care funcționează devine un design în care se are încredere.