Внутреннее устройство Linux

NM_CONTROLLED=yes

Если такой строки нет или установлено значение no, менеджер NetworkManager игнорирует данный интерфейс. Например, вы обнаружите, что он деактивизирован в файле ifcfg-lo. Можно также указать адрес аппаратного средства, которое следует игнорировать:

HWADDR=10:78:d2:eb:76:97

Если вы не используете ни одну из этих схем сетевой конфигурации, можно применить плагин keyfile, чтобы указать неуправляемое устройство прямо в файле NetworkManager.conf с помощью адреса MAC. Это могло бы выглядеть так:

[keyfile]

unmanaged-devices=mac:10:78:d2:eb:76:97;mac:1c:65:9d:cc:ff:b9

Диспетчеризация

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

Когда статус сетевого интерфейса в системе меняется, менеджер NetworkManager запускает все, что находится в каталоге /etc/NetworkManager/dispatcher.d с каким-либо из аргументов, таким как up или down. Это сравнительно просто, однако во многих версиях ОС используются собственные сценарии управления сетью, поэтому в указанном каталоге нет отдельных сценариев диспетчеризации. В Ubuntu, например, применяется всего один сценарий — 01ifupdown, который запускает все, что расположено в соответствующем подкаталоге каталога /etc/network, например в /etc/network/if-up.d.

Что касается остальной конфигурации менеджера NetworkManager, подробности сценариев не так уж важны; вам необходимо знать лишь о том, как определить соответствующее местоположение, если вам потребуется внести изменения. И, как обычно, заглядывайте в сценарии собственной системы.

9.12. Разрешение имени хоста

Одной из заключительных задач любого сетевого конфигурирования является разрешение имени хоста с помощью службы DNS. Вы уже видели инструмент host, который переводит имя, такое как www.example.com, в IP-адрес вроде 10.23.2.132.

Служба DNS отличается от рассмотренных нами элементов сети, так как она расположена на прикладном уровне, полностью в пространстве пользователя. Технически она немного не на своем месте в данной главе, рядом с обсуждением интернет-уровня и физического уровня. Но при неправильной конфигурации DNS ваше интернет-подключение практически бесполезно. Никто не станет рекламировать IP-адреса вместо имен сайтов и адресов электронной почты, поскольку IP-адрес хоста может измениться, да и набор чисел запомнить непросто. Автоматические службы сетевой конфигурации, такие как DHCP, почти всегда содержат конфигурацию DNS.

Практически все сетевые приложения в Linux выполняют поиски DNS. Процесс разрешения имен обычно протекает следующим образом.

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

2. Когда эта функция запускается, она действует в соответствии с набором правил (расположенных в файле /etc/nsswitch.conf), чтобы установить план действий при поисках. Например, такие правила обычно говорят о том, что перед переходом к DNS следует проверить ручное переопределение в файле /etc/hosts.

3. Когда функция решает использовать службу DNS для поиска имени, она обращается к дополнительному файлу конфигурации, чтобы найти сервер имен DNS. Сервер имен представлен в виде IP-адреса.

4. Функция отправляет DNS-запрос на поиск (по сети) серверу имен.

5. Сервер имен сообщает в ответ IP-адрес имени хоста, а функция возвращает этот IP-адрес приложению.

Это упрощенный вариант. В типичной современной системе присутствует больше исполнителей, которые стремятся ускорить трансакцию и/или добавить гибкость. Пока проигнорируем их и более подробно рассмотрим основные составляющие.

9.12.1. Файл /etc/hosts

В большинстве систем можно переопределить параметры поиска имен хоста с помощью файла /etc/hosts. Обычно это выглядит так:

127.0.0.1 localhost

10.23.2.3 atlantic.aem7.net atlantic

10.23.2.4 pacific.aem7.net pacific

Практически всегда вы увидите здесь запись для локального хоста (см. раздел 9.13).

примечание

В старые недобрые времена был единственный центральный хост-файл, который каждый пользователь копировал на собственный компьютер, чтобы данные были самыми свежими (см. Рабочие предложения № 606, 608, 623 и 625), однако с развитием сетей ARPANET/Internet это быстро стало ненужным.

9.12.2. Файл resolv.conf

Традиционным файлом конфигурации для серверов DNS является файл /etc/resolv.conf. Когда все было проще, типичный пример мог выглядеть так (здесь 10.32.45.23 и 10.3.2.3 — это адреса серверов имен у поставщика интернет-услуг):

search mydomain.example.com example.com

nameserver 10.32.45.23

nameserver 10.3.2.3

Строка search определяет правила для неполных хост-имен (то есть для первой части имени хоста; например, myserver вместо myserver.example.com). Здесь библиотека с функцией разрешения имен попыталась бы поискать имена host.mydomain.examp­le.com и host.example.com. Однако теперь все, как правило, не настолько просто. В конфигурации службы DNS сделано много улучшений и изменений.

9.12.3. Кэширование и службы DNS без конфигурирования

Традиционная конфигурация службы DNS имеет две основные проблемы. Во-первых, локальный компьютер не кэширует имя, которое возвращает сервер, поэтому частый повторяющийся доступ к сети может неоправданно замедлиться вследствие запросов к серверу имен. Чтобы справиться с этой проблемой, многие компьютеры (и маршрутизаторы, если они работают в качестве серверов имен) запускают промежуточный демон, чтобы перехватывать запросы к серверу имен и возвращать на них, если это возможно, кэшированный ответ. В противном случае запросы отправляются на реальный сервер имен. Два наиболее распространенных демона Linux для этой цели — dnsmasq и nscd. Можно также настроить демон BIND (стандартный демон сервера имена в Unix) в качестве кэша. Часто можно понять, запущен ли демон кэширования имен, если в файле конфигурации /etc/resolv.conf присутствует адрес 127.0.0.1 (localhost) или же в качестве имени сервера отображается 127.0.0.1, когда вы запускаете команду nslookup -debug host.

Может оказаться непросто выяснить конфигурацию, если вы используете демон кэширования имен. По умолчанию для демона dnsmasq применяется файл конфигурации /etc/dnsmasq.conf, но в вашей версии системы это может быть переопределено. Например, в Ubuntu, если вы вручную настроили интерфейс, который управляется менеджером NetworkManager, вы найдете его конфигурацию в соответствующем файле каталога /etc/NetworkManager/system-connections, поскольку менеджер NetworkManager при активизации соединения запускает также и демон dnsmasq с данной конфигурацией. Можно переопределить все это, если снять комментарии с записи в файле NetworkManager.conf, относящейся к демону dnsmasq.