Centos 7 nic teaming настройка
Обновлено: 02.07.2024
За основу взята более ранняя прочитанная мной статья на Хабре, которой лично мне оказалось достаточно для понимания механизма policy routing в целом — и катастрофически мало для реализации этого типа маршрутизации на сервере компании. Было 2 серьезных подводных камня, над которыми пришлось работать самостоятельно, и которые нельзя оставить без внимания:
- Сохранение настроек в целом
- Перебивание настроек утилитой Network Manager
Свою статью я напишу в виде той инструкции, которую написал для будущих поколений айтишников в своей фирме — так что некоторые пункты из основной статьи буду приводить либо в неизменном, либо в пересказанном для себя виде. Их буду выделять курсивом. Для полного понимания того, что здесь написано, рекомендую ознакомиться с ней полностью.
Немного практики, или чего мы хотим
А хотим мы получить маршрутизацию, которая:
- будет отправлять данные на тот же шлюз, с которого пришел запрос
- будет контролируемо балансировать нагрузку между шлюзами, используя т.н. «вес» (weight) шлюзов
Выдаем IP-адреса:
Определяем таблицы:
Для использования более чем одного маршрута, статической маршрутизации уже недостаточно. Для OSPF наша схема слишком проста, поэтому остановимся на динамической маршрутизации с использованием таблиц.
Заворачиваем исходящий трафик, на шлюзы, с которых пришел входящий:
Думаю теперь уже объяснять смысл этих строк не надо. Аналогичным образом можно сделать доступность сервера по более чем двум шлюзам.
Балансировка трафика между аплинками
Делается одной элегантной командой:
Эта запись заменит существующий default-роутинг в таблице main. При этом маршрут будет выбираться в зависимости от веса шлюза (weight). Например, при указании весов 7 и 3, через первый шлюз будет уходить 70% соединений, а через второй – 30%. Есть один момент, который при этом надо учитывать: ядро кэширует маршруты, и маршрут для какого-либо хоста через определенный шлюз будет висеть в таблице еще некоторое время после последнего обращения к этой записи. А маршрут до часто используемых хостов может не успевать сбрасываться и будет все время обновляться в кэше, оставаясь на одном и том же шлюзе. Если это проблема, то можно иногда очищать кэш вручную командой ip route flush cache.
Результат
После выполнения данной команды можно проверять доступность сервера. В принципе, можно было сказать, что на этом наша работа закончилась. Однако есть одна проблема — после перезагрузки все настройки сбросятся.
Сохранение настроек в целом
Теперь необходимо заставить систему применять полученные настройки после перезагрузки.
IP-адреса
Для начала выясняем, какой mac-address какому интерфейсу принадлежит. Выполняем команду:
Далее создаем конфигурационные файлы настроек ifconfig с использованием полученных mac-адресов. Для этого создаем файлы с приставкой ifcfg и названием интерфейса в папке
Создаем таблицы маршрутизации
Далее необходимо создать постоянные таблицы, присвоить им имена (чтобы было проще ориентироваться) и прописать правила использования этих таблиц:
Теперь возвращаемся в каталог /etc/sysconfig/network-scripts и продолжаем работать там.
Создаем содержимое таблиц:
Создаем правила обработки этих таблиц:
Балансировка
Далее заменяем статику динамикой. Не обошлось без напильника, т.к. стартап-скрипты, описанные выше, привязываются к интерфейсам, а в нашем случае правило пишется сразу про 2 интерфейса. Поэтому решено было создать отдельный скрипт и прописать его в автозагрузку, используя стандартный механизм автозапуска Linux — /etc/rc.local . Содержимое скрипта:
Его путь в автозагрузке:
Для тех, у кого не заработало исполнение файла rc.local, прошу выполнить следующие команды:
В результате после перезагрузки мы получаем рабочую систему с использованием 2 независимых аплинков, трафик между которыми балансируется с помощью weight. А теперь печальная новость: ничего этого работать не будет.
Перебивание настроек утилитой Network Manager
Меньшая проблема из тех, что были на моем пути, но которая тем не менее, изрядно попортила мне нервы. Проблема данной утилиты в том, что она сохраняет и использует настройки не из основных конфигурационных файлов системы, а из своих внутренних. Поскольку стартует она вместе с X11, то есть в самую последнюю очередь, когда сеть уже запущена, она перезаписывает настройки сети, и каких-то сложных конфигураций на ней построить не получится.
Чтобы ее отключить, необходимо выполнить в консоли:
Также, можно пойти другим путем и использовать systemctl:
Результат
И вот после выполнения этого действия и перезагрузки мы получаем рабочую систему с использованием 2 независимых аплинков, трафик между которыми балансируется с помощью weight.
Что такое "объединение" (bonding) сетевых интерфейсов и как оно работает?
Под словом объединение будем подразумевать - портовый транкинг (автоматическое распределение каналов по требованию). В дальнейшем будет использоваться слово - "объединение" потому, что происходит практически объединение в единое целое.
Объединение позволяет совокупно собрать несколько портов в одну группу, эффективно объединяя пропускную способность в одном направлении. Объединение так же позволяет создавать мульти-гигабитные каналы для транспортировки трафика через высокопропускные районы вашей сети. Например, вы можете объединить два порта по 100 мегабит в 200 мегабитный магистральный порт. Это эквивалентно одному интерфейсу с пропускной способностью 200 мегабит.
Где я могу использовать подобное решение?
Вы можете использовать его там, где необходима избыточность звязи, отказоустойчивость и балансировка нагрузки сети. Это лучший способ иметь высокий сегмент доступности сети. Очень полезно использовать объединение в сетях с поддержкой 802.1q VLAN (ваше сетевое оборудование должно поддерживать протокол 802.1q).
Какие типы режимов объединения доступны?
mod = 1 (active-backup)
Работает только один интерфейс, остальные находятся в очереди горячей замены. Если ведущий интерфейс перестает функционировать, то его нагрузку подхватывает следующий (присвоив mac-адрес) и становится активным. Дополнительная настройка коммутатора не требуется.
mode = 2 (balance-xor)
XOR политика: Передача на основе [(исходный MAC-адрес → XOR → MAC-адрес получателя) %число интерфейсов]. Эта команда выбирает для каждого получателя определенный интерфейс в соответствии с mac-адресом. Режим обеспечивает балансировку нагрузки и отказоустойчивость.
mode = 3 (broadcast)
Все пакеты передаются на все интерфейсы в группе. Режим обеспечивает отказоустойчивость.
mode = 4 (802.3ad)
- IEEE 802.3ad Dynamic Link aggregation (динамическое объединение каналов). Создает агрегации групп, имеющие одни и те же скорости и дуплексные настройки. Использует все включенные интерфейсы в активном агрегаторе согласно спецификации 802.3ad.
- Предварительнае реквизиты
- Поддержка ethtool (позволяет отображать или изменять настройки сетевой карты) базы драйверов для получения скорости и дуплекса каждого интерфейса.
- Коммутатор с поддержкой IEEE 802.3ad Dynamic Link aggregation. Большинство параметров потребует некоторой конфигурации для режима 802.3ad.
mode =5 (balance-tlb)
- Поддержка ethtool (позволяет отображать или изменять настройки сетевой карты) базы драйверов для получения скорости и дуплекса каждого интерфейса.
mode = 6 (balance-alb)
Адаптивное перераспределение нагрузки: включает balance-tlb плюс receive load balancing (rlb) для трафика IPv4 и не требует специального конфигурирования. То есть все так же как и при mode =5, только и входящий трафик балансируется между интерфейсами. Полученная балансировка нагрузки достигается опросом ARP. Драйвер перехватывает ответы ARP, направленные в локальной системе в поисках выхода и перезаписывает исходный адрес сетевой карты с уникальным аппаратным адресом одного из интерфейсов в группе.
Объединение интерфейсов в CentOS 4.
Далее вы подключаете к коммутатору второй (третий . ) кабель. И проводите конфигурацию.
В файле modprobe.conf добавить следующее:
Обязательно добавте псевдоним сети.
В каталоге /etc/sysconfig/network-scripts создать файл ifcfg-bond0
Изменить ifcfg-eth0:
Проверте состояние объединения.
Вы можете использовать несколько объединенных интерфейсов. Для этого вам необходимо загрузить модули объединения столько, сколько вам нужно. Полагая, что вы хотите два объединенных интерфейса, вы должны настроить /etc/modules.conf следующим образом:
Чтобы управлять самим объединением интерфейсов, вы можете использовать команду ifenslave (см. man ifenslave).
На серверах имеющих несколько сетевых интерфейсов каждый отдельно взятый интерфейс можно использовать под какую-то выделенную задачу, например отдельный интерфейс под трафик управления хостом и отдельный интерфейс под трафик периодического резервного копирования. Может возникнуть мысль о том, что такая конфигурация имеет свои плюсы, например, позволяет максимально жёстко разграничить утилизацию интерфейсов под особенности разных задач. Но на этом плюсы, пожалуй, и заканчиваются. Ибо при таком подходе может получиться так, что один интерфейс будет постоянно чем-то чрезмерно нагружен, а другой интерфейс будет периодически полностью простаивать. К тому же, в такой схеме каждый из физических интерфейсов будет выступать как конкретная сущность, при выходе из строя которой будет происходить остановка того или иного сетевого сервиса, жёстко связанного с этой сущностью. C точки зрения повышения доступности и балансировки нагрузки, более эффективными методом использования нескольких сетевых интерфейсов сервера является объединение этих интерфейсов в логические сущности с использованием технологий Network Bonding и Network Teaming.
В этой заметке на конкретном примере мы рассмотрим то, как с помощью технологии Network Bonding в ОС CentOS Linux 7.2 можно организовать объединение физических сетевых интерфейсов сервера в логический сетевой интерфейс (bond), а уже поверх него создать виртуальные сетевые интерфейсы под разные задачи и сетевые службы с изоляцией по разным VLAN. Агрегирование каналов между коммутатором и сервером будет выполняться с помощью протокола Link Aggregation Control Protocol (LACP) регламентированного документом IEEE 802.3ad. Использование LACP, с одной стороны, обеспечит высокую доступность агрегированного канала, так как выход из строя любого из линков между сервером и коммутатором не приведёт к потери доступности сетевых сервисов сервера, и с другой стороны, обеспечит равномерную балансировку нагрузки между физическими сетевыми интерфейсами сервера. Настройка в нашем примере будет выполняться как на стороне коммутатора (на примере коммутатора Cisco Catalyst WS-C3560G), так и на стороне Linux-сервера с двумя сетевыми интерфейсами (на примере сервера HP ProLiant DL360 G5 с контроллерами Broadcom NetXtreme II BCM5708/HP NC373i)
Настройка конфигурации LACP на коммутаторе Cisco
Активация механизмов LACP на коммутаторе Cisco сводится к созданию виртуальной группы портов channel-group и включению в эту группу нужных нам портов коммутатора.
Очищаем существующую конфигурацию портов коммутатора, которые будем включать в channel-group (в нашем примере это будут порты 21 и 22 ):
Создаём channel-group и включаем в неё нужные нам порты коммутатора, предварительно эти отключив порты:
Вносим изменения в свойства появившегося виртуального интерфейса Port-channel2:
Изменения в свойствах первого порта-участника channel-group вносим минимальные, так как основные параметры наследуются портом с виртуального интерфейса channel-group:
Вносим изменения в свойства второго порта-участника channel-group:
Не забываем сохранить изменения:
Проверяем итоговую конфигурацию портов:
Проверяем статус подключения портов:
До тех пор, пока на стороне нашего Linux-сервера не будет настроен LACP, статус портов будет отображаться как suspended/notconnect, а после настройки статус должен будет измениться на connected (это можно будет проверить позже):
Проверяем внутренний статус LACP:
Здесь аналогично, до тех пор, пока на стороне нашего Linux-сервера не будет настроен LACP, статус LACP будет соответствующий, а после настройки статус должен будет измениться:
Теперь можем перейти к настройке Network Bonding с LACP на стороне Linux-сервера.
Настройка Network Bonding c LACP в CentOS Linux 7.2
Проверим наличие модуля поддержки bonding (команда должна отработать без ошибок):
В ниже представленном примере мы рассмотрим сценарий настройки логического bond-интерфейса bond0 (master-интерфейс), членами которого будут два имеющихся в сервере физических интерфейса enp3s0 и enps5s0 (slave-интерфейсы). А затем на созданном bond-интерфейсе мы создадим дочерний VLAN-интерфейс, имеющий доступ к изолированной тегированной сети с определённым номером VLAN. Всю настройку мы будем выполнять путём прямой правки файлов интерфейсов.
Создадим файл с конфигурацией нового агрегирующего интерфейса bond0 :
Наполним файл параметрами бонда bond0 :
Опции BONDING_OPTS можно передавать и через файл /etc/modprobe.d/bonding.conf , но вместо этого лучше использовать файлы ifcfg-bond*. Исключением здесь является лишь глобальный параметр max_bonds. Это замечание описано в документе Create a Channel Bonding Interface .
Получить информацию о всех возможных опциях BONDING_OPTS и вариантах их значений можно в документе Using Channel Bonding .
В нашем примере используется несколько опций:
- mode= 802.3ad , который определяет режим работы bond-а (bonding policy). В нашем случае выбран режим с использованием протокола LACP. Этот режим для корректной работы должен поддерживаться и коммутатором, к которому подключаются сетевые интерфейсы bond-а.
- lacp_rate= fast , который заставляет bonding-интерфейс отсылать пакеты LACPDU ежесекундно, в то время как значение по умолчанию slow , которое определяет 30-секундный интервал.
- xmit_hash_policy= layer2+3 , который определяет режим вычисления хешей при организации балансировки нагрузки между интерфейсами бонда. Эта опция используется только для режимов работы бонда (ранее описанный mode) поддерживающих балансировку нагрузки, таких как balance-xor и 802.3ad . Значение layer2+3 говорит о том, что для вычисления хешей будут использоваться как MAC адреса получателей/отправителей пакета, так и их IP адреса, если это возможно. Значение по умолчанию для этой опции – layer2 , что определяет вычисление хеша только по MAC-адресам.
- miimon= 100 , который определяет количество миллисекунд для мониторинга состояния линка с помощью механизмов MII, который, к слову говоря, должен поддерживаться физическим сетевым контроллером. Значение опции miimon по умолчанию – 0, что значит, что данный функционал не используется.
Чтобы проверить то, может ли наш сетевой контроллер работать с MII, можно выполнить:
Значение yes в данном случае говорит о поддержке MII.
Если вы используете режим active-backup bonding, то есть рекомендация настраивать дополнительную опцию bond-интерфейса: fail_over_mac= 1 . Как я понял, это нужно для того, чтобы использовать для bond в качестве основного MAC-адреса, MAC-адрес backup-интерфейса, что позволит сократить время потери соединений в процессе fail-over.
Создадим файл с конфигурацией slave-интерфейсов, то есть физических Ethernet-портов, которые будут участниками bond0 (файл скорее всего уже существует, так что просто отредактируем его под свою задачу):
Второй slave-интерфейс настраиваем по аналогии:
Параметры файла аналогичные за исключением параметров DEVICE и NAME
Если используется служба NetworkManager, то перезагрузим её конфигурацию с учётном созданных/изменённых файлов ifcfg-* :
Перезапускаем slave-интерфейсы:
Если отдельное отключение/включение интерфейсов приводит к ошибкам (это возможно в случае если ранее подключения контролировались службой NetworkManager), то перезапускаем сеть полностью:
Убедимся в том, что созданные интерфейсы успешно запущены со статусом UP и заданными нами настройками, например обратим внимание на размер MTU.
Итак, bond создан и запущен в работу, и теперь переходим к созданию виртуальных интерфейсов с поддержкой VLAN поверх нашего bond-а.
Проверим наличие модуля поддержки VLAN (команда должна отработать без ошибок)
Под каждый отдельный VLAN-интерфейс создаём конфигурационные файлы в каталоге /etc/sysconfig/network-scripts по типу ifcfg-bond < номер бонда > . < номер VLAN-а > . Например создадим конфигурационный файл для bond-интерфейса bond0 с VLAN 2
Попробуем поднять созданный VLAN-интерфейс или опять-же просто перезапускаем сеть:
Чтобы разнообразные сетевые службы, используемые на нашем сервере приняли во внимание изменение сетевой конфигурации, можно перезапустить их, либо просто перезагрузить сервер.
Убедимся в том, что VLAN-интерфейс поднялся с указанными нами настройками:
Аналогичным образом мы можем создать на сервере столько выделенных виртуальных VLAN интерфейсов, сколько потребуется для разделения трафика между разными задачами и сетевыми службами исполняемыми на сервере.
Проверяем статус работы bond0 :
Если в секции 802.3ad info значение параметра Partner Mac Address не содержит MAC-адреса коммутатора, а вместо этого видно значение 00:00:00:00:00:00, это значит то, что обмен пакетами LACPDU с коммутатором по какой-то причине не выполняется (либо на стороне коммутатора неправильно настроен LACP, либо коммутатор вовсе его не поддерживает)
На этом этапе агрегированный LACP линк между коммутатором и сервером можно считать настроенным. На стороне коммутатора убедимся в том, что вывод ранее упомянутых команд изменился:
Теперь можно переходить к заключительному этапу – проверкам нашего LACP соединения на предмет устойчивости соединения при отказе любого из портов на стороне коммутатора/сервера а также на предмет корректности балансировки нагрузки.
Проверка высокой доступности соединения
Теперь попробуем проверить устойчивость нашего LACP-соединения. Для этого запустим с любой сторонней системы, например с рабочей станции администратора, ping IP-адреса bond-интерфейса сервера
Подключимся к коммутатору Cisco и выполним отключение одного из портов, входящих в группу channel-group, обеспечивающей со стороны коммутатора LACP-соединение.
Убедимся в том, что запущенная утилита ping не отражает факт потери пакетов. Если всё в порядке, включим отключенный порт коммутатора, а затем отключим второй порт входящий в группу channel-group:
Снова проверим, что ping не имеет потерь пакетов. Если всё в порядке, включим отключенный порт коммутатора и будем считать, что наше LACP-соединение Cisco channel-group <-> Linux bond успешно отрабатывает ситуацию потери соединения на любом из интерфейсов коммутатора, входящих в channel-group. Аналогичную проверку можно выполнить и со стороны Linux сервера попеременно отключая интерфейсы входящие в bond:
Здесь между включением первого интерфейса и отключением второго для чистоты эксперимента нужно сделать небольшую паузу (5-7 секунд), чтобы LACP-линк смог полностью перестроиться для того, чтобы не было потерь пакетов. Если же эту паузу не сделать, то несколько пакетов может таки потеряться, но потом соединение всё-же будет автоматически восстановлено.
Проверка балансировки нагрузки соединения
Чтобы проверить факт того, что трафик действительно распределяется по интерфейсам bond-а, воспользуемся немного более сложной процедурой тестирования, для которой используем три компьютера, то есть сам наш сервер KOM-AD01-VM32 (IP: 10.1.0.32 ) и любые два Linux-компьютера, например KOM-AD01-SRV01 (IP: 10.1.0.11 ) и KOM-AD01-SRV02 (IP: 10.1.0.12 ). Установим на все три компьютера две утилиты - iperf (для тестирования скорости) и nload (для отображения нагрузки интерфейсов в реальном времени).
Начнем с проверки входящего трафика.
Установим на проверяемом сервере KOM-AD01-VM32 утилиты iperf и nload а затем на время теста выключим брандмауэр (либо можете создать разрешающее правило для порта, который будет слушать запущенный серверный iperf, по умолчанию это TCP 5001). Запустим утилиту iperf в режиме сервера (с ключом -s), то есть ориентированную на приём трафика:
Здесь же, но в отдельной консоли, запустим утилиту nload, которая в реальном времени будет показывать нам статистические значения нагрузки на интерфейсы. В качестве параметров укажем названия интерфейсов, за нагрузкой которых нужно следить:
Затем выполняем отсылку трафика с помощью iperf (в режиме клиента) с компьютеров KOM-AD01-SRV01 и KOM-AD01-SRV02 (запустим одинаковую команду одновременно на обоих этих компьютерах):
В качестве параметров iperf укажем следующие значения:
- -c – работа в режиме клиента (отсылка трафика)
- 10.1.0.32 - IP адрес сервера, на который клиент iperf будет посылать трафик ( KOM-AD01-VM32 )
- -t 600 – время, в течение которого будет выполняться отсылка трафика (600 секунд)
- -i 2 - интервал в секундах для вывода статистической информации об отсылке трафика на экран (каждые 2 секунды)
- -b 100m – размер пропускной способности сети, которую будет пытаться задействовать iperf при отсылке трафика (в нашем случае 100 мегабит/с)
После того, как iperf в режиме клиента начнёт работу на обоих серверах, переходим на проверяемый сервер KOM-AD01-VM32 и наблюдаем за статистикой nload. На начальном экране увидим статистику по входящему и исходящему трафику по первому интерфейсу ( enp3s0 ). Обращаем внимание на значения по входящему трафику:
Чтобы увидеть статистику по следующему интерфейсу ( enp5s0 ) просто нажмём Enter:
Как видим, скорость на обоих интерфейсах распределена равномерно и равна примерно 100 мегабит/с, значит балансировка входящего трафика работает успешно.
Далее, по аналогичной методике, протестируем механизм балансировки нагрузки для трафика исходящего с нашего подопытного сервера KOM-AD01-VM32 . Для этого iperf будет запускаться на компьютерах KOM-AD01-SRV01 / KOM-AD01-SRV02 в режиме сервера, принимающего трафик. Запустим одинаковую команду на обоих этих компьютерах, не забывая при этом про необходимость открытия порта для сервера iperf:
А на компьютере KOM-AD01-VM32 утилиту iperf запускаем в режиме клиента, отправляющего трафик на компьютеры KOM-AD01-SRV01 / KOM-AD01-SRV02 , используя при этом запуск из двух разных консолей:
Запускаем на компьютере KOM-AD01-VM32 третью консоль и наблюдаем за ситуацией в nload
На этот раз обращаем внимание на исходящий трафик на первом интерфейсе…
…и исходящий трафик на втором интерфейсе…
Как видим, трафик распределён по разным интерфейсам нашего bond-a, значит балансировка исходящего трафика работает успешно.
Если ранее на время теста отключался брандмауэр, то по окончанию теста не забываем включить его обратно:
В данной статье мы рассмотрим способы настройки сети в системах Linux CentOS 7/8, покажем, как настраивать сетевых интерфейсов через конфигурационные файлы, основные утилиты для настройки сети и многое другое. Это актуальная тема, так как изначально настройка любого сервера начинается с настройки на нем сети.
В статье мы покажем особенности настройки сети в CentOS 7 с помощью стандартного сервиса network. Посмотрим, как использовать для настройки сети NetworkManager (NM), который предлагается по-умолчанию в CentOS 8.
Именование сетевых интерфейсов в CentOS
Классическая схема именования сетевых интерфейсов в Linux присваивает имена eth0, eth1 и так далее по порядку. Но эти имена не привязываются жестко к интерфейсам и после перезагрузки при наличии нескольких сетевых интерфейсов, эти имена могут поменяться. Это может доставлять некоторые проблемы, при настройке, например, межсетевого экрана через firewalld или iptables. В связи с этим начиная с RedHat 7 и CentOS 7, решено было назначать имена сетевых интерфейсов на основе иерархии различных схем именования. По умолчанию systemd будет поочередно применять схемы именования, остановившись на первой доступной и применимой. Имена присваиваются в автоматическом режиме, остаются неизменными даже если аппаратные средства добавлены или изменены. С другой стороны, такие имена интерфейсов менее читабельны, например, enp5s0 или ens3, чем традиционные eth0 и eth1.
Можно вернуться к стандартному имени интерфейса Linux с помощью следующих действий.
Отредактируйте файл /etc/default/grub:
В строку GRUB_CMDLINE_LINUX нужно добавить:
Пример полной строки:
Обновите конфигурацию grub:
Переименуйте конфигурационный файл сетевого интерфейса:
И заменить значение DEVICE:
Сохраните файл, перезагрузите сервер и проверьте все ли в порядке:
Интерфейс теперь называется eth0.
Первоначальная настройка сети при установке CentOS
Изначально при установке CentOS Linux, вы можете настроить сетевой интерфейс в графическом режиме в пункте меню “Network & Hostname”. В данном пункте вы указываете имя сервера, добавляете нужный IP адрес и шлюз, DNS и многое другое. Более подробную настройку на данном шаге, вы можете посмотреть в статье по ссылке выше.
Ручная настройка конфигурационного файла сетевого интерфейса в CentOS
Выведем список доступных сетевых интерфейсов в системе:
Файлы конфигурации сети вашего сервера хранятся в каталоге /etc/sysconfig/network-scripts. Эти файлы создает демон NetworkManager для каждого сетевого интерфейса. В нашем случае файл конфигурации называется ifcfg-eth0 (у вас может отличаться в зависимости от схемы именования сетевого интерфейса).
Рассмотрим основные параметры:
- DEVICE – имя сетевого адаптера, совпадает с именем в системе, у нас это eht0
- BOOTPROTO – способ назначения IP-адреса (static — статическое значение, указываем в ручную. dhcp — получить адрес автоматически)
- IPADDR – IP-адрес
- NETMASK – маска подсети
- GATEWAY – шлюз по умолчанию
- DNS1 – Основной DNS-сервер
- DNS2 — альтернативный DNS-сервер
- ONBOOT — способ запуска сетевого интерфейса (yes – автоматически, no – вручную)
- UUID – уникальный идентификатор сетевого интерфейса. Можно сгенерировать самостоятельно командой uuidgen.
- IPV4_FAILURE_FATAL – отключение сетевого интерфейса с IP-адресом v4, если он имеет неверную конфигурацию (yes – отключить, no – не отключать)
- IPV6_FAILURE_FATAL – отключение сетевого интерфейса с IP-адресом v6, если он имеет неверную конфигурацию (yes – отключить, no – не отключать)
- IPV6_AUTOCONF – разрешает или запрещает автоконфигурирование Ipv6 с помощью протокола
- IPV6_INIT – включение возможности использования адресации Ipv6(yes – адресация может использоваться, no – не используется)
- PEERROUTES – устанавливает приоритет настройки шлюза по умолчанию, при использовании DHCP
- IPV6_PEERROUTES — устанавливает приоритет настройки шлюза по умолчанию, при использовании DHCP для IPv6
Исходя из этой информации, настроим сетевой интерфейс.
Настройка статического IP адреса в CentOS
Откроем файл для редактирования:
В этом примере я указал статический IP адрес, маску подсети, шлюз и несколько DNS серверов. Включаем автозапуск интерфейса:
После всех модификаций, нужно выполнить рестарт сервиса network. Если все в порядке, вы получите такой листинг:
Также можно просто перезапустить все профили подключений :
Получение динамического IP адреса для интерфейса через DHCP
Если ваш сервер должен получить IP адрес от DHCP севера, откройте конфигурационный файл интерфейса и измените настройки:
То есть мы убрали все настройки, связанные с IP-адресами и маской, а так же поменяли способ назначения IP-адреcа на dhcp (BOOTPROTO=”dhcp”). После всех изменений, не забываем выполнять перезагрузку network.
Как отключить IPv6 в CentOS?
На время написания статьи активного использования ipv6 в России нет, да и зачастую если таковая возможность имеется, администраторы предпочитают протокол ipv4. Поэтому если вы все же не используете данный протокол, его нужно отключить на сервере. Если вы точно уверены, что ни один из сервисов не настроен под работу с ipv6, можете сразу перейти к настройке сетевого интерфейса, если же нет, то начните с проверки. Нам нужно проверить, какие сервисы используют ipv6 и отключить данный протокол в конфигурации сервиса. Запустим команду:
У меня сервер тестовый, поэтому ipv6 используется только для sshd и cronyd. Это можно определить по “. ”.
Чтобы не возникало проблем после отключения ipv6 в конфигурации сети, отключите данный протокол в сервисах, в которых они используются на вашем сервере. Например для sshd, нужно открыть конфигурационный файл:
И раскомментируйте строки:
После чего перезапустите сервис:
Как видим, для sshd протокол ipv6 теперь недоступен. Проделайте аналогичные настройки со всеми сервисами.
Перейдем к отключению протокола ipv6 в настройках сети. Откройте файл /etc/sysctl.conf:
Сохраните файл и примените через:
Перейдем к файлу /etc/sysconfig/network. Добавьте в него следующую конфигурацию:
Из файла конфигурации сетевого интерфейса /etc/sysconfig/network-scripts/ifcfg-eth0 удалите строку:
И наконец добавим запрет на работу ipv6 в grub:
В конец строки GRUB_CMDLINE_LINUX, добавляем:
После всех настроек, сохраните файл и обновите grub:
Выполните перезагрузку сервера и проверьте конфигурацию сети:
Протокол ipv6 на сервере отключен.
Как указать DNS сервера для сетевого интерфейса в CentOS?
Настроить DNS-сервера для вашего сервера, вы можете с помощью файла /etc/resolv.conf или указать их в настройках сетевого интерфейса. При настройке static конфигурации для сетевого интерфейса, мы уже указывали DNS-сервера, через параметры:
Установите нужные вам DNS-сервера и перезагрузите сервис network.
В файл /etc/resolv.conf, DNS-сервера прописываются автоматически при перезагрузке сервера, забирая их с файла конфигурации сети. Если же вы не указали DNS-сервера при настройке сети, пропишите их вручную в файл /etc/resolv.conf:
Как настроить несколько IP адресов на одном сетевом интерфейсе CentOS?
Если вам нужно использовать несколько IP-адресов на одном сетевом интерфейсе, настройку можно выполнить через алиас интерфейса или же добавив дополнительный IP-адрес в основной файл конфигурации.
И измените его следующим образом:
IPADDR1 — первый IP-адрес
IPADDR2 — второй IP-адрес
GATEWAY — основной шлюз
Либо создайте alias к вашему основному файлу конфигурации:
И добавьте несколько строк, без основного шлюза:
После всех настроек нужно выполнить перезапуск сети:
Настройка VLAN (802.1Q) в CentOS
Подробнее о настройке нескольких VLAN для одного сетевого интерфейса в CentOS мы говорили в статье: Настройка VLAN на сетевом интерфейсе в CentOS.
Настройка нескольких сетевых интерфейсов в CentOS
Если у вас на сервере несколько сетевых интерфейсов, для них можно указать разные IP-адреса. Разберемся как это сделать. Если у вас на сервере более одного сетевого интерфейса, команда “ip a” должна отобразить эту информацию:
Чтобы сконфигурировать второй интерфейс, нужно создать для него файл:
И добавьте следующую конфигурацию:
После этого на сервере нужно установить шлюз по умолчанию. Проверим какой шлюз установлен в данный момент и при необходимости поменяем его:
В качестве основного шлюза у нас выступает интерфейс eth1. Я же хочу использовать eth0, для этого изменим его:
Если вы хотите, чтобы данная настройка сохранилась после перезагрузки сервера, добавьте эти команды в rc.local (см. статью об автозагрузке сервисов в CentOS).
Полезные команды по работе с сетью в CentOS
- ifdown eth1 — отключить указанный сетевой интерфейс.
- ifup eth1 – поднять указанный сетевой интерфейс.
- ifconfig – проверить информацию о всех интерфейсах.
- ifconfig -a | grep ether | gawk '' — команда для вывода MAC-адресов интерфейсов
- ip a | grep ether | gawk '' — тоже самое, только через утилиту ip a
- service network restart или systemctl restart network – перезапустить сервис network с помощью systemctl
- systemctl restart NetworkManager.service – перезапустить NM
- ip route или ip route show — посмотреть таблицу маршрутизации
- ping host – пропинговать указанный хост
- whois domain – получить информацию whois для домена
- dig domain – получить DNS информацию о домене
Утилиты администрирования сети в CentOS
Если сервер уже работает некоторое время или же настройкой занимались вообще не вы, первое действие которое нужно сделать, это узнать какие интерфейсы присутствуют на сервере. Для удобства установите необходимые инструменты из базового репозитория:
После установки, можно воспользоваться утилитой ifconfig:
Как видим, имя нашего сетевого интерфейса eth0.
Без установки пакета net-tools, вы можете проверить ваши интерфейсы с помощью следующей команды:
Результат будет практически тот же:
Управление сетью с помощью NetworkManager в CentOS 8
В CentOS 8 для настройки сети рекомендуется использовать только NetworkManager. Эта служба управление сетевыми подключениями, контролирует настройки и применяет изменения к сетевым адаптерам.
Чтобы проверить статус NM, используйте команду:
В CentOS предлагается использовать для настройки сети командную консоль nmcli или графическую утилиту nmtui.
Чтобы перейти в режим настройк сети, введите команду:
При выборе первого пункта, у вас откроется окно с выбором сетевого интерфейса для редактирования:
Выбираем нужный нам интерфейс и редактируем:
Нам доступно редактирование имени, IP-адреса, Шлюза, DNS-серверов. Так же в интерактивном меню NM, мы можем изменить способ назначения IP адреса, на DHCP:
Замените “manual” на “automatic”:
После чего сохраните настройки. С помощью nmtui в графическом режиме, вы можете выполнить любые настройки, которые выполняете вручную через конфигурационные файлы. Если вы предпочитаете использовать командную строку для настройки интерфейсов, можете использовать nmcli. Например, следующие команды изменят IP адрес, щлюз и DNS сервера для интерефейса eth1.
Для применения изменений, перезагрузите интерфейс:
Если же вам удобнее работать с файлами конфигурации, установите через yum отдельный пакет network-scripts (в CentOS 8 по умолчанию его нет):
После установки данного пакета, вы можете редактировать настройки сети, как мы описывали ранее, через конфигурационные файлы:
Читайте также: