etcnet

Эту статью следует викифицировать.

Подсказки пользователю /etc/net

Раскроем тему (отдельные страницы)
- настройка QoS
- настройка сетевого экрана (firewall)

Быстрый старт

Где брать информацию

Обращаю внимание, что начиная с версии 0.8.0 документация /etc/net переместилась из комментариев, рассеянных по множеству файлов, в несколько man-страниц. Список всех файлов документации пакета можно получить командой

rpmquery -d etcnet

Как быстро настроить одну карту Ethernet

Создайте каталог /etc/net/ifaces/eth0. Это собственный каталог конфигурации данного интерфейса, в нём будут храниться файлы с настройками.
Определите, какой модуль необходим для вашей карты. Для этого можно использовать lspci, lspcidrake, pciscan. Затем
В каталоге конфигурации создайте файл options, в который впишите строку
```
MODULE=<имя модуля>
```
. Больше ничего пока не добавляйте.
Выясните, какой IP-адрес должен быть назначен вашему интерфейсу. Если интерфейс конфигурируется по DHCP, то поместите в файл /etc/net/ifaces/eth0/options строку BOOTPROTO=dhcp и переходите к шагу 7. Замечание: в ряде случаев может также понадобиться
```
DHCP_HOSTNAME=<имя машины без домена>
```
. Эта опция описана в man-странице etcnet-options. Также необходимо, чтобы была пустая строка в конце файла.
У вашего интерфейса есть два взаимосвязанных атрибута: IP-адрес и сетевая маска. Текущие назначенные адреса можно просмотреть командой /sbin/ip address show. Скорее всего вы увидите, что интерфейс-петля lo уже сконфигурирован с адресом 127.0.0.1/8. Создайте файл /etc/net/ifaces/eth0/ipv4address, в который поместите IP-адрес с длиной маски, например
```
10.0.0.20/24
```
. Наиболее популярны маски /24 и /30. Для справки приводится##LINKTOFTN ftnd1## таблица соответствия сетевых масок в различных нотациях.
Выясните адрес вашего шлюза (маршрут по умолчанию). Например, этот IP-адрес — 10.0.0.254. Создайте файл /etc/net/ifaces/eth0/ipv4route, в который поместите строку
```
default via 10.0.0.254
```
Убедитесь, что всё выполнено правильно, выполнив команду service network restart. Ваш интерфейс должен быть успешно сконфигурирован. Если вы конфигурировали использование DHCP, но адрес интерфейсу не назначается, просмотрите /var/log/messages.

Как настроить ifplugd

С версии 0.7.10 /etc/net управляет ifplugd самостоятельно. Это было сделано для лучшей интеграции пакетов и для возможности мониторить несколько интерфейсов одновременно. Для корректного использования ifplugd необходимо выполнить chkconfig ifplugd off и назначить переменную USE_IFPLUGD в файлах options соответствующих интерфейсов. Комментарий по данной переменной дан в файле /etc/net/ifaces/default/options-eth.

Как настроить интерфейс PPP

Для настройки обычного модемного PPP-соединения вам нужно:

Создать каталог конфигурации, например, /etc/net/ifaces/ppp5. Сейчас вы не можете использовать что-либо кроме pppN или pppNN или pppNNN и т. п.
Прочесть /etc/net/ifaces/default/options-ppp
Создать файлы конфигурации. Скорее всего вам понядобятся pppconnect и pppdisconnect, чтобы pppd знал, как дозваниваться и соединяться. Это скрипты для программы chat(8). Кроме этого в файле pppoptions можно (а зачастую нужно) перечислить опции pppd(8), определяющие способ авторизации, скорость и название порта и т. п.
Заполнить /etc/ppp/chap-secrets или /etc/ppp/pap-secrets.

Как настроить интерфейс PPtP или PPPoE

Хотя PPtP-соединения могут быть настроены и как обычные PPP-соединения, в /etc/net версии 0.7.10 для удобства пользователей была введена опция PPPTYPE. Она может принимать следующие значения:

dialup: обычный PPP-интерфейс.
pppoe: интерфейс PPPoE. Для такого интерфейса необходимо в опции HOST указывать имя Ethernet-интерфейса, через который будет производиться работа PPPoE. Побочным положительным эффектом будет то, что этот интерфейс будет при необходимости автоматически подниматься (см. ##FTN requires##).
pptp: интерфейс PPtP. Для такого интерфейса необходимо в опции PPTP_SERVER указывать имя хоста или IP-адрес PPtP-сервера, к которому будет производиться подключение. Обратите внимание, что хотя такие интерфейсы не имеют опции HOST, в большинстве случаев имеет смысл указать в опции REQUIRES интерфейс, через который будет достижим хост, указанный в PPTP_SERVER.

См также ##FTN vpn##)

DNS и PPP-соединения

Внимание: здесь описывается проблема, которая на самом деле была создана, а не решена — бишь ради специфики kppp была создана чётная ошибка в ppp-common; последняя уже исправлена.

Довольно долгое время существовала проблема неправильной модификации /etc/resolv.conf при установке PPP-соединений: https://bugzilla.altlinux.org/show_bug.cgi?id=4249. Сейчас она решена, но необходимо дать пояснения. Прежде всего убедитесь, что у вас в файле /etc/resolv.conf есть строка

# ppp temp entry

Если этой строки нет, то в файле не будут модифицироваться строки nameserver, если только какая-нибудь программа типа kppp это не сделает специально. Если такая строка есть, то /etc/resolv.conf будет модифицироваться в зависимости от значения булевской переменной RESOLV_MODS, которую необходимо задавать в файле /etc/sysconfig/network.//

Внимание

: при ppp-common >= 0.4-alt1 строки # ppp temp entry в /etc/resolv.conf при отсутствии PPP-соединения, поднятого какой-либо «звонилкой», запущенной от рута — быть не должно! Если есть — уберите, чтобы /etc/ppp/ip-up занимался обновлением записей про DNS в этом файле.

restart, reload и другие команды

У сервиса network имеется ряд команд:

start: запустить все стационарные интерфейсы. hotplug-интерфейсы будут сконфигурированы при поступлении соответствующего вызова от hotplug.
startwith <имя профиля>: start с указанным именем профиля, а не определённым автоматически.
stop: остановить все стационарные интерфейсы. hotplug-интерфейсы будут расконфигурированы при поступлении соответствующего вызова от hotplug.
stopwith <имя профиля>: stop с указанным именем профиля, а не определённым автоматически.
restart: эквивалентно stop с последующим start, как и в большинстве других сервисов.
restartwith <имя профиля>: рестарт в контексте указанного профиля, эквивалентно stopwith <имя профиля> и startwith <имя профиля>.
switchto <имя профиля>: переключение в указанный профиль, эквивалентно stop и startwith <имя профиля>.
reload: семантически обозначает «актуализировать текущую конфигурацию». Для всех сконфигурированных в настоящий момент интерфейсов будет выполнена реконфигурация при наличии конфигурации.
check: автоматическая проверка конфигурационной базы.

Протоколы конфигурации адресов

С помощью опции BOOTPROTO вы можете управлять тем, как у интерфейса будут появляься адреса и маршруты (это относится только к протоколу IPv4, так как IPv6 и IPX приобретают адреса только статически).

static — адреса и маршруты будут взяты из ipv4address и ipv4route.
dhcp — интерфейс будет сконфигурирован по DHCP.
ipv4ll — интерфейс будет сконфигурирован с помощью IPv4LL (link-local), ранее известному как ZCIP (zeroconf IP). Это значит, что из сети 169.254.0.0/16 будет подобран ещё не использованный адрес и назначен на интерфейс.

Существует несколько комбинированных способов:

dhcp-static — если конфигурация по DHCP не удалась, конфигурировать методом static.
dhcp-ipv4ll — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll.
dhcp-ipv4ll-static — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll. Если и это не удалось, конфигурировать методом static.

Почему всё так устроено

Общие сведения

/etc/net — немного больше, чем кажется на первый взгляд. Несмотря на это, /etc/net остаётся системой конфигурации сети в Linux, то есть должна позволить вам сконфигурировать вашу сеть без трюков и особого напряжения. Если вы всё же читаете эту страницу, то у вас, вероятно, возникли трудности с её использованием.

Для начала я дам ряд утверждений, от которых можно оттолкнуться:

У проекта есть сайт, на котором можно найти примеры конфигурации и тексты, претендующие на звание документации: http://etcnet.org/
/etc/net интегрирован в ALTLinux Sisyphus в виде пакетов:
- etcnet (базовые сценарии)
- etcnet-full (виртуальный пакет с зависимостями на все пакеты, которые могут использоваться сценариями /etc/net, с указанием их точных версий)
- etcnetconf (прототип конфигуратора)
- etcnet-defaults-desktop (умолчания для рабочей станции)
- etcnet-defaults-server (умолчания для сервера)
Пакеты etcnet и net-scripts — две конфликтующие реализации такой сущности, как «подсистема конфигурации сети» (network-config-subsystem).
При установке etcnet вместо net-scripts или наоборот сервис network оказывается выключенным. Это означает, что при загрузке системы сеть не будет сконфигурирована, проверить это можно командой chkconfig --list network. Для быстрого исправления проблемы можно дать команду chkconfig network reset.
etcnet НЕ импортирует автоматически настройки net-scripts. Если вы только что установили etcnet и ваши сетевые интерфейсы всё ещё остаются сконфигурированными (несмотря на уже отсутствующий пакет net-scripts), то вы можете запустить сценарий /etc/net/scripts/initconf. Он попытается проанализировать текущее состояние интерфейсов и выведет вам результат. Никаких файлов при этом записано не будет. Если вам понравится вывод initconf, запустите его с параметром write и он проделает то же самое, но уже с сохранением конфигурации.
Для корректной работы системы в целом необходимо, чтобы содержимое файла /etc/sysconfig/network было корректным.
Переменные sysctl в ALT Linux конфигурируются в следующих местах: /etc/sysctl.conf (глобальные системные), /etc/sysconfig/network-scripts/sysctl.conf (общие сетевые в net-scripts), /etc/net/sysctl.conf (общие сетевые в /etc/net), /etc/net/ifaces/*/sysctl.conf* (частные для конкретных интерфейсов или их типов в /etc/net).

Как организованы опции по умолчанию

Методология /etc/net предусматривает несколько шагов наследования опций, первый из которых — загрузка опций по умолчанию. Раньше это происходило из одного файла /etc/net/options, сейчас же в нашем распоряжении есть каталог /etc/net/options.d, из которого будут последовательно прочитаны все файлы.

Смысл этого нагромождения следующий: оригинальный архив etcnet содержит только файл /etc/net/options.d/00-default.

Упаковщик etcnet в какой-либо дистрибутив вместо того, чтобы прикладывать патч, просто добавляет файл с бОльшим номером, который переопределяет нужные опции.

Администратору системы может не понравиться дистрибутивный набор, в этом случае он создаст файл с ещё более высоким номером и определит умолчания для своей системы. В результате такого подхода:

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

Зачем нужен iftab

Имена сетевых интерфейсов по умолчанию, как правило, содержат их тип (eth, ppp, wifi, ipsec) и индекс: 0 для первого созданного интерфейса, 1 для второго и т. д. При этом соответствие автоматически назначенных имён физическим устройствам может не сохраняться.

Эта особенность неудобна, когда машина с Linux имеет более одного интерфейса каждого типа. Типичными примерами являются маршрутизаторы и ноутбуки. В маршрутизаторах, как правило, используются однотипные сетевые карты и при их замене или изменении порядка на PCI-шине соответствие оказывается нарушенным. В ноутбуках используются ethernet и wifi-устройства с горячим подключением, при этом слотов и карт может быть более чем 1. В этом случае пользователь скорее всего пожелает закрепить за каждой сменной картой её конфигурацию.

/etc/net при конфигурации интерфейса использует то имя, под которым он сконфигурирован, а именно имя каталога, в котором хранятся файлы конфигурации интерфейса. За редким исключением интерфейсам можно назначать произвольные имена. Для того, чтобы автоматически назначенное имя было изменено на требуемое, необходимо поддерживать в актуальном состоянии файл /etc/net/iftab. man-страница по формату этого файла входит в пакет ifrename (man 5 iftab). Позволю себе заметить, что формат businfo зависит от версии ядра, у 2.6 он длиннее. Мне кажется, у ethtool -i businfo более корректна, чем у lspci.

См. тж. это письмо про отличия etcnet и сервиса ifrename:

И сразу позволю себе прокомментировать другие письма этого треда:
1. «etcnet уже научился менять местами eth0 и eth1?»
Освоение этого фокуса обладает сомнительной пользой. Я по-прежнему рекомендую рассматривать eth0 как временное имя с малым сроком жизни, а для повышения комфорта пользователей Ethernet-интерфейсы предлагаю называть eth00, eth01, eth02 etc.
2. «Существование (номинальное) net-scripts вынуждает поддерживать ряд сервисов, которые иначе могли бы быть упразднены»
Эти сервисы можно обезвредить контролем CONFMETHOD из /etc/sysconfig/network. При этом зависимости на пакет etcnet не возникнет, только на network-config-subsystem. Примеры таких пакетов должны быть в Sisyphus.
3. «после приведения в порядок /etc/udev/rules.d/19-udev-ifrename.rules нужности в /etc/net/iftab я не заметил»
Важнейшее принципиальное отличие /etc/net/iftab от /etc/iftab — нахождение /etc/net/iftab в специальном пространстве имён. Для него действуют механизмы определения профиля и хоста конфигурации. Это, например, позволит _желающим_ составить конфигурацию так, что срочный ремонт маршрутизатора сведётся к переносу диска (или массива) из сгоревшего шасси в запасное. Возможны и другие примеры, которые станут невозможными при помещении iftab в /etc и его лобовой интерпретации.
Конечно, пользователю единственного ноутбука с одним-двумя сетевыми интерфейсами такая практика — полный overkill, но его никто и не
заставляет видеть всю подводную часть. В этом и гибкость.

Интерфейсы lo, default и unknown

Сразу после установки в каталоге /etc/net/ifaces (в котором хранятся конфигурации интерфейсов) можно обнаружить три каталога: lo, default и unknown.

Интерфейс lo — стандартная петля, которая должна быть во всякой Linux-системе, поэтому конфигурация для него включена по умолчанию. В остальном он ничем не отличается от любого другого интерфейса и конфигурируется точно так же файлами options и ipv4address.

Интерфейс default — вовсе не интерфейс. Это специальный каталог, файлы в котором обрабатываются следующим образом:

resolv.conf — если присутствует, то копируется в /etc/resolv.conf.
options — файл опций, читается после опций по умолчанию. Этот файл содержит комментарии.
options-<вид интерфейса> — этот файл содержит опции, специфичные для данного вида интерфейсов. Какие-то из них необязательны и позволяют использовать особенности данного вида интерфейсов, например, LINKDETECT в options-eth; другие обязательны, например, HOST в options-bri. Эти файлы содержат комментарии. Обратите внимание, что эти файлы лучше не редактировать. Если вам нужно задать опцию для интерфейса, то как правило это можно сделать в файле options в конфигурационном каталоге данного интерфейса. Это облегчит процесс обновления пакета etcnet.
sysctl.conf-<вид интерфейса> — файл с переменными sysctl, которые необходимо изменить. Сейчас единственный такой файл — sysctl.conf-dvb, который отключает return path filter, что всегда нужно в случае асимметричной маршрутизации.
iplink-<вид интерфейса> — файл с командами iplink, специфичными для данного вида.
selectprofile — если этот файл исполняемый, то он будет вызван из сценариев ifup/ifdown, setup/shutdown для того, чтобы вернуть на стандартном выводе имя профиля, которое необходимо использовать. Это позволяет автоматически переключать профили в зависимости от каких-либо условий. В поставку включен комментированный пример сценария: /etc/net/ifaces/default/selectprofile.
fw — каталог с настройками сетевого экрана по умолчанию.

Интерфейс unknown — специальная конфигурация, которая будет использована в том случае, когда /etc/net просят сконфигурировать hotplug-интерфейс, для которого не существует каталога конфигурации. Это будет работать только в том случае, если включена опция ALLOW_UNKNOWN.

О загадочном broadcast

Периодически возникает вопрос: почему после старта /etc/net при запуске ifconfig можно видеть Bcast:0.0.0.0, хотя при использовании net-scripts это поле было правильным? Дело в том, что net-scripts оперируют адресом, маской, адресом сети и широковещательным адресом, пытаясь определить неизвестные компоненты из известных, а config-ipv4 просто передаёт утилите ip содержимое файла ipv4address, не заботясь о его содержимом. Хорошо ли это или плохо? Я думаю, что скорее хорошо.

Во-первых, если iproute2 изменит свой синтаксис, то с большой вероятностью править придётся только конфигурационные файлы. Во-вторых, я пока не встречал проблем с «отсутствующим» broadcast address. Он есть в таблице маршрутизации local. В-третьих, вы всегда можете назначить адрес broadcast в файле ipv4address. Проще всего это сделать с помощью выражения broadcast +##LINKTOFTN ftnd2##. Обновление: в версии 0.8.0 появилась опция AUTO_BROADCAST для автоматического дополнения каждой строки ipv4address.

О ядре 2.6 и пропадающих интерфейсах

Иногда жалуются, что если два интерфейса используют один и тот же модуль ядра и у них определена опция MODULE (то есть скрипты /etc/net сами загружают и выгружают модули), то при опускании одного интерфейса пропадает и второй. Почти наверняка используется ядро 2.6, особенностью которого являются странные значения счётчика ссылок (третий столбец вывода lsmod). Когда он оказывается равен нулю (довольно часто), скрипты могут попытаться выгрузить модуль интерфейса, для которого запущен ifdown. И у них получится, несмотря на то, что другой интерфейс, использующий этот же модуль, находится в состоянии UP.

Чтобы заблокировать выгрузку модулей, можно использовать булевскую переменную NEVER_RMMOD. Возможно, позже это будет происходить автоматически для таких странных ядер.

О hotplug-интерфейсах и не только

Часто задают вопросы об опции USE_HOTPLUG, причём задают в контексте уже установленной кем-то USE_HOTPLUG=yes. Я попробую объяснить, зачем нужна эта опция и как её правильно использовать. Есть несколько сценариев конфигурации сети.

Первый и самый простой — выполнение service network start при старте системы или вручную. При этом требуется только сформировать погруппные (потиповые) списки интерфейсов, подлежащих обработке, и последовательно выполнить требуемые действия. Модули ядра при этом загружаются сценариями /etc/net, при этом имена модулей берутся из опции MODULE (кстати, в этой опции можно перечислить несколько имён и они будут последовательно загружены, только не забудьте взять список в кавычки). Это мой любимый метод конфигурации, он лучше всего подходит для маршрутизаторов. Преимущество его в том, что вся необходимая информация сконцентрирована в одном месте — каталоге /etc/net. Если опция MODULE не определена, то будет предпринята попытка загрузки по имени интерфейса в надежде на правильно заполненный /etc/modules.conf.

Второй сценарий — реакция на событие ifplugd. Раньше существовала путаница, так как требовалась синхронная настройка сервиса ifplugd, но сейчас логика работы более определена, так как /etc/net взяла управление ifplugd на себя. В части загрузки модуля этот сценарий не отличается от первого.

Третий сценарий — реакция на появление или исчезновение сменного устройства. Для обработки таких событий предназначены сценарии /etc/net/scripts/{ifup,ifdown}-removable, которые вызываются из сценариев пакетов hotplug и pcmcia-cs. Сложность заключается в том, что для сменных PCMCIA-карт вызовы могут дублироваться: для одного и того же события первый раз ifup-removable будет вызван из hotplug, второй — из pcmcia-cs. Но это не всё. hotplug также реагирует на загрузку модулей ядра для обычных карт PCI и более того, включает сценарии, которые пытаются загружать модули самостоятельно. В этом контексте /etc/net получает слишком много вызовов от hotplug и по умолчанию их игнорирует (USE_HOTPLUG=no).

Предположим, вам необходимо настроить действительно сменную карту. После заполнения /etc/net/iftab в файле options необходимо будет задать USE_HOTPLUG=yes. После этого при получении события от hotplug /etc/net будет работать в том контексте, что модуль в загрузке и выгрузке не нуждается. Кроме того, такой интерфейс будет пропущен при обычном старте сети. Почему? Потому, что если он сменный, то единственный достоверный способ узнать, что он присутствует — получить вызов от hotplug. Из факта выполнения service network start совсем не следует, что какой-то один или несколько из сконфигурированных hotplug-интерфейсов сейчас в наличии и требует конфигурации. Если вы хотите вручную расконфигурировать hotplug-интерфейс до его извлечения, дайте команду ifdown. Для повторной конфигурации вставьте его ещё раз.

Также существует опция USE_PCMCIA. Если события для вашей карты генерирует pcmcia-cs, то вам нужно её включить. Если события генерируются только hotplug, то используйте опцию USE_HOTPLUG.

Почему вредно использование eth0

/etc/net активно использует ifrename, который в свою очередь использует файл /etc/net/iftab. Часто встречается практика помещать в него правила, назначающие интерфейсам имена eth0 и eth1. Однако существует ряд обстоятельств, лишающих эти действия смысла:

При загрузке модулей имена интерфейсов принимают вид eth0, eth1, eth2… Какие именно, в общем случае контролировать нельзя.
Имя eth0 обладает наибольшей вероятностью оказаться занятым.
ifrename не может переименовать интерфейс, если целевое имя уже занято. Единственный способ это сделать — использовать ifrename -t, чего лучше избежать.

С учётом этого становится ясно, что если /etc/net/iftab содержит тот же набор имён интерфейсов, что уже имеется после загрузки модулей, то единственный случай, когда ifrename сможет без ошибок обработать такой файл — изначальное соответствие, не требующее переименования. Поэтому ifrename выдаёт предупреждение при попытке переименовать интерфейс в eth0. Единственный способ разорвать порочный круг — в конце концов отказаться от имён ethX.

Расширенные возможности