Виртуальные сетевые интерфейсы в Linux: VLAN, bridge, bond, loopback и туннели

Что такое виртуальные сетевые интерфейсы Linux и зачем они нужны

Виртуальный сетевой интерфейс Linux представляет собой программный объект ядра, который создаёт логическую точку подключения или обработки трафика. Он может работать поверх физического адаптера, другого интерфейса, сетевого моста, network namespace или туннеля. Для управления такими объектами используется набор утилит iproute2, прежде всего команда ip.

Физическая сетевая карта, например enp1s0, связана с оборудованием и физическим линком. Виртуальные объекты вроде lo, vlan10, br0, bond0 и пары veth создаются ядром без установки отдельного адаптера. Они получают MAC- и IP-параметры, участвуют в маршрутизации, коммутации и фильтрации трафика, но зависят от своей схемы подключения.

Один физический порт может обслуживать несколько VLAN, bond может объединить несколько физических каналов, bridge может связать виртуальные машины с внешней сетью, а veth соединяет разные сетевые пространства. Поэтому виртуальные интерфейсы применяют для сегментации, виртуализации, контейнеров, Kubernetes, отказоустойчивых подключений и туннелирования. Любое изменение нужно проверять на уровне интерфейсов, адресов, маршрутов, MTU, внешнего коммутатора и firewall.

Физический и виртуальный интерфейс: ключевые отличия

Если отключить физическую карту или кабель, верхние интерфейсы могут сохранить состояние UP, но потерять связь с внешней сетью. Если удалить виртуальный объект, ядро перестанет показывать его в списке, а связанные маршруты и адреса могут исчезнуть. Это особенно критично для bridge, bond и интерфейсов, через которые открыт SSH.

Как Linux представляет интерфейсы и связи между ними

У виртуального интерфейса часто есть родительский, или lower, интерфейс. Например, vlan10 создаётся поверх enp1s0, а VLAN поверх bond обычно строят на bond0. Верхний интерфейс называют upper, нижний слой, который переносит или принимает трафик, называют lower.

Поля master и связанные с ними зависимости показывают принадлежность порта к другому объекту. Физический порт может быть портом bridge или участником bond. Veth-хост подключают к bridge, а второй конец пары переносят в network namespace контейнера. В одной схеме цепочка может выглядеть так: enp1s0 и enp2s0 -> bond0 -> vlan10 -> br-mgmt -> tap-интерфейс виртуальной машины.

Состояние UP означает административное включение объекта. Флаг LOWER_UP обычно указывает, что нижний уровень сообщает рабочий carrier. Для loopback отсутствие физического carrier нормально. Network namespace формирует отдельное сетевое пространство: собственные интерфейсы, адреса, маршруты, таблицу соседей и правила firewall.

Типы сетевых интерфейсов Linux: назначение и различия

Выбор интерфейса зависит от задачи. VLAN разделяет трафик тегами, bridge пересылает Ethernet-кадры между портами, bond объединяет физические каналы, veth связывает namespaces, туннель переносит пакеты через другую сеть, а loopback обслуживает локальное взаимодействие.

Loopback-интерфейс Linux: lo

lo нужен для локального обмена данными внутри хоста. IPv4-адрес 127.0.0.1 указывает на текущую систему, а IPv6-адрес ::1 выполняет ту же функцию для IPv6. Диапазон 127.0.0.0/8 зарезервирован для loopback, хотя чаще всего используют именно 127.0.0.1.

ip addr show dev lo
ip link show dev lo
ping -c 3 127.0.0.1
ping6 -c 3 ::1

Сервис, который слушает только 127.0.0.1:8080, принимает соединения от процессов на этом сервере. Запрос к адресу физического интерфейса, например 192.0.2.10:8080, к нему не попадёт. Для доступа из сети процесс должен слушать нужный адрес или все IPv4-адреса через 0.0.0.0, а firewall должен разрешать соединение.

Loopback используют для локальных health-check, межпроцессного обмена, сервисных endpoint и стабильных адресов маршрутизируемых приложений. Для внешнего доступа он не заменяет физический интерфейс, VLAN или туннель.

VLAN-интерфейс: разделение трафика по тегам 802.1Q

VLAN-интерфейс добавляет логическую сеть поверх родительского Ethernet-интерфейса. Имя vlan10 или enp1s0.10 обычно содержит VLAN ID, но Linux не требует конкретного формата имени. Тег 802.1Q содержит идентификатор VLAN, а сам тег добавляет 4 байта к Ethernet-кадру.

Один trunk-порт может переносить несколько сетей. Например, VLAN 10 используют для управления, VLAN 20 для storage, VLAN 30 для tenant-трафика. Сервер создаёт vlan10, vlan20 и vlan30 поверх одного enp1s0 или bond0, а коммутатор передаёт разрешённые теги через trunk. На access-порту кадры обычно идут без тега, поэтому серверная схема должна соответствовать режиму порта.

Обычно доступны VLAN ID 1-4094. Значения 0 и 4095 имеют специальные назначения и не используются как обычные пользовательские VLAN. Linux-сервер не сможет обмениваться трафиком VLAN 10, если коммутатор отправляет порт в access-сегмент с другим VLAN ID, запрещает VLAN 10 в списке trunk или использует другой native VLAN.

Для маршрутизации между такими сегментами нужны IP-адреса на VLAN-интерфейсах, маршруты, IPv4 forwarding и правила фильтрации. Пошаговая схема с trunk, шлюзами и проверкой тегов описана в руководстве по маршрутизации между VLAN на Linux-сервере.

Linux bridge: программный коммутатор br0

Linux bridge работает как программный коммутатор второго уровня. Он изучает MAC-адреса, записывает их в forwarding database и пересылает кадры между портами. В bridge могут входить физический интерфейс, tap-порт виртуальной машины, veth-конец контейнера и другие Ethernet-объекты.

Типовая схема виртуализации выглядит так: внешний кабель подключён к enp1s0, этот порт добавлен в br0, а виртуальная машина подключена к bridge через tap-интерфейс. Кадр от гостевой системы проходит через tap, bridge и физический порт. Bridge не назначает IP-адреса своим портам автоматически и не маршрутизирует подсети без отдельной L3-настройки.

Если физический порт входит в bridge, IP-адрес хоста обычно размещают на br0. На enp1s0 оставляют только канальную роль. Размещение адреса одновременно на физическом порту и bridge создаёт неоднозначность для ARP, маршрутов и исходного адреса.

Для защиты от L2-петель применяют STP. В небольших схемах без резервных физкана́лов STP может быть отключён, но при наличии параллельных связей нужно заранее определить, где будет блокироваться резервный путь. Проверяйте состав портов командами bridge link show и bridge vlan show.

Bonding: объединение физических интерфейсов

Bonding объединяет несколько физических интерфейсов в один логический bond0. Он помогает пережить отказ кабеля, порта или сетевой карты. Некоторые режимы распределяют потоки между участниками, но скорость одной TCP-сессии обычно ограничена одним физическим каналом и выбранным алгоритмом хеширования.

Режим active-backup выбирает один активный интерфейс и переключается на резервный при потере carrier. Для него обычно не нужен LACP на коммутаторе, но порты должны находиться в согласованной L2-сети. Режим 802.3ad использует LACP и требует агрегированной группы на коммутаторе. Несогласованный LACP часто приводит к потере пакетов или тому, что работает только один порт.

Bonding и bridge решают разные задачи. Bond собирает физические каналы в один логический путь, bridge пересылает кадры между портами. Их можно объединить в цепочку: физические NIC -> bond0 -> VLAN или bridge.

Veth pair: виртуальный Ethernet-кабель между namespace

Veth создаётся только парами. Пакет, вошедший в один конец, появляется на другом конце. Один интерфейс можно оставить в root namespace и подключить к bridge, а второй переместить в namespace контейнера.

Внутри namespace veth обычно получает имя eth0, хотя конкретное имя зависит от container runtime или CNI-плагина. На хосте остаётся интерфейс с техническим именем вроде veth8a1c. У каждого конца собственное состояние, MAC-адрес и настройки, но физически они связаны между собой.

Удаление одного конца veth обычно удаляет и второй. Перенос интерфейса в namespace меняет область его видимости: команда ip link show в root namespace больше его не покажет. Проверять такой интерфейс нужно через ip netns exec или инструменты конкретного runtime.

Туннельные интерфейсы Linux

