Хмарна група безпеки для VPN: відкрийте слухача, а не все

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

Назвіть протокол до правила

Правило — це протокол, діапазон портів і джерело. WireGuard слухає UDP, зазвичай 51820. OpenVPN зазвичай працює через UDP або TCP 1194 залежно від налаштування. IPsec потребує обміну IKE на UDP 500 і 4500 плюс сам протокол ESP, який є номером протоколу, а не портом. Здогадка про TCP тому, що інші правила TCP, приводить до правила, яке виглядає правильним і ні з чим не збігається.

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

Обмежте джерело діапазоном клієнтів, який допускає проєкт, а не всім інтернетом.

Групи безпеки зберігають стан; ACL підмережі — ні

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

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

Чинна політика — це об'єднання прив'язаного, а не файл, який ви редагували.

Брандмауер хоста — окремий кордон

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

Якщо хост використовує фронтенд брандмауера дистрибутива, перевірте базові правила, а не назву профілю, бо профіль може бути активним, поки порт закритий.

Захоплення на інтерфейсі скаже, який кордон відкинув пакет.

Дозволити слухача — не означає маршрутизувати клієнтів

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

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

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

Залиште шлях назад, потім звузьте правило

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

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

Задокументуйте й прив'язку, інакше змінний інтерфейс мовчки втратить політику.