При аренде физического сервера провайдер обычно выдаёт хотя бы один публичный IP-адрес. Для большинства сайтов этого достаточно, но в конфигураторах почти всегда есть возможность заказать дополнительные IPv4, подключить IPv6 или получить целую подсеть. Из-за этого создаётся впечатление, что серьёзному серверу обязательно нужно несколько адресов и чем их больше, тем лучше.
На практике количество IP почти никак не связано с мощностью машины. На одном адресе можно разместить один сайт, десять сайтов или несколько десятков проектов. Современные веб-серверы спокойно определяют, к какому домену обращается посетитель, и отдают нужный сайт даже тогда, когда все домены указывают на один и тот же IP.
Поэтому дополнительный адрес нужен не потому, что на сервере появился ещё один сайт. Он нужен тогда, когда проекту действительно требуется отдельная сетевая идентичность, собственная маршрутизация, изоляция сервиса или другая техническая схема.
Для обычного владельца сайта самое полезное правило звучит просто: если вы не можете объяснить, зачем нужен второй IPv4, скорее всего, его пока можно не покупать.
Сколько сайтов можно разместить на одном IP физического сервера
Один публичный IPv4 способен обслуживать множество доменных имён. Например, на сервере одновременно работают example.ru, shop-example.ru и ещё несколько сайтов. Все их DNS-записи A могут указывать на один адрес. Когда браузер подключается к серверу, веб-сервер понимает, какой домен запросил пользователь, и выбирает соответствующую конфигурацию.
Именно так работает большая часть современного веб-хостинга. Для каждого сайта не требуется отдельная сетевая карта и не нужен собственный публичный адрес.
Когда используется HTTPS, серверу также не обязательно выдавать отдельный IP каждому домену. Современные клиенты поддерживают SNI, благодаря чему при установлении защищённого соединения можно определить нужное доменное имя и выбрать соответствующий TLS-сертификат. Поэтому аргумент каждому SSL-сертификату нужен отдельный IPv4 сегодня относится главным образом к старым или очень специфическим системам.
Если на одной машине размещается несколько WordPress, интернет-магазинов или корпоративных сайтов, один IP обычно никак не мешает их работе. Ограничением становятся процессор, RAM, диски, база данных и приложение, а не количество сетевых адресов.
Когда отдельный IP всё-таки имеет смысл
Первый понятный сценарий — разделение разных сервисов. Например, на одном физическом сервере работают публичный сайт, VPN, административная система и собственный почтовый сервер. Технически часть этих служб можно разместить на одном адресе, распределив их по разным портам, но отдельные IP иногда делают инфраструктуру удобнее для настройки и контроля.
Другой вариант возникает при виртуализации. Один физический сервер может быть разделён на несколько виртуальных машин. Если каждая виртуальная машина должна быть доступна из интернета независимо и вести себя как отдельный сервер, ей можно назначить собственный публичный адрес.
Например, одна виртуальная машина обслуживает интернет-магазин, вторая используется для API, третья выполняет роль почтового сервера. Несколько IP в такой инфраструктуре выглядят вполне естественно.
Дополнительные адреса применяются и для сетевых устройств, балансировщиков, виртуальных маршрутизаторов и некоторых схем высокой доступности. Здесь речь уже идёт не о количестве сайтов, а об архитектуре инфраструктуры.
Отдельный IP может понадобиться и приложению, которое должно явно принимать соединения на собственном адресе. Это встречается у VPN, прокси, некоторых игровых сервисов, корпоративных систем и программного обеспечения со специфическими требованиями к лицензированию или сетевой конфигурации.
Для обычного веб-сервера такие задачи не характерны. Если физическая машина арендуется только для размещения нескольких сайтов, автоматически заказывать каждому из них по IPv4 нет необходимости.
При этом один сервер технически может иметь несколько адресов на одном сетевом интерфейсе. Не требуется устанавливать отдельную физическую сетевую карту для каждого IPv4. Операционная система просто получает дополнительные сетевые адреса и принимает трафик для них.
Хостинг-провайдер при этом должен маршрутизировать соответствующие адреса к вашему серверу. Поэтому нельзя взять случайный свободный IP и самостоятельно назначить его в Linux. Адрес или подсеть должны быть предоставлены оператором и корректно настроены в его сети.
Почтовый сервер требует особого внимания к IP
Отдельный разговор — собственная электронная почта. Если физический сервер отправляет письма напрямую получателям, репутация его IP начинает иметь большое значение.
Почтовые системы оценивают множество факторов: корректность DNS, SPF, DKIM, DMARC, обратную PTR-запись, историю отправителя и поведение самого сервера. Если адрес ранее использовался для массового спама и имеет плохую репутацию, доставка писем может оказаться сложнее.
Поэтому почтовому серверу часто действительно выделяют собственный IPv4. Это позволяет не смешивать его сетевую репутацию с другими задачами и нормально настроить обратную DNS-запись.
Но несколько IP сами по себе не улучшают доставляемость. Более того, попытка постоянно менять адреса после попадания в антиспам-фильтры обычно только ухудшает ситуацию. Нормальная почтовая инфраструктура строится вокруг стабильного адреса, корректной конфигурации и хорошей репутации отправителя.
Если сервер арендуется исключительно ради сайта, поднимать на нём собственную почту вообще необязательно. Для корпоративных ящиков часто проще использовать специализированный почтовый сервис и не заниматься репутацией IP самостоятельно.
IPv4 и IPv6 на физическом сервере работают по-разному
Когда говорят об IP-адресе сервера, чаще всего имеют в виду IPv4. Он выглядит примерно как 203.0.113.10 и до сих пор остаётся важнейшим способом публичного подключения к интернет-сервисам.
Но адресное пространство IPv4 ограничено, поэтому провайдеры относятся к таким адресам как к отдельному ресурсу. Дополнительные IPv4 нередко оплачиваются отдельно, а для получения крупного блока оператор может попросить объяснить техническую необходимость.
IPv6 решает проблему нехватки адресов иначе. Адресное пространство здесь огромно, поэтому провайдер способен выделить серверу не один адрес, а целую IPv6-подсеть.
Внешне IPv6 выглядит непривычно, например 2001:db8::10. Но для владельца сайта принцип остаётся похожим: адрес связывается с сервером, а доменное имя указывает на него через DNS.
Для IPv4 используется запись A, а для IPv6 — AAAA.
Один домен может одновременно иметь обе записи. Тогда клиент с поддержкой IPv6 способен подключиться по IPv6, а остальные пользователи продолжают работать через IPv4. Такой режим называют dual stack.
Для публичного сайта это обычно наиболее безопасная схема внедрения IPv6. Не нужно отказываться от привычного IPv4 и надеяться, что каждый провайдер и устройство посетителя уже полностью перешли на новый протокол.
При аренде физического сервера полезно сразу посмотреть, входит ли IPv6 в тариф и как именно выдаётся адресное пространство. Даже если сейчас проект использует только IPv4, наличие нормальной IPv6-сети оставляет больше возможностей на будущее.
Однако само получение IPv6 ничего не ускоряет. Это другой сетевой протокол и дополнительный способ связи с сервером, а не технология повышения производительности процессора или веб-приложения.
После включения IPv6 нужно помнить и о безопасности. Распространённая ошибка выглядит так: администратор тщательно настроил firewall для IPv4, а IPv6 оставил без аналогичных ограничений. В результате служба, которая считалась закрытой от внешнего интернета, неожиданно становится доступной через второй протокол.
Поэтому правила firewall, мониторинг и политика доступа должны учитывать обе версии IP.
Не стоит и создавать AAAA-запись только потому, что провайдер выдал IPv6. Сначала нужно убедиться, что веб-сервер действительно слушает соответствующий адрес, маршрутизация работает, firewall настроен правильно, а сайт доступен извне. Иначе часть пользователей может пытаться подключаться по IPv6 и получать ошибку, хотя IPv4-версия сайта работает нормально.
Второй важный момент — привязка IP к конкретному серверу. Если физическая машина выходит из строя и проект необходимо быстро перенести на другую, возможность сохранить тот же публичный адрес зависит от инфраструктуры провайдера.
В некоторых сетях адрес жёстко связан с определённым сервером или портом. В других провайдер может перенаправить IP на новую машину. Также существуют плавающие IP и другие механизмы, которые позволяют переключать адрес между серверами.
Для обычного сайта это редко является главным критерием. DNS можно изменить и направить домен на другой IP. Но для инфраструктуры с жёсткими списками разрешённых адресов, интеграциями партнёров или собственными API возможность сохранить один и тот же IP уже может быть очень полезной.
Представим B2B-сервис, к которому клиент разрешает доступ только с заранее согласованного IP. Если после аварии сервер переехал и получил другой адрес, необходимо связаться с клиентом и изменить его firewall. Таких партнёров может быть несколько десятков. Плавающий или переносимый IP сильно упрощает восстановление.
Дополнительный IPv4 может использоваться и для миграции. Старый сервис продолжает работать на одном адресе, новый разворачивается на другом, после чего трафик постепенно переключается. Но это уже временный технический сценарий, а не постоянная необходимость держать много адресов.
Некоторые владельцы сайтов считают, что отдельный IP полезен для SEO. Для обычного сайта покупать его исключительно ради продвижения нет оснований. Современный интернет давно построен на совместном использовании адресов, CDN, обратных прокси и балансировщиках, поэтому сам факт собственного уникального IPv4 не делает сайт автоматически качественнее или авторитетнее.
Аналогично не стоит заказывать десятки адресов только ради размещения разных сайтов на разных IP. Если проекты принадлежат одному владельцу и нормально работают на одной машине, технической необходимости искусственно разносить их по адресам обычно нет.
Совсем другое дело, когда сама архитектура требует сетевой изоляции. Например, несколько виртуальных машин должны иметь разные правила firewall, разные PTR-записи или независимо обслуживать внешние соединения. Здесь дополнительные IP используются по назначению.
Количество адресов стоит учитывать и при выборе провайдера. Если сейчас нужен один IPv4, а через год планируется несколько виртуальных машин, полезно заранее узнать, можно ли заказать дополнительные адреса без переезда на другой сервер.
Условия различаются. Один хостер позволяет заказать адрес кнопкой в панели. Другой выдаёт дополнительный IPv4 только после обращения в поддержку. Третий требует обоснования или предлагает сразу небольшую подсеть.
Стоимость тоже может заметно различаться, поэтому при большом количестве адресов она превращается в отдельную статью расходов.
Для большинства обычных сценариев выбор намного проще. Один физический сервер с несколькими сайтами обычно прекрасно работает на одном IPv4. При наличии поддержки имеет смысл дополнительно настроить IPv6. Второй или третий IPv4 стоит заказывать тогда, когда появляется конкретная задача: отдельный почтовый сервер, виртуальная машина, VPN, балансировщик или другой сервис, которому действительно нужен собственный сетевой адрес.
Это хороший пример того, почему конфигурацию физического сервера не стоит собирать по принципу максимального количества всего. Дополнительные процессорные ядра могут простаивать, огромный порт может никогда не загружаться, а десяток IPv4 способен годами существовать без единого соединения.
Правильнее начинать с архитектуры проекта. Какие сервисы будут работать на машине, какие из них должны быть доступны из интернета, нужны ли отдельные PTR-записи, будет ли виртуализация, требуется ли фиксированный адрес для интеграций и поддерживает ли проект IPv6.
После ответа на эти вопросы количество IP определяется почти само. Для одного веб-сервера это часто один IPv4 и IPv6. Для более сложной инфраструктуры адресов может понадобиться несколько. Но сама по себе физическая мощность сервера никак не обязывает покупать большой блок IP.
