Ваш IP забанили за соседа: как работают блокировки по целой подсети

MAATRIX

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

Почему банят подсеть, а не IP

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

Поэтому у защитных систем есть простая экономическая логика: если из блока /24 (256 адресов) или /22 (1024 адреса) стабильно идёт вредоносная активность с нескольких точек внутри диапазона, дешевле и надёжнее забанить весь блок или привязать репутацию к ASN (номеру автономной системы — грубо говоря, к оператору сети) целиком, чем гоняться за каждым отдельным адресом. Это снижает нагрузку на защитную систему и закрывает лазейку «поменял IP — снова чист».

Эта логика встроена в очень разные слои инфраструктуры:

• Спам-фильтры почтовых провайдеров — репутация считается не только по IP отправителя, но и по диапазону/ASN, особенно если это первое письмо с адреса без истории.
• DNS-based blacklist листы (DNSBL/RBL) — часть списков публикует записи не только на отдельные IP, но и на целые CIDR-блоки, особенно для известных «плохих» хостинг-диапазонов.
• Антифрод-системы платёжных шлюзов и SaaS-сервисов — банят по ASN или подсети, если оттуда массово идут фрод-паттерны (карточный фрод, фейковые регистрации, брутфорс).
• Файрволы и WAF сторонних сервисов — некоторые публичные API и облачные сервисы держат списки «подозрительных диапазонов хостинг-провайдеров» и режут по ним трафик заранее, до анализа конкретного запроса.

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

Почему это особенно бьёт по дешёвому и массовому хостингу

Проблема не распределена равномерно. У крупного облачного провайдера с миллионами клиентов и активным контролем злоупотреблений IP-пространство тоже переиспользуется, но там обычно есть автоматизированный abuse-мониторинг, который быстро гасит нарушителей и снижает шанс, что весь блок «протухнет». У маленьких и дешёвых хостеров ситуация часто хуже по нескольким причинам:

• Быстрая ротация клиентов. Дешёвый VPS — это часто минимальный порог входа: оплата криптой без верификации, мгновенная активация. Это удобно и добропорядочным клиентам, и тем, кто арендует сервер на неделю специально под спам-рассылку или брутфорс, зная, что его быстро забанят и просто бросят.
• Ограниченный abuse-контроль. Небольшая команда хостера физически не успевает разбирать каждую жалобу за часы — а внешние блэклисты реагируют быстро и автоматически.
• Ограниченный пул IP. У хостера может быть один-два блока /22-/20 на весь дата-центр. Если внутри такого узкого пространства случилось несколько эпизодов злоупотреблений подряд, репутационный урон концентрируется на небольшом числе адресов, которые потом просто переиспользуются для новых клиентов — в том числе для вас.
• История «до вас». IP, который вам выдали сегодня, мог до этого принадлежать десяткам разных арендаторов за последние годы. Если один из них был спамером или держал C2-сервер ботнета, след в некоторых блэклистах может сохраняться месяцами, даже если конкретно ваш IP никогда лично не нарушал правил.

Это не значит, что дешёвый хостинг — плохой выбор. Это значит, что при выборе конкретного провайдера и конкретного дата-центра репутацию IP-пространства стоит проверять так же осознанно, как заявленные CPU и RAM.

Как понять, что дело именно в этом

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

1. Проблема появилась сразу после аренды, без изменений в вашем софте — вы ничего не рассылали и не сканировали, а блокировка уже есть в первый день.
2. Блокировка касается сервиса целиком, а не конкретного действия. Например, письма с вашего сервера отклоняются на уровне SMTP-хендшейка (до анализа содержимого), или API стороннего сервиса возвращает отказ по IP-репутации в самом теле ошибки.
3. Проверка вашего кода и конфигов ничего не находит — почтовый сервер настроен корректно, SPF/DKIM/DMARC на месте, лишнего трафика с сервера не уходит (это стоит проверить через iftop, nethogs или логи исходящих соединений — на случай, если сервер всё-таки скомпрометирован и реально что-то шлёт).
4. Соседние IP из того же диапазона тоже числятся в блэклистах — это самый прямой признак проблемы уровня подсети, а не вашего конкретного адреса.

Проверка честности собственного сервера — обязательный первый шаг: если это ваш сервер реально скомпрометирован и шлёт спам, смена IP ничего не даст, вы просто испортите репутацию следующему адресу. Разбор именно такого сценария — в статье «Сервер начал рассылать спам ночью: как это понять».

Диагностика: проверка репутации своего IP и подсети

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

• Blacklist-чекеры общего назначения. Существует категория публичных веб-сервисов, которые опрашивают сразу десятки известных DNSBL/RBL-списков по вашему IP и показывают, в каких именно вы числитесь. Это первый и самый быстрый шаг диагностики.
• Проверка вручную через DNS-запрос к конкретному блэклисту. Многие DNSBL работают по простому принципу: вы делаете обратный DNS-запрос к IP, добавленному в специальный домен листа. Например, для проверки IP 192.0.2.1 в листе с доменом-примером example.dnsbl.org запрос выглядит так:

dig +short 1.2.0.192.example.dnsbl.org

(октеты IP переставляются в обратном порядке перед доменом листа). Если ответ пустой — IP не числится в этом конкретном листе; если возвращается адрес вида 127.0.0.x — числится, и код в последнем октете обычно указывает причину.

• Проверка не только своего IP, но и соседей по /24. Если у вас есть IP вида 203.0.113.45, стоит прогнать через тот же чекер несколько соседних адресов (.40–.50) — если большинство тоже в списках, это подтверждает проблему уровня подсети, а не персональную.
• Определение ASN и владельца блока. Команда whois по вашему IP покажет, какой подсети и ASN он принадлежит:

whois 203.0.113.45 | grep -iE "netname|origin|route|descr"

Это полезно, если вы хотите проверить репутацию всего блока через инструменты класса «IP reputation lookup» или почитать публичные жалобы на конкретный ASN.

• Тестовая отправка почты через сторонние проверочные ящики (например, создать тестовое письмо и посмотреть его полный заголовок после доставки в разные почтовые системы) — покажет, на каком именно этапе и по какой причине письмо помечается как спам. Подробный разбор пути письма и того, что смотреть в заголовках, — в статье «Как письма попадают в спам: разбор пути».

Если проверка подтвердила, что в блэклистах числится не только ваш IP, а весь диапазон или заметная его часть — это довод для обращения к хостеру, а не повод переустанавливать почтовый сервер с нуля.

Что делать: разговор с хостером

У большинства хостеров есть штатная процедура на такой случай, потому что ситуация типовая, а не уникальная для вас. Порядок действий:

1. Соберите доказательства. Скриншоты или текстовый вывод blacklist-чекера с указанием конкретных листов, где числится IP; результат whois с ASN; если это про почту — заголовки отклонённых писем с текстом ошибки (обычно там прямо написано что-то вроде «IP listed» или код блэклиста).
2. Откройте тикет в поддержку с конкретной формулировкой. Не «у меня всё не работает», а «IP X.X.X.X числится в листах A и B, вот подтверждение, прошу либо очистить репутацию блока, либо выдать IP из другого диапазона». Конкретика ускоряет обработку в разы.
3. Запросите смену IP, если репутация блока действительно испорчена. У адекватного хостера это штатная операция — обычно бесплатная или за символическую плату, и не требует пересоздания сервера с нуля (IP можно переназначить на существующую машину). Уточните: относится ли новый IP к тому же диапазону (тогда риск повторной проблемы высок) или к отдельному, менее нагруженному пулу.
4. Если хостер отказывается или не может помочь — это сигнал, что стоит рассматривать переезд. Хронически «грязное» IP-пространство — это не разовая неприятность, а системная проблема провайдера, которая будет повторяться с каждым новым адресом из того же пула.
5. После смены IP запросите делистинг из ключевых блэклистов сами, если это критично для почты — часть листов снимает блок автоматически по истечении срока (от часов до недель), часть требует ручной заявки через форму на сайте самого листа с указанием причины и даты исправления.

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

Как избежать проблемы заранее

Дешевле проверить IP до аренды, чем разбираться с блокировками после. Практический чек-лист перед заказом сервера, особенно если на нём будет работать email-инфраструктура, платёжный бэкенд или что-то ещё, чувствительное к репутации адреса:

• Спросите у хостера напрямую, есть ли у них политика ротации и очистки IP-пространства после ухода клиентов, и что они делают при обнаружении злоупотреблений — быстрая блокировка нарушителя защищает репутацию всего пула, в том числе вашу в будущем.
• Проверьте выданный IP через blacklist-чекер сразу после активации сервера, до того как начали что-то на нём разворачивать. Если IP уже в нескольких листах — это повод сразу запросить замену, не тратя время на настройку сервиса на «грязном» адресе.
• Для почтовой инфраструктуры проверка обязательна регулярно, а не разово — IP может быть чистым сегодня и попасть в блэклист через месяц из-за действий соседей по подсети, даже если вы ничего не меняли. Регламент такой периодической проверки, включая репутацию IP, разобран в статье «Ежемесячная проверка доставляемости почты с вашего сервера».
• Учитывайте, что физическая близость сервера к вашим пользователям — не единственный критерий выбора локации. Иногда важнее выбрать дата-центр с более «чистым» и менее нагруженным IP-пулом, чем гнаться за минимальным пингом — тем более что сам маршрут трафика редко идёт по кратчайшей географической линии, это разобрано в статье «Почему пакет из Москвы в Питер идёт через Стокгольм».
• Для проектов с высокими требованиями к репутации (транзакционная почта, антифрод-чувствительные API) рассматривайте выделенный IP отдельно от общих пулов — там, где это технически возможно, а не default-адрес, который мог использоваться десятками предыдущих арендаторов подряд.

Частые вопросы