Туннель инкапсулирует исходный трафик в другой протокол и отправляет его через underlay-сеть. L3-туннели переносят IP-пакеты между endpoint, L2-туннели переносят Ethernet-кадры и могут подключаться к bridge. Туннель не создаёт маршруты автоматически и не шифрует данные, если выбранный протокол не содержит шифрования.

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

Базовые команды ip для просмотра сетевых интерфейсов

Как посмотреть состояние, адреса и связи интерфейсов

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

sudo ip link show
sudo ip -details link show
sudo ip addr show
sudo ip route show
sudo ip neigh show
sudo ip -br link
sudo ip -br addr
sudo ip link show dev br0
sudo ip addr show dev vlan10
sudo bridge link show
sudo bridge vlan show

ip link show показывает существование интерфейса, флаги, MTU, тип очереди, MAC и состояние. Фильтр dev ограничивает вывод одним объектом. Команда ip addr show добавляет IPv4- и IPv6-адреса, префиксы, broadcast и scope.

Для VLAN команда ip -details link show dev vlan10 должна показать тип vlan, протокол 802.1Q и идентификатор. Для bond вывод содержит режим и параметры агрегации. Для VXLAN видны VNI, локальный и удалённый endpoint. Bridge-порты проверяют через bridge link show.

Короткий формат удобен при аварийной диагностике:

sudo ip -br link
sudo ip -br addr

В нём быстро видны имена, административное состояние и адреса. Для loopback отсутствие carrier не считается ошибкой. Для физического порта ищите сочетание UP и LOWER_UP, если ожидаете рабочий линк.

Как читать вывод ip без лишних предположений

Наличие имени в выводе ip link подтверждает только создание объекта. Интерфейс может быть без IP-адреса, маршрута, соседней записи ARP или доступа к удалённому узлу.

Например, сочетание state UP и отсутствующего LOWER_UP у физического порта указывает на возможную проблему с кабелем, портом коммутатора, SFP-модулем или настройкой линка. Для VLAN оба флага не подтверждают, что коммутатор пропускает нужный тег. Для bridge наличие порта в списке не доказывает, что кадр выходит через правильный физический интерфейс.

Чтение результата выполняйте в связке:

• ip link отвечает, существует ли интерфейс и включён ли он;
• ip addr показывает адреса и префиксы;
• ip route показывает, куда ядро отправляет пакет;
• ip neigh показывает состояние ARP или IPv6 Neighbor Discovery;
• tcpdump подтверждает фактическое прохождение кадров.

Маршрут по умолчанию может присутствовать, но вести через другой интерфейс. Команда ip route get помогает проверить выбор пути и исходного адреса для конкретного назначения.

Как создать и настроить виртуальные интерфейсы Linux

Команды ip меняют runtime-конфигурацию текущего сеанса. Для их выполнения обычно нужны права root или sudo. Последовательность безопасной настройки выглядит так: определить основу, создать объект, задать MTU и адреса, включить интерфейс, проверить связи и маршруты, затем подключить сервис.

Создание VLAN-интерфейса

Пример создаёт VLAN 10 поверх enp1s0 и назначает ему тестовый адрес. Подставьте имена, VLAN ID и подсеть из своей схемы.

sudo ip link add link enp1s0 name vlan10 type vlan id 10
sudo ip addr add 192.0.2.10/24 dev vlan10
sudo ip link set dev vlan10 up
sudo ip -details link show dev vlan10
sudo ip route show dev vlan10

Родительский интерфейс должен быть включён. На коммутаторе порт сервера должен работать как trunk с разрешённым VLAN 10. Если сервер использует bond, создавайте интерфейс поверх bond0:

sudo ip link add link bond0 name vlan10 type vlan id 10

IP-адрес размещают на vlan10, когда сервер сам участвует в этой подсети. Если VLAN служит транспортом для виртуальных машин, поверх него можно создать bridge и оставить bridge без адреса, когда хосту не нужен доступ в этот сегмент.

Создание Linux bridge и добавление порта

Минимальный пример создаёт br0 и добавляет в него физический порт.

sudo ip link add name br0 type bridge
sudo ip link set dev enp1s0 up
sudo ip link set dev br0 up
sudo ip link set dev enp1s0 master br0
sudo ip addr add 192.0.2.10/24 dev br0
sudo bridge link show
sudo ip link show master br0

Если адрес 192.0.2.10/24 уже находился на enp1s0, его переносят на bridge после проверки резервного доступа:

