Dedicated-сервер с IP-подсетью: семь проверок до аренды и настройки Linux

Типичный сценарий: администратор получает выделенный сервер и IPv4-подсеть, добавляет адреса на сетевой интерфейс — и теряет SSH-доступ. Либо исходящий трафик работает, а подключиться к новым адресам извне невозможно.

Обычно проблема не в Ubuntu, Debian, CentOS или openSUSE. Настройка началась раньше, чем была выяснена сетевая схема провайдера.

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

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

Отдельный блок адресов оправдан, если на сервере размещаются:

• виртуальные машины с публичными IP;
• клиентские окружения на Proxmox, KVM или другой платформе;
• несколько независимых шлюзов и сервисов;
• инфраструктура хостинг-провайдера;
• распределённые API и сетевые узлы;
• стенды, где требуется разделение адресов без NAT.

Для одного сайта, VPN или административной панели обычно достаточно одного или нескольких дополнительных адресов. Арендовать /24 «на будущее» невыгодно: подсеть требует учёта адресов, настройки маршрутизации, контроля репутации, обработки жалоб и отдельной политики межсетевого экрана.

Если блок действительно нужен, до оплаты стоит пройти семь проверок.

1. Как подсеть будет доставляться до сервера

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

Основных вариантов три.

Подсеть в одном L2-сегменте

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

Она выглядит привычно, но не каждый провайдер разрешает назначать произвольные MAC-адреса виртуальным машинам.

Routed subnet

Провайдер направляет весь префикс на основной адрес сервера. Новые IP не обязательно находятся в одной сети со шлюзом: они могут назначаться как отдельные /32 для IPv4 или /128 для IPv6 на loopback-интерфейс, Linux bridge либо виртуальные машины.

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

BGP-анонс

Подсеть объявляется в интернете из определённой автономной системы. Это может быть AS провайдера или собственная AS клиента. Такой вариант нужен, когда важны самостоятельная маршрутизация, multihoming или возможность использовать адресное пространство в более сложной инфраструктуре.

До заказа необходимо получить:

• точный CIDR;
• основной адрес или next hop;
• модель on-link, routed либо BGP;
• номер origin ASN;
• требования к VLAN и MAC-адресам;
• правила подключения виртуальных машин;
• схему работы IPv6.

Без этих данных писать Netplan или конфигурацию NetworkManager рано.

2. Появится ли подсеть в реальной таблице BGP

LoA, объект route в RADB и работающий маршрут — не одно и то же.

LoA подтверждает, что владелец адресного ресурса разрешает оператору выполнить определённое действие. Объект route или route6 в IRR описывает пару «префикс — origin ASN» и может использоваться сетями для построения фильтров.

Но записи в реестре сами по себе не передают трафик. Фактический маршрут появляется только после BGP-анонса.

Проверять нужно отдельно:

1. Какой префикс должен быть виден в интернете.
2. Из какой AS он будет анонсирован.
3. Создан ли соответствующий маршрутный объект.
4. Наблюдают ли маршрут внешние BGP-коллекторы.
5. Нет ли неожиданного более специфичного или покрывающего маршрута.

Для проверки удобно использовать RIPEstat: он показывает наблюдаемый маршрут, origin ASN, видимость через коллекторы RIS и найденные IRR-объекты.

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

3. Кто управляет RPKI и ROA

RPKI позволяет проверить, имеет ли конкретная автономная система право анонсировать указанный префикс. Для этого создаётся ROA — подписанное разрешение, содержащее префикс, origin ASN и максимально допустимую длину маршрута.

У BGP-анонса возможны три состояния:

• Valid — существующий ROA разрешает этот префикс и origin ASN;
• Not Found — покрывающего ROA нет;
• Invalid — ROA существует, но не разрешает текущую AS или длину маршрута.

Особенно опасен последний вариант. Часть операторов отбрасывает RPKI Invalid-маршруты, поэтому подсеть может работать в одних сетях и быть недоступной в других.

До запуска нужно уточнить:

• существует ли ROA;
• кто может его изменить;
• какой origin ASN в нём указан;
• соответствует ли maxLength планируемому анонсу;
• сколько времени займёт изменение при переносе подсети.

Если origin ASN меняется, старое разрешение необходимо обновить до переключения маршрута.

4. Кто контролирует обратную DNS-зону

Возможность установить один PTR и управление обратной зоной всей подсети — разные услуги.

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

• изменение PTR через панель;
• настройку записей по заявке;
• делегирование обратной зоны на DNS-серверы клиента.

Для большого блока последний вариант удобнее: администратор самостоятельно управляет адресами в in-addr.arpa для IPv4 и ip6.arpa для IPv6. Но такую возможность необходимо согласовать заранее.

Минимальная проверка после настройки:

dig -x* 192.0.2.10
dig NS 2.0.192.in-addr.arpa

Следует узнать, кто меняет PTR, доступно ли делегирование reverse DNS, какие серверы имён потребуются и что произойдёт с зоной после окончания аренды.

5. В каком состоянии находятся адреса

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

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

• наличие в актуальных DNSBL;
• историю маршрутизации и смены origin ASN;
• данные WHOIS;
• контакт abuse-c;
• определяемую внешними сервисами географию;
• доступность популярных API и платформ.

Проверка одного адреса ничего не говорит обо всём диапазоне. Отсутствие записей в списках сегодня также не гарантирует, что они не появятся позже.

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

6. Соответствует ли сервер сетевой задаче

Подсеть не увеличивает пропускную способность сервера. Сотни адресов всё равно могут использовать один физический порт.

Поэтому параметры машины и сети нужно согласовывать вместе:

