Prima di sostituire IPsec con Shadowsocks, elencate i compiti che mancano

Tre servizi, un tunnel: un'applicazione web, un database e una cartella condivisa. Qualcuno propone di scambiare IPsec con Shadowsocks perché è più semplice da gestire. Il dibattito sulla cifratura che segue manca il punto, perché il tunnel svolge diversi compiti insieme e solo uno riguarda i cifrari. Annotate quei compiti prima di confrontare i prodotti. L'elenco è breve e ogni singola voce può invalidare lo scambio.

Partite da come viene catturato il traffico

Il protocollo ha due metà. Un componente locale accetta una connessione, cifra un flusso che inizia con l'indirizzo di destinazione e lo invia a un componente remoto. La metà remota apre una connessione verso quella destinazione e inoltra i byte. UDP segue la stessa forma con i datagrammi. Questo è inoltro per i flussi che cattura, e non dice nulla sui flussi che non cattura. Un'applicazione che parla esplicitamente un proxy è facile; tutto il resto ha bisogno di un adattatore o di regole di instradamento per essere catturato.

Documentate il metodo di cattura per applicazione prima di confrontare qualsiasi altra cosa. Il traffico non catturato esce dal percorso abituale, e nessuno se ne accorge finché un servizio non si comporta diversamente fuori dall'ufficio.

Nominate ogni destinazione e ogni protocollo

La metà remota deve poter raggiungere ogni servizio interno. Una sessione cifrata funzionante verso quell'host non aggiunge una rotta da esso al database e non fa risolvere i nomi interni sul client. Elencate indirizzi, porte e protocolli invece di scrivere che la LAN è inclusa.

Aggiungete i casi che rompono i progetti ordinati: DNS interno, applicazioni che ignorano le impostazioni del proxy e ogni flusso che deve essere avviato dal server verso il client. Ognuno richiede un accordo esplicito, non una supposizione.

La cifratura non è autorizzazione

I metodi AEAD documentati in Shadowsocks offrono cifratura autenticata, quindi scartare l'intera famiglia come insicura è sbagliato. Lasciare che quel fatto risponda alla domanda sull'accesso è altrettanto sbagliato. Qualcuno deve decidere chi raggiunge quale servizio, come si revoca l'accesso quando una persona se ne va, dove vengono conservati i segreti e quale componente applica il confine. Un unico segreto condiviso dà a ogni detentore la stessa portata, e l'uscita di una persona diventa una rotazione per tutti.

Tenete la configurazione IPsec attuale allo stesso metro. La sua etichetta non prova che le sue regole siano giuste, e confrontare una versione rifinita di un progetto con una versione vaga dell'altro non decide nulla.

Elencate i controlli che esistono oggi su entrambi i lati, poi giudicate con quali lacune potete convivere.

Contate il lavoro operativo

Ogni sostituzione ha bisogno di un responsabile per i pacchetti client, gli aggiornamenti del server, la rotazione delle credenziali e la gestione dei guasti. Notate cosa fa ogni applicazione quando il tunnel non è disponibile: fallisce, riprova sul percorso locale o attende. Quel comportamento viene dall'installazione, non dal nome del protocollo.

Per una sola applicazione web, un proxy stretto può bastare. Per l'accesso all'intera rete con permessi per persona, i pezzi aggiuntivi di solito costano più del tunnel che hanno sostituito.

La decisione non è quale prodotto suona più sicuro. È quale progetto completa i compiti elencati con controlli che il team manterrà davvero.