Перш ніж замінити IPsec на Shadowsocks, перелічіть відсутні завдання

Три сервіси, один тунель: вебзастосунок, база даних і спільна тека. Хтось пропонує замінити IPsec на Shadowsocks, бо його простіше експлуатувати. Наступна дискусія про шифрування оминає суть, бо тунель виконує кілька завдань одночасно і лише одне з них про шифри. Запишіть ці завдання до порівняння продуктів. Список короткий, і будь-який пункт може скасувати заміну.

Почніть із того, як перехоплюється трафік

Протокол має дві половини. Локальний компонент приймає з'єднання, шифрує потік, що починається з адреси призначення, і надсилає його віддаленому компоненту. Віддалена половина відкриває з'єднання до цього призначення і передає байти. UDP дотримується тієї самої схеми з датаграмами. Це переспрямування для потоків, які він перехоплює, і воно нічого не каже про потоки, які не перехоплює. Застосунок, який явно говорить із проксі, простий; усе інше потребує адаптера або правил маршрутизації, щоб його взагалі перехопили.

Задокументуйте спосіб перехоплення для кожного застосунку, перш ніж порівнювати будь-що інше. Неперехоплений трафік виходить звичайним шляхом, і ніхто цього не помічає, доки сервіс не почне поводитися інакше поза офісом.

Назвіть кожне призначення й кожен протокол

Віддалена половина повинна діставатися кожного внутрішнього сервісу. Робоча шифрована сесія до цього хоста не додає маршрут від нього до бази даних і не змушує внутрішні імена розв'язуватися на клієнті. Перелічіть адреси, порти й протоколи замість того, щоб писати, що LAN включено.

Додайте випадки, які ламають охайні схеми: внутрішній DNS, застосунки, що ігнорують налаштування проксі, і будь-який потік, який треба ініціювати з сервера в бік клієнта. Кожному потрібна явна домовленість, а не припущення.

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

Задокументовані методи AEAD у Shadowsocks дають автентифіковане шифрування, тому відкидати всю родину як небезпечну неправильно. Так само неправильно дозволяти цьому факту відповідати на питання доступу. Хтось має вирішити, хто дістається якого сервісу, як забирається доступ, коли людина йде, де зберігаються секрети і який компонент забезпечує межу. Один спільний секрет дає кожному власникові однаковий обсяг, і вихід однієї людини стає ротацією для всіх.

Прикладіть до поточного налаштування IPsec ту саму мірку. Його назва не доводить, що правила правильні, а порівняння відшліфованої версії однієї схеми з розпливчастою версією іншої нічого не вирішує.

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

Порахуйте експлуатаційну роботу

Кожна заміна потребує відповідального за клієнтські пакети, оновлення сервера, ротацію облікових даних і обробку відмов. Зауважте, що робить кожен застосунок, коли тунель недоступний: падає, повторює спробу локальним шляхом або чекає. Така поведінка походить із розгортання, а не з назви протоколу.

Для одного вебзастосунку вузького проксі може бути достатньо. Для доступу до всієї мережі з правами на людину додаткові частини зазвичай коштують дорожче за замінений тунель.

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