Для второго сайта, отдельного сервиса, переноса приложения или связи с дополнительной подсетью серверу иногда нужен ещё один IP-адрес. В Linux несколько адресов можно назначить одному сетевому интерфейсу без создания второй физической карты. Но команда, которая успешно добавила адрес в ядро, ещё не означает, что он переживёт перезагрузку или что до него доберутся клиенты.
Разберём весь путь: выбрать интерфейс, исключить конфликт, добавить адрес для проверки, сохранить его в действующем сетевом менеджере и убедиться, что приложение принимает соединения. Примеры используют интерфейс enp1s0, основной адрес 192.0.2.10/24, дополнительный 192.0.2.20/24 и шлюз 192.0.2.1. Диапазон 192.0.2.0/24 выделен для документации: замените эти значения реальными адресами, согласованными с вашей сетью. Не копируйте маску из примера для адреса, который провайдер выдаёт как маршрутизируемый /32.
Быстро добавить адрес и проверить результат
Если интерфейс и свободный адрес уже известны, минимальная операция выглядит так:
sudo ip address add 192.0.2.20/24 dev enp1s0
ip -4 address show dev enp1s0
ip route get 192.0.2.1 from 192.0.2.20Первая команда добавляет IPv4-адрес к текущему состоянию интерфейса. Она не заменяет основной адрес и не создаёт второй шлюз по умолчанию. Во втором выводе должна появиться строка inet 192.0.2.20/24; признак secondary для второго IPv4 в той же подсети нормален. Третья команда показывает выбранный маршрут для пакета с дополнительным адресом источника. Это расчёт маршрута, а не отправка пакета.
Такой адрес может исчезнуть после перезапуска сетевого соединения, перезагрузки или повторного применения профиля сетевым менеджером. Чтобы отменить именно это добавление:
sudo ip address del 192.0.2.20/24 dev enp1s0Не используйте ip address flush: она удаляет набор адресов интерфейса и может оборвать административное соединение. Если add вернула RTNETLINK answers: File exists, сначала проверьте вывод ip address, а не удаляйте действующую конфигурацию ради повторного выполнения команды.
Выбрать интерфейс, маску и владельца конфигурации
Перед постоянной настройкой соберите сведения:
ip -br link
ip -br address
ip route show
systemctl is-active NetworkManager systemd-networkd
nmcli device status
networkctl status enp1s0Отсутствие nmcli или networkctl в конкретной системе не является неисправностью сети. Это подсказка о том, какой инструмент установлен. Состояние службы тоже недостаточно: NetworkManager может работать, но не управлять данной картой. Смотрите конкретный интерфейс и профиль. Если адрес находится на br0, bond0 или VLAN-интерфейсе, добавлять его нужно туда, а не на физический порт, входящий в мост или bond.
| Что обнаружено | Где сохранять адрес | Что проверить |
|---|---|---|
| Интерфейс управляется NetworkManager | Профиль через nmcli | Имя или UUID активного соединения, текущий метод IPv4 |
| Сеть описана Netplan | Действующий YAML в /etc/netplan | Renderer и объединение нескольких файлов |
| Интерфейс управляется networkd напрямую | Совпавший файл .network | Правила Match и действующий Network File |
| ALT с etcnet | /etc/net/ifaces/имя/ipv4address | Режим статической адресации и наличие другого менеджера |
| Debian-подобная система с ifupdown | Действующая конфигурация interfaces | Кто поднимает интерфейс и подключаемые snippets |
| Облако или хостинг | Согласованный механизм гостевой ОС и панели | Разрешённые IP/MAC, маршрутизируемый адрес, anti-spoofing |
Для обычной локальной подсети дополнительный адрес берут из того же сегмента и исключают из DHCP-пула. Адрес из другого префикса не создаёт VLAN и не переносит интерфейс в другую физическую сеть. Соседи должны иметь возможность передать ему кадр, а маршрутизаторы — знать обратный путь. Дополнительный публичный /32 может доставляться через маршрут провайдера без широковещательного сегмента; в таком случае маску и шлюз задают по его схеме.
Проверьте резервирование в IPAM или у администратора сети. В локальном Ethernet можно дополнительно проверить дубликат ARP-пробой, если установлен пакет с arping:
sudo arping -D -I enp1s0 -c 3 192.0.2.20Ключ -D задаёт проверку дубликата в распространённой реализации iputils. Проверьте arping --help: утилиты с таким именем бывают разными. Ответ другого узла — причина остановиться. Отсутствие ответа не гарантирует свободу адреса: владелец может быть выключен, изолирован или не отвечать. Для маршрутизируемого /32 за пределами локального сегмента такой тест не заменяет проверку у провайдера.
NetworkManager: дополнить профиль, не потеряв основной адрес
Сначала найдите активное соединение, связанное с нужным устройством:
nmcli -f NAME,UUID,DEVICE connection show --active
nmcli -f ipv4.method,ipv4.addresses,ipv4.gateway,ipv4.routes connection show "Wired connection 1"Имя Wired connection 1 — пример. Используйте показанный UUID, если имена повторяются. Зафиксируйте текущие адреса и метод IPv4 до изменения. Экспорт вывода в закрытый файл удобен для сверки, но не равнозначен полной резервной копии профиля со всеми настройками. При ручном резервировании keyfile сохраняйте права и не публикуйте секреты Wi-Fi или VPN.
sudo nmcli connection modify "Wired connection 1" +ipv4.addresses 192.0.2.20/24
sudo nmcli device reapply enp1s0
nmcli -f ipv4.method,ipv4.addresses connection show "Wired connection 1"
ip -4 address show dev enp1s0Знак + означает добавление к списку. Без него ipv4.addresses заменит список и может убрать основной статический адрес. Если профиль получает основной адрес по DHCP, не переключайте ipv4.method в manual только ради второго адреса: NetworkManager позволяет сочетать автоматическую настройку с дополнительными статическими адресами. Семантика изменения списков и reapply описана в справочнике nmcli.
connection modify меняет постоянный профиль; device reapply пытается применить допустимые изменения к работающему устройству. Если версия или тип профиля не позволяет это сделать, команда сообщит ошибку. Тогда активацию профиля выполняют из локальной консоли или в согласованное окно: nmcli connection up способен прервать соединение.
В версиях с поддержкой checkpoint можно защитить применение таймером возврата. Предварительно проверьте nmcli device checkpoint --help. Неполученное подтверждение должно вернуть сетевое состояние, но постоянный профиль после любой аварии отдельно сверяйте с сохранённым исходным состоянием.
sudo nmcli device checkpoint --timeout 120 enp1s0 -- nmcli connection up "Wired connection 1"Для удаления только добавленного адреса из профиля:
sudo nmcli connection modify "Wired connection 1" -ipv4.addresses 192.0.2.20/24
sudo nmcli device reapply enp1s0После этого сверьте и профиль, и ядро. Не считайте откат законченным только потому, что команда завершилась без ошибки.
Netplan: сохранить адрес в действующем YAML
Netplan генерирует конфигурацию для NetworkManager или networkd. Не создавайте одновременно независимый профиль того же интерфейса в обоих механизмах. Начните с просмотра действующей модели и файлов:
sudo netplan get
sudo ls -l /etc/netplanНайдите YAML, который описывает ваш интерфейс. В статической конфигурации добавьте ещё один элемент в addresses, сохранив существующие маршруты и DNS. Полный учебный пример ниже показывает структуру, а не команду на замену всех файлов сервера.
network:
version: 2
renderer: networkd
ethernets:
enp1s0:
dhcp4: false
addresses:
- 192.0.2.10/24
- 192.0.2.20/24
routes:
- to: default
via: 192.0.2.1
nameservers:
addresses: [192.0.2.53]Если основной адрес приходит по DHCP, оставьте dhcp4: true и добавьте список addresses без выдуманного статического основного адреса. Убедитесь, что другой YAML не переопределяет те же параметры. Файлы cloud-init могут генерироваться повторно: в облаке сохраняйте настройки через предусмотренный поставщиком механизм, иначе правка исчезнет при следующем запуске.
Сохраните исходный файл вне /etc/netplan, чтобы резервная YAML-копия не участвовала в объединении конфигурации. Затем выполните проверку генерации и пробное применение:
sudo netplan generate
sudo netplan try --timeout 120
ip -4 address show dev enp1s0
ip route showgenerate проверяет модель и создаёт backend-конфигурацию; это не проверка доступности шлюза. try применяет изменения с ожиданием подтверждения. Если связь пропала, не подтверждайте вслепую. После возврата проверьте файлы и состояние интерфейса, особенно при мостах и других сложных устройствах: автоматический откат не заменяет консоль. Документация команд Netplan разделяет генерацию, применение и пробный режим.
Networkd, etcnet и ifupdown: варианты постоянной записи
При прямом управлении systemd-networkd найдите файл, который действительно совпал с интерфейсом: его показывает networkctl status enp1s0. У networkd важно первое подходящее .network-описание; случайный дополнительный файл не обязательно дополнит уже действующее. В выбранном файле или корректном drop-in можно повторять Address=:
[Match]
Name=enp1s0
[Network]
Address=192.0.2.10/24
Address=192.0.2.20/24
Gateway=192.0.2.1
DNS=192.0.2.53Сохраните текущие параметры. Для DHCP-профиля сохраняется его DHCP=. После резервирования и подготовки консольного доступа:
sudo networkctl reload
sudo networkctl reconfigure enp1s0
networkctl status enp1s0
ip -4 address show dev enp1s0reload перечитывает конфигурацию; reconfigure применяет её к устройству и может изменить адреса или маршруты. Не используйте его удалённо без возможности восстановить связь. Повторяемость Address= определена в исходной документации systemd.
В ALT с etcnet статические адреса записываются в /etc/net/ifaces/enp1s0/ipv4address, по одному адресу с префиксом на строку. В существующем статическом файле сохраните основную строку и добавьте вторую:
192.0.2.10/24
192.0.2.20/24Посмотрите options этого интерфейса и убедитесь, что его не контролирует NetworkManager. Маршруты находятся отдельно; второй адрес сам по себе не требует второго default route. Применение выполняйте штатным механизмом вашей версии ALT из консоли. Пока нельзя прерывать сеть, текущий адрес можно добавить командой ip address add, а постоянную запись проверить при плановом перезапуске. Руководство ALT Server описывает файлы etcnet.
В ifupdown второй адрес можно привязать к подъёму основного интерфейса. В уже существующей секции статического интерфейса добавляют:
up ip address add 192.0.2.20/24 dev enp1s0
down ip address del 192.0.2.20/24 dev enp1s0Это вариант для согласованной конфигурации ifupdown, а не для любой Debian-системы. До добавления убедитесь, что тот же адрес не задан другим hook или менеджером. Не вызывайте ifdown через единственный SSH-сеанс; для первоначальной проверки используйте временное добавление, постоянный подъём проверьте из консоли.
Почему адрес есть, а сервис не работает
Назначение IP отвечает лишь за сетевой уровень. Приложение может слушать только основной адрес или loopback. Посмотрите сокеты:
sudo ss -lntup
ping -c 3 -I 192.0.2.20 192.0.2.1
ip route get 192.0.2.53 from 192.0.2.200.0.0.0:443 обычно означает прослушивание на всех IPv4-адресах, а 192.0.2.10:443 — только на конкретном. Не меняйте bind-адрес без оценки других клиентов. Проверять доступ к новому IP нужно с другого узла: локальное соединение может обойти часть реального пути. Для HTTPS сохраняйте правильное имя и SNI:
curl --resolve service.example:443:192.0.2.20 https://service.example/Домен здесь также пример. Команда направит запрос на указанный IP, сохранив имя сервиса для TLS; сертификат должен быть действителен для этого имени. Не подменяйте такую проверку curl -k: отключение проверки сертификата скрывает отдельную ошибку.
| Симптом | Возможная причина | Где смотреть |
|---|---|---|
| Адрес исчез после перезагрузки | Только временная команда или генерация cloud-init | Действующий профиль, YAML, механизм облака |
| Адрес локально доступен, снаружи нет | Firewall, ACL, anti-spoofing, нет маршрута | Шлюз, площадка, журналы фильтрации |
| Ping работает, приложение нет | Сервис слушает другой IP или порт | ss, конфигурация приложения |
| Ответы идут с основного IP | Приложение не выбрало источник | Bind сокета, маршрут с from, policy routing |
| Доступ периодически пропадает | Конфликт адресов | ARP-таблицы, DHCP-пул, IPAM |
| После добавления другого префикса ломается связь | Изменились connected routes или обратный путь | Маска, таблицы маршрутов, rp_filter |
При нескольких провайдерах выбор исходного адреса и обратного пути решается policy routing, а не добавлением ещё одного default route наугад. Сначала составляют таблицы и правила для источников, затем тестируют каждый путь. После завершения сохраните вывод профиля, адресов и маршрутов, проверьте соединение с удалённого клиента и повторите проверку после согласованного перезапуска. Шаблон протокола изменения поможет записать исходные значения и результат, чтобы второй адрес не остался неизвестной настройкой следующему администратору.