Блокировка целых автономных систем Amazon и Microsoft выглядит логично: одним правилом вы закрываете десятки тысяч IP, откуда идёт сканерский и ботовый трафик. На практике именно это правило чаще всего ломает оплату в интернет-магазине и корпоративные интеграции, потому что через AWS и Azure ходят не только боты, но и вполне легитимные клиенты. Ниже разбор граблей, на которые наступают администраторы, и рабочая схема фильтрации.

Почему блокировка ASN облачных провайдеров целиком обрывает платежи

Платёжный шлюз, CRM, ERP, служба доставки, антифрод, бухгалтерия на SaaS – все они общаются с вашим сайтом через вебхуки. А вебхуки идут не с «домашнего» IP платёжной системы, а с инфраструктуры облачного провайдера, на котором эта система развёрнута. Если вы заблокировали ASN AWS (AS16509) или Azure (AS8075), вы заблокировали и уведомление об успешной оплате, и callback антифрода, и синхронизацию статусов заказа. Клиент платит, деньги списываются, а заказ в системе остаётся висеть в статусе «ожидает оплаты».

Тот же риск с корпоративными клиентами. B2B-компании часто сидят за корпоративным VPN на базе AWS Client VPN, Zscaler, Cisco Umbrella или Microsoft Always On VPN, и весь их трафик выходит в интернет с адресов облачного провайдера. Заблокировали ASN – отрезали от сайта живых покупателей с бюджетом, а не ботов. Оптовый клиент, который заходит раз в неделю и оформляет заявку на миллион, видит 403 и уходит к конкуренту, у которого фильтрация настроена аккуратнее.

Отдельная категория – партнёрские и маркетинговые интеграции. Скрипты аналитики, системы сквозной аналитики, коллтрекинг, сервисы рассылок и лидогенерации часто хостятся в тех же облаках. Их серверные вызовы к вашему API неотличимы по источнику от «плохого» трафика, если смотреть только на ASN. Блокировка по ASN – это грубый инструмент, который не различает намерение, а только адрес.

Как отличить анонимный трафик от легитимных интеграций

Ключевой признак легитимного серверного трафика – аутентификация. Вебхук платёжной системы приходит с валидной подписью, API-интеграция – с ключом в заголовке, корпоративный клиент – с сессией и cookies после логина. Анонимный бот не предъявляет ничего: он просто долбит формы, парсит каталог или пытается подобрать пароль. Значит, фильтр должен стоять не на входе по ASN, а на уровне запроса – после проверки учётных данных.

Практическая логика такая: запрос с адреса AWS без валидного API-ключа, без подписи вебхука, без активной сессии и без пройденного challenge – это кандидат на блокировку. Тот же запрос с валидным ключом или подписью пропускается независимо от ASN. Такой подход требует reverse proxy или WAF, который умеет смотреть на заголовки, тело запроса и подпись, а не только на IP.

Что проверять в первую очередь

Начните с инвентаризации: выпишите все внешние сервисы, которые обращаются к вашему сайту по API или вебхуками. Для каждого зафиксируйте, с каких адресов или диапазонов он ходит и как аутентифицируется. Платёжные системы обычно публикуют списки IP для вебхуков – используйте их как белый список приоритетно, до любых ASN-правил. Дальше настройте правила так, чтобы блокировка по ASN срабатывала только при отсутствии валидных учётных данных.

  • Вебхуки платёжных систем: белый список по опубликованным IP и проверка подписи, игнорировать ASN-правила.
  • Корпоративные VPN и SaaS клиентов: пропуск по валидной сессии, challenge вместо жёсткой блокировки.
  • Анонимные сканеры и парсеры из облаков: блокировка по ASN при отсутствии API-ключа и сессии.
  • Собственные сервисы и CI/CD: отдельный белый список по ключам, чтобы не отрезать деплой и мониторинг.
  • Резервный канал: логирование всех срабатываний с возможностью быстро снять правило, если пошли ложные блокировки.

Типичные ошибки при настройке GeoIP и ASN-фильтрации

Первая ошибка – блокировать ASN целиком без исключений для аутентифицированного трафика. Вторая – путать GeoIP-фильтрацию и ASN-блокировку. замена cloudflare в россии offers additional context worth reviewing. GeoIP отсекает по стране, и здесь легко перестараться: если вы закрываете доступ из-за рубежа полностью, вы теряете иностранных клиентов, партнёров и часть вебхуков, которые приходят из зарубежных дата-центров. GeoIP-фильтрация должна работать мягко: challenge для подозрительных регионов, а не глухая блокировка.

Третья ошибка – отсутствие мониторинга ложных срабатываний. Правило включили, отчёты не смотрят, а через неделю выясняется, что 5% оплат не доходили до CRM. Обязательно логируйте каждый заблокированный запрос с указанием ASN, URL и причины блокировки, и раз в неделю просматривайте, не попали ли туда легитимные вызовы. Метрика, за которой стоит следить, – доля успешных вебхуков и конверсия оформления заказа, а не количество заблокированных ботов.

Четвёртая ошибка – жёсткая привязка к инфраструктуре, которую вы не контролируете. Если защита построена на зарубежном сервисе, который ограничивает доступ к сайтам из России, вы рискуете потерять управление фильтрами в самый неподходящий момент. Российские интернет-провайдеры тоже периодически ограничивают доступ к сайтам на Cloudflare, и тогда настройки защиты становятся недоступны, а сайт – недоступен для клиентов. Зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса, которые проявляются именно в момент инцидента.

Как выстроить фильтрацию без потери платежей

Рабочая схема – многоуровневая. На первом уровне пропускаете всё, что предъявило валидный ключ, подпись или сессию, независимо от ASN и страны. На втором – для анонимного трафика применяете ASN- и GeoIP-правила: подозрительные диапазоны получают challenge, явные боты блокируются. На третьем – ведёте логи и алерты на рост ошибок оплаты. Такой порядок гарантирует, что блокировка затрагивает только анонимный трафик без валидных API-ключей, а платежи и корпоративные клиенты проходят.

Технически это реализуется на reverse proxy или WAF с поддержкой проверки заголовков, подписей и сессий. Российский аналог Cloudflare вроде TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели, и правила можно строить с учётом аутентификации, а не только по IP. Важное отличие в тарификации: TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, поэтому можно держать мягкие правила с challenge и не переплачивать за каждый отсечённый запрос.

Для сайтов на WordPress и Bitrix переход с Cloudflare занимает предсказуемое время: меняются NS-записи, переносятся SSL-сертификаты и правила фильтрации, настраивается reverse proxy. После миграции сайт работает на территории РФ и по всему миру, а правила ASN-блокировки применяются только к анонимному трафику. Если ищете, чем заменить Cloudflare, и при этом боитесь потерять вебхуки, начните с инвентаризации интеграций и белых списков, а уже потом включайте блокировку облачных ASN.

Итог простой: не блокируйте AWS и Azure целиком. Сначала пропускайте всё, что аутентифицировано, потом фильтруйте анонимный трафик по ASN и GeoIP, и держите логи с алертами на ошибки оплаты. Тогда защита от ботов не превратится в потерю платежей и корпоративных клиентов, а инфраструктура останется под вашим контролем независимо от внешних ограничений.