GeoIP-блокировка на nginx и Cloudflare: инструкция DevOps

GeoIP блокировка: где ломается логика доступа

GeoIP блокировка выглядит как простое правило: сопоставили адрес клиента с диапазоном из базы регионов и вернули отказ. На деле это одно из самых хрупких мест в контуре доступа — сбой проявляется не сразу и не там, где его ищут.

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

Второй — обход блокировки через прокси и VPN. Выходные узлы арендуют в облаках и дата-центрах, чьи диапазоны закреплены за другой страной, поэтому фильтр «пускать только свои регионы» пропускает ровно тех, от кого закрывались. Геофильтрация трафика по стране адреса в такой схеме даёт не защиту, а иллюзию контроля.

Третий — актуальность баз регионов и их рассинхрон между узлами. Диапазоны переезжают между операторами, базы обновляются по расписанию, и если часть серверов читает старую копию, а внешний фильтр применяет собственную таблицу, один и тот же клиент получает разные решения в зависимости от точки входа. Поверх ложатся ручные правки в конфигурациях: исключения, добавленные под конкретный инцидент, остаются в файлах и постепенно перекрывают исходную логику.

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

Что даёт управление доступом по регионам

Управление доступом по географии ценно не самим фактом «закрыть регион», а измеримым фильтром на входе. Когда правила отсечения стоят на периметре, до приложения доходит только целевой трафик — падает число запросов, которые раньше занимали воркеры и пул соединений.

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

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

Автоматизация правил доступа снимает ручные правки конфигураций. Списки и исключения описываются декларативно, проходят ревью и применяются из одного источника — расхождений между окружениями не возникает, а объём ручных изменений сокращается до нескольких строк на релиз.

Вместе это даёт стабильность работы сервиса: уходит целый класс отказов — переполнение пула соединений и деградация при всплесках из нецелевых регионов. Фильтр работает как штатный предохранитель перед приложением, а не как костыль внутри него.

Сравнение подходов: nginx, Cloudflare, балансировщик

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

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

Ограничения подходов складываются: чем раньше отсекаем, тем дешевле трафик, но тем грубее правила. Гибридная схема обычно даёт лучший баланс — грубый фильтр по странам на входе и точные исключения на сервере.

Порядок внедрения: от аудита до передачи

Геофильтрация редко ломает продакшн в момент включения — проблема приходит позже, когда правила живут в нескольких местах и постепенно расходятся. Поэтому этапы внедрения геофильтрации строим так, чтобы каждое решение опиралось на измеренный трафик, а не на предположение о том, «откуда к нам ходят».

1. Аудит правил доступа и инвентаризация трафика. Собираем реальную картину: доли запросов по странам, источники ботов, уже существующие ограничения на периметре и в приложении. Здесь же видно, кого фильтр затронет первым.
2. Схема фильтрации. Определяем точку принятия решения — край сети или сам веб-сервер, — источник геоданных и поведение при устаревшей базе: пропускать или отклонять. Отдельно фиксируем, что делать с поисковыми роботами и уведомлениями платёжного шлюза.
3. Настройка источников геоданных. Подключаем обновляемую базу адресов, ставим регулярное обновление и контроль рассинхрона между периметром и сервером, чтобы правила не разъезжались.
4. Мягкий режим. Фильтр только пишет в лог и не отдаёт отказ. Держим его столько, сколько нужно, чтобы убедиться: ни один легитимный сценарий не попал в срабатывания.
5. Проверка на тестовом контуре. Прогоняем типовые и граничные запросы из разных регионов, сверяем коды ответов и заголовки, заранее проверяем откат к прежним правилам.
6. Включение и передача с регламентом. Переводим в боевой режим поэтапно, отдаём схему, порядок обновления баз и регламент обслуживания: кто и как добавляет исключения, как быстро откатываем и где смотрим логи.

Что передаём на руки: конфигурации и регламенты

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

• Файлы правил — конфигурации GeoIP на nginx и наборы выражений в Cloudflare, сведённые в репозиторий с историей изменений, а не разбросанные по личным кабинетам.
• Карта схемы прохождения запроса: на каком узле принимается решение о блокировке, какие заголовки доходят до приложения и где подменяется реальный адрес клиента.
• Источники геоданных и расписание их обновления: какая база используется, с какой периодичностью подтягивается и что происходит при недоступности источника.
• Документация по доступам: роли, зоны ответственности, где хранятся ключи, как они ротируются и кто подтверждает выдачу.
• Политики исключений: белые списки для поисковых роботов, мониторинга, платёжных коллбеков и внутренних сервисов — с порядком добавления и согласования.
• Порядок отката изменений: какая правка снимается одной командой, сколько занимает применение и по каким метрикам видно, что блокировка действительно снята.
• Регламент обновления правил: проверка на тестовом контуре, окно применения, кто согласует спорные блокировки и как фиксируется решение.
• Контакты ответственных с обеих сторон и точка эскалации на случай, если правило задело реальных клиентов.

Перед передачей прогоняем сценарий по этим документам по шагам: добавить исключение, откатить изменение, обновить базу. Если какой-то шаг приходится объяснять по памяти — дорабатываем документ, а не оставляем как есть.

Кейс: ложные срабатывания и нагрузка на периметр

Что было до изменений

Интернет-магазин с трафиком из нескольких регионов держал геофильтрацию прямо на периметре: правила на nginx и списки стран на стороне Cloudflare. Диапазоны адресов менялись, а правила обновлялись вручную — дежурный инженер правил конфиги и перезапускал сервис. Ложные срабатывания доходили до 6–8% попыток входа, поддержка разбирала около 40 обращений в неделю.

Побочный эффект — рутина: 2–3 часа в день уходило на сверку списков с логами, а одна ошибочная запись выключала целый регион.

Что изменили

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

Источник данных — логи доступа и выгрузка обращений поддержки за сопоставимые периоды на одинаковом профиле трафика. Канареечное включение дважды поймало проблемные диапазоны до раскатки на весь трафик — эти отказы не дошли до клиентов.

Чем GeoIP блокировка на nginx отличается от Cloudflare

В обоих случаях работает одна и та же логика «регион по базе — правило — отказ», но точка принятия решения разная. GeoIP блокировка на сервере живёт в конфигурации nginx: запрос доходит до машины, адрес сверяется с базой геолокации, и только затем запрос либо уходит в приложение, либо получает отказ. На стороне CDN проверка происходит на узле провайдера — до того, как трафик вообще попадёт в ваш контур.

Отсюда главное расхождение — определение региона клиента за прокси. Если перед сервером стоит балансировщик или CDN, сокет отдаёт адрес промежуточного узла, а не посетителя. Без корректно настроенных доверенных прокси и заголовка с исходным адресом фильтр начнёт сравнивать регион самого промежуточного звена — правило формально работает, а решение принимается по чужим данным. На стороне CDN адрес клиента известен изначально, подменять его нечем, но и влиять на эту часть цепочки вы не можете.

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

По задержке и нагрузке разница тоже ощутима. Локальная фильтрация не ускоряет ответ: запрос всё равно занимает соединение и обработку на сервере, зато даёт полный контроль над правилами, логикой исключений и журналами отказов. Фильтрация на стороне CDN отсекает трафик раньше — снимает нагрузку с канала и приложения, но менее гибкая. На практике подходы совмещают: CDN работает грубым первичным фильтром, nginx — вторым слоем и точкой для нестандартных правил.

Частые технические сомнения перед стартом

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

Блокировка не заденет живых клиентов?

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

Насколько актуальны геоданные?

Наборы обновляются раз в одну-две недели, и для части диапазонов страна не определена. Такие запросы по умолчанию не считаем нарушителями — правило для них задаём отдельно.

Партнёры и сервисы за рубежом не отвалятся?

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

Как проверить правило до запуска?

Сначала режим наблюдения: запросы логируются, но не отсекаются. По логам видно объём, страны и затронутые сценарии. Полную блокировку включаем последней, с планом отката.

Обсудим задачу и вернёмся с планом внедрения

Чтобы обсудить задачу предметно и вернуться с планом внедрения, а не с общими соображениями, нам нужны исходные данные для оценки. Гео-правила работают по-разному в зависимости от того, где завершается шифрование, какие сервисы стоят за сетью доставки и кто должен остаться в белом списке — от этого зависит и объём работ, и порядок включения.

• Схема прохождения трафика: где именно терминируется соединение, какие узлы стоят перед приложением, есть ли промежуточные звенья и балансировщики.
• Перечень сервисов и регионов: какие домены и приложения попадают под ограничение, из каких стран их открывают легальные пользователи.
• Текущие правила: существующие гео-списки, статические сети, правила на веб-сервере и на стороне сети доставки, порядок их применения.
• Требования к исключениям: кого блокировать нельзя — поисковых роботов, системы мониторинга, платёжные и партнёрские адреса, корпоративные выходы сотрудников.
• Требования к доступам: какие роли нужны в панели управления и на серверах, кто подтверждает изменения и согласует окно работ.
• Режим запуска: сначала наблюдение без блокировки со сбором статистики, затем точечное включение по регионам, затем полное применение с откатом одной правкой.
• Критерии приёмки: какие метрики считаем успехом, какую долю ложных срабатываний допускаем и за какой срок выходим на целевые значения.

С таким набором мы сразу видим узкие места и предлагаем реалистичный порядок шагов. Опишите задачу и пришлите то, что есть, — вернёмся с оценкой сроков и планом внедрения.