ЛР1: настройка сети в Linux - полный разбор от ТЗ до сдачи

Эта страница - не конспект теории, а полный путь по одной конкретной лабе курса "Сети" (ITMO): что требовало задание, какое решение под каждый пункт подготовлено, где лежит каждый файл и что ещё нужно доделать руками на реальных ВМ перед отправкой отчёта. Если открываешь это через полгода и забыл всё - начинай отсюда, а не с пересказа теории ниже.

Что было в задании

Тема: "Консольные утилиты настройки сетевых компонентов Linux" (ПРАКТИЧЕСКАЯ РАБОТА №1 v 001-2026). Цель по методичке - получить навыки конфигурирования сетевых интерфейсов (IPv4) в Linux, освоить утилиты командной строки и современные сетевые менеджеры.

Нужно для выполнения: VirtualBox + две виртуальные машины Linux (в методичке названы CentOS и Debian, но дальше по тексту прямо рекомендуются две ВМ Debian 12/13, лучше связанные копии одного образа).

Два сценария конфигурации, которые используются во всех частях:

1. Статика: IP=10.100.0.2, MASK=255.255.255.0, GATE=10.100.0.1, DNS=8.8.8.8.
2. Динамика: все параметры - по DHCP.

Части задания:

• Часть 1. Написать скрипт-меню на первой ВМ, который умеет (без использования сетевых менеджеров, только голые утилиты): показать модель карты/скорость/duplex/link/MAC, показать текущий IPv4 (адрес/маска/шлюз/DNS), настроить интерфейс по сценарию №1, настроить по сценарию №2, выйти. Ограничение: скрипт не должен менять системные конфигурационные файлы, кроме DNS.
• Часть 2. На первой ВМ через nmcli: применить сценарий №1 на реальном интерфейсе, создать виртуальный dummy-интерфейс dm0 с адресом 10.100.0.3, поднять его, проверить ping между реальным интерфейсом и dm0, определить MAC виртуального интерфейса. Требуется режим сети VirtualBox "Внутренняя сеть".
• Часть 3. На второй ВМ (та же внутренняя сеть, что в Части 2) через netplan: назначить интерфейсу два адреса - 10.100.0.4 и 10.100.0.5 (маска /24), шлюз 10.100.0.3 (тот самый dummy с первой ВМ). Проверить ping между всеми адресами 10.100.0.2–10.100.0.5, посмотреть ARP-кэш.
• Часть 4. На любой из ВМ - bonding: добавить сетевой интерфейс в конфигурацию ВМ (режим NAT), убедиться, что загружен модуль ядра bonding, собрать bond-группу bond007 в режиме чередования пакетов (round-robin) с DHCP на самой группе, поднять её, посмотреть /proc/net/bonding/bond007 и /proc/net/dev, написать скрипт, выводящий время + имя интерфейса + RX/TX packets, и трижды собрать эти данные во время ping -I bond007 8.8.8.8, проанализировать результат.

Отчёт должен содержать: титульный лист, артефакты (скрипт Части 1 п.2; команды Части 2 п.2; команды и вывод Части 2 п.4; YAML-файл Части 3 п.3; команды и вывод Части 3 п.5; команды/конфиги и вывод Части 4 п.5; скрипт Части 4 п.7) и письменные ответы на 7 контрольных вопросов (про ip, nmcli, netplan, режимы bonding, duplex, смысл нескольких IP на интерфейсе, смысл виртуальных интерфейсов).

Куда сдавать: edu-net@yandex.ru, тема письма - №группы ФИО(латиницей) №работы, срок - 4 недели с момента выдачи.

Все файлы решения

Каждый файл ниже соответствует одному пункту задания - открывай прямо по ссылке, все они лежат рядом с этой страницей:

Как устроен каждый слой - концептуальный разбор

Задание решает одну и ту же задачу (задать интерфейсу адрес, маску, шлюз, DNS) четырьмя разными инструментами подряд, от самого низкоуровневого к самому высокоуровневому. Разбор ниже объясняет, зачем нужен каждый слой и чем он отличается от соседних - это база, без которой команды в файлах выше выглядят как магические заклинания.

Слой 1: голые команды ip, ethtool, dhclient - решает part1_net_utils.sh

Это уровень прямого общения с ядром Linux: команда меняет состояние интерфейса прямо сейчас, в памяти, без какой-либо службы, которая бы это состояние помнила. После reboot всё возвращается к тому, что записано в конфигурационных файлах - а этот слой файлы вообще не трогает. Именно поэтому задание прямо требует "не менять системные конфигурационные файлы" в Части 1: это тест на то, что ты понимаешь разницу между runtime-состоянием и постоянным конфигом.

Базовый набор команд, из которых собран скрипт:

ip link show                                    # интерфейсы, MAC, up/down
ip -4 addr show dev eth0                        # текущий IPv4 + маска
ip addr add 10.100.0.2/24 dev eth0               # добавить адрес
ip addr flush dev eth0                           # снять все адреса с интерфейса
ip route replace default via 10.100.0.1 dev eth0 # шлюз по умолчанию
ip neigh show                                    # ARP-кэш
ip neigh flush all                               # очистить ARP-кэш
ethtool eth0                                     # скорость, duplex, статус линка
ethtool -i eth0                                  # драйвер + bus-info (для lspci -s)
dhclient eth0                                    # получить адрес по DHCP

ARP-кэш заполняется автоматически при любом обмене пакетами внутри локальной сети - команда ip neigh show просто показывает то, что ядро уже выучило, а не что-то, что нужно настраивать руками.

DNS на этом уровне - не команда, а простой текстовый файл /etc/resolv.conf со строкой nameserver 8.8.8.8. Никакой отдельной "утилиты DNS" тут нет: файл читает системный резолвер при каждом обращении по имени. Задание прямо разрешает менять этот файл - единственное исключение из правила "не трогать конфиги".

ethtool -i eth0 даёт bus-info (адрес на шине PCI) - по нему lspci -s <bus-info> показывает уже человекочитаемую модель карты, потому что сам ethtool модель не печатает, только техническую информацию о драйвере. Именно так это сделано внутри part1_net_utils.sh.

Слой 2: NetworkManager и nmcli - решает part2_nmcli_commands.sh

NetworkManager решает главную проблему первого слоя - "конфиг живёт только до перезагрузки". Он хранит профили подключений и сам применяет их при старте системы или при появлении устройства.

nmcli con show                                   # список профилей и их устройств
nmcli con mod "<имя>" ipv4.method manual \
    ipv4.addresses 10.100.0.2/24 \
    ipv4.gateway 10.100.0.1 ipv4.dns 8.8.8.8      # правка профиля
nmcli con up "<имя>"                              # применить профиль

Отдельный практический трюк лабы - создать dummy-интерфейс dm0 с адресом в той же подсети /24, что и реальная карта:

nmcli con add type dummy ifname dm0 con-name dm0 \
    ipv4.method manual ipv4.addresses 10.100.0.3/24
nmcli con up dm0

Реальный интерфейс (10.100.0.2) и виртуальный dm0 (10.100.0.3) оказываются в одной логической сети с точки зрения ядра - ping между ними проходит внутри одной машины, без какого-либо второго устройства. Это дешёвый способ потренировать многие сценарии (маршрутизация, ARP, bonding) вообще без второй ВМ, и заодно основа для Части 3: адрес 10.100.0.3 на этом dm0 дальше становится шлюзом для второй ВМ.

Слой 3: netplan - решает part3_netplan_config.yaml и part3_check_commands.sh

Первые два слоя - императивные: ты выполняешь команду за командой, и результат - сумма всех выполненных действий. netplan устроен иначе - один YAML-файл описывает, каким должно быть состояние сети, а netplan apply сам разбирается, что для этого нужно сделать (обычно дёргает под капотом NetworkManager или systemd-networkd).

network:
  version: 2
  ethernets:
    enp0s3:
      addresses:
        - 10.100.0.4/24
        - 10.100.0.5/24
      routes:
        - to: default
          via: 10.100.0.3

Два адреса на одном интерфейсе - не ошибка и не крайний случай: ядро откликается на любое количество IP, назначенных интерфейсу. Практический смысл (это вопрос №6 из методички) - один физический сервер может отвечать за два логических сервиса с разными адресами, либо временно "жить" сразу в двух подсетях при миграции без простоя.

Gateway здесь - 10.100.0.3, то есть тот самый dm0 с первой ВМ из Части 2: вторая ВМ считает своим шлюзом виртуальный интерфейс первой. Отсюда требование задания делать это "в той же внутренней сети VirtualBox" - иначе пакеты друг до друга физически не дойдут. После netplan apply part3_check_commands.sh прогоняет ping по всем четырём адресам и печатает ARP-кэш - если пинги прошли, в кэше обязаны появиться MAC-адреса всех участников, потому что ARP "выучивает" соответствие IP→MAC при любом обмене пакетами в локальной сети.

Слой 4: bonding - решает part4_bonding_setup.sh и part4_stats_script.sh

bonding берёт несколько физических карт (слейвов) и превращает их в один логический интерфейс - мастер. Решение, через какой слейв слать конкретный пакет, принимает сам модуль ядра по выбранному режиму.

Зачем это нужно на практике - две независимые причины, не одна:

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

Стандартные режимы:

// mode=0 - пакеты передаются поочерёдно
// через каждый слейв по кругу.
// Балансировка + отказоустойчивость.
// Свитч не обязан ничего знать про bonding,
// но пакеты могут прийти не по порядку.

// mode=1 - активен только один слейв,
// остальные простаивают в резерве.
// Только отказоустойчивость, без балансировки.
// Не требует вообще никакой настройки свитча.

Ещё три режима, которые встречаются реже: balance-xor и 802.3ad (LACP) дают балансировку через хеш или динамическую агрегацию, но требуют, чтобы свитч поддерживал агрегацию каналов на своей стороне; balance-tlb/balance-alb балансируют адаптивно по текущей загрузке слейвов и не требуют особой настройки свитча вовсе. Задание просит именно "чередование пакетов" - это mode=balance-rr, он и зашит в part4_bonding_setup.sh.

Проверить режим balance-rr вживую можно без спецсофта - во время ping -I bond007 8.8.8.8 смотреть на /proc/net/dev скриптом part4_stats_script.sh: счётчики RX packets/TX packets у слейвов должны расти поочерёдно, а не только у одного из них (использование: ./part4_stats_script.sh bond007 3 5 - три снимка с паузой 5 секунд). /proc/net/bonding/bond007 - отдельный псевдофайл, который ядро обновляет в реальном времени специально для отладки состояния bonding-группы (кто активен, какой режим, статус линка каждого слейва).

Что в отчёте и что ещё нужно сделать руками

otchet_lab1.pdf - это уже почти готовый документ: титульный лист, полный текст всех скриптов и конфигов из таблицы выше вставлен целиком по разделам (Часть 1–4), плюс готовые развёрнутые ответы на все 7 контрольных вопросов (включая таблицу по режимам bonding для вопроса №4).

Дожить до отправки в файле нужно руками три вещи, которые невозможно сделать без реальных ВМ:

1. Титульный лист - вписать ФИО (плюс латиницей отдельно для темы письма), группу и дату вместо плейсхолдеров [ЗАПОЛНИТЬ].
2. Реальные имена интерфейсов - везде в скриптах и в самом отчёте заменить заглушки enp0s3/enp0s8/dm0 (где это не имя, а пример) на то, что покажет ip -brief link конкретно на твоих ВМ.
3. Консольный вывод - прогнать все скрипты на ВМ и вставить в отчёт настоящий вывод вместо всех оставшихся плейсхолдеров [ЗАПОЛНИТЬ: ...] (модель карты и duplex, текущий IPv4 до/после каждого сценария, MAC dm0, ping и arp-кэш Части 3, содержимое /proc/net/bonding/bond007, три снимка статистики Части 4 п.9).