GeoIP-блокування: де ламається логіка доступу
GeoIP-блокування виглядає як просте правило: зіставили адресу клієнта з діапазоном із бази регіонів і повернули відмову. Насправді це одне з найкрихкіших місць у контурі доступу — збій проявляється не одразу й не там, де його шукають.
Перша типова відмова — хибні блокування клієнтів. Мобільні оператори збирають трафік за спільним шлюзом, корпоративні мережі виходять в інтернет через один вузол, і адреса перестає збігатися з реальним регіоном користувача.
Клієнт, що платить, із цільової країни отримує відмову, підтримка розбирається годинами, бо в логах видно лише спрацьоване правило за країною.
Друга — обхід блокування через проксі та VPN. Вихідні вузли орендують у хмарах і дата-центрах, чиї діапазони закріплені за іншою країною, тому фільтр «пропускати лише свої регіони» пропускає рівно тих, від кого закривалися. Геофільтрація трафіку за країною адреси в такій схемі дає не захист, а ілюзію контролю.
Третя — актуальність баз регіонів та їхній розсинхрон між вузлами.
Діапазони переїжджають між операторами, бази оновлюються за розкладом, і якщо частина серверів читає стару копію, а зовнішній фільтр застосовує власну таблицю, той самий клієнт отримує різні рішення залежно від точки входу.
Зверху лягають ручні правки в конфігураціях: винятки, додані під конкретний інцидент, залишаються у файлах і поступово перекривають початкову логіку.
Розбираємо, як це закривається: де тримати базу регіонів, як розвести правила за шарами і що логувати, щоб хибне блокування було видно раніше, ніж клієнт напише в підтримку.
Що дає управління доступом за регіонами
Управління доступом за географією цінне не самим фактом «закрити регіон», а вимірюваним фільтром на вході. Коли правила відсікання стоять на периметрі, до застосунку доходить лише цільовий трафік — падає число запитів, які раніше займали воркери та пул з'єднань.
Зниження навантаження на сервер рахують за часткою запитів, відхилених до передачі в застосунок, і за тим, скільки звільнених ресурсів пішло на корисну роботу.
Паразитний фон відсікається раніше, ніж потрапляє в логи застосунку, тому сервіс тримає пікові сплески без екстреного масштабування, а час відповіді на цільових запитах перестає плавати.
Головний ризик будь-якого регіонального фільтра — помилкові відмови в доступі. Реальні користувачі приходять через мобільних операторів, корпоративні проксі, супутникові канали та публічні точки виходу VPN, і їхні адреси не завжди збігаються з очікуваною географією.
Тому частку хибних спрацьовувань вимірюють окремо, ведуть список винятків і логують кожне рішення фільтра — інцидент розбирається за фактом, а не за здогадами.
Автоматизація правил доступу знімає ручні правки конфігурацій. Списки та винятки описуються декларативно, проходять рев'ю і застосовуються з одного джерела — розбіжностей між середовищами не виникає, а обсяг ручних змін скорочується до кількох рядків на реліз.
Разом це дає стабільність роботи сервісу: зникає цілий клас відмов — переповнення пулу з'єднань і деградація при сплесках із нецільових регіонів. Фільтр працює як штатний запобіжник перед застосунком, а не як костиль усередині нього.
Порівняння підходів: nginx, Cloudflare, балансувальник
Рішення про геофільтрацію можна ухвалити на трьох рівнях: до потрапляння запиту на вашу інфраструктуру, на вході в неї або вже всередині застосунку. Від вибору залежить і витрата ресурсів, і точність правил, і те, яку адресу клієнта бачить система.
Окремий практичний момент — робота за проксі: якщо реальна адреса не підставляється в ланцюжок довірених заголовків, блокування на рівні сервера починає відсікати не тих. Нижче — чотири схеми та їхні обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила на стороні сервера (nginx + геобаза) | Один-два сервери, перед застосунком немає CDN, потрібен повний контроль над списком країн і докладні логи | Запит доходить до сервера й витрачає його ресурси; під час роботи за проксі без коректної підстановки реальної адреси правила спрацьовують за чужим IP |
| Правила на CDN (Cloudflare) | Публічний трафік, потрібне відсікання до вашої інфраструктури та захист від сплесків | Логіка обмежена набором правил провайдера, точність залежить від його геобаз; тонкі винятки за підмережами та користувацькі списки налаштовувати складніше |
| Балансувальник навантаження | Кілька сервісів за єдиною точкою входу, єдиний фільтр для всіх | Балансувальник має вміти працювати з геобазою; оновлення баз і синхронізація правил між вузлами — окрема задача, помилка валить увесь трафік одразу |
| Гібридна схема фільтрації | Потрібне відсікання обсягу на вході та точні правила на застосунку | Складніше налагодження: незрозуміло, на якому шарі відсікся запит; потрібне наскрізне логування та узгоджена передача реальної адреси |
Обмеження підходів складаються: чим раніше відсікаємо, тим дешевший трафік, але тим грубіші правила. Гібридна схема зазвичай дає кращий баланс — грубий фільтр за країнами на вході та точні винятки на сервері.
Порядок впровадження: від аудиту до передачі
Геофільтрація рідко ламає продакшн у момент увімкнення — проблема приходить пізніше, коли правила живуть у кількох місцях і поступово розходяться.
Тому етапи впровадження геофільтрації будуємо так, щоб кожне рішення спиралося на виміряний трафік, а не на припущення про те, «звідки до нас ходять».
- Аудит правил доступу та інвентаризація трафіку. Збираємо реальну картину: частки запитів за країнами, джерела ботів, уже наявні обмеження на периметрі та в застосунку. Тут же видно, кого фільтр зачепить першим.
- Схема фільтрації. Визначаємо точку ухвалення рішення — край мережі чи сам веб-сервер, — джерело геоданих і поведінку при застарілій базі: пропускати чи відхиляти. Окремо фіксуємо, що робити з пошуковими роботами та повідомленнями платіжного шлюзу.
- Налаштування джерел геоданих. Підключаємо оновлювану базу адрес, ставимо регулярне оновлення та контроль розсинхрону між периметром і сервером, щоб правила не роз'їжджалися.
- М'який режим. Фільтр лише пише в лог і не віддає відмову. Тримаємо його стільки, скільки потрібно, щоб переконатися: жоден легітимний сценарій не потрапив у спрацьовування.
- Перевірка на тестовому контурі. Проганяємо типові та граничні запити з різних регіонів, звіряємо коди відповідей і заголовки, заздалегідь перевіряємо відкат до попередніх правил.
- Увімкнення та передача з регламентом. Переводимо в бойовий режим поетапно, віддаємо схему, порядок оновлення баз і регламент обслуговування: хто і як додає винятки, як швидко відкочуємо і де дивимося логи.
Що передаємо на руки: конфігурації та регламенти
Здаємо проєкт не в момент, коли правило заробило на проді, а коли ваша команда може відтворити його, поправити й відкотити без нас. Тому на руки йде не набір скриншотів, а робочий комплект артефактів, за яким новий інженер вводиться в контур за один день.
- Файли правил — конфігурації GeoIP на nginx і набори виразів у Cloudflare, зведені в репозиторій з історією змін, а не розкидані по особистих кабінетах.
- Карта схеми проходження запиту: на якому вузлі ухвалюється рішення про блокування, які заголовки доходять до застосунку і де підміняється реальна адреса клієнта.
- Джерела геоданих і розклад їхнього оновлення: яка база використовується, з якою періодичністю підтягується і що відбувається при недоступності джерела.
- Документація щодо доступів: ролі, зони відповідальності, де зберігаються ключі, як вони ротуються і хто підтверджує видачу.
- Політики винятків: білі списки для пошукових роботів, моніторингу, платіжних колбеків і внутрішніх сервісів — з порядком додавання та погодження.
- Порядок відкату змін: яка правка знімається однією командою, скільки займає застосування і за якими метриками видно, що блокування справді знято.
- Регламент оновлення правил: перевірка на тестовому контурі, вікно застосування, хто погоджує спірні блокування і як фіксується рішення.
- Контакти відповідальних з обох сторін і точка ескалації на випадок, якщо правило зачепило реальних клієнтів.
Перед передачею проганяємо сценарій за цими документами крок за кроком: додати виняток, відкотити зміну, оновити базу. Якщо якийсь крок доводиться пояснювати з пам'яті — доопрацьовуємо документ, а не залишаємо як є.
Кейс: хибні спрацьовування та навантаження на периметр
Що було до змін
Інтернет-магазин із трафіком із кількох регіонів тримав геофільтрацію прямо на периметрі: правила на nginx і списки країн на стороні Cloudflare. Діапазони адрес змінювалися, а правила оновлювалися вручну — черговий інженер правив конфіги й перезапускав сервіс.
Хибні спрацьовування доходили до 6–8% спроб входу, підтримка розбирала близько 40 звернень на тиждень.
Побічний ефект — рутина: 2–3 години на день ішло на звірку списків із логами, а один помилковий запис вимикав цілий регіон.
Що змінили
Розвели джерела геоданих і логіку рішень: база оновлюється за розкладом, відповіді кешуються, для службових адрес і підтверджених клієнтів — окремий список винятків. Перевірка геолокації перестала бути гарячою точкою периметра, бо кожен запит більше не йде в базу.
Нові правила вмикаємо канареечно на малій частці трафіку, а частка відмов за регіонами виведена на дашборд поряд із кодом відповіді.
| Показник | До | Після |
|---|---|---|
| Хибні відмови | 6–8% | 0,4% |
| Звернення в підтримку | ~40 на тиждень | ~5 на тиждень |
| Ручна правка правил | 2–3 год на день | 20 хв на тиждень |
| Інциденти через помилку в правилах | 2–3 на місяць | 0 за квартал |
Джерело даних — логи доступу та вивантаження звернень підтримки за зіставні періоди на однаковому профілі трафіку. Канареечне ввімкнення двічі зловило проблемні діапазони до розкатки на весь трафік — ці відмови не дійшли до клієнтів.
Чим GeoIP-блокування на nginx відрізняється від Cloudflare
В обох випадках працює та сама логіка «регіон за базою — правило — відмова», але точка ухвалення рішення різна.
GeoIP-блокування на сервері живе в конфігурації nginx: запит доходить до машини, адреса звіряється з базою геолокації, і лише потім запит або йде в застосунок, або отримує відмову.
На стороні CDN перевірка відбувається на вузлі провайдера — до того, як трафік взагалі потрапить у ваш контур.
Звідси головна розбіжність — визначення регіону клієнта за проксі. Якщо перед сервером стоїть балансувальник або CDN, сокет віддає адресу проміжного вузла, а не відвідувача.
Без коректно налаштованих довірених проксі та заголовка з вихідною адресою фільтр почне порівнювати регіон самої проміжної ланки — правило формально працює, а рішення ухвалюється за чужими даними.
На стороні CDN адреса клієнта відома від початку, підміняти його нічим, але й впливати на цю частину ланцюжка ви не можете.
Дані про геолокацію оновлюються по-різному. На сервері база лежить у вас: її потрібно регулярно забирати, стежити за свіжістю та перечитувати після оновлення — зазвичай це перезавантаження конфігурації, тому оновлення планують окремо від релізів.
На стороні CDN базу оновлює провайдер: у вас немає ні строків, ні можливості відкотити — поведінка змінюється сама, і це варто закладати в правила винятків для спірних діапазонів і операторів мобільного зв'язку.
За затримкою та навантаженням різниця теж відчутна. Локальна фільтрація не прискорює відповідь: запит усе одно займає з'єднання й обробку на сервері, зате дає повний контроль над правилами, логікою винятків і журналами відмов.
Фільтрація на стороні CDN відсікає трафік раніше — знімає навантаження з каналу та застосунку, але менш гнучка. На практиці підходи поєднують: CDN працює грубим первинним фільтром, nginx — другим шаром і точкою для нестандартних правил.
Часті технічні сумніви перед стартом
Перед увімкненням фільтрації в інженерів виникає той самий список питань: що буде з живим трафіком, як не зламати інтеграції і коли правило можна вважати перевіреним.
Обхід через VPN знецінює блокування?
Повністю закрити доступ із країни не можна, і це не мета: геофільтр знімає масовий автоматизований трафік — сканери та парсери. Поодинокі заходи через VPN навантаження не створюють.
Блокування не зачепить живих клієнтів?
Тому вмикаємо м'який режим фільтрації: замість відмови запит отримує перевірку на бота або пропускається із записом у лог. Прикордонні адреси залишаються обслугованими, а ми набираємо статистику.
Наскільки актуальні геодані?
Набори оновлюються раз на один-два тижні, і для частини діапазонів країна не визначена. Такі запити за замовчуванням не вважаємо порушниками — правило для них задаємо окремо.
Партнери та сервіси за кордоном не відваляться?
Ведемо явні винятки: адреси партнерських майданчиків, вузли моніторингу, вже розгорнуті за кордоном сервіси, плюс пропуск за секретним заголовком. Список живе в конфігурації поряд із правилами.
Як перевірити правило до запуску?
Спочатку режим спостереження: запити логуються, але не відсікаються. За логами видно обсяг, країни та зачеплені сценарії. Повне блокування вмикаємо останнім, із планом відкату.
Обговоримо задачу і повернемося з планом впровадження
Щоб обговорити задачу предметно і повернутися з планом впровадження, а не із загальними міркуваннями, нам потрібні вихідні дані для оцінки.
Гео-правила працюють по-різному залежно від того, де завершується шифрування, які сервіси стоять за мережею доставки і хто має залишитися в білому списку — від цього залежить і обсяг робіт, і порядок увімкнення.
- Схема проходження трафіку: де саме термінується з'єднання, які вузли стоять перед застосунком, чи є проміжні ланки та балансувальники.
- Перелік сервісів і регіонів: які домени та застосунки потрапляють під обмеження, з яких країн їх відкривають легальні користувачі.
- Поточні правила: наявні гео-списки, статичні мережі, правила на веб-сервері та на стороні мережі доставки, порядок їхнього застосування.
- Вимоги до винятків: кого блокувати не можна — пошукових роботів, системи моніторингу, платіжні та партнерські адреси, корпоративні виходи співробітників.
- Вимоги до доступів: які ролі потрібні в панелі управління та на серверах, хто підтверджує зміни і погоджує вікно робіт.
- Режим запуску: спочатку спостереження без блокування зі збором статистики, потім точкове ввімкнення за регіонами, потім повне застосування з відкатом однією правкою.
- Критерії приймання: які метрики вважаємо успіхом, яку частку хибних спрацьовувань допускаємо і за який строк виходимо на цільові значення.
З таким набором ми одразу бачимо вузькі місця і пропонуємо реалістичний порядок кроків. Опишіть задачу і надішліть те, що є, — повернемося з оцінкою строків і планом впровадження.