• скорость порта;
• гарантированная или разделяемая полоса;
• лимит трафика;
• наличие Fair Usage;
• стоимость превышения лимита;
• защита от DDoS;
• возможность маршрутизации блока в выбранном дата-центре;
• скорость переноса подсети на резервный сервер.

Надпись 10 Gb/s port ещё не означает гарантированные 10 Гбит/с постоянного трафика. Условия Fair Usage, ограниченный объём и Unmetered Guaranteed описывают разные модели услуги.

Если подсеть предназначена для виртуальных машин, отдельно выясните, поддерживаются ли дополнительные MAC-адреса, vMAC, routed bridge, proxy ARP или proxy NDP. Включать эти механизмы на Linux вслепую не следует.

7. Что произойдёт при смене сервера или провайдера

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

До заказа нужно зафиксировать:

• минимальный срок аренды;
• срок уведомления об отключении;
• возможность переноса блока между серверами;
• возможность переноса между дата-центрами одного оператора;
• порядок замены проблемного диапазона;
• кто удаляет старые PTR, IRR-объекты и ROA;
• предоставляется ли период для перенумерации;
• можно ли сохранить подсеть при смене серверной конфигурации.

Для Provider Aggregatable-пространства смена оператора обычно означает перенумерацию инфраструктуры. Поэтому адреса приложений не стоит без необходимости жёстко прописывать в лицензиях, конфигурациях клиентов и сторонних интеграциях. Лучше заранее использовать DNS, централизованный IPAM и шаблоны конфигурации.

Диагностика одинакова на разных дистрибутивах

Постоянная сетевая конфигурация зависит от системы:

• Ubuntu обычно использует Netplan;
• Debian — ifupdown, systemd-networkd или NetworkManager;
• CentOS Stream, AlmaLinux и Rocky Linux — NetworkManager;
• openSUSE — Wicked либо NetworkManager.

Но первичную диагностику везде можно выполнить средствами iproute2:

ip -br address
ip -4 route
ip -6 route
ip neigh

ip route get 1.1.1.1 from 192.0.2.10
ip -6 route get 2606:4700:4700::1111 from 2001:db8::10

dig -x* 192.0.2.10

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

Если сервер выступает маршрутизатором для виртуальных машин, может потребоваться ip_forward. Proxy ARP, proxy NDP и изменение rp_filter нужны только при соответствующей сетевой схеме. Отключать фильтрацию или включать proxy-механизмы «на всякий случай» опасно.

После добавления публичного блока также следует проверить nftables или другой межсетевой экран. Сервис, слушающий 0.0.0.0 или ::, может неожиданно оказаться доступным на всех новых адресах.

Как не потерять SSH при применении конфигурации

Безопасный порядок выглядит так:

1. Сохраните основной адрес и рабочий маршрут управления.
2. Проверьте наличие KVM/IPMI или другой удалённой консоли.
3. Добавьте один тестовый адрес без перезапуска всей сети.
4. Проверьте исходящий маршрут с выбранного адреса.
5. Проверьте входящее соединение с внешней машины.
6. Только после этого переносите настройку в постоянную конфигурацию.
7. Выполните контролируемую перезагрузку до запуска production-сервисов.

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

Почему сервер и подсеть удобнее арендовать вместе

Когда физическая машина и адресное пространство заказываются у разных компаний, при любой проблеме появляется лишняя граница ответственности: владелец подсети проверяет документы, серверный провайдер — next hop, а сетевой оператор — BGP.

Для такой инфраструктуры рекомендуем рассмотреть QCKL: у провайдера можно арендовать dedicated-сервер и IPv4-блоки от /24 до /20, а также IPv6 /29. Публично заявлены помощь с WHOIS и rDNS, подготовка LoA, работа с RADB для BGP-сценариев и сопровождение регистрации ASN.

Перед оплатой всё равно следует согласовать конкретную схему: дата-центр, routed subnet или BGP, origin ASN, next hop, управление PTR и возможность переноса блока. Поддержку RPKI/ROA также нужно подтвердить отдельно — наличие подсети и LoA не означает, что эта часть будет настроена автоматически.

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

Чек-лист перед заказом

Перед оплатой сервера и подсети должны быть известны:

• назначение и требуемый размер блока;
• точный CIDR;
• модель on-link, routed или BGP;
• gateway либо next hop;
• origin ASN;
• наличие и параметры ROA;
• порядок создания IRR-объекта;
• способ управления PTR;
• скорость порта и условия трафика;
• требования к MAC, VLAN и Linux bridge;
• правила обработки abuse;
• условия переноса и прекращения аренды;
• наличие удалённой консоли для восстановления доступа.

Нужен ли собственный ASN для routed subnet?

Нет. Провайдер может маршрутизировать блок на основной адрес сервера внутри своей сети. Собственный ASN нужен, когда клиент планирует самостоятельно анонсировать префикс по BGP или строить независимую сетевую политику.

Можно ли использовать /24 на одном сервере?

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

Подойдёт ли одна конфигурация для Ubuntu, Debian, CentOS и openSUSE?

Сетевая логика останется одинаковой, но формат постоянной конфигурации будет различаться. Сначала нужно проверить схему временными командами iproute2, а затем перенести рабочий вариант в Netplan, NetworkManager, systemd-networkd, ifupdown или Wicked.

Правильная настройка начинается не с команды ip addr add, а с сетевой схемы, зафиксированной в заявке провайдеру. Если неизвестны CIDR, next hop, origin ASN, способ маршрутизации и управление reverse DNS, сервер ещё не готов к подключению подсети.

Редактор: Анастасия