Шторм перепідключень у філії: ліміти приймання strongSwan

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

Простежте один ноутбук, що повертається в мережу

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

Ніщо в цій послідовності не є збоєм. Шлях приймання робить те, для чого його налаштовано.

Рахуйте напіввідкриту роботу окремим ресурсом

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

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

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

swanctl --stats
swanctl --list-sas | grep -c ESTABLISHED

Прочитайте налаштування приймання, перш ніж їх змінювати

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

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

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

grep -rn -E 'block_threshold|cookie_threshold' /etc/strongswan.conf /etc/strongswan.d/
swanctl --stats | grep -i half

Плануйте повернення, а не лише стійкий стан

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

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

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