Antes de sustituir IPsec por Shadowsocks, enumere los trabajos que se pierden

Tres servicios, un túnel: una aplicación web, una base de datos y un recurso compartido. Alguien propone cambiar IPsec por Shadowsocks porque es más sencillo de mantener. El debate sobre el cifrado que sigue no va al grano, porque el túnel hace varias tareas a la vez y solo una de ellas tiene que ver con los cifrados. Anote esas tareas antes de comparar productos. La lista es corta y cualquier punto puede invalidar el cambio.

Empiece por cómo se captura el tráfico

El protocolo tiene dos mitades. Un componente local acepta una conexión, cifra un flujo que comienza con la dirección de destino y lo envía a un componente remoto. La mitad remota abre una conexión hacia ese destino y retransmite los bytes. UDP sigue la misma forma con datagramas. Esto es reenvío para los flujos que captura, y no dice nada sobre los flujos que no captura. Una aplicación que habla un proxy de forma explícita es fácil; todo lo demás necesita un adaptador o reglas de enrutamiento para ser capturado.

Documente el método de captura por aplicación antes de comparar cualquier otra cosa. El tráfico no capturado sale por el camino habitual, y nadie lo nota hasta que un servicio se comporta distinto fuera de la oficina.

Nombre cada destino y cada protocolo

La mitad remota debe poder alcanzar cada servicio interno. Una sesión cifrada que funciona hacia ese host no añade una ruta desde él hasta la base de datos ni hace que los nombres internos se resuelvan en el cliente. Enumere direcciones, puertos y protocolos en lugar de anotar que la LAN está incluida.

Añada los casos que rompen los diseños ordenados: DNS interno, aplicaciones que ignoran la configuración del proxy y cualquier flujo que deba iniciarse desde el servidor hacia el cliente. Cada uno necesita un acuerdo explícito, no una suposición.

El cifrado no es autorización

Los métodos AEAD documentados en Shadowsocks ofrecen cifrado autenticado, así que descartar toda la familia como insegura es incorrecto. Dejar que ese hecho responda la pregunta del acceso es igual de incorrecto. Alguien tiene que decidir quién llega a qué servicio, cómo se retira el acceso cuando una persona se va, dónde se guardan los secretos y qué componente aplica la frontera. Un único secreto compartido da a cada portador el mismo alcance, y dar de baja a una persona se convierte en una rotación para todos.

Someta la configuración actual de IPsec al mismo estándar. Su etiqueta no demuestra que sus reglas sean correctas, y comparar una versión pulida de un diseño con una versión vaga del otro no decide nada.

Enumere los controles que existen hoy en ambos lados y después juzgue con qué carencias puede convivir.

Cuente el trabajo operativo

Cada sustitución necesita un responsable de los paquetes de cliente, las actualizaciones del servidor, la rotación de credenciales y la gestión de fallos. Fíjese en qué hace cada aplicación cuando el túnel no está disponible: falla, reintenta por el camino local o espera. Ese comportamiento viene del despliegue, no del nombre del protocolo.

Para una aplicación web, un proxy estrecho puede bastar. Para acceso a toda la red con permisos por persona, las piezas adicionales suelen costar más que el túnel al que sustituyeron.

La decisión no es qué producto suena más seguro. Es qué diseño termina los trabajos enumerados con controles que el equipo realmente mantendrá.