Abans de substituir IPsec per Shadowsocks, enumereu les feines que es perden

Tres serveis, un túnel: una aplicació web, una base de dades i un recurs compartit. Algú proposa canviar IPsec per Shadowsocks perquè és més senzill de mantenir. El debat sobre el xifratge que segueix no va al gra, perquè el túnel fa diverses feines alhora i només una té a veure amb els xifratges. Apunteu aquestes feines abans de comparar productes. La llista és curta i qualsevol punt pot invalidar el canvi.

Comenceu per com es captura el trànsit

El protocol té dues meitats. Un component local accepta una connexió, xifra un flux que comença amb l'adreça de destinació i l'envia a un component remot. La meitat remota obre una connexió a aquesta destinació i retransmet els bytes. UDP segueix la mateixa forma amb datagrames. Això és reenviament per als fluxos que captura, i no diu res sobre els fluxos que no captura. Una aplicació que parla un proxy explícitament és fàcil; tota la resta necessita un adaptador o regles d'encaminament per ser capturada.

Documenteu el mètode de captura per aplicació abans de comparar qualsevol altra cosa. El trànsit no capturat surt pel camí habitual, i ningú no ho nota fins que un servei es comporta diferent fora de l'oficina.

Anomeneu cada destinació i cada protocol

La meitat remota ha de poder arribar a cada servei intern. Una sessió xifrada que funciona fins a aquest amfitrió no afegeix cap ruta des d'ell fins a la base de dades ni fa que els noms interns es resolguin al client. Enumereu adreces, ports i protocols en lloc d'escriure que la LAN hi és inclosa.

Afegiu els casos que trenquen els dissenys ben ordenats: DNS intern, aplicacions que ignoren la configuració del proxy i qualsevol flux que s'hagi d'iniciar des del servidor cap al client. Cadascun necessita un acord explícit, no una suposició.

El xifratge no és autorització

Els mètodes AEAD documentats a Shadowsocks ofereixen xifratge autenticat, així que descartar tota la família com a insegura és incorrecte. Deixar que aquest fet respongui la pregunta de l'accés és igualment incorrecte. Algú ha de decidir qui arriba a quin servei, com es retira l'accés quan una persona marxa, on es guarden els secrets i quin component aplica la frontera. Un sol secret compartit dona a cada posseïdor el mateix abast, i donar de baixa una persona es converteix en una rotació per a tothom.

Poseu la configuració actual d'IPsec al mateix nivell. La seva etiqueta no demostra que les seves regles siguin correctes, i comparar una versió polida d'un disseny amb una versió vaga de l'altre no decideix res.

Enumereu els controls que existeixen avui a banda i banda i, després, jutgeu amb quines mancances podeu conviure.

Compteu la feina operativa

Cada substitució necessita un responsable dels paquets de client, les actualitzacions del servidor, la rotació de credencials i la gestió de fallades. Fixeu-vos què fa cada aplicació quan el túnel no està disponible: falla, torna a provar pel camí local o espera. Aquest comportament ve del desplegament, no del nom del protocol.

Per a una aplicació web, un proxy estret pot ser suficient. Per a accés a tota la xarxa amb permisos per persona, les peces addicionals solen costar més que el túnel que van substituir.

La decisió no és quin producte sona més segur. És quin disseny completa les feines llistades amb controls que l'equip realment mantindrà.