Да, арендованную IP-подсеть можно сохранить при переезде в другой дата-центр, если владелец адресов разрешает использовать её в новой сети, а принимающий провайдер готов подключить именно этот блок. Эти условия нужно подтвердить до заказа сервера: наличие услуги BYOIP на сайте ещё не означает, что площадка примет любую арендованную подсеть.
При таком переезде адреса остаются прежними, но меняется маршрут, по которому интернет-трафик доходит до ваших серверов. Данные, приложения и сетевые настройки переносятся отдельно. Сохранение IP помогает избежать перенастройки клиентов и списков разрешённых адресов, однако само по себе не гарантирует работу сервисов без перерыва.
Какие адреса получится забрать с собой
Сначала выясните, на каких условиях вам предоставлены IP.
- Отдельно арендованная подсеть с разрешением на внешний анонс. Обычно это подходящий вариант для переезда. Понадобятся согласование новой сети и подготовка разрешений на анонс.
- Адреса, выданные вместе с сервером. Возможность использовать их может зависеть от аренды этого сервера. Уточните, готов ли провайдер оставить подсеть за вами как отдельную услугу и разрешить подключение на другой площадке.
- Несколько отдельных IP или небольшой блок, например /29. Их обычно нельзя самостоятельно объявить всему интернету через нового оператора. Для IPv4 широко применяется фильтрация маршрутов длиннее /24. Поэтому перенос небольшого блока может потребовать участия прежнего провайдера и специальной схемы доставки трафика.
Разбить /24 на два блока /25 и переносить их по очереди — ненадёжный способ: такие анонсы могут не приниматься значительной частью сетей. Для обычного переезда самостоятельной IPv4-подсети планируйте переключение всего /24.
Что согласовать с владельцем подсети
Главный вопрос — продолжит ли действовать аренда адресов после отказа от старого сервера или смены дата-центра. Получите письменное подтверждение в договоре, дополнительном соглашении или тикете.
В подтверждении должны быть понятны следующие условия:
- Какой именно префикс разрешено перенести, в какую сеть и, если есть ограничения, в какую страну.
- Сохраняются ли срок аренды и стоимость после переезда.
- Нужно ли отдельно оплачивать смену ASN, выпуск нового LOA или изменение записей в реестрах.
- Кто подготовит разрешения для нового оператора и сколько времени это займёт.
- Можно ли сохранить разрешения для прежней сети на период проверки и возможного возврата.
- Кто будет управлять обратными DNS-записями после переезда.
Особенно внимательно оформляйте отказ от старых услуг. Если сервер и подсеть находятся в одном заказе, попросите поддержку подтвердить, что закрытие сервера не приведёт к прекращению аренды IP.
Если подсеть предоставил посредник, выясните, кто фактически может подписать разрешение на анонс и изменить RPKI. Ответ «передадим запрос владельцу» означает дополнительный этап согласования, который нужно учесть в сроках.
Что получить от нового провайдера до оплаты сервера
Отправьте точный префикс, сведения о его арендодателе и выбранную локацию. Попросите подтвердить возможность подключения к конкретному выделенному серверу или тарифу. Услуга может быть доступна только в части дата-центров либо иметь ограничения по размеру блока, региональному реестру и способу подтверждения права пользования.
Собственный ASN нужен не всегда. Провайдер может анонсировать подсеть из своей автономной системы. Если используется ваш ASN, согласовываются BGP-подключение и маршрутизация через новую сеть. Для разрешений нужен именно origin ASN — номер автономной системы, которая будет указана источником маршрута.
Кроме возможности анонса уточните:
- Как подсеть попадёт на сервер. Провайдер должен выдать схему подключения: шлюз, маршруты, VLAN или параметры BGP. Старые сетевые настройки могут не подойти.
- Разрешён ли исходящий трафик с этих IP. Фильтры против подмены адресов должны учитывать вашу подсеть, иначе входящие запросы могут доходить, а ответы сервера — отбрасываться.
- Как работает защита от DDoS. Уточните, распространяется ли она на принесённые адреса и потребуются ли дополнительные разрешения на анонс для защитной сети.
- Когда можно подготовить подключение. Можно ли выполнить проверку документов и настройку, пока подсеть ещё работает в старом дата-центре? На каком этапе требуется снять прежний анонс?
- Что входит в стоимость. Отдельные платежи могут относиться к подключению префикса, BGP, трафику, защите и сетевому сопровождению.
Если подбираете выделенный сервер QCKL вместе с арендованной подсетью, перед оплатой согласуйте префикс, локацию и способ анонса с поддержкой. Для подсетей предоставляется LOA, а BGP-анонс подключается отдельно. Возможность подключения нужно подтвердить для выбранной конфигурации.
Какие документы и записи подготовить
Единого пакета для всех дата-центров нет. Одному оператору достаточно LOA и корректных записей маршрутизации, другой дополнительно запросит подтверждение через WHOIS/RDAP. Получите его требования заранее и передайте владельцу адресов.
| Что подготовить | Для чего это нужно | Что проверить |
|---|---|---|
| Подтверждение права пользования подсетью | Показывает, что владелец разрешает использовать адреса в новой сети. | Указан нужный префикс, аренда действует, внешний анонс разрешён. Форма подтверждения подходит принимающему провайдеру. |
| LOA — Letter of Authorization | Разрешает указанному оператору анонсировать подсеть. | Верны префикс, ASN, данные получателя, дата и срок действия, если он предусмотрен. Документ выдан владельцем или уполномоченной стороной. |
| Объект route в IRR | Используется операторами при формировании фильтров допустимых маршрутов. | Префикс и origin ASN соответствуют будущему анонсу. Реестр и порядок создания согласованы с новой площадкой. |
| ROA в RPKI | Подтверждает, какая автономная система вправе объявлять префикс. | Разрешён будущий origin ASN, а допустимая длина префикса соответствует анонсу. |
LOA, запись в IRR и ROA выполняют разные задачи. Отправка LOA в поддержку сама по себе не изменяет маршрутизацию. Запись route тоже не запускает BGP-анонс: сетевую конфигурацию должен подготовить оператор.
При смене origin ASN заранее добавляют разрешение для новой автономной системы. Если существующий ROA разрешает только прежний ASN, а нового разрешения нет, новый маршрут может получить статус RPKI Invalid и отбрасываться сетями, которые фильтруют такие объявления.
Для двух origin ASN создают отдельные ROA. Это позволяет подготовить новую площадку, пока старая ещё работает. Разрешение для прежней сети сохраняют на согласованный период возврата. Если origin ASN и объявляемый префикс остаются прежними, само изменение дата-центра не требует нового ROA.
Как организовать переключение
В переезде участвуют владелец адресов, старый и новый сетевые операторы, а также администратор серверов. Иногда несколько ролей выполняет одна компания, но ответственность всё равно нужно разделить: кто меняет разрешения, кто переключает маршруты и кто проверяет приложения.
-
Подготовьте новый сервер и перенесите основную часть данных. Установите приложения, перенесите конфигурацию, сертификаты и резервные копии. Проверьте сервисы через временный адрес или изолированное подключение. Сохраните доступ через служебный IP или консоль на случай ошибки в маршрутизации.
-
Завершите согласование подсети. Новый провайдер должен принять документы, подтвердить готовность маршрутов и фильтров. Дождитесь, чтобы новые разрешения RPKI были видны при проверке. Подготовка документов и обновление фильтров могут занять больше времени, чем само переключение BGP.
-
Зафиксируйте окно работ. Укажите дату, время с часовым поясом, контакты ответственных и последовательность действий. Старый оператор должен знать, когда снимать согласованные анонсы, новый — когда начинать объявление. Заранее определите, при каких проблемах и через какое время возвращаетесь на прежнюю площадку.
-
Выполните финальную синхронизацию данных. Для приложений с записью в базу предусмотрите режим обслуживания или другой согласованный способ остановить изменения. Две независимые копии приложения, одновременно принимающие заказы или платежи, могут привести к расхождению данных.
-
Переключите маршрутизацию по согласованному плану. При обычном переносе отдельного префикса старый оператор снимает его анонс, новый начинает объявление и направляет трафик на подготовленный сервер. Если подсеть раньше входила в более крупный общий анонс, эту ситуацию отдельно учитывают в плане: отключать весь чужой агрегат ради вашего блока не требуется.
-
Проверьте сеть и приложения, затем завершите работы. Сохраните старый сервер и возможность восстановления до окончания согласованного периода наблюдения. В бюджет переезда заложите время одновременной аренды двух площадок.
План возврата должен учитывать данные. Если новый сервер уже принял изменения, простое восстановление старого анонса может вернуть пользователей к устаревшей базе. До переключения определите, как остановить запись и сохранить изменения, появившиеся на новой площадке.
Можно ли переехать без простоя
Для обычного переноса между двумя независимыми площадками разумно предусмотреть технический перерыв. Даже при подготовленных разрешениях маршрутам нужно распространиться по сетям, а существующие соединения могут оборваться.
Одновременный анонс одной подсети из двух дата-центров сам по себе эту проблему не решает. Разные сети могут направлять пользователей на разные площадки. BGP не синхронизирует базы, файлы и пользовательские сессии. Такой вариант требует специально подготовленной архитектуры; кроме того, принимающий оператор может ограничивать параллельные анонсы.
Иногда на переходный период организуют туннель или пересылку трафика со старой площадки на новую. Это нужно согласовать с операторами и проверить по пропускной способности, задержкам и MTU. Пока трафик зависит от старой сети, её отключение остаётся отдельным этапом переезда.
Нужно ли менять DNS и rDNS
Если публичные IP сервисов сохранились, соответствующие DNS-записи A могут остаться прежними. Снижение их TTL не ускоряет переключение BGP: DNS отвечает за соответствие имени адресу, а BGP — за маршрут к этому адресу. Отдельно проверьте AAAA-записи, если у сервиса есть IPv6, который переносится по другой схеме.
PTR-записи обратного DNS нужно сохранить и проверить после переключения. Если обратная зона обслуживалась на DNS-серверах старого провайдера, заранее согласуйте её дальнейшее обслуживание или смену делегации. Иначе после закрытия старой услуги обратные записи могут перестать работать.
При переезде в другую страну отдельно займитесь геолокацией адресов. Физическое перемещение сервера не гарантирует немедленного обновления сторонних GeoIP-баз. Проверьте сервисы, для которых страна или ASN влияют на доступ.
Как убедиться, что переезд завершён
Проверяйте результат снаружи новой площадки. Открытая панель сервера и успешный ping ещё не показывают, что пользователи могут работать с приложением.
- Маршрут виден из разных сетей. Проверьте префикс через независимые BGP-наблюдения или looking glass. Origin ASN должен соответствовать плану. При RPKI Invalid сначала проверяют разрешённый ASN и длину префикса в ROA.
- Входящие соединения доходят до нового сервера. Проверьте нужные протоколы через несколько независимых подключений, например домашний и мобильный интернет. По журналам убедитесь, что запросы обрабатывает новая площадка.
- Работают исходящие соединения. Выполните запрос к внешнему сервису и проверьте адрес источника. Если входящий доступ есть, а ответы или исходящие запросы не проходят, проверяют шлюз, обратный маршрут, NAT и фильтры провайдера.
- Работают все используемые группы адресов. Если подсеть распределена между несколькими серверами или виртуальными машинами, проверьте каждый вариант маршрутизации. Успешный тест одного IP не подтверждает работу остальных.
- Проходит реальная операция в приложении. Например, создайте тестовую заявку через внешний интерфейс, найдите её в базе на новом сервере и проверьте связанное уведомление или API-вызов.
После успешной проверки и окончания периода наблюдения согласуйте удаление больше не нужных разрешений для прежней сети и закрытие старого сервера. Перед отключением ещё раз подтвердите, что аренда подсети продолжается, а рабочий трафик и DNS-службы больше не зависят от прежней площадки.
