Прежде чем заменить IPsec на Shadowsocks, перечислите недостающие задачи

Три сервиса, один туннель: веб-приложение, база данных и общая папка. Кто-то предлагает заменить IPsec на Shadowsocks, потому что его проще эксплуатировать. Последующая дискуссия о шифровании упускает суть: туннель выполняет несколько задач сразу, и только одна из них про шифры. Запишите эти задачи до сравнения продуктов. Список короткий, и любой его пункт может отменить замену.

Начните с того, как перехватывается трафик

У протокола две половины. Локальный компонент принимает соединение, шифрует поток, который начинается с адреса назначения, и отправляет его удалённому компоненту. Удалённая половина открывает соединение к этому назначению и передаёт байты. UDP следует той же схеме с датаграммами. Это перенаправление для потоков, которые он перехватывает, и оно ничего не говорит о потоках, которые не перехватывает. Приложение, которое явно говорит с прокси, — простое; всему остальному нужен адаптер или правила маршрутизации, чтобы его вообще перехватили.

Задокументируйте способ перехвата для каждого приложения, прежде чем сравнивать что-либо ещё. Неперехваченный трафик уходит обычным путём, и никто этого не замечает, пока сервис не начнёт вести себя иначе вне офиса.

Назовите каждое назначение и протокол

Удалённая половина должна достигать каждого внутреннего сервиса. Рабочая шифрованная сессия до этого хоста не добавляет маршрут от него к базе данных и не заставляет внутренние имена разрешаться на клиенте. Перечислите адреса, порты и протоколы вместо записи о том, что LAN включена.

Добавьте случаи, которые ломают аккуратные схемы: внутренний DNS, приложения, игнорирующие настройки прокси, и любой поток, который нужно инициировать с сервера в сторону клиента. Каждому нужна явная договорённость, а не допущение.

Шифрование — это не авторизация

Документированные методы AEAD в Shadowsocks дают аутентифицированное шифрование, поэтому отвергать всё семейство как небезопасное неправильно. Так же неправильно позволять этому факту отвечать на вопрос о доступе. Кто-то должен решить, кто достигает какого сервиса, как отзывается доступ, когда человек уходит, где хранятся секреты и какой компонент обеспечивает границу. Один общий секрет даёт каждому держателю одинаковый охват, и уход одного человека превращается в ротацию для всех.

Приложите к текущей настройке IPsec ту же мерку. Её название не доказывает, что правила верны, а сравнение отполированной версии одной схемы с расплывчатой версией другой ничего не решает.

Перечислите контроли, которые существуют сегодня с обеих сторон, и затем оцените, с какими пробелами вы можете жить.

Посчитайте эксплуатационную работу

Каждая замена требует ответственного за клиентские пакеты, обновления сервера, ротацию учётных данных и обработку отказов. Отметьте, что делает каждое приложение, когда туннель недоступен: падает, повторяет попытку локальным путём или ждёт. Это поведение следует из развёртывания, а не из названия протокола.

Для одного веб-приложения узкого прокси может хватить. Для доступа ко всей сети с правами на человека дополнительные части обычно стоят дороже заменённого туннеля.

Решение не в том, какой продукт звучит безопаснее. Оно в том, какая схема завершит перечисленные задачи с контролями, которые команда действительно будет поддерживать.