«Чистый» IPv4 в 2026 году: что проверить до аренды сервера и подсети

2026-07-17

0 1 325 Автор: Tunecom

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

Чистый IPv4 в 2026 году

С железом при этом всё в порядке. Проблема — в IP-адресе, истории его использования и репутации соседней сети.

На профильных форумах подобные ситуации обсуждают постоянно. Пользователь получает новый IPv4 и не понимает, почему адрес уже вызывает подозрения, хотя сам он ещё ничего с него не запускал. Другой арендует сервер в Нидерландах, а часть сервисов определяет его как американский. Третий покупает порт 10 Гбит/с без ограничения трафика, но после нескольких дней постоянной нагрузки обнаруживает скрытый fair use.

Раньше при выборе сервера смотрели прежде всего на процессор, память и диски. Сейчас этого недостаточно. Для рабочего проекта IP-адрес, маршрут, геолокация, правила защиты от атак и условия использования канала могут оказаться важнее лишних ядер процессора.

Универсально «чистых» IP-адресов не существует

Формулировка «чистый IPv4» звучит так, будто у адреса есть единый сертификат качества. На практике разные системы оценивают его по-разному.

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

Поэтому отсутствие адреса в одном публичном блэклисте ещё не означает, что с ним не возникнет проблем. Отдельный IPv4 может выглядеть нормально, но весь диапазон /24 уже иметь плохую историю. Бывает и обратная ситуация: автоматический сервис показывает высокий риск, хотя нужные клиенту сайты и API работают без ограничений.

Проверять адрес нужно не абстрактно, а под конкретную задачу.

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

Хороший вопрос провайдеру звучит не как «IP точно чистый?», а так:

можно ли получить тестовый адрес из предлагаемого диапазона;
проверяется ли только один IPv4 или вся подсеть;
использовался ли диапазон ранее другим клиентом;
можно ли заменить адрес, если он не проходит необходимые проверки;
что происходит, если проблема затрагивает весь диапазон или ASN;
кто занимается снятием ошибочных блокировок.

Гарантировать репутацию навсегда невозможно: она меняется в зависимости от использования адресов. Но проверить исходное состояние и порядок решения проблем до оплаты вполне реально.

Сервер может находиться в одной стране, а IP — «жить» в другой

Физическая локация сервера и геолокация его адреса — не одно и то же.

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

Запись в реестре показывает владельца ресурса, но не обязательно фактическое место его использования. BGP показывает, откуда сеть объявляется, но разные базы интерпретируют эти данные по-своему. Geofeed помогает сообщить актуальную страну и город, однако изменения не появляются одновременно во всех сервисах.

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

Перед долгой арендой нужно проверить:

как адрес определяется несколькими GeoIP-базами;
что показывают Google и другие необходимые проекту платформы;
откуда фактически проходит маршрут;
публикует ли оператор geofeed;
помогает ли он отправлять исправления в геолокационные базы;
сколько обычно занимает обновление.

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

Аренда подсети — это зависимость от владельца адресов

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

При аренде подсети клиент не становится её владельцем. Он зависит от организации, на которую зарегистрирован ресурс. Именно она может создавать необходимые объекты, выдавать разрешение на анонс и вносить изменения в данные сети.

Поэтому при аренде на полгода или год важно обсуждать не только цену за адрес. В договоре или тикете необходимо зафиксировать:

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

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

LoA, IRR и ROA отвечают на разные вопросы

При внешнем анонсе подсети одного письма LoA может быть недостаточно.

LoA подтверждает, что владелец разрешает определённой автономной системе объявлять диапазон. Объект route в IRR описывает предполагаемую маршрутизацию. ROA в системе RPKI указывает, какой ASN действительно имеет право публиковать этот маршрут.

Если Origin ASN в ROA не совпадает с реальным анонсом, сети с включённой проверкой ROV могут считать маршрут недействительным и отбрасывать его. В результате часть интернета будет видеть подсеть, а часть — нет. Такая ошибка особенно неприятна тем, что с одного рабочего места всё выглядит нормально, а пользователи из других сетей жалуются на недоступность.

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

Перед подключением арендованной подсети стоит выяснить:

кто создаёт и изменяет ROA;
какой ASN будет указан как Origin;
кто публикует route-объекты в IRR;
можно ли использовать собственный ASN;
сколько занимает изменение записей при миграции;
кто настраивает PTR и обратные DNS-зоны;
существует ли план отката при ошибочном анонсе.

Если поставщик передаёт LoA и предлагает всё остальное сделать самостоятельно, это не готовая сетевая услуга. Клиенту потребуется собственный специалист, который понимает BGP, RPKI и работу реестров.

Почему 10 Гбит/с не всегда означают 10 Гбит/с

Одна из самых конфликтных тем на хостинговых форумах — значение слова unmetered.

Порт сервера действительно может поддерживать 10 Гбит/с. Но это не гарантирует, что клиент сможет постоянно передавать данные на полной скорости. Аплинк может быть общим, гарантированная полоса — значительно ниже, а правила fair use разрешать кратковременные пики, но не постоянную загрузку.

Unmetered обычно означает, что провайдер не выставляет отдельный счёт за каждый переданный терабайт. Это не всегда означает отсутствие ограничений скорости, месячного объёма или правил допустимого использования.

До оплаты необходимо получить ответы на конкретные вопросы:

порт выделенный или разделяется с другими серверами;
какая полоса гарантируется постоянно;
одинаковы ли условия для входящего и исходящего трафика;
существует ли месячный лимит;
применяется ли fair use;
считается ли нагрузка по 95-му процентилю;
что произойдёт при постоянной загрузке порта;
возможны ли снижение скорости, доплата или блокировка;
учитывается ли паразитный трафик во время DDoS-атаки.

Для рабочего проекта честные гарантированные 1–3 Гбит/с могут быть полезнее рекламного порта 10 Гбит/с с неопределёнными ограничениями.

«Защита от DDoS включена» тоже ничего не объясняет

Современные атаки могут быть очень мощными и при этом продолжаться всего несколько десятков секунд. За это время инженер не успеет прочитать тикет и вручную включить фильтрацию. Защита должна срабатывать автоматически.

Но даже автоматическая фильтрация бывает разной. Один оператор очищает сетевой трафик, другой при превышении порога отправляет атакованный адрес в null-route. Формально сеть защищена, но сервис клиента становится недоступным. Некоторые решения работают только с атаками L3/L4, но не защищают веб-приложение на уровне HTTP. Для игр, VoIP, VPN и нестандартных UDP-протоколов могут требоваться отдельные профили.

Вместо вопроса «есть ли DDoS-защита?» стоит уточнить:

фильтрация постоянная или включается после обнаружения;
какие типы атак и протоколы поддерживаются;
при каком объёме применяется null-route;
как долго адрес остаётся заблокированным;
защищается один IP или вся выданная подсеть;
можно ли настроить отдельный профиль под приложение;
предоставляется ли статистика атаки;
возникают ли дополнительные платежи за очищенный трафик.

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

Старый Xeon с сорока потоками не всегда быстрее современного Ryzen

Ещё один популярный спор — что выбрать: недорогой сервер с двумя старыми Xeon, современный Ryzen или конфигурацию на EPYC.

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

Для виртуализации, множества контейнеров, больших объёмов памяти и параллельных вычислений важнее количество ядер, каналы памяти, ECC и линии PCIe. Там EPYC или серверный Xeon могут оказаться разумнее.

При долгой аренде нужно смотреть не только на модель CPU:

какие установлены накопители и можно ли проверить их состояние;
используется ли аппаратный или программный RAID;
доступны ли IPMI или KVM;
есть ли запас дисков, памяти и блоков питания на площадке;
чем заменят сервер при аппаратной аварии;
сохранится ли подсеть при переносе на другую машину;
можно ли увеличить память, диски или канал без полного переезда.

Бонусные месяцы не помогут, если после отказа диска провайдер несколько дней ищет совместимую замену.

Когда имеет смысл оплачивать сервер и адреса на 6–12 месяцев

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

Оплачивать длительный срок разумно, когда:

протестирован именно будущий сервер или эквивалентная конфигурация;
проверен конкретный IP или диапазон, который получит клиент;
геолокация подходит под реальные сервисы проекта;
понятна история подсети и порядок работы с блокировками;
согласованы PTR, WHOIS, LoA, IRR и ROA;
зафиксированы гарантированная полоса и правила fair use;
описано поведение защиты при атаке;
провайдер закрепляет адреса на весь оплаченный период;
известны правила продления, изменения цены и досрочного прекращения;
оборудование можно заменить или расширить без потери адресов.

На практике удобнее, когда сервер, адресное пространство и маршрутизацию сопровождает один подрядчик. В HSTQ можно одним запросом согласовать выделенный сервер, IPv4-подсеть, PTR/WHOIS, LoA и подключение через BGP или GRE — однако конкретный диапазон и условия всё равно следует проверить до оплаты.

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

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