WireGuard è pronto per la produzione? La risposta non è il protocollo

Le persone chiedono se WireGuard è pronto per la produzione, il che suona come una domanda sulla crittografia ed è in realtà una domanda sul vostro ambiente. Il protocollo è esaminato da anni; il dispiegamento deve ancora rispondere se le vostre reti trasportano il suo traffico, chi iscrive e ritira i dispositivi e chi applica le patch al pacchetto alle due estremità. Queste risposte differiscono tra due server in un rack e mille portatili. Il protocollo è lo stesso nei due casi; le operazioni no.

La domanda dietro la domanda

Quello che le persone di solito vogliono sapere è se possono impegnarsi su un progetto che non le metterà in imbarazzo fra sei mesi. È una domanda di dispiegamento in quattro parti, e ogni parte può fallire indipendentemente dalle altre. Rispondere bene a tre non compensa la quarta.

Un vecchio avvertimento su uno snapshot pre-rilascio è un fatto su quello snapshot, non un'etichetta permanente su ogni pacchetto successivo. Allo stesso modo, nessun post di blog può dichiarare pronta la vostra specifica combinazione di kernel, client, rete e personale. Il lavoro è rendere esplicita la combinazione e verificarla.

Trattate la prontezza come un insieme di porte che o superate o registrate come aperte. Questo trasforma una discussione in una lista di controllo con responsabili. Inoltre rende visibili le voci aperte a chi firma l'approvazione, invece di seppellirle in un rapporto pilota.

Porta uno: il percorso deve trasportare UDP

WireGuard trasporta il suo traffico su UDP e documenta che non offre una modalità TCP né offuscamento del traffico. Un progetto che dipende dall'apparire come traffico web ordinario, o dal cambio di porta per ottenere un comportamento TCP, si basa su un presupposto che il software non supporta.

La prima porta è quindi un'indagine, non un test su una sola macchina. Elencate gli ambienti di accesso in cui i vostri utenti lavorano davvero, poi verificate il percorso UDP approvato in ciascuno e decidete cosa accade quando non è disponibile.

Una connessione che funziona dall'ufficio non dimostra nulla su una rete d'albergo, un firewall di campus o un operatore mobile che gestisce UDP in modo diverso. Sono questi ambienti la ragione per cui i dispiegamenti di accesso remoto falliscono dopo un pilota riuscito. Il pilota non era sbagliato; era stretto. Ampliarlo è la porta.

Scrivete anche il ripiego. Se la risposta è che non c'è alcun ripiego, è una decisione che vale la pena dichiarare in anticipo invece di scoprirla durante un viaggio di lavoro.

Porta due: qualcuno deve possedere le chiavi

I peer di WireGuard si autenticano con chiavi, una coppia per partecipante. È semplice da descrivere e impegnativo da gestire, perché nulla nel protocollo iscrive un dispositivo, tiene traccia di chi possiede quale chiave o rimuove l'accesso quando un portatile va perduto. Il protocollo presuppone che le chiavi siano già corrette, e la correttezza è il lavoro di qualcuno.

Nominate la persona che iscrive un dispositivo, il registro che associa una chiave pubblica a una persona e a un dispositivo, e la procedura di rimozione. Se la rimozione dipende dal ricordo di dove sono stati installati gli esemplari di un file di configurazione, la procedura non è finita.

Scegliete un dispositivo durante il pilota e ritiratelo da capo a fondo. Quell'esercizio produce informazioni più utili di un altro test di connettività, perché espone le lacune nei vostri registri.

Porta tre: il pacchetto ha bisogno di un manutentore

WireGuard può arrivare come implementazione nel kernel, come pacchetto di distribuzione o come client nello spazio utente, e ciascuno ha il proprio percorso di aggiornamento. La domanda operativa è quale eseguite, da dove viene e chi applica un bollettino di sicurezza.

Usiamo WireGuard non è un inventario. Non identifica il pacchetto da correggere, la versione sul gateway né la persona che può annullare un aggiornamento difettoso.

Porta quattro: accettate il carico di lavoro, non la stretta di mano

I criteri di accettazione dovrebbero descrivere ciò che fanno gli utenti. Raggiungere un'applicazione interna, risolvere il suo nome privato, essere respinti verso una destinazione non autorizzata e seguire il comportamento definito quando il tunnel è abbassato sono tutti osservabili, e una stretta di mano riuscita non è nessuno di essi.

Eseguite questi controlli attraverso un cambio di rete, un riavvio del dispositivo e una finestra di manutenzione del gateway, perché è in queste transizioni che i dispiegamenti si rompono.

Tenete le prove accanto ai criteri, compreso lo stato locale che le ha prodotte:

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

Un test verde su una rete tranquilla con un solo portatile è un'osservazione iniziale. Non è un'affermazione di affidabilità, e trattarlo come tale è il modo in cui un progetto che funziona diventa un progetto di cui ci si fida.