Antes de substituír IPsec por Shadowsocks, enumere os traballos que se perden

Tres servizos, un túnel: unha aplicación web, unha base de datos e un recurso compartido. Alguén propón cambiar IPsec por Shadowsocks porque é máis sinxelo de manter. O debate sobre o cifrado que segue non vai ao grao, porque o túnel fai varias tarefas á vez e só unha delas ten que ver cos cifrados. Anote esas tarefas antes de comparar produtos. A lista é curta e calquera punto pode invalidar o cambio.

Empece por como se captura o tráfico

O protocolo ten dúas metades. Un compoñente local acepta unha conexión, cifra un fluxo que comeza co enderezo de destino e envíao a un compoñente remoto. A metade remota abre unha conexión cara a ese destino e retransmite os bytes. UDP segue a mesma forma con datagramas. Isto é reenvío para os fluxos que captura, e non di nada sobre os fluxos que non captura. Unha aplicación que fala un proxy de forma explícita é fácil; todo o demais necesita un adaptador ou regras de encamiñamento para ser capturado.

Documente o método de captura por aplicación antes de comparar calquera outra cousa. O tráfico non capturado sae polo camiño habitual, e ninguén o nota ata que un servizo se comporta distinto fóra da oficina.

Nomee cada destino e cada protocolo

A metade remota debe poder alcanzar cada servizo interno. Unha sesión cifrada que funciona cara a ese host non engade unha ruta desde el ata a base de datos nin fai que os nomes internos se resolvan no cliente. Enumere enderezos, portos e protocolos no canto de anotar que a LAN está incluída.

Engada os casos que rompen os deseños ordenados: DNS interno, aplicacións que ignoran a configuración do proxy e calquera fluxo que deba iniciarse desde o servidor cara ao cliente. Cada un necesita un acordo explícito, non unha suposición.

O cifrado non é autorización

Os métodos AEAD documentados en Shadowsocks ofrecen cifrado autenticado, así que descartar toda a familia como insegura é incorrecto. Deixar que ese feito responda a pregunta do acceso é igual de incorrecto. Alguén ten que decidir quen chega a que servizo, como se retira o acceso cando unha persoa marcha, onde se gardan os segredos e que compoñente aplica a fronteira. Un único segredo compartido dá a cada portador o mesmo alcance, e dar de baixa a unha persoa convértese nunha rotación para todos.

Someta a configuración actual de IPsec ao mesmo estándar. A súa etiqueta non demostra que as súas regras sexan correctas, e comparar unha versión pulida dun deseño cunha versión vaga do outro non decide nada.

Enumere os controis que existen hoxe en ambos os lados e despois xulgue con que carencias pode convivir.

Cente o traballo operativo

Cada substitución necesita un responsable dos paquetes de cliente, as actualizacións do servidor, a rotación de credenciais e a xestión de fallos. Fixe en que fai cada aplicación cando o túnel non está dispoñible: falla, tenta de novo polo camiño local ou espera. Ese comportamento vén do despregamento, non do nome do protocolo.

Para unha aplicación web, un proxy estreito pode abondar. Para acceso a toda a rede con permisos por persoa, as pezas adicionais adoitan custar máis que o túnel ao que substituíron.

A decisión non é que produto soa máis seguro. É que deseño remata os traballos enumerados con controis que o equipo realmente manterá.