Можно ли сохранить IPv4-подсеть при смене серверного провайдера

Да, если право использования адресов сохраняется после переезда, а новая площадка готова подключить подсеть. Это нужно согласовать до отключения старых серверов.

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

В каких случаях адреса можно сохранить

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

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

Запись с названием вашей компании в WHOIS сама по себе не определяет условия переноса. Нужно проверить договор и полномочия стороны, которая разрешает использование подсети.

Почему важен размер блока

Чтобы трафик из интернета приходил на новую площадку, сеть должна объявить маршрут к подсети. Такое объявление называют BGP-анонсом.

Для самостоятельного анонса IPv4 в глобальном интернете обычно рассматривают /24 и более крупные блоки. В /24 содержится 256 адресов. Более мелкие блоки, например /25 или /27, многие операторы фильтруют. Поэтому рассчитывать на их повсеместную доступность как отдельных маршрутов нельзя.

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

На странице аренды IPv4-подсетей HSTQ это различие отражено в условиях: для /27–/25 внешний анонс и LoA не предусмотрены, а для /24–/22 такие возможности указаны. Конкретную площадку и схему подключения согласуют до заказа.

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

Что согласовать с новым провайдером

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

Обычно обсуждают следующие вопросы.

Разрешение на анонс. Провайдер может запросить LoA — письмо от держателя ресурса или уполномоченной стороны. В нём указывают подсеть и разрешённую схему анонса. Документ должен соответствовать фактическому подключению.

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

Маршрутные записи. Сетевые инженеры проверяют записи IRR и разрешения ROA в RPKI. Они должны соответствовать префиксу и ASN, из которой он будет анонсироваться. Несоответствие может привести к тому, что часть сетей отвергнет маршрут.

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

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

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

Как подготовить перенос

1. Сохранить действующие услуги на время перехода

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

Заранее определите условия возврата на старую площадку, если переключение пройдёт неудачно.

2. Подготовить приложение и данные

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

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

3. Проверить документы и маршрутные разрешения

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

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

4. Согласовать порядок переключения

В плане должны быть указаны ответственные, последовательность изменения маршрутов, ожидаемое окно работ и критерии отката.

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

Возможность переезда без заметного простоя оценивают по всей схеме. Существующие соединения могут оборваться даже при сохранении IP, если новое оборудование не располагает состоянием прежних сессий.

5. Проверить результат снаружи

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

Также нужно проверить:

• работу сайта, API или других используемых сервисов;
• исходящий IP при обращении к партнёрам;
• видимость маршрута и соответствие анонса разрешениям RPKI;
• PTR-записи и почтовые операции, если используется собственная почта;
• подключения, для которых у партнёров настроены ограничения по IP.

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

Можно ли сохранить небольшую подсеть через туннель

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

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

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

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

Что делать, если адреса придётся заменить

Смена IP становится управляемой задачей, если подготовить её заранее.

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

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

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