sudo ip addr del 192.0.2.10/24 dev enp1s0
sudo ip addr add 192.0.2.10/24 dev br0

Команда удаления адреса приведена с конкретным значением. Не используйте без проверки универсальный ip addr flush на рабочем сервере, поскольку он может удалить несколько адресов и оборвать SSH.

Установка master-связи может кратко прервать трафик. При удалённой работе заранее подготовьте консоль, второй канал или проверенный сценарий отката. Подробные схемы Linux bridge для KVM, Proxmox и других платформ собраны в руководстве по виртуальным коммутаторам и Linux bridge.

Создание bond и выбор режима

Для отказоустойчивости двух физических портов используйте active-backup. В примере адрес назначается логическому bond0, а физические интерфейсы становятся его участниками.

sudo ip link add bond0 type bond mode active-backup
sudo ip link set dev enp1s0 master bond0
sudo ip link set dev enp2s0 master bond0
sudo ip link set dev bond0 up
sudo ip link set dev enp1s0 up
sudo ip link set dev enp2s0 up
sudo ip addr add 192.0.2.10/24 dev bond0
sudo ip -details link show dev bond0

Физические интерфейсы не должны сохранять отдельные IP-адреса. Для LACP замените режим на 802.3ad и заранее создайте агрегированную группу на коммутаторе:

sudo ip link add bond0 type bond mode 802.3ad

Проверьте режим, активного участника, MII-состояние и ошибки:

sudo ip -details link show dev bond0
sudo cat /proc/net/bonding/bond0

active-backup проще проверить в изолированном окне обслуживания. Для LACP нужно сверить хеширование потоков, состояние LAG, скорость и duplex на стороне коммутатора.

Создание veth pair и подключение к network namespace

Ниже приведён самостоятельный пример. Он создаёт namespace ns1, пару veth и L3-связь между root namespace и namespace.

sudo ip netns add ns1
sudo ip link add veth-host type veth peer name veth-ns
sudo ip link set veth-ns netns ns1
sudo ip link set dev veth-host up
sudo ip addr add 192.0.2.1/24 dev veth-host
sudo ip netns exec ns1 ip link set dev lo up
sudo ip netns exec ns1 ip link set dev veth-ns up
sudo ip netns exec ns1 ip addr add 192.0.2.2/24 dev veth-ns
sudo ip netns exec ns1 ip route add default via 192.0.2.1

Для подключения host-конца к bridge используйте другую схему. В этом случае IP-адрес для общей L2-сети размещают на br0, а на veth-host адрес обычно не назначают:

sudo ip link set dev veth-host master br0
sudo ip link set dev veth-host up
sudo bridge link show

Команды для интерфейса внутри namespace выполняйте через ip netns exec ns1. Проверяйте адрес, маршрут и состояние обоих концов, иначе контейнер может видеть интерфейс, но не иметь рабочего пути до шлюза.

Создание туннельного интерфейса

Пример GRE связывает два IPv4 endpoint. Адреса 198.51.100.10 и 198.51.100.20 замените на реальные адреса underlay.

sudo ip tunnel add gre1 mode gre local 198.51.100.10 remote 198.51.100.20 ttl 64
sudo ip addr add 10.255.0.1/30 dev gre1
sudo ip link set dev gre1 up
sudo ip route add 10.20.0.0/24 via 10.255.0.2 dev gre1
sudo ip tunnel show

На удалённом узле нужна зеркальная настройка с адресом 10.255.0.2/30 и обратным маршрутом. До создания GRE должен существовать underlay-маршрут до remote endpoint. Firewall должен пропускать протокол GRE, это IP protocol 47, а не TCP-порт.

Для IPIP используется похожая конструкция:

sudo ip tunnel add tun0 mode ipip local 198.51.100.10 remote 198.51.100.20
sudo ip addr add 10.255.1.1/30 dev tun0
sudo ip link set dev tun0 up

Для VXLAN создают L2-устройство с VNI. Статический remote endpoint подходит для простой тестовой схемы:

sudo ip link add vxlan100 type vxlan id 100 local 198.51.100.10 remote 198.51.100.20 dstport 4789
sudo ip link set dev vxlan100 up

VXLAN можно подключить к bridge, если требуется перенос Ethernet-кадров. VNI 100 и VLAN ID 100 могут совпасть по числу, но это разные идентификаторы разных технологий.

Удаление интерфейсов и сброс временной конфигурации

Удаляйте виртуальные объекты после остановки сервисов и проверки зависимостей.

sudo ip link delete vlan10
sudo ip link delete veth-host
sudo ip netns del ns1
sudo ip link delete gre1
sudo ip link delete vxlan100
sudo ip link delete br0
sudo ip link delete bond0

Удаление veth-host обычно удаляет и второй конец пары. Удаление namespace уничтожает интерфейсы, которые находятся внутри него. Bridge, bond и VLAN могут быть частью активного маршрута, поэтому перед командой проверьте ip route show и текущую SSH-сессию.

Практические схемы: виртуальные машины, контейнеры, Kubernetes и VLAN

Сервер виртуализации: bond + VLAN + bridge

Типовая схема сервера с двумя NIC и несколькими сетями выглядит так:

enp1s0 + enp2s0 -> bond0 -> vlan10 -> br-mgmt -> управление хостом и VM
                         -> vlan20 -> br-storage -> storage-сеть
                         -> vlan30 -> br-vm -> tenant-сеть виртуальных машин

Для active-backup оба физических порта подключают к согласованным портам коммутатора. Для 802.3ad коммутатор должен видеть их как одну LACP-группу. VLAN-интерфейсы создают поверх bond0, затем каждый VLAN можно подключить к отдельному bridge.

IP-адрес управления хостом размещают на br-mgmt. Адрес storage-сети размещают на br-storage, если сам хост обращается к хранилищу. br-vm может оставаться без IP, если он переносит трафик только гостевых систем.

Альтернативный вариант использует один bridge поверх bond0 с включённой фильтрацией VLAN. Виртуальным портам назначают разрешённые VLAN, а отдельные интерфейсы vlan10 и vlan20 на хосте не создают. Выбирайте одну модель и фиксируйте её в документации, чтобы не смешать два разных места назначения тегов.

Контейнер: veth + bridge + network namespace

Контейнер получает собственное сетевое пространство. Его интерфейс соединяется с host namespace через veth-пару:

namespace контейнера: eth0 <-> veth-host: bridge docker0 или cni0 -> физический или VLAN-интерфейс

Внутри контейнера обычно назначают IP и default route. На хосте veth подключают к bridge. Bridge передаёт кадры между контейнерами, а для выхода наружу runtime может настроить NAT, маршрутизацию или прямое подключение к VLAN.

Docker-подобная bridge-сеть создаёт такие связи автоматически. Ручная настройка через ip помогает понять устройство схемы и собрать лабораторный стенд, но не заменяет конфигурацию Docker, containerd или другого runtime. Автоматический менеджер может удалить ручной интерфейс при перезапуске сети.

Kubernetes: почему veth и bridge видны на узле

На worker-узле Kubernetes pod обычно получает отдельный network namespace и veth-пару. Один конец находится внутри pod как eth0, второй остаётся в сетевом пространстве узла. Дальше трафик обрабатывает CNI-плагин: он может использовать bridge, маршруты, eBPF, VXLAN, IPIP или собственные устройства.

В Calico, Cilium, Flannel и других CNI имена интерфейсов, наличие bridge и способ overlay отличаются. Поэтому удаление незнакомого veth, bridge или tunnel может нарушить связь сразу нескольких pod. Перед ручным изменением проверьте конфигурацию CNI, namespace процесса и правила маршрутизации.

Для учебного кластера или временной worker-ноды можно использовать облачную инфраструктуру с VDS и Kubernetes, например Timeweb Cloud. Сетевую схему узла всё равно нужно сверять с выбранным CNI, сетевой моделью провайдера и ограничениями MTU.

Изоляция трафика с помощью VLAN

Пример логического разделения:

На сервере создают vlan10, vlan20 и vlan30 поверх bond0 или физического trunk-порта. На коммутаторе разрешают эти VLAN. IP-подсети, default gateway, policy routing и firewall задают отдельно для каждой сети.

VLAN изолирует широковещательный домен и разделяет канальный трафик. Доступ между подсетями требует L3-маршрутизации, поэтому VLAN не заменяет правила nftables, ACL на коммутаторе и контроль доступа самого приложения. Сценарий router-on-a-stick с сабинтерфейсами Linux и фильтрацией разобран в пошаговой инструкции по маршрутизации между VLAN.

Отказоустойчивость сетевого подключения через bonding

В режиме active-backup трафик идёт через один физический порт. При потере MII-состояния bond выбирает резервный интерфейс. Проверять нужно не только состояние bond0, но и активного участника:

sudo cat /proc/net/bonding/bond0
sudo ip -details link show dev bond0
sudo ip -s link show dev enp1s0
sudo ip -s link show dev enp2s0

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

Bond защищает от отказа линии, NIC или отдельного порта. Общий коммутатор, общий блок питания, неправильный маршрут и отказ upstream-оборудования остаются единой точкой отказа. Для защиты от отказа коммутатора нужна отдельная архитектура с MLAG, stack или независимыми путями, если это поддерживает оборудование.

Как проверить работу интерфейса и диагностировать ошибки

Диагностику выполняйте снизу вверх: существование объекта, административное состояние, физический carrier, адреса, маршруты, ARP или ND, фактический трафик, VLAN, bridge, bond, namespace, firewall и приложение. Удобная последовательность команд собрана в шпаргалке по диагностике сетевых интерфейсов Linux.

Проверка состояния и адресации

sudo ip -br link
sudo ip -br addr
sudo ip link show dev enp1s0
sudo ip addr show dev vlan10
sudo ip addr show dev br0

Проверьте четыре пункта:

• интерфейс присутствует в системе;
• нужные флаги включены, обычно UP;
• на правильном объекте есть нужный IP и префикс;
• для физического пути присутствует LOWER_UP.

Для lo отсутствие физического carrier нормально. Для bridge состояние порта и состояние самого bridge могут отличаться. Для VLAN наличие интерфейса не подтверждает, что его тег проходит через коммутатор.

Проверка маршрута и выбора исходного адреса

sudo ip route show
sudo ip route get 203.0.113.20
sudo ip rule show
sudo ip neigh show

В результате ip route get ищите устройство, исходный адрес и gateway. Пример ожидаемой логики: запрос к storage-подсети должен выйти через vlan20 с адресом из 10.10.20.0/24, а не через management-интерфейс.

При нескольких uplink могут работать policy routing и отдельные таблицы. Команда ip route show без номера таблицы не всегда показывает всю картину. Проверяйте ip rule, таблицы маршрутов и исходный адрес. Состояние FAILED в ip neigh указывает на проблему ARP или ND, неправильный VLAN, отсутствие ответа узла или фильтрацию.

Проверка VLAN и bridge

sudo ip -details link show dev vlan10
sudo bridge link show
sudo bridge vlan show
sudo tcpdump -eni enp1s0 'vlan 10'
sudo tcpdump -eni vlan10 host 10.10.10.20

В выводе ip -details сверяйте VLAN ID и родительский интерфейс. В bridge link должен присутствовать нужный порт с правильным master. Команда bridge vlan show показывает VLAN, разрешённые на bridge-портах, если включена VLAN-фильтрация.

Захват на физическом trunk-порту помогает увидеть тег 802.1Q. Если на enp1s0 нет кадров VLAN 10, проблема может находиться на коммутаторе, в разрешённом списке VLAN или выше по стеку. Если тег виден на физическом порту, но нет трафика на vlan10, проверяйте родительский интерфейс, ID и локальную фильтрацию.

Проверка bond

sudo ip -details link show dev bond0
sudo cat /proc/net/bonding/bond0
sudo ip link show dev enp1s0
sudo ip link show dev enp2s0
sudo ethtool enp1s0
sudo ethtool enp2s0

В файле /proc/net/bonding/bond0 проверьте режим, MII Status, Active Slave и состояние каждого участника. Для active-backup один порт должен быть активным, резервный должен оставаться доступным для переключения. Для 802.3ad ищите сведения о партнёре LACP и состоянии агрегирования.

Счётчики ошибок и dropped packets смотрите через ip -s link. Рост RX errors, TX errors или carrier changes требует проверки кабелей, SFP, скорости, duplex и порта коммутатора.

Проверка veth и network namespace

sudo ip netns list
sudo ip link show
sudo ip netns exec ns1 ip link show
sudo ip netns exec ns1 ip addr
sudo ip netns exec ns1 ip route
sudo bridge link show

Проверьте наличие обоих концов veth, состояние UP, IP-адрес внутри namespace и host-конце, default route и подключение host-конца к bridge. Команду нужно выполнять в правильном namespace: адрес, добавленный в root namespace, не появляется внутри контейнера.

Если namespace создан container runtime, он может не отображаться в списке именованных namespaces. В этом случае используйте инструменты runtime и найдите сетевое пространство процесса, не удаляя интерфейсы вручную.

Проверка прохождения пакетов через tcpdump

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

1. интерфейс источника, например veth-host;
2. bridge, например br0;
3. VLAN или bond;
4. физический trunk-порт;
5. удалённый узел или gateway.

sudo tcpdump -eni veth-host host 192.0.2.2
sudo tcpdump -eni br0 icmp
sudo tcpdump -eni bond0 port 4789
sudo tcpdump -eni enp1s0 'vlan 10 and icmp'
sudo tcpdump -eni any host 10.10.10.20

Отсутствие исходного пакета на первом ожидаемом интерфейсе указывает на проблему выше по стеку, например приложение не отправляет трафик или маршрут выбран неправильно. Наличие запроса без ответа требует проверки удалённого узла, обратного маршрута, ARP, firewall и security group провайдера.

Распространённые ошибки при настройке виртуальных интерфейсов Linux

IP-адрес оставлен на физическом интерфейсе после добавления в bridge

• Симптом: хост теряет часть соединений, ARP ведёт себя нестабильно, пакеты выбирают неожиданный MAC.
• Причина: физический порт продолжает участвовать в L3, хотя должен работать как bridge port.
• Проверка: выполните ip addr show dev enp1s0, ip addr show dev br0 и bridge link show.
• Исправление: перенесите адреса и связанные маршруты на br0, а на физическом порту оставьте канальную конфигурацию. Делайте это через консоль или резервный канал.

VLAN создан, но коммутатор не пропускает тегированный трафик

• Симптом: vlan10 присутствует и включён, но шлюз не отвечает.
• Причина: порт коммутатора работает как access, VLAN 10 не разрешён в trunk, либо native VLAN настроен иначе.
• Проверка: сверяйте trunk/tagged-режим, разрешённый список VLAN, native VLAN и результат tcpdump -eni enp1s0 'vlan 10'.
• Исправление: синхронизируйте VLAN ID на сервере и коммутаторе. Проверьте порт с другой стороны и не меняйте сразу несколько параметров.

Перепутаны bridge, bond и VLAN

Короткое правило: bond собирает каналы, bridge коммутирует L2-порты, VLAN разделяет трафик тегами, veth соединяет namespaces, tunnel инкапсулирует пакеты, loopback обслуживает локальный стек.

Изменения через ip исчезли после перезагрузки

• Симптом: интерфейс, адрес или bridge работал до reboot и пропал после него.
• Причина: команды ip link и ip addr изменяют состояние ядра только в текущем запуске.
• Проверка: определите активный менеджер сети и проверьте его конфигурацию.
• Исправление: перенесите параметры в NetworkManager, systemd-networkd, netplan или ifupdown, выбрав один основной инструмент для конкретного интерфейса.

Не смешивайте несколько менеджеров. NetworkManager может поднять интерфейс с одними параметрами, systemd-networkd применить другие, а CNI или Docker создать собственные bridge и veth.

MTU не учтён в туннеле или цепочке VLAN

• Симптом: ping проходит, небольшие запросы работают, а HTTP, storage или репликация зависают на крупных пакетах.
• Причина: заголовки инкапсуляции уменьшили полезный размер, а Path MTU Discovery заблокирован firewall.
• Проверка: смотрите MTU командой ip link show и проверяйте пакеты с запретом фрагментации.
• Исправление: уменьшите MTU на tunnel и зависимых интерфейсах или настройте MSS, затем проверьте весь путь.

sudo ip link show dev gre1
ping -M do -s 1472 192.0.2.1
ping -M do -s 1400 10.255.0.2

Для IPv4 при MTU 1500 размер ICMP payload 1472 даёт пакет около 1500 байт с учётом заголовков. В туннеле безопасный размер часто ниже. Точное значение зависит от протокола инкапсуляции и underlay.

Сетевой интерфейс изменён вручную, но им управляет NetworkManager или CNI

• Симптом: ручной адрес исчезает, bridge пересоздаётся, veth получает другие параметры.
• Причина: управляющий компонент применяет собственное состояние при перезапуске или изменении pod.
• Проверка: определите владельца интерфейса по конфигурации NetworkManager, systemd-networkd, Docker или CNI.
• Исправление: меняйте постоянный источник конфигурации. Ручной ip используйте для теста, диагностики и временного эксперимента.

Постоянная настройка и безопасное применение на сервере

Каким инструментом управлять сетью: NetworkManager, systemd-networkd, netplan или ifupdown

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

После сохранения конфигурации проверьте порядок запуска: сначала физические интерфейсы, затем bond, после него VLAN или bridge, затем адреса и маршруты. Для namespace и CNI порядок задаёт runtime или оркестратор.

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

1. Получите доступ через консоль гипервизора, IPMI, serial console или второй независимый канал.
2. Сохраните вывод ip -br link, ip -br addr, ip route show, ip rule show и настройки firewall.
3. Определите интерфейс, через который идёт текущая SSH-сессия.
4. Проверьте, где должен находиться IP-адрес после изменения: на VLAN, bridge, bond или физическом порту.
5. Откройте вторую SSH-сессию и не закрывайте первую до полной проверки.
6. Подготовьте план отката, включая обратные команды и доступ к консоли.
7. Для рискованной операции настройте контрольный таймер, который вернёт старые параметры при отсутствии подтверждения.

Пример запуска подготовленного скрипта отката через systemd timer:

sudo systemd-run --unit=network-rollback --on-active=5m /usr/local/sbin/rollback-network.sh

Скрипт должен существовать, иметь права на запуск и быть проверен заранее. После успешной проверки отмените временный unit:

sudo systemctl stop network-rollback.timer 2>/dev/null || true

Команда отмены зависит от того, как systemd создал transient unit. На критичном сервере проверяйте имя через systemctl list-timers и не полагайтесь на непроверенный rollback-скрипт.

Как документировать схему интерфейсов

Фиксируйте физические порты, роли интерфейсов, VLAN ID, IP-подсети, master-связи, namespace, MTU, режим bond и внешний порт коммутатора. Для каждой точки указывайте, где находится IP-адрес и какой компонент управляет настройками.

Пример записи:

enp1s0 + enp2s0 -> bond0, mode active-backup
bond0 -> vlan10, 10.10.10.0/24, management
bond0 -> vlan20 -> br-storage, 10.10.20.0/24
bond0 -> vlan30 -> br-vm, L2 для tenant VM
br-vm -> veth-host -> ns1:veth-ns

Отдельно записывайте MTU каждого слоя. Для туннеля добавляйте локальный и удалённый endpoint, маршрут до endpoint, протокол или UDP-порт, VNI для VXLAN и правила firewall. Такая схема сокращает время диагностики и помогает безопасно передать конфигурацию другому администратору.

Шпаргалка: какой интерфейс выбрать и какие команды использовать

Выбор технологии по задаче

Минимальный набор команд ip

Перед запуском заменяйте enp1s0, vlan10, VLAN ID, адреса и имена namespace на значения своей схемы. Не применяйте команды создания bridge или bond к рабочему SSH-интерфейсу без резервного доступа и плана отката.

Финальный чек-лист проверки

1. Интерфейс существует и имеет ожидаемый тип.
2. Нужные объекты находятся в правильном namespace.
3. Интерфейс и его зависимости имеют состояние UP.
4. Для физического пути присутствует LOWER_UP.
5. IP-адрес, префикс и MAC назначены правильному уровню схемы.
6. Маршрут до целевого узла выбирает нужный интерфейс и исходный адрес.
7. Для VLAN совпадают ID на Linux и коммутаторе, а trunk пропускает тег.
8. Для bridge проверены порты, VLAN-фильтрация и отсутствие L2-петли.
9. Для bond проверены режим, active slave, MII-состояние и LACP.
10. Для veth проверены оба конца, адреса и маршрут внутри namespace.
11. Для tunnel проверены underlay-маршрут, endpoint, MTU, протокол или UDP-порт.
12. tcpdump показывает прохождение запроса и ответа на нужных участках.
13. Firewall, ACL и правила cloud-провайдера разрешают ожидаемый трафик.
14. Конфигурация сохраняется после перезагрузки через выбранный сетевой менеджер.
15. Рабочие сервисы и SSH остаются доступными после применения изменений.