Avant de remplacer IPsec par Shadowsocks, listez les tâches qui manquent

Trois services, un tunnel : une application web, une base de données et un partage de fichiers. Quelqu'un propose de remplacer IPsec par Shadowsocks parce que c'est plus simple à exploiter. Le débat sur le chiffrement qui suit manque le point, car le tunnel remplit plusieurs tâches à la fois et une seule concerne les chiffrements. Notez ces tâches avant de comparer des produits. La liste est courte, et n'importe quel point peut invalider le remplacement.

Commencez par la façon dont le trafic est capturé

Le protocole a deux moitiés. Un composant local accepte une connexion, chiffre un flux qui commence par l'adresse de destination et l'envoie à un composant distant. La moitié distante ouvre une connexion vers cette destination et relaie les octets. UDP suit la même forme avec des datagrammes. C'est du transfert pour les flux qu'il capture, et cela ne dit rien des flux qu'il ne capture pas. Une application qui parle explicitement un proxy est facile ; tout le reste a besoin d'un adaptateur ou de règles de routage pour être capturé.

Documentez la méthode de capture par application avant de comparer quoi que ce soit d'autre. Le trafic non capturé sort par le chemin habituel, et personne ne le remarque tant qu'un service ne se comporte pas différemment hors du bureau.

Nommez chaque destination et chaque protocole

La moitié distante doit pouvoir atteindre chaque service interne. Une session chiffrée qui fonctionne vers cet hôte n'ajoute pas de route de celui-ci vers la base de données et ne fait pas résoudre les noms internes sur le client. Listez les adresses, les ports et les protocoles au lieu d'écrire que le LAN est inclus.

Ajoutez les cas qui cassent les conceptions bien rangées : DNS interne, applications qui ignorent les réglages de proxy et tout flux qui doit être lancé du serveur vers le client. Chacun demande un arrangement explicite, pas une supposition.

Le chiffrement n'est pas une autorisation

Les méthodes AEAD documentées de Shadowsocks offrent un chiffrement authentifié, donc rejeter toute la famille comme peu sûre est faux. Laisser ce fait répondre à la question de l'accès est tout aussi faux. Quelqu'un doit décider qui atteint quel service, comment l'accès est retiré quand une personne part, où les secrets sont stockés et quel composant applique la frontière. Un seul secret partagé donne à chaque détenteur la même portée, et le départ d'une personne devient une rotation pour tous.

Mesurez la configuration IPsec actuelle à la même aune. Son étiquette ne prouve pas que ses règles sont justes, et comparer une version polie d'une conception avec une version floue de l'autre ne décide rien.

Listez les contrôles qui existent aujourd'hui des deux côtés, puis jugez avec quelles lacunes vous pouvez vivre.

Comptez le travail d'exploitation

Chaque remplacement a besoin d'un responsable pour les paquets clients, les mises à jour du serveur, la rotation des identifiants et le traitement des pannes. Notez ce que fait chaque application quand le tunnel est indisponible : échouer, réessayer par le chemin local ou attendre. Ce comportement vient du déploiement, pas du nom du protocole.

Pour une application web, un proxy étroit peut suffire. Pour un accès à tout le réseau avec des permissions par personne, les pièces supplémentaires coûtent généralement plus cher que le tunnel qu'elles ont remplacé.

La décision n'est pas quel produit sonne plus sûr. C'est quelle conception termine les tâches listées avec des contrôles que l'équipe maintiendra réellement.