9. Представление о сети и ее конфигурации
Создание сети — это установка соединения между компьютерами и пересылка данных между ними. Звучит достаточно просто, но, чтобы понять, как это работает, необходимо задать два главных вопроса.
• Каким образом компьютер, отправляющий данные, знает, куда их отправлять?
• Когда компьютер-адресат получает данные, как он догадывается о том, что он только что получил?
Компьютер отвечает на эти вопросы, используя набор компонентов, каждый из которых ответственен за определенный аспект отправки, получения и идентификации данных. Эти компоненты организованы в виде групп, которые формируют сетевые уровни, расположенные один над другим, чтобы создать законченную систему. Ядро Linux обращается с сетью подобно тому, как оно работает с подсистемой SCSI, описанной в главе 3.
Поскольку каждый уровень стремится быть независимым, есть возможность построить сети с помощью различных комбинаций компонентов. Именно здесь конфигурация сети может стать очень сложной. По этой причине мы начнем данную главу с рассмотрения уровней в очень простых сетях. Вы узнаете о том, как просматривать параметры вашей сети, а когда усвоите основы работы каждого уровня, вы будете готовы к изучению того, как самостоятельно конфигурировать эти уровни. Наконец, мы перейдем к таким сложным темам, как построение собственных сетей и настройка брандмауэров. Пропустите этот материал, если ваши глаза начинают тускнеть; вы всегда сможете вернуться к нему позже.
9.1. Основные понятия о сети
Прежде чем разбираться с теорией сетевых уровней, взгляните на простую сеть, показанную на рис. 9.1.
Такой тип сети является повсеместным, подобным образом сконфигурировано большинство сетей в квартирах и небольших офисах. Каждый компьютер, подключенный к этой сети, называется хостом. Хосты подключены к маршрутизатору, который является хостом, способным передавать данные от одной сети к другой. Эти компьютеры (то есть хосты A, B и C) и маршрутизатор составляют локальную сеть (LAN, local area network). Подключения в локальной сети могут быть проводными или беспроводными.
Рис. 9.1. Типичная локальная сеть с маршрутизатором, который обеспечивает доступ в Интернет
Маршрутизатор подключен также к Интернету, изображенному на рисунке в виде облака. Поскольку маршрутизатор подключен одновременно и к локальной сети, и к Интернету, все компьютеры локальной сети также имеют доступ к Интернету через маршрутизатор. Одной из целей данной главы является описание того, каким образом маршрутизатор обеспечивает такой доступ.
Наша исходная точка обзора будет располагаться в компьютере с Linux, таком как хост А в локальной сети на рис. 9.1.
Пакеты. Компьютер передает данные по сети в виде небольших порций, называемых пакетами. Они состоят из двух частей: заголовка и полезной нагрузки. Заголовок содержит такую идентифицирующую информацию, как хосты происхождения/назначения и основной протокол. С другой стороны, полезная нагрузка — это реальные данные, которые компьютер собирается передать (например, код HTML или изображение).
Пакеты позволяют хосту взаимодействовать с другими хостами «одновременно», поскольку хосты могут отправлять, получать и обрабатывать пакеты в любом порядке, вне зависимости от того, откуда они поступили и куда направляются. Разбиение сообщений на небольшие части также облегчает нахождение и устранение ошибок, возникших при передаче.
В большинстве случаев вам не придется заботиться о переводе пакетов в данные, которые используют ваши приложения, поскольку в операционной системе есть необходимые для этого средства. Однако полезно узнать о роли пакетов в сетевых уровнях, к чему мы и приступаем.
9.2. Сетевые уровни
Полностью функционирующая сеть содержит полный набор сетевых уровней, называемый сетевым стеком. В любой действующей сети есть стек. Типичный интернет-стек выглядит следующим образом, от верхнего уровня к нижнему.
� Прикладной уровень. Содержит «язык», с помощью которого общаются приложения и серверы. Как правило, это какой-либо протокол верхнего уровня. Самыми распространенными протоколами прикладного уровня являются: HTTP (Hypertext Transfer Protocol, протокол передачи гипертекстовых файлов; используется во Всемирной паутине), SSL (Secure Socket Layer, протокол защищенных сокетов) и FTP (File Transfer Protocol, протокол передачи файлов). Протоколы прикладного уровня часто могут сочетаться. Так, например, протокол SSL обычно используется в соединении с протоколом HTTP.
Транспортный уровень. Определяет характеристики передачи данных для прикладного уровня. Этот уровень содержит проверку целостности данных, порты источника и назначения, а также спецификации по разбиению данных приложения на пакеты (если прикладной уровень еще не выполнил это). Самыми распространенными протоколами транспортного уровня являются TCP (Transmission Control Protocol, протокол управления передачей) и UDP (User Datagram Protocol, протокол дейтаграмм пользователя). Транспортный уровень иногда также называют уровнем протоколов.
Сетевой или интернет-уровень. Определяет, как перемещать пакеты от хоста-источника к хосту-назначению. Частные правила передачи пакетов через Интернет известны как протокол IP (Internet Protocol, интернет-протокол). Поскольку в этой книге речь пойдет только о сети Интернет, мы на самом деле будем говорить лишь об интернет-уровне. Тем не менее, так как сетевые уровни задуманы как не зависящие от аппаратных средств, можно одновременно настроить несколько независимых сетевых уровней (таких как IP, IPv6, IPX и AppleTalk) на одном хосте.
Физический уровень. Определяет, как необработанные данные передаются через физический посредник, например сеть Ethernet или модем. Иногда этот уровень называют связывающим уровнем или уровнем «хост-сеть».
Важно понимать структуру сетевого стека, поскольку данные должны пройти через эти уровни минимум дважды, прежде чем достигнут программу на месте назначения. Если, например, вы отправляете данные от хоста A к хосту B, как показано на рис. 9.1, байты покидают прикладной уровень хоста A и перемещаются через транспортный и сетевой уровни хоста A. Затем они попадают вниз, в физический посредник, передаются по нему, после чего поднимаются вверх через различные уровни до прикладного уровня хоста B очень сходным образом. Если что-либо отправляется на интернет-хост через маршрутизатор, то данные пройдут через некоторые (но, как правило, не все) уровни маршрутизатора и всего, что находится между ними.
Иногда уровни странным образом вклиниваются друг в друга, поскольку было бы неэффективно продвигаться по всем уровням последовательно. Например, устройства, которые исторически имели дело только с физическим уровнем, теперь иногда заглядывают в данные транспортного и интернет-уровней, чтобы быстро отфильтровать и проложить маршрут для данных. Не беспокойтесь об этом, пока вы изучаете основы.
Мы начнем с рассмотрения того, как компьютер с Linux подключается к сети, чтобы ответить на вопрос «куда?», поставленный в начале этой главы. Это самая нижняя часть стека — физический и сетевой уровни. Далее мы рассмотрим два верхних уровня, чтобы ответить на вопрос «что?».
примечание
Вы, наверное, слышали о другом наборе уровней, известном как модель OSI (Open Systems Interconnection Reference Model). Это модель сети, которая содержит семь уровней и часто используется при обучении и в разработке сетей, однако мы не будем рассматривать ее, поскольку вы будете напрямую работать с четырьмя уровнями, описанными здесь. Чтобы узнать об уровнях больше (и о сетях вообще), обратитесь к книге Эндрю С. Таненбаума (Andrew S. Tanenbaum) и Дэвида Дж. Уэзерола (David J. Wetherall) Computer Networks («Компьютерные сети»), 5-е издание (Prentice Hall, 2010).
9.3. Интернет-уровень
Вместо того чтобы начать с самого низа сетевого стека, физического уровня, мы начнем с сетевого уровня, поскольку его проще понять. Интернет, как мы уже знаем, основан на интернет-протоколе, начиная с версии 4 (IPv4) и заканчивая набирающей силу версией 6 (IPv6). Одним из самых важных аспектов интернет-уровня является то, что он призван быть сетью программного обеспечения, которое не предъявляет специальных требований к аппаратным средствам или операционным системам. Суть в том, что вы можете отправлять и получать интернет-пакеты с помощью любого аппаратного обеспечения, используя любую операционную систему.
Топология Интернета децентрализована; эта сеть составлена из более мелких сетей, называемых подсетями. Идея заключается в том, что все подсети каким-либо образом соединены между собой. Например, на рис. 9.1 локальная сеть обычно является единственной подсетью.
Хост может быть подключен к более чем одной подсети. Как вы видели в разделе 9.1, такой тип хоста называется маршрутизатором, если он может передавать данные из одной подсети в другую (еще один термин для маршрутизатора — шлюз). Рисунок 9.2 уточняет рис. 9.1 за счет идентификации локальной сети в качестве подсети, а также за счет добавления интернет-адресов для каждого хоста и для маршрутизатора. Маршрутизатор на этом рисунке обладает двумя адресами: 10.23.2.1 в локальной подсети, а также интернет-ссылкой (сейчас нам неважен адрес интернет-ссылки, поэтому она отмечена как «Адрес ссылки верхнего уровня»). Сначала мы рассмотрим адреса, а затем обозначение подсети.
Каждый интернет-хост обладает по крайней мере одним численным IP-адресом в виде a.b.c.d, например 10.23.2.37. Адрес в подобной записи называется четверкой чисел, разделенных точками. Если хост подключен к нескольким подсетям, у него есть хотя бы один IP-адрес для каждой подсети. Каждый IP-адрес хоста должен быть уникальным для сети Интернет в целом, однако, как вы увидите позже, частные сети и преобразование сетевых адресов (NAT) могут вызвать небольшую путаницу.
примечание
С технической точки зрения IP-адрес состоит из 4 байт (или 32 бит), abcd. Байты a и d являются числами от 1 до 254, а байты b и c — числами от 0 до 255. Компьютер обрабатывает IP-адреса в виде «сырых» байтов. Тем не менее человеку намного проще читать и записывать адрес в виде четверки чисел, разделенных точками, вроде 10.23.2.37, а не в виде неприглядного шестнадцатеричного числа 0x0A170225.
Рис. 9.2. Сеть с IP-адресами
IP-адреса напоминают почтовые адреса. Чтобы взаимодействовать с другим хостом, ваш компьютер должен знать IP-адрес этого хоста. Посмотрим на адреса в вашем компьютере.
9.3.1. Просмотр IP-адресов компьютера
У одного хоста может быть несколько IP-адресов. Чтобы увидеть адреса, которые активны на вашем компьютере с Linux, запустите такую команду:
$ ifconfig
Результат вывода окажется, вероятно, довольно обширным, но он должен содержать нечто подобное:
eth0 Link encap: Ethernet HWaddr 10:78:d2:eb:76:97
inet addr:10.23.2.4 Bcast:10.23.2.255 Mask:255.255.255.0
inet6 addr: fe80::1278:d2ff: feeb:7697/64 Scope: Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:85076006 errors:0 dropped:0 overruns:0 frame:0
TX packets:68347795 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:86427623613 (86.4 GB) TX bytes:23437688605 (23.4 GB)
Interrupt:20 Memory: fe500000-fe520000
Вывод команды ifconfig включает множество деталей об интернет-уровне и о физическом уровне (иногда он даже совсем не содержит интернет-адреса!). Более подробно мы обсудим этот вывод позже, а сейчас сосредоточимся на второй строке, которая сообщает, что хост настроен на использование адреса IPv4 (inet addr) 10.23.2.4. В той же самой строке для параметра Mask указано значение 255.255.255.0. Это маска подсети, определяющая подсеть, к которой принадлежит IP-адрес. Посмотрим, как это устроено.
примечание
Команда ifconfig, подобно некоторым другим, которые вы встретите в этой главе (такие как route и arp), на техническом уровне вытеснена более новой командой ip. Команда ip способна выполнить больше, чем старые команды, и она предпочтительнее при написании сценариев. Однако большинство пользователей по-прежнему использует старые команды при настройки сети вручную, и такие команды также могут быть применены в других версиях Unix. По этой причине мы будем применять команды «в старом стиле».
9.3.2. Подсети
Подсеть — это соединенная группа хостов, IP-адреса которых каким-либо образом упорядочены. Обычно такие хосты расположены в одной физической сети, как показано на рис. 9.2. Например, хосты между 10.23.2.1 и 10.23.2.254 могли бы составлять подсеть, равно как и хосты между 10.23.1.1 и 10.23.255.254.
Подсеть определяется с помощью двух фрагментов: сетевого префикса и маски подсети (вроде той, которую вы видели в отчете команды ifconfig в предыдущем разделе). Предположим, необходимо создать подсеть, содержащую IP-адреса от 10.23.2.1 до 10.23.2.254. Сетевой префикс — та часть, которая является общей для всех адресов данной подсети; в приведенном примере это 10.23.2.0, а маской подсети будет 255.255.255.0. Посмотрим, почему эти числа правильны.
Не сразу понятно, каким образом префикс и маска работают совместно, чтобы дать вам все возможные IP-адреса в подсети. Выяснить это поможет просмотр данных чисел в двоичном представлении. Маска отмечает положения битов в IP-адресе, которые являются общими для подсети. Вот, например, двоичная запись адресов 10.23.2.0 и 255.255.255.0:
10.23.2.0: 00001010 00010111 00000010 00000000
255.255.255.0: 11111111 11111111 11111111 00000000
Теперь выделим жирным шрифтом те положения битов в адресе 10.23.2.0, которые являются единицами в адресе 255.255.255.0:
10.23.2.0: 000010100001011100000010 00000000
Посмотрите на биты, которые не выделены жирным шрифтом. Для любого из них можно установить значение 1, чтобы получить правильный IP-адрес для данной подсети, за исключением случая, когда все биты являются нулями или единицами.
Собирая все воедино, можно понять, как хост с IP-адресом 10.23.2.1 и маской подсети 255.255.255.0 оказывается в той же подсети, что и любой другой компьютер, IP-адрес которого начинается с 10.23.2. Можно обозначить в целом эту подсеть как 10.23.2.0/255.255.255.0.
9.3.3. Распространенные маски подсети и нотация CIDR
Если вам повезет, вы будете иметь дело в основном с простыми масками подсети вроде 255.255.255.0 или 255.255.0.0. В случае невезения вам может попасться адрес 255.255.255.192, для которого не так-то просто установить набор адресов, принадлежащих подсети. Более того, возможно, что вы встретите другую форму представления подсети, которая называется нотацией CIDR (Classless Inter-Domain Routing, бесклассовая междоменная маршрутизация). В ней подсеть 10.23.2.0/255.255.255.0 будет записана в виде 10.23.2.0/24.
Чтобы понять, что это значит, посмотрите на маску в двоичной форме (как в примере, который вы видели в предыдущем разделе). Вы обнаружите, что практически все маски подсетей являются всего лишь набором единиц, за которыми следует набор нулей. Например, вы только что видели, что адрес 255.255.255.0 в двоичной записи представлен в виде 24 единичных бит, за которыми следуют 8 нулевых бит. Нотация CIDR идентифицирует маску подсети по количеству ведущих единиц в записи маски подсети. Следовательно, такая комбинация, как 10.23.2.0/24, содержит как префикс подсети, так и маску подсети.
В табл. 9.1 приведено несколько примеров масок подсети и их записи в форме CIDR.
Таблица 9.1. Маски подсети
Длинная форма
Форма CIDR
255.0.0.0
8
255.255.0.0
16
255.240.0.0
12
255.255.255.0
24
255.255.255.192
26
примечание
Если вы не очень хорошо знакомы с преобразованием чисел в десятичный, двоичный и шестнадцатеричный форматы, можно воспользоваться утилитой-калькулятором, например bc или dc, чтобы переводить числа с различными основаниями системы счисления. Например, в утилите bc можно запустить команду obase=2; 240, чтобы вывести число 240 в двоичной форме (основание равно 2).
Идентификация подсетей и их хостов является первым строительным блоком в понимании того, как работает Интернет. Но тем не менее подсети еще предстоит соединить.
9.4. Маршруты и таблица маршрутизации ядра
Соединение подсетей Интернет заключается в основом в идентификации хостов, подключенных к более чем одной подсети. Вернитесь к рис. 9.2 и поразмышляйте о хосте А с IP-адресом 10.23.2.4. Этот хост подключен к локальной сети 10.23.2.0/24 и может напрямую взаимодействовать с хостами этой сети. Чтобы добраться до остальной части Интернета, он должен «общаться» через маршрутизатор с адресом 10.23.2.1.
Как ядро Linux различает эти два типа назначений? Чтобы выбрать для себя образ действий, оно использует конфигурацию назначений, которая называется таблицей маршрутизации. Чтобы отобразить таблицу маршрутизации, применяйте команду route — n. Вот что вы могли бы увидеть для простого хоста, такого как хост с адресом 10.23.2.4:
$ route — n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.23.2.1 0.0.0.0 UG 0 0 0 eth0
10.23.2.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
Две последние строки здесь содержат информацию о маршрутизации. Столбец Destination сообщает префикс сети, а столбец Genmask — маску, которая соответствует данной сети. В этом выводе определены две сети: 0.0.0.0/0 (которая соответствует каждому адресу в Интернете) и 10.23.2.0/24. У каждой из этих сетей в столбце Flags стоит символ U, который говорит о том, что данный маршрут активен («up»).
Различие между назначениями заложено в комбинации значений столбцов Gateway и Flags. Для адреса 0.0.0.0/0 в столбце Flags указан флаг G, который означает, что для данной сети связь должна проходить через шлюз, указанный в столбце Gateway (в данном случае 10.23.2.1). Однако для сети 10.23.2.0/24 в столбце Flags нет символа G, это говорит о том, что данная сеть подключена напрямую каким-либо способом. Здесь 0.0.0.0 используется в качестве заместителя значения в столбце Gateway. Не обращайте пока внимания на остальные столбцы вывода.
Есть некоторая хитрость: допустим, хост собирается отправить что-либо по адресу 10.23.2.132, который соответствует обоим правилам таблицы маршрутизации, 0.0.0.0/0 и 10.23.2.0/24. Как ядро узнает о том, что необходимо применить второй адрес? Оно выбирает самый длинный совпадающий префикс назначения. Именно здесь нотация CIDR становится чрезвычайно удобной: адрес 10.23.2.0/24 годится, и длина его префикса равна 24 битам; адрес 0.0.0.0/0 тоже подходит, но его префикс — нулевой длины (то есть у него нет префикса), поэтому берет верх правило для адреса 10.23.2.0/24.
примечание
Параметр — n просит команду route отобразить IP-адреса вместо имен хостов и сетей. Следует помнить об этом важном параметре, поскольку вы сможете использовать его в других командах, относящихся к работе с сетью, таких как netstat.
Шлюз по умолчанию. Запись для адреса 0.0.0.0/0 в таблице маршрутизации имеет особое значение, поскольку она соответствует любому адресу в Интернете. Это маршрут по умолчанию, и адрес, который указан в столбце Gateway (в результате вызова команды route — n) для маршрута по умолчанию, является шлюзом по умолчанию. Когда остальные правила не подходят, маршрут по умолчанию всегда годится, а в шлюз по умолчанию отправляются сообщения, если нет другого выбора. Можно настроить хост без шлюза по умолчанию, но он будет неспособен подключиться к тем хостам, назначения которых отсутствуют в таблице маршрутизации.
примечание
В большинстве сетей с маской 255.255.255.0 маршрутизатор обычно расположен по адресу подсети 1 (например, 10.23.2.1 в сети 10.23.2.0/24). Поскольку это просто договоренность, возможны исключения.
9.5. Основные инструменты, использующие протокол ICMP и службу DNS
Теперь пришло время рассмотреть некоторые основные утилиты, помогающие взаимодействовать с хостами. Эти инструменты используют два протокола, представляющих особый интерес: ICMP (Internet Control Message Protocol, протокол управляющих сообщений в Интернете), который может помочь в искоренении проблем с подключением и маршрутизацией, и систему DNS (Domain Name Service, служба доменных имен), которая сопоставляет имена с IP-адресами, чтобы вам не приходилось запоминать уйму чисел.
9.5.1. Команда ping
Команда ping (см. http://ftp.arl.mil/~mike/ping.html) является одним из главнейших инструментов для сетевой отладки. Она отправляет пакеты эхо-запроса по протоколу ICMP какому-либо хосту-адресату и просит вернуть его отправителю. Если принимающий хост получает пакет и настроен на ответ, он отправляет эхо-ответ по протоколу ICMP.
Допустим, например, что вы запустили команду ping 10.23.2.1 и получили такой результат:
$ ping 10.23.2.1
PING 10.23.2.1 (10.23.2.1) 56(84) bytes of data.
64 bytes from 10.23.2.1: icmp_req=1 ttl=64 time=1.76 ms
64 bytes from 10.23.2.1: icmp_req=2 ttl=64 time=2.35 ms
64 bytes from 10.23.2.1: icmp_req=4 ttl=64 time=1.69 ms
64 bytes from 10.23.2.1: icmp_req=5 ttl=64 time=1.61 ms
Первая строка говорит о том, что вы отправляете пакеты из 56 байт (если учитывать заголовки, то из 84 байтов) по адресу 10.23.2.1 (по умолчанию один пакет в секунду); остальные строки приводят отклик от хоста с адресом 10.23.2.1. Самыми важными частями вывода являются порядковый номер (icmp_req) и время прохождения в прямом и обратном направлениях (time). Количество возвращенных байтов равно размеру отправленного пакета плюс 8. Содержимое пакетов не имеет значения.
Разрывы в порядковых номерах (такие как между 2 и 4) обычно свидетельствуют о каких-либо неполадках с подключением. Возможно также, что пакеты будут приходить в неправильном порядке. Если это так, то это тоже говорит о проблеме, так как команда ping отправляет только один пакет в секунду. Если на доставку ответа требуется больше секунды (1000 мс), то подключение является крайне медленным.
Время прохождения — это интервал времени с момента отправки пакета-запроса до момента прибытия пакета-ответа. Если достичь назначения не представляется возможным, конечный маршрутизатор, который видит данный пакет, возвращает команде ping ICMP-пакет host unreachable («хост недоступен»).
В проводной локальной сети следует ожидать полное отсутствие потери пакетов и очень малое значение времени прохождения. Приведенный выше пример взят из беспроводной сети. Следует также ожидать отсутствие потери пакетов и устойчивую величину времени прохождения при передаче между вашей сетью и поставщиком интернет-услуг.
примечание
Из соображений безопасности не все хосты в Интернете отвечают на пакеты эхо-запросов, поэтому вы можете подключиться к какому-либо сайту на хосте, но не получить ответа на команду ping.
9.5.2. Команда traceroute
Основанная на протоколе ICMP команда traceroute окажется полезной, когда вы дойдете в этой главе до материала, посвященного уровню маршрутизации. Воспользуйтесь командой traceroute host, чтобы увидеть путь, который проходят пакеты до удаленного хоста. Команда traceroute — n host отключает поиск имени хоста.
Одной из самых приятных черт команды traceroute является то, что она возвращает значения времени прохождения для каждого участка маршрута, как показано в приведенном ниже фрагменте вывода:
4 206.220.243.106 1.163 ms 0.997 ms 1.182 ms
5 4.24.203.65 1.312 ms 1.12 ms 1.463 ms
6 64.159.1.225 1.421 ms 1.37 ms 1.347 ms
7 64.159.1.38 55.642 ms 55.625 ms 55.663 ms
8 209.247.10.230 55.89 ms 55.617 ms 55.964 ms
9 209.244.14.226 55.851 ms 55.726 ms 55.832 ms
10 209.246.29.174 56.419 ms 56.44 ms 56.423 ms
Поскольку в этом выводе видна большая задержка между шагами 6 и 7, вероятно, эта часть маршрута является каким-либо протяженным звеном.
Результаты команды traceroute могут быть непоследовательными. Например, на некотором шаге ответы могут прерваться, чтобы затем «заново возникнуть» на следующих шагах. Обычно причиной является отказ маршрутизатора на этом шаге вернуть отладочный вывод, который ожидает команда traceroute, но при этом маршрутизаторы следующих этапов благополучно возвращают результат. Более того, маршрутизатор мог бы назначить более низкий приоритет отладочному трафику по сравнению с нормальным.
9.5.3. Служба DNS и хост
IP-адреса трудно запомнить, к тому же они могут измениться. Именно поэтому мы обычно пользуемся вместо них именами вроде www.example.com. Библиотека службы DNS в вашей системе, как правило, автоматически выполняет это преобразование, но иногда вам может потребоваться вручную перевести имя в IP-адрес. Чтобы определить IP-адрес, стоящий за доменным именем, используйте такую команду host:
$ host www.example.com
www.example.com has address 93.184.216.119
www.example.com has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7
Обратите внимание на то, что в этом примере есть как адрес версии IPv4 (93.184.216.119), так и более длинный адрес версии IPv6. Это означает, что данный хост обладает также адресом сети Интернет следующего поколения.
Можно также использовать команду host наоборот: введите IP-адрес вместо имени хоста, чтобы попытаться определить имя хоста, соответствующее данному IP-адресу. Не ожидайте, что это будет работать надежно. Многие имена хостов могут представлять один и тот же IP-адрес, и служба DNS не знает, как определить, которое из имен соответствует указанному адресу. Администратор домена должен вручную настраивать это обратное определение, но зачастую администраторы этого не делают. Помимо команды host, есть много других моментов, относящихся к службе DNS. Мы рассмотрим основную конфигурацию клиента позже, в разделе 9.12.
9.6. Физический уровень и сеть Ethernet
Об Интернете следует усвоить одну ключевую идею — он является сетью программного обеспечения. Ничто из рассмотренного нами до настоящего момента не привязано к какому-либо аппаратному средству, и даже более того: одной из причин успеха Интернета является его способность работать практически в любом типе компьютера, операционной системы и физической сети. Тем не менее по-прежнему необходимо помещать сетевой уровень поверх какого-либо аппаратного обеспечения, и такой интерфейс называется физическим уровнем.
В данной книге мы рассмотрим наиболее распространенный тип физического уровня — сеть Ethernet. Семейство стандартов IEEE 802 определяет различные типы сетей Ethernet, от проводных до беспроводных, но их все объединяют некоторые ключевые особенности.
• Все устройства сети Ethernet обладают адресом MAC (Media Access Control, управление доступом к среде передачи данных), который иногда называют аппаратным адресом. Этот адрес не зависит от IP-адреса хоста и является уникальным для сети Ethernet этого хоста (но не обязательно для более крупной программной сети, такой как Интернет). MAC-адрес может быть, например, таким: 10:78:d2:eb:76:97.
• Устройства в сети Ethernet отправляют сообщения в виде кадров, которые являются оболочкой вокруг набора данных. Кадр содержит MAC-адреса отправителя и назначения.
На самом деле сеть Ethernet не пытается выйти за рамки аппаратного обеспечения для одной сети. Если, например, у вас есть две различные сети Ethernet с одним хостом, подключенным к обеим сетям (и два различных устройства сетевого интерфейса), вы не сможете напрямую передать кадр из одной сети Ethernet в другую, если вы не настроите специальный Ethernet-мост. Именно здесь возникают более высокие сетевые уровни (такие как интернет-уровень). По договоренности каждая сеть Ethernet является обычно и подсетью Интернета. Даже если кадр не может покинуть физическую сеть, маршрутизатор способен извлечь данные из кадра, заново упаковать их и отправить хосту другой физической сети — именно это и происходит в сети Интернет.
9.7. Понятие о сетевых интерфейсах ядра
Физический и интернет-уровни должны быть соединены таким способом, который позволяет интернет-уровню сохранять свою не зависящую от аппаратных средств гибкость. Ядро Linux обеспечивает собственное разделение этих двух уровней и предоставляет стандарты коммуникации для их соединения под названием «сетевой интерфейс (ядра)». Когда вы настраиваете сетевой интерфейс, вы соединяете настройки IP-адреса со стороны Интернета с идентификацией аппаратного средства со стороны физического устройства. Сетевые интерфейсы имеют имена, которые обычно отражают тип расположенного под ними аппаратного средства, например eth0 (первая карта Ethernet в компьютере) и wlan0 (беспроводной интерфейс).
В подразделе 9.3.1 вы узнали о наиболее важной команде для просмотра или ручной настройки параметров сетевого интерфейса: ifconfig. Вспомните такой результат ее работы:
eth0 Link encap: Ethernet HWaddr 10:78:d2:eb:76:97
inet addr:10.23.2.4 Bcast:10.23.2.255 Mask:255.255.255.0
inet6 addr: fe80::1278:d2ff: feeb:7697/64 Scope: Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:85076006 errors:0 dropped:0 overruns:0 frame:0
TX packets:68347795 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:86427623613 (86.4 GB) TX bytes:23437688605 (23.4 GB)
Interrupt:20 Memory: fe500000-fe520000
Для каждого сетевого интерфейса в левой части вывода отображается имя интерфейса, а правая часть содержит параметры и статистические данные об этом интерфейсе. В дополнение к уже рассмотренным нами частям интернет-уровня можно увидеть MAC-адрес на физическом уровне (HWaddr). Строки, которые содержат слова UP и RUNNING, сообщают о том, что такой интерфейс работает.
Хотя команда ifconfig и показывает некоторую информацию об аппаратном средстве (в данном случае даже параметры низкоуровневого устройства, такие как прерывание и использованная память), она предназначена в основном для просмотра и конфигурирования программных уровней, присоединенных к интерфейсам. Чтобы проникнуть вглубь аппаратного и физического уровней, стоящих за сетевым интерфейсом, используйте что-либо вроде команды ethtool для отображения или изменения параметров карт Ethernet. Мы кратко рассмотрим беспроводные сети в разделе 9.23.
9.8. Введение в конфигурирование сетевого интерфейса
Теперь вы узнали обо всех основных элементах, которые входят в нижние уровни сетевого стека: физический уровень, сетевой (интернет-) уровень и сетевые интерфейсы ядра Linux. Чтобы объединить эти части в целях подключения компьютера с Linux к Интернету, вам или какому-либо ПО необходимо выполнить следующее.
1. Подключить сетевое оборудование и убедиться в том, что у ядра есть драйверы для него. Если драйвер есть, то команда ifconfig — a отобразит сетевой интерфейс ядра, соответствующий этому аппаратному средству.
2. Выполнить дополнительную настройку физического уровня, например выбор имени сети или пароля.
3. Связать IP-адрес и маску сети с сетевым интерфейсом ядра, чтобы драйверы устройства (физический уровень) и подсистемы Интернета (интернет-уровень) могли общаться друг с другом.
4. Добавить дополнительные необходимые маршруты, включая шлюз по умолчанию.
Когда все компьютеры были большими стационарными ящиками, соединенными с помощью проводов, все было сравнительно просто: ядро выполняло первый шаг, второй шаг не требовался и вам следовало выполнить третий шаг с помощью команды ifconfig и четвертый шаг с помощью команды route.
Чтобы вручную указать IP-адрес и маску сети для сетевого интерфейса ядра, нужно было выполнить следующее:
# ifconfig interface address netmask mask
Здесь параметр interface является именем интерфейса, таким как eth0. Когда интерфейс заработает, вам следует быть готовыми к добавлению маршрутов, что, как правило, сводится к указанию шлюза по умолчанию, например, так:
# route add default gw gw-address
Параметр gw-address является IP-адресом вашего шлюза по умолчанию; он должен быть адресом в локально подключенной подсети, определенной адресом и маской одного из сетевых интерфейсов.
Добавление и удаление маршрутов вручную. Чтобы удалить шлюз по умолчанию, запустите команду:
# route del — net default
Можно легко переопределить шлюз по умолчанию с помощью других маршрутов. Допустим, ваш компьютер находится в подсети 10.23.2.0/24, вы желаете попасть в подсеть 192.168.45.0/24 и знаете о том, что адрес 10.23.2.44 может выступать в роли маршрутизатора для этой подсети. Запустите такую команду, чтобы отправить трафик, связанный с адресом 192.168.45.0 на этот маршрутизатор:
# route add — net 192.168.45.0/24 gw 10.23.2.44
Нет необходимости указывать маршрутизатор, чтобы удалить маршрут:
# route del — net 192.168.45.0/24
Вам следует знать о том, что работа с маршрутами зачастую намного сложнее, чем кажется. Для приведенного примера следует также убедиться в том, что маршруты для всех хостов сети 192.163.45.0/24 могут привести обратно в сеть 10.23.2.0/24, а иначе первый добавленный вами маршрут окажется бесполезным.
Обычно для своих клиентов вам следует настраивать сети по возможности проще, чтобы хостам требовался лишь один маршрут. Если вам необходимо несколько подсетей и возможность маршрутизации между ними, обычно для этого лучше настроить маршрутизаторы в качестве шлюзов по умолчанию, которые выполняют всю работу по маршрутизации между различными локальными подсетями. Пример вы увидите в разделе 9.17.
9.9. Конфигурация сети, активизируемая при загрузке системы
Мы рассмотрели способы ручной настройки сети. Традиционно для обеспечения правильной сетевой конфигурации компьютера требовалось, чтобы во время загрузки системы запускался сценарий ручной конфигурации. Это сводится к запуску таких инструментов, как ifconfig и route, где-либо среди последовательности событий загрузки. Многие серверы до сих пор поступают подобным образом.
Предпринимались многие попытки стандартизировать файлы конфигурации для настройки сети во время загрузки системы Linux. Инструменты ifup и ifdown выполняют это: например, сценарий загрузки может (теоретически) запустить команду ifup eth0, чтобы запустить корректные команды ifconfig и route для интерфейса eth0. К сожалению, в разных версиях системы различная реализация команд ifup и ifdown, в результате чего их файлы конфигурации также совершенно различны. Версия Ubuntu, например, использует вариант ifupdown, файлы конфигурации которого расположены в каталоге /etc/network, а версия Fedora пользуется собственным набором сценариев и конфигурацией в каталоге /etc/sysconfig/network-scripts.
Вам не обязательно знать подробности об этих файлах конфигурации, но, если вы настаиваете на ручной настройке в обход инструментов конфигурации вашей системы, можно посмотреть формат этих файлов на страницах руководства ifup(8) и interfaces(5). Важно знать о том, что этот тип конфигурации, активизируемой во время загрузки, часто не используется совсем. Чаще всего вы будете встречать его в сетевом интерфейсе локальных хостов (или lo, см. раздел 9.13) и более нигде, поскольку он недостаточно гибок, чтобы отвечать потребностям современных систем.
9.10. Проблемы, связанные с конфигурацией сети вручную и при активизации во время загрузки системы
Несмотря на то что в большинстве систем настройка сети была заложена в их механизм загрузки (а многие серверы до сих пор так устроены), динамичная природа современных сетей означает, что у большинства компьютеров нет статического (неизменного) IP-адреса. Вместо того чтобы хранить IP-адрес и другую сетевую информацию на компьютере, ваш компьютер получает эту информацию откуда-либо из локальной физической сети, когда он в первый раз подключается к ней. Большинство обычных клиентских сетевых приложений не сильно заботит, какой IP-адрес использует компьютер, пока он работает. Инструменты с протоколом DHCP (Dynamic Host Configuration Protocol, протокол динамической конфигурации хоста; рассмотрен в разделе 9.16) выполняют основную конфигурацию сетевого уровня для типичных клиентов.
Но на этом история не заканчивается. Можно добавить, например, беспроводные сети и дополнительные измерения конфигурации интерфейса, такие как сетевые имена, аутентификация и методы шифрования. Когда вы отступите назад, чтобы увидеть картину в целом, вы поймете, что вашей системе необходимо отвечать на следующие вопросы.
• Если компьютер имеет несколько физических сетевых интерфейсов (например, ноутбук с проводным и беспроводным Ethernet-подключением), как выбрать тот, который следует использовать?
• Каким образом компьютер должен настроить физический интерфейс? Для беспроводных сетей для этого потребуется сканирование сетевых имен, выбор имени и проведение аутентификации.
• Когда интерфейс физической сети подключен, каким образом компьютер должен настроить программные сетевые уровни, такие как интернет-уровень?
• Как разрешить пользователю выбирать варианты подключения? Например, как позволить выбор беспроводной сети?
• Что должен предпринять компьютер в случае потери подключения к сетевому интерфейсу?
Ответ на эти вопросы, как правило, выше возможностей простых сценариев загрузки, а в ручной конфигурации практически неосуществим. Следует использовать системную службу, которая может отслеживать физические сети и выбирать (и автоматически конфигурировать) сетевые интерфейсы ядра на основе набора правил, которые понятны пользователю. Эта служба должна быть также способна отвечать на запросы пользователей, у которых должна быть возможность смены беспроводной сети без необходимости использования корневых привилегий только для того, чтобы «подкручивать» настройки сети всякий раз, когда что-либо изменится.
9.11. Менеджеры сетевой конфигурации
Есть несколько способов автоматического конфигурирования сетей в системах на основе Linux. Наиболее широко в ПК и на ноутбуках используется менеджер сети NetworkManager. Другие системы управления сетевой конфигурацией предназначены главным образом для небольших внедренных систем, например netifd для OpenWRT, служба ConnectivityManager для платформы Android, менеджеры ConnMan и Wicd.
Мы кратко рассмотрим менеджер NetworkManager, поскольку вам, вероятно, встретится именно он. Однако не станем углубляться в устрашающее количество деталей, поскольку после того, как вы увидите всю картину, менеджер NetworkManager и другие системы конфигурирования окажутся более прозрачными.
9.11.1. Работа менеджера NetworkManager
Менеджер NetworkManager — это демон, который запускается во время загрузки системы. Подобно другим демонам, он не зависит от запущенного компонента рабочего стола. Его задача состоит в прослушивании системных и пользовательских событий с последующим изменением конфигурации сети на основе набора правил.
Во время работы менеджер NetworkManager обслуживает два основных уровня конфигурации. Первый — это информация о доступных аппаратных средствах, обычно она извлекается из ядра и появляется при отслеживании демона udev через шину Desktop Bus (D-Bus). Второй уровень конфигурации представляет специальный перечень подключений: аппаратные средства и дополнительные параметры конфигурации физического и сетевого уровней. Например, беспроводная сеть может быть представлена как подключение.
Чтобы активизировать подключение, менеджер NetworkManager часто поручает задачи другим специализированным сетевым инструментам и демонам, например dhclient, которые узнают конфигурацию интернет-уровня из локально подключенной физической сети. Поскольку инструменты и схемы конфигурирования сети отличаются в разных версиях системы, менеджер NetworkManager использует плагины, чтобы осуществить стыковку с ними, а не навязывать собственный стандарт. Существуют, например, плагины как для конфигурации интерфейса Debian/Ubuntu, так и в стиле Red Hat.
Во время запуска менеджер NetworkManager собирает всю доступную информацию о сетевом устройстве, отыскивает его перечень подключений, а затем предпринимает попытку активизации какого-либо из них. Вот как это выглядит для интерфейсов Ethernet.
1. Если проводное подключение доступно, попытаться подключиться с его использованием. В противном случае применять беспроводные подключения.
2. Просмотреть список доступных беспроводных сетей. Если доступна сеть, к которой вы уже подключались ранее, менеджер NetworkManager попробует подключиться к ней снова.
3. Если будет доступно несколько беспроводных сетей, с которыми ранее было установлено соединение, выбрать ту, к которой подключались совсем недавно.
После установления подключения менеджер NetworkManager обслуживает его: пока оно не будет утрачено, пока не появится сеть с лучшими параметрами (например, вы подключили сетевой кабель, когда работает беспроводное соединение) или пока пользователь не выполнит изменения.
9.11.2. Взаимодействие с менеджером NetworkManager с помощью интерфейса
Большинство пользователей взаимодействует с менеджером NetworkManager с помощью апплета на рабочем столе: как правило, это значок в верхнем или нижнем правом углу, который сообщает статус соединения (проводное, беспроводное или отсутствие подключения). Если щелкнуть кнопкой мыши на этом значке, появится возможность изменить подключение, например выбрать беспроводную сеть или отключиться от текущей сети. В каждой среде рабочего стола своя версия этого апплета, поэтому он выглядит немного по-разному.
В дополнение к этому апплету есть несколько инструментов, которые можно использовать для выполнения запросов к менеджеру и управления им из оболочки. Чтобы получить очень быстрый отчет о текущем статусе соединения, применяйте команду nm-tool без аргументов. Вы получите перечень интерфейсов и параметров конфигурации. Это в некоторой степени напоминает отчет команды ifconfig, за исключением того, что здесь больше подробностей, в особенности при просмотре беспроводных подключений.
Для управления менеджером NetworkManager из командной строки используйте команду nmcli. Эта команда довольно обширная; дополнительную информацию о ней см. на странице руководства nmcli(1).
Наконец, утилита nm-online сообщит вам о том, функционирует сеть или нет. Если сеть в порядке, команда возвращает нулевое значение кода завершения; в противном случае оно отличается от нуля. Подробности об использовании кода завершения в сценарии оболочки см. в главе 11.
9.11.3. Конфигурация менеджера NetworkManager
Основным каталогом конфигурации менеджера NetworkManager обычно является /etc/NetworkManager, и в нем присутствует несколько различных типов конфигурации. Главный файл конфигурации — NetworkManager.conf. Его формат подобен XDG-файлам. desktop и файлам. ini стандарта Microsoft: пары параметров «ключ — значение» распределены по различным секциям. Вы обнаружите, что практически каждый файл конфигурации содержит секцию [main], которая определяет необходимые для использования плагины. Вот простой пример, в котором активизируется плагин ifupdown, применяемый в системах Ubuntu и Debian:
[main]
plugins=ifupdown,keyfile
Плагинами, которые зависят от версии ОС, являются ifcfg-rh (для семейства Red Hat) и ifcfg-suse (для SuSE). Плагин keyfile, который вы также видите здесь, поддерживает собственный файл конфигурации менеджера NetworkManager. При использовании этого плагина можно увидеть опознанные системой подключения в файле /etc/NetworkManager/system-connections.
В большинстве случаев вам не потребуется изменять файл NetworkManager.conf, поскольку специальные параметры конфигурации находятся в других файлах.
Неуправляемые интерфейсы
Несмотря на то что менеджер NetworkManager может вам понадобиться для управления большинством сетевых интерфейсов, иногда возникают ситуации, когда необходимо игнорировать интерфейсы. Например, нет причин для того, чтобы большинству пользователей понадобился какой-либо тип динамической конфигурации интерфейса локального хоста (lo), так как эта конфигурация никогда не меняется. Может также потребоваться настроить этот интерфейс на ранних стадиях процесса загрузки системы, поскольку основные системные службы часто зависят от него. В большинстве версий ОС менеджер NetworkManager не допускается к локальному хосту.
Можно дать указание менеджеру NetworkManager, чтобы он игнорировал какой-либо интерфейс, используя плагины. Если вы применяете плагин ifupdown (например, в Ubuntu и Debian), добавьте конфигурацию интерфейса в файл /etc/network/interfaces, а затем в секции ifupdown файла NetworkManager.conf установите для параметра managed значение false:
[ifupdown]
managed=false
Для плагина ifcfg-rh, который используется в Fedora и Red Hat, поищите строку, подобную приведенной ниже, в каталоге /etc/sysconfig/network-scripts, который содержит конфигурационные файлы ifcfg-*:
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.example.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.
Другой проблемой, связанной с традиционным устройством сервера имен, является то, что оно может оказаться чрезвычайно негибким, когда вам потребуется выяснить имена в вашей локальной сети, не вникая в детали сетевой конфигурации. Если, например, вы настраиваете сетевое устройство в своей сети, вам может понадобиться немедленно вызвать его по имени. Это часть идеи, которая заложена в такие службы имен, не требующие конфигурации, как mDNS (Multicast DNS, многоадресная служба DNS) и SSDP (Simple Service Discovery Protocol, простой протокол обнаружения службы). Если необходимо найти в локальной сети хост по его имени, то вы просто рассылаете запрос по этой сети; если требуемый хост в ней присутствует, то он возвращает в ответ свой адрес. Эти протоколы выходят за рамки разрешения имени хоста, предоставляя также информацию о доступных службах.
Наиболее широко используемая реализация mDNS для Linux называется Avahi. Вариант mdns часто указывается в качестве функции разрешения имен в файле /etc/nsswitch.conf, который мы сейчас рассмотрим более подробно.
9.12.4. Файл /etc/nsswitch.conf
Файл /etc/nsswitch.conf контролирует параметры старшинства, связанные с именами, такие как информация о пользователе и пароле. Однако мы будем говорить в данной главе лишь о параметрах DNS. В этом файле должна быть строка, подобная следующей:
hosts: files dns
Параметр files помещен перед параметром dns, чтобы система искала запрашиваемый вами IP-адрес в файле /etc/hosts, прежде чем обратиться к серверу DNS. Обычно такой способ хорош (особенно при отыскании локального хоста, как описано ниже), но при этом файл /etc/hosts должен быть по возможности коротким. Не помещайте в него ничего для улучшения производительности, это только навредит вам впоследствии. Можно поместить данные о всех хостах небольшой частной локальной сети в файл /etc/hosts, однако общее правило здесь таково: если у какого-либо хоста есть запись в службе DNS, его не следует указывать в файле /etc/hosts. Файл /etc/hosts полезен также для разрешения имен на ранних этапах загрузки системы, когда сеть может оказаться недоступной.
примечание
Тема, посвященная DNS, достаточно обширна. Если вы каким-либо образом ответственны за доменные имена, прочитайте книгу Крикета Лиу (Cricket Liu) и Пола Альбитца (Paul Albitz) DNS and BIND («Службы DNS и BIND»), 5-е издание (O’Reilly, 2006).
9.13. Локальный хост
Если запустить команду ifconfig, можно заметить интерфейс lo:
lo Link encap: Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr:::1/128 Scope: Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
Интерфейс lo является виртуальным сетевым интерфейсом, который называется возвратной петлей, поскольку он «закольцован» сам на себя. Результат таков, что при подключении к адресу 127.0.0.1 происходит подключение к компьютеру, которым вы пользуетесь в данный момент. Когда исходящие данные для локального хоста доходят до сетевого интерфейса lo в ядре, ядро просто заново упаковывает их как входящие данные и отправляет обратно через интерфейс lo.
Интерфейс возвратной петли lo часто является единственным местом, где можно увидеть статическую сетевую конфигурацию в сценариях загрузки системы. Так, например, команда ifup в Ubuntu читает файл /etc/network/interfaces, а в Fedora используется файл /etc/sysconfig/network-interfaces/ifcfg-lo. Часто можно обнаружить конфигурацию какого-либо устройства с возвратной петлей, если поискать в каталоге /etc с помощью команды grep.
9.14. Транспортный уровень: протоколы TCP, UDP и службы
До сих пор мы видели лишь то, как пакеты перемещаются от хоста к хосту по сети Интернет, другими словами, ответ на вопрос «куда?» из начала этой главы. Теперь начнем отвечать на вопрос «что?». Важно знать, как ваш компьютер представляет данные пакета, которые он получает от других хостов, своим работающим процессам. Для команд из пространства пользователя трудно и неудобно иметь дело с набором пакетов таким образом, как с ними может работать ядро. В особенности важна гибкость: сразу несколько приложений должны иметь возможность одновременного обращения к сети (например, вам может потребоваться запустить почтовый клиент и браузер).
Протоколы транспортного уровня заполняют разрыв между необработанными пакетами интернет-уровня и «рафинированными» потребностями приложений. Двумя самыми популярными транспортными протоколами являются TCP (Transmission Control Protocol, протокол управления передачей) и UDP (User Datagram Protocol, протокол передачи дейтаграмм пользователя). Мы сосредоточимся на протоколе TCP, так как он безоговорочно является наиболее используемым, и вкратце рассмотрим и протокол UDP.
9.14.1. Порты TCP и соединения
Протокол TCP предоставляется нескольким сетевым приложениям на одном компьютере с помощью сетевых портов. Порт — это просто число. Если IP-адрес можно уподобить почтовому индексу какого-либо жилого дома, то порт похож на номер почтового ящика: это дальнейшее деление на более мелкие части.
При использовании протокола TCP приложение открывает соединение (не смешивайте с подключениями в менеджере NetworkManager) между одним из портов данного компьютера и каким-либо портом удаленного хоста. Например, такое приложение, как браузер, могло бы открыть соединение между портом 36406 компьютера и портом 80 удаленного хоста. С точки зрения приложения порт 36406 является локальным портом, а порт 80 — удаленным портом.
Можно идентифицировать соединение с помощью пары, составленной из IP-адреса и номера порта. Чтобы увидеть соединения, которые в данный момент открыты на компьютере, воспользуйтесь командой netstat. Приведем пример, в котором показаны TCP-соединения (параметр — n отключает разрешение имен (DNS), а параметр — t ограничивает результаты только протоколом TCP):
$ netstat — nt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 10.23.2.4:47626 10.194.79.125:5222 ESTABLISHED
tcp 0 0 10.23.2.4:41475 172.19.52.144:6667 ESTABLISHED
tcp 0 0 10.23.2.4:57132 192.168.231.135:22 ESTABLISHED
Поля Local Address и Foreign Address показывают соединения с точки зрения компьютера. Следовательно, для этого компьютера интерфейс настроен на IP-адрес 10.23.2.4, а локальные порты 47626, 41475 и 57132 подключены. Здесь первое соединение установлено между портом 47626 и портом 5222 по адресу 10.194.79.125.
9.14.2. Установление TCP-соединений
Чтобы установить соединение с помощью транспортного уровня, процесс на каком-либо хосте инициирует подключение одного из своих локальных портов ко второму хосту с помощью специальной серии пакетов. Чтобы распознать входящее соединение и ответить на него, второй хост должен обладать процессом, который прослушивает правильный порт. Как правило, подключающийся процесс называется клиентом, а прослушивающий — сервером (подробности изложены в главе 10).
О портах важно знать следующее: клиент выбирает такой порт со своей стороны, который в настоящее время не используется, но он практически всегда соединяется с каким-либо хорошо известным портом на стороне сервера. Вернитесь к выводу команды netstat из предыдущего раздела:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 10.23.2.4:47626 10.194.79.125:5222 ESTABLISHED
С небольшой подсказкой можно понять, что это соединение с удаленным сервером было, по-видимому, инициировано локальным клиентом, так как порт локальной стороны (47626) выглядит как динамически присвоенное число, в то время как удаленный порт (5222) является хорошо известной службой (службой сообщений Jabber или XMPP, если быть конкретнее).
примечание
Динамически назначаемый порт называется эфемерным портом.
Однако если локальный порт в этом выводе хорошо известен, то соединение, вероятно, было инициировано удаленным хостом. В приведенном ниже примере удаленный хост 172.24.54.234 подключился к порту 80 (веб-порт по умолчанию) локального хоста.
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 10.23.2.4:80 172.24.54.234:43035 ESTABLISHED
Удаленный хост, подключающийся к хорошо известному порту вашего компьютера, подразумевает, что сервер локального компьютера прослушивает данный порт. Чтобы убедиться в этом, выведите список всех TCP-портов, которые прослушивает ваш компьютер, с помощью команды netstat:
$ netstat — ntl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
— snip—
Строка, которая содержит значение 0.0.0.0:80 как локальный адрес, говорит о том, что локальный компьютер прослушивает подключения к порту 80 от удаленных компьютеров. Сервер может ограничить доступ к некоторым интерфейсам, как показано в последней строке, где нечто прослушивает соединения только в интерфейсе локального хоста. Чтобы узнать еще больше подробностей, воспользуйтесь командой lsof для идентификации процесса, выполняющего прослушивание (как рассказано в подразделе 10.5.1).
9.14.3. Номера портов и файл /etc/services
Как узнать, является ли порт хорошо известным? Однозначно сказать нельзя, но начать стоит с просмотра файла /etc/services, который переводит значения хорошо известных портов в имена. Это простой текстовый файл. Вы можете увидеть в нем записи вроде:
ssh 22/tcp # SSH Remote Login Protocol
smtp 25/tcp
domain 53/udp
Первый столбец содержит имя, а во втором указаны номер порта и относящийся к нему протокол транспортного уровня (который может отличаться от TCP).
примечание
В дополнение к файлу /etc/services по адресу http://www.iana.org/ существует онлайн-реестр портов, который регулируется документом RFC6335 о сетевых стандартах.
В Linux только те процессы, которые запущены с корневыми (superuser) правами, могут использовать порты с 1 по 1023. Все пользовательские процессы могут выполнять прослушивание и создавать соединения, применяя порты с 1024 и далее.
9.14.4. Характеристики протокола TCP
Протокол TCP популярен как протокол транспортного уровня, поскольку он требует сравнительно немного со стороны приложения. Процессу приложения надо знать лишь о том, как открывать (или прослушивать), считывать, записывать и закрывать соединение. Для приложения это напоминает входящие и исходящие потоки данных; процесс почти так же прост, как работа с файлом.
Однако за всем этим стоит большая работа. Для начала протоколу TCP необходимо знать о том, как разбивать исходящий от процесса поток данных на пакеты. Сложнее узнать, как преобразовать серию входящих пакетов во входной поток данных для процесса, в особенности тогда, когда входящие пакеты не обязательно приходят в правильном порядке. В дополнение к этому хост, использующий протокол TCP, должен выполнять проверку на ошибки: при пересылке через Интернет пакеты могут быть потеряны или повреждены, протокол TCP должен обнаружить и исправить подобные ситуации. На рис. 9.3 приведена упрощенная схема того, как хост может использовать протокол TCP для отправки сообщения.
К счастью, вам не нужно знать обо всем этом практически ничего, кроме того, что в Linux протокол TCP реализован главным образом в ядре, а утилиты, которые работают с транспортным уровнем, стремятся использовать структуры данных ядра. Одним из примеров является система фильтрации пакетов с помощью IP-таблиц, которая рассмотрена в разделе 9.21.
9.14.5. Протокол UDP
Протокол UDP является намного более простым транспортным уровнем по сравнению с протоколом TCP. Он определяет передачу только для отдельных сообщений, потока данных здесь нет. В то же время, в отличие от протокола TCP, протокол UDP не выполняет коррекцию утерянных или неправильно расположенных пакетов. На самом деле, хотя у протокола UDP и есть порты, он даже не обладает соединениями! Хост просто отправляет сообщение от одного из своих портов порту на сервере, а сервер отправляет что-либо обратно, если желает. Тем не менее в протоколе UDP все же присутствует выявление ошибок данных внутри пакета. Хост может установить, что пакет поврежден, но он ничего не должен делать в связи с этим.
Если протокол TCP похож на телефонный разговор, то протокол UDP напоминает отправку письма, телеграммы или мгновенного сообщения (за исключением того, что мгновенные сообщения более надежны). Приложения, которые используют протокол UDP, часто заинтересованы в скорости: отправить сообщение настолько быстро, насколько возможно. Им не нужны дополнительные данные, как в протоколе TCP, поскольку они предполагают, что сетевое соединение между двумя хостами достаточно устойчивое. Им не нужна, как в TCP-протоколе, коррекция ошибок, так как они располагают собственными системами обнаружения ошибок или же просто не обращают на них внимания.
Одним из примеров приложения, которое использует протокол UDP, является протокол NTP (Network Time Protocol, протокол сетевого времени). Клиент отправляет короткий и простой запрос серверу, чтобы получить текущее время, ответ сервера такой же краткий. Поскольку ответ необходим клиенту по возможности быстро, приложению годится протокол UDP; если ответ сервера затеряется где-либо в сети, клиент может просто направить повторный запрос или прекратить попытки. Другим примером является видеочат: в этом случае изображения пересылаются с помощью протокола UDP. Если некоторые фрагменты будут утрачены в пути, клиент на принимающей стороне сделает все возможное для их компенсации.
Рис. 9.3. Отправка сообщения с помощью протокола TCP
примечание
Оставшаяся часть этой главы посвящена боле сложным темам, таким как сетевая фильтрация и маршрутизаторы, поскольку они относятся к более низким сетевым уровням по сравнению с рассмотренными: физическим, сетевым и транспортным. Если желаете, можете спокойно приступать к следующей главе, чтобы узнать о прикладном уровне, на котором все объединяется в пространстве пользователя. Вы увидите процессы, использующие сеть, а не просто перекидывающие наборы адресов и пакетов.
9.15. Возвращаемся к простой локальной сети
Сейчас мы рассмотрим дополнительные компоненты простой локальной сети, о которой шла речь в разделе 9.3. Вспомните, что эта сеть состоит из одной местной сети в качестве подсети и маршрутизатора, который соединяет эту подсеть с остальной частью Интернета. Вы узнаете следующее:
• каким образом хост в этой подсети автоматически получает свою сетевую конфигурацию;
• как настроить маршрутизацию;
• что такое маршрутизатор на деле;
• как узнать, какой IP-адрес применить для подсети;
• как настроить брандмауэры, чтобы фильтровать нежелательный интернет-трафик.
Начнем с изучения того, каким образом хост в подсети автоматически получает свою сетевую конфигурацию.
9.16. Понятие о протоколе DHCP
Когда вы настраиваете сетевой хост на автоматическое получение конфигурации из сети, вы указываете ему, чтобы он использовал протокол DHCP (Dynamic Host Configuration Protocol, протокол динамического конфигурирования хоста) для получения IP-адреса, маски подсети, шлюза по умолчанию и серверов DNS. Помимо того что не приходится вводить эти параметры вручную, протокол DHCP обладает другими преимуществами для сетевого администратора, такими как предотвращение конфликтов IP-адресов и минимизация последствий при изменении сети. Нечасто можно встретить современную сеть, которая не использует протокол DHCP.
Чтобы хост получал свою конфигурацию с помощью протокола DHCP, он должен быть способен отправлять сообщения DHCP-серверу той сети, к которой он подключен. Следовательно, каждая физическая сеть должна обладать собственным DHCP-сервером, а в простой сети (подобной той, которая описана в разделе 9.3) его роль обычно выполняет маршрутизатор.
примечание
При выполнении первичного DHCP-запроса хост не знает даже адреса DHCP-сервера, поэтому он рассылает свой запрос всем хостам (как правило, всем хостам своей физической сети).
Когда компьютер запрашивает IP-адрес у сервера DHCP, на самом деле он просит об аренде этого адреса на некоторое время. Когда аренда заканчивается, клиент может запросить обновление аренды.
9.16.1. Клиент DHCP в Linux
Хотя и существует множество разных типов систем управления сетью, почти все они используют команду dhclient (которая придерживается стандартов ISC (Internet Software Consortium, Консорциум по разработке ПО для сети Интернет)) для выполнения реальной работы. Можно проверить работу команды dhclient вручную из командной строки, но сначала вы обязаны удалить маршрут шлюза по умолчанию. Чтобы выполнить тест, просто укажите имя сетевого интерфейса (в данном примере это eth0):
# dhclient eth0
Во время запуска команда dhclient сохраняет идентификатор своего процесса в файле /var/run/dhclient.pid, а информацию об аренде — в файле /var/state/dhclient.leases.
9.16.2. Серверы DHCP в Linux
Вы можете поручить компьютеру с Linux задачу по поддержанию сервера DHCP, чтобы обеспечить достаточную степень контроля над адресами, которые он раздает. Однако если вы не администрируете большую сеть с многими подсетями, то, вероятно, лучше будет использовать специальные аппаратные средства маршрутизации, в которые встроены серверы DHCP.
Возможно, о DHCP-серверах важнее всего знать следующее: необходимо применять только один такой сервер внутри подсети, чтобы избежать конфликтующих IP-адресов или неправильной конфигурации.
9.17. Настройка Linux в качестве маршрутизатора
По существу, маршрутизаторы являются всего лишь компьютерами, которые обладают несколькими интерфейсами физической сети. Можно с легкостью настроить компьютер с Linux как маршрутизатор.
Допустим, у вас есть две локальные подсети — 10.23.2.0/24 и 192.168.45.0/24. Чтобы их соединить, у вас имеется компьютер-маршрутизатор с Linux, в котором присутствуют три сетевых интерфейса: два для локальных подсетей и один — для связи с Интернетом, как показано на рис. 9.4. Как видите, это не сильно отличается от примера с простой сетью, который мы использовали в начале этой главы.
IP-адреса маршрутизатора для локальных подсетей таковы: 10.23.2.1 и 192.168.45.1. При настройке этих адресов таблица маршрутизации выглядит подобным образом (имена интерфейсов в действительности могут быть другими; интернет-ссылку пока проигнорируем):
Рис. 9.4. Две подсети, соединенные с помощью маршрутизатора
Destination Gateway Genmask Flags Metric Ref Use Iface
10.23.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.45.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
Допустим, что для хостов в каждой из подсетей маршрутизатор указан в качестве шлюза по умолчанию (10.23.2.1 для сети 10.23.2.0/24 и 192.168.45.1 для сети 192.168.45.0/24). Если сеть 10.23.2.4 желает отправить пакет куда-либо за пределы сети 10.23.2.0/24, она передает такой пакет по адресу 10.23.2.1. Например, чтобы отправить пакет от адреса 10.23.2.4 (хост A) по адресу 192.168.45.61 (хост E), пакет приходит на адрес 10.23.2.1 (маршрутизатор) через интерфейс eth0, а затем уходит с него через интерфейс маршрутизатора eth1.
Однако по умолчанию ядро Linux не перемещает автоматически пакеты из одной подсети в другую. Чтобы задействовать эту основную функцию маршрутизации, необходимо включить IP-перенаправление в ядре маршрутизатора с помощью такой команды:
# sysctl — w net.ipv4.ip_forward
Как только вы введете эту команду, компьютер должен начать маршрутизацию пакетов между двумя подсетями при условии, что хосты этих подсетей знают о том, что пакеты следует отправлять только что созданному вами маршрутизатору.
Чтобы это изменение сохранилось после перезагрузки, можно добавить его в файл /etc/sysctl.conf. В зависимости от версии ОС может быть также вариант размещения в файле /etc/sysctl.d, чтобы ваши изменения не были перезаписаны при обновлениях системы.
Интернет-ссылки верхнего уровня. Когда в маршрутизаторе присутствует также третий сетевой интерфейс с интернет-ссылкой верхнего уровня, такая же настройка разрешает доступ в Интернет всем хостам, так как они сконфигурированы на использование этого маршрутизатора в качестве шлюза по умолчанию. Однако здесь все сложнее. Проблема в том, что конкретные IP-адреса, такие как 10.23.2.4, в действительности не видны всему Интернету; они находятся в так называемых частных сетях. Чтобы обеспечить их подключением к Интернету, следует настроить в маршрутизаторе функцию под названием NAT (Network Address Translation, преобразование сетевых адресов). Программное обеспечение почти у всех специализированных маршрутизаторов выполняет эту задачу, в ней нет ничего необычного, но рассмотрим более детально вопрос о частных подсетях.
9.18. Частные сети
Предположим, вы решили создать собственную сеть. Вы уже подготовили компьютеры, маршрутизатор и аппаратные средства сети. С теми знаниями о простой сети, которые у вас уже есть, возникает следующий вопрос: «Какие IP-адреса для подсети следует использовать?»
Если вам нужна группа интернет-адресов, которые может видеть любой хост в Интернете, можете приобрести их у своего поставщика интернет-услуг. Однако, поскольку диапазон адресов версии IPv4 весьма ограничен, это стоит довольно дорого и годится лишь для того, чтобы запустить сервер, который может видеть остальная часть Интернета. Большинству пользователей на самом деле не нужен такой тип услуг, поскольку они подключаются к Интернету в качестве клиентов.
Простая и недорогая альтернатива заключается в выборе адресов частной подсети на основе документов RFC 1918/6761, содержащих интернет-стандарты, показанные в табл. 9.2.
Таблица 9.2. Частные подсети, определяемые в документах RFC 1918 и 6761
Сеть
Маска подсети
Форма CIDR
10.0.0.0
255.0.0.0
10.0.0.0/8
192.168.0.0
255.255.0.0
192.168.0.0/16
172.16.0.0
255.240.0.0
172.16.0.0/12
Вы можете настраивать частные подсети как вам угодно. Если вы не планируете иметь более 254 хостов внутри одной сети, выберите небольшую подсеть вроде 10.23.2.0/24, которую мы рассматриваем в этой главе. Сети с такой маской иногда называют подсетями класса C. Хотя этот термин является технически устаревшим, он по-прежнему применяется.
Что же в итоге? Хосты в реальном Интернете ничего не знают о частных подсетях и не станут отправлять им пакеты, поэтому без дополнительной помощи хосты частных подсетей не могут общаться с внешним миром. Маршрутизатору (с неприватным адресом), подключенному к Интернету, необходимо какое-либо средство, чтобы заполнить разрыв между данным соединением и хостами частной сети.
9.19. Преобразование сетевых адресов (маскировка IP-адреса)
Функция NAT — широко применяемый способ совместного использования единственного IP-адреса для частной сети. Он почти универсален в домашних сетях и сетях небольших офисов. В Linux вариант функции NAT, который использует большинство людей, известен как маскировка IP-адреса.
Суть функции NAT заключается в том, что маршрутизатор не просто передает пакеты от одной подсети в другую, но и трансформирует их во время передачи. Интернет-хосты знают, как подключиться к маршрутизатору, однако ничего не знают о расположенной за ним частной сети. Хостам частной сети не требуется специальная конфигурация; маршрутизатор является для них шлюзом по умолчанию.
Эта система в общих чертах работает так.
1. Хост внутренней частной сети намерен установить соединение с внешним миром, поэтому он отправляет пакеты своего запроса на соединение через маршрутизатор.
2. Маршрутизатор перехватывает эти пакеты, вместо того чтобы отправить их в Интернет (в котором они пропали бы, поскольку общественный Интернет ничего не знает о частных сетях).
3. Маршрутизатор определяет пункт назначения для пакета-запроса и открывает собственное соединение с этим пунктом назначения.
4. Когда маршрутизатор установит соединение, он отправляет фальсифицированное сообщение «соединение установлено» обратно, исходному внутреннему хосту.
5. Теперь маршрутизатор становится посредником между внутренним хостом и пунктом назначения. Пункт назначения ничего не знает о внутреннем хосте; для удаленного хоста соединение выглядит как исходящее от маршрутизатора.
Однако все не настолько просто, как выглядит. Нормальная IP-маршрутизация знает лишь IP-адреса источника и пункта назначения в интернет-уровне. Однако, если бы маршрутизатор имел дело только с интернет-уровнем, каждый хост внутренней сети смог бы установить только одно соединение с единственным пунктом назначения в данный момент времени (есть и другие ограничения), поскольку та часть пакета, которая относится к интернет-уровню, не содержит информации о том, как отличить повторные запросы от одного хоста к тому же пункту назначения. Следовательно, функция NAT должна выйти за пределы интернет-уровня и «вскрыть» пакеты, чтобы извлечь дополнительную идентифицирующую информацию, в частности номера портов UDP и TCP, из транспортных уровней. Протокол UDP достаточно прост, поскольку здесь есть порты, но нет соединений; сложнее дело с транспортным уровнем на основе протокола TCP.
Чтобы компьютер с Linux играл роль NAT-маршрутизатора, в конфигурации ядра должны быть активизированы следующие составляющие: фильтрация сетевых пакетов («поддержка брандмауэра»), отслеживание подключений, поддержка IP-таблиц, полная функция NAT и поддержка маскировки (MASQUERADE). В большинстве версий ядра эта поддержка присутствует.
Далее необходимо запустить несколько сложных на вид команд iptables, чтобы маршрутизатор использовал функцию NAT для частной подсети. Вот пример, который применяется к внутренней сети Ethernet с интерфейсом eth1, совместно использующей внешнее подключение к интерфейсу eth0 (о синтаксисе команды iptables вы узнаете подробнее из раздела 9.21):
# sysctl — w net.ipv4.ip_forward
# iptables — P FORWARD DROP
# iptables — t nat — A POSTROUTING — o eth0 — j MASQUERADE
# iptables — A FORWARD — i eth0 — o eth1 — m state — state ESTABLISHED,RELATED — j ACCEPT
# iptables — A FORWARD — i eth1 — o eth0 — j ACCEPT
примечание
Хотя на практике функция NAT работает превосходно, помните о том, что по существу она является обходным маневром, который используется для продления времени жизни пространства адресов IPv4. В совершенном мире мы без каких-либо затруднений пользовались бы адресами IPv6 (Интернет следующего поколения), более длинными и усовершенствованными.
Вам, вероятно, никогда не потребуется использовать команды, приведенные выше, если вы не заняты разработкой собственного ПО. К тому же сейчас доступно так много специализированных маршрутизаторов. Однако роль Linux в сети на этом не заканчивается.
9.20. Маршрутизаторы и Linux
В ранние годы широкополосного Интернета пользователи с не столь высокими требованиями просто подключали свой компьютер напрямую к Интернету. Однако прошло совсем немного времени, и многим захотелось совместно использовать единственное широкополосное подключение для своих сетей, а пользователи Linux, в частности, настраивали дополнительный компьютер в качестве маршрутизатора с функцией NAT.
Производители откликнулись на этот новый рынок, предложив специализированные аппаратные средства маршрутизации, которые содержат эффективный процессор, некоторый объем флеш-памяти и несколько сетевых портов — этой функциональности достаточно для управления типичной простой сетью, запуска такого необходимого ПО, как сервер DHCP, а также для использования функции NAT. Когда дело дошло до программного обеспечения, многие производители прибегли к помощи Linux, чтобы привести в действие свои маршрутизаторы. Были добавлены необходимые функции ядра, упрощено ПО пространства пользователя и созданы графические интерфейсы администрирования.
Почти сразу же с появлением первых таких маршрутизаторов многие пользователи заинтересовались детальным устройством аппаратных средств. У одного из производителей, компании Linksys, потребовали выпустить исходный код ПО на условиях лицензии для одного из его компонентов, и вскоре для маршрутизаторов стали появляться специальные версии Linux, такие как OpenWRT. Символы WRT возникли из названия моделей оборудования Linksys.
Помимо любознательности, есть веские причины для использования таких версий: они зачастую более стабильны, чем заводская прошивка, в особенности для старых маршрутизаторов, и, как правило, предлагают дополнительные функции. Например, чтобы создать мост между сетью и беспроводным подключением, многие производители требуют покупки подходящего оборудования. Однако если установить OpenWRT, то тогда ни производитель, ни возраст оборудования не будут иметь значения. Это связано с тем, что вы используете в маршрутизаторе по-настоящему открытую операционную систему, для которой неважно, что за аппаратные средства вы применяете, если только они поддерживаются.
Вы можете применить большую часть сведений из этой книги, чтобы исследовать внутренние части специализированной прошивки Linux, хотя вам и встретятся отличия, в особенности при входе в систему. Как и во многих внедренных системах, прошивки с открытым кодом стремятся использовать утилиты BusyBox, чтобы предоставить большинство функций оболочки. Утилиты BusyBox являются единым исполняемым приложением, которое предлагает ограниченную функциональность для многих команд Unix, таких как shell, ls, grep, cat и more. Так экономится существенный объем памяти. Кроме того, команда init для загрузки системы оказывается очень простой во внедренных системах. Тем не менее подобные ограничения не создадут проблем для вас, так как пользовательские прошивки Linux обычно содержат веб-интерфейс для администрирования, который напоминает интерфейс, предлагаемый производителем.
9.21. Брандмауэры
Маршрутизаторы должны всегда содержать какой-либо брандмауэр для запрещения нежелательного трафика в сети. Брандмауэр — это программное обеспечение и/или конфигурация аппаратных средств, которые обычно размещаются в маршрутизаторе между Интернетом и малой сетью, пытаясь не допустить того, чтобы что-либо «плохое» навредило малой сети. Можно также настроить функции брандмауэра для каждого компьютера, и тогда компьютер станет фильтровать все входящие и выходящие данные на уровне пакетов (в противоположность прикладному уровню, на котором серверные программы обычно пытаются самостоятельно обеспечить некоторый контроль доступа). Использование брандмауэра на отдельных компьютерах иногда называется IP-фильтрацией.
Система может фильтровать пакеты, когда она:
• получает пакет;
• отправляет пакет;
• перенаправляет пакет другому хосту или шлюзу.
Если брандмауэра нет, система просто обрабатывает пакеты и отправляет их по назначению. Брандмауэры помещают проверочные пункты для пакетов в указанных выше точках передачи данных. На этих проверочных пунктах пакеты удаляются, отклоняются или принимаются, как правило, на основе таких критериев:
• IP-адрес или подсеть источника или пункта назначения;
• порт источника или пункта назначения (в сведениях транспортного уровня);
• сетевой интерфейс брандмауэра.
Брандмауэры обеспечивают возможность работы с подсистемой ядра Linux, которая обрабатывает IP-пакеты. Рассмотрим ее сейчас.
9.21.1. Брандмауэр в Linux: основные понятия
В Linux правила для брандмауэра создаются в виде последовательности, известной как цепочка. Набор цепочек формирует таблицу. Когда пакет проходит через различные части сетевой подсистемы Linux, ядро применяет правила из определенных цепочек к пакетам. Например, после получения нового пакета от физического уровня ядро активизирует правила в цепочках, соответствующих вводу.
Все эти структуры данных обслуживаются ядром. Такая система в целом называется таблицами iptables, а команда из пространства пользователя iptables создает правила и управляет ими.
ПРИМЕЧАНИЕ
Есть также более современная система, nftables, которая призвана заменить таблицы iptables. Однако на момент написания книги таблицы iptables являются преобладающими для брандмауэров.
Поскольку таблиц может быть несколько — каждая со своим набором цепочек, содержащих множество правил, — то перемещение пакетов становится довольно сложным. Тем не менее обычно работают с единственной таблицей, которая называется «фильтр» и контролирует основной поток пакетов. В таблице фильтра есть три главные цепочки: INPUT для входящих пакетов, OUTPUT для исходящих пакетов и FORWARD для перенаправляемых пакетов.
На рис. 9.5 и 9.6 приведены упрощенные схемы того, где к пакетам применяются правила из таблицы фильтра. Схем две, поскольку пакеты могут либо поступать в систему из сетевого интерфейса (см. рис. 9.5), либо генерироваться локальным процессом (см. рис. 9.6). Как видите, входящий пакет из сети может быть поглощен пользовательским процессом и не достичь цепочки FORWARD или OUTPUT. Пакеты, создаваемые пользовательскими процессами, не достигают цепочек INPUT или FORWARD.
В действительности все сложнее, поскольку есть и другие этапы, помимо этих трех цепочек. Например, пакеты проходят обработку в цепочках PREROUTING и POSTROUTING, а сама обработка может происходить на любом из трех нижних сетевых уровней. Чтобы увидеть полную схему, поищите в онлайн-источниках что-либо под названием «Поток пакетов в сетевом фильтре Linux», но имейте в виду, что подобные схемы пытаются учесть все возможные сценарии поступления и перемещения пакетов. Часто может помочь разбиение схем на основе источников пакетов, как на рис. 9.5 и 9.6.
Рис. 9.5. Последовательность обработки цепочек для входящих пакетов сети
Рис. 9.6. Последовательность обработки цепочек для входящих пакетов от локального процесса
9.21.2. Определение правил для брандмауэра
Посмотрим, как работает на практике система IP-таблиц. Начнем с просмотра текущей конфигурации, использовав команду:
# iptables — L
Вывод обычно представляет собой пустой набор цепочек:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
У каждой цепочки брандмауэра есть политика по умолчанию, которая определяет, что делать с пакетом, если он не удовлетворяет ни одному из правил. Для всех трех цепочек в данном примере установлена политика ACCEPT. Это означает, что ядро разрешает пакету пройти через систему фильтрации. Политика DROP говорит ядру о том, что пакет надо отбросить. Чтобы указать политику цепочки, используйте команду iptables — P, например, так:
# iptables — P FORWARD DROP
внимание
Не торопитесь с изменением политик на своем компьютере, пока не дочитаете данный раздел до конца.
Допустим, кто-либо с IP-адресом 192.168.34.63 надоедает вам. Чтобы избавиться от его запросов к вашему компьютеру, запустите следующую команду:
# iptables — A INPUT — s 192.168.34.63 — j DROP
Здесь параметр — A INPUT присоединяет правило к цепочке INPUT. Фрагмент — s 192.168.34.63 указывает IP-адрес источника в этом правиле, а часть — j DROP говорит ядру о том, чтобы оно отбрасывало любые пакеты, удовлетворяющие этому правилу. Следовательно, ваш компьютер будет отвергать любые пакеты, приходящие с адреса 192.168.34.63.
Чтобы увидеть это правило на своем месте, запустите команду iptables — L:
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all — 192.168.34.63 anywhere
Но вот беда: ваш приятель с адресом 192.168.34.63 сообщил всем в своей подсети, чтобы к вашему компьютеру подключались через порт SMTP (TCP-порт 25). Чтобы избавиться также и от этого трафика, запустите такую команду:
# iptables — A INPUT — s 192.168.34.0/24 — p tcp — destination-port 25 — j DROP
В этом примере добавлен спецификатор маски сети для адреса источника, а также флаг — p tcp, чтобы учитывать только пакеты TCP. Следующее ограничение, — destination-port 25, говорит о том, что данное правило должно применяться только к трафику порта 25. IP-таблица для цепочки INPUT теперь выглядит так:
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all — 192.168.34.63 anywhere
DROP tcp — 192.168.34.0/24 anywhere tcp dpt: smtp
Все идет замечательно, пока кто-то из ваших знакомых с адресом 192.168.34.37 не говорит вам, что он не может отправить вам почту, поскольку вы заблокировали его компьютер. Думая о том, что это легко исправить, вы запускаете следующую команду:
# iptables — A INPUT — s 192.168.34.37 — j ACCEPT
Однако это не срабатывает. Чтобы понять почему, взгляните на новую цепочку:
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all — 192.168.34.63 anywhere
DROP tcp — 192.168.34.0/24 anywhere tcp dpt: smtp
ACCEPT all — 192.168.34.37 anywhere
Ядро считывает цепочки сверху вниз, применяя первое правило, которое подходит.
Первое правило не подходит для адреса 192.168.34.37, а второе подходит, так как оно применяется ко всем хостам в диапазоне адресов от 192.168.34.1 до 192.168.34.254 и говорит о том, что пакеты должны отвергаться. Когда правило подходит, ядро приступает к действиям и уже не смотрит остальные цепочки. Вы, наверное, заметили, что с адреса 192.168.34.37 можно отправлять пакеты на любой порт вашего компьютера, кроме 25, так как второе правило применяется только для него.
Решение заключается в перемещении третьего правила вверх. Сначала удалите третье правило с помощью такой команды:
# iptables — D INPUT 3
Затем вставьте это правило в верхней части цепочки с помощью команды iptables — I:
# iptables — I INPUT — s 192.168.34.37 — j ACCEPT
Чтобы вставить правило где-либо внутри цепочки, укажите номер правила после имени цепочки (например, iptables — I INPUT 4…).
9.21.3. Стратегии для брандмауэров
Хотя приведенные выше указания объяснили вам, как вставлять правила и как ядро обрабатывает IP-цепочки, мы еще не видели стратегий для брандмауэра, которые реально работают. Теперь поговорим о них.
Существуют два основных типа сценариев для брандмауэров: один для защиты отдельных компьютеров (здесь можно указывать правила в цепочке INPUT каждого компьютера), а второй — для защиты компьютеров в составе сети (здесь правила указываются в цепочке FORWARD маршрутизатора). В обоих случаях вы не можете достичь серьезной защиты, если вы применяете по умолчанию политику ACCEPT, а затем постоянно добавляете правила, которые отбрасывают пакеты от источников, начинающих рассылать нежелательный контент. Вы должны разрешать только те пакеты, которым доверяете, и отвергать все остальные.
Допустим, что у вашего компьютера имеется SSH-сервер, обслуживающий TCP-порт 22. Нет никаких оснований для того, чтобы какой-либо хост инициировал соединение с другими портами вашего компьютера, и вы не должны давать такой возможности никаким хостам. Чтобы это организовать, сначала установите для цепочки INPUT политику DROP:
# iptables — P INPUT DROP
Чтобы включить ICMP-трафик (для команды ping и других утилит), используйте такую строку:
# iptables — A INPUT — p icmp — j ACCEPT
Убедитесь в том, что вы можете получать пакеты, которые вы отправляете как на IP-адреса внутри собственной сети, так и на адрес 127.0.0.1 (локальный хост). При условии, что my_addr — это IP-адрес вашего хоста, выполните следующее:
# iptables — A INPUT — s 127.0.0.1 — j ACCEPT
# iptables — A INPUT — s my_addr — j ACCEPT
Если вы управляете подсетью в целом (и доверяете в ней всему), можно заменить адрес my_addr на адрес вашей подсети и ее маску, например, на 10.23.2.0/24.
Теперь, хотя вам по-прежнему требуется отклонять входящие TCP-соединения, необходимо убедиться в том, что ваш хост способен устанавливать TCP-соединения с внешним миром. Поскольку все TCP-соединения начинаются с пакета SYN (запрос соединения), то можно позволить поступление всех TCP-пакетов, которые не являются SYN-пакетами, и тогда все будет в порядке:
# iptables — A INPUT — p tcp '!' —syn — j ACCEPT
Далее, если вы используете удаленный сервер DNS с протоколом UDP, вы должны принимать трафик от вашего сервера имен, чтобы компьютер мог отыскивать имена с помощью службы DNS. Выполните это для всех серверов DNS, указанных в файле /etc/resolv.conf, используя следующую команду (здесь ns_addr означает адрес сервера имен):
# iptables — A INPUT — p udp — source-port 53 — s ns_addr — j ACCEPT
И наконец, разрешите SSH-соединения от кого угодно:
# iptables — A INPUT — p tcp — destination-port 22 — j ACCEPT
Приведенные настройки IP-таблиц подходят для многих ситуаций, включая любое прямое соединение (в особенности широкополосное), когда злоумышленник будет, скорее всего, сканировать порты вашего компьютера. Можно было бы также адаптировать эти настройки для маршрутизатора с функцией брандмауэра, использовав цепочку FORWARD вместо INPUT и указав подсети источника и назначения, где это допустимо. Для более сложных конфигураций может оказаться полезным такой инструмент, как надстройка Shorewall.
Наш рассказ лишь слегка затронул политику безопасности. Помните о ключевой идее: разрешать только то, что вы считаете приемлемым, и не пытаться выискивать и плохое содержимое. Более того, IP-фильтрация является лишь фрагментом в картине безопасности. Дополнительные сведения вы получите в следующей главе.
9.22. Сеть Ethernet, протоколы IP и ARP
В реализации протокола IP для сетей Ethernet есть одна интересная деталь, о которой мы еще не упоминали. Вспомните о том, что хост должен помещать IP-пакет в кадр Ethernet, чтобы переместить пакет на физическом уровне к другому хосту. Вспомните также, что сами кадры не содержат информацию об IP-адресе, они используют адреса MAC (аппаратные). Вопрос таков: каким образом при создании кадра Ethernet для IP-пакета хост определяет, какой MAC-адрес соответствует IP-адресу пункта назначения?
Обычно мы не раздумываем над этим вопросом, поскольку сетевое ПО содержит автоматическую систему поиска MAC-адресов, которая называется протоколом ARP (Address Resolution Protocol, протокол разрешения адресов). Хост, который использует сеть Ethernet как физический уровень и протокол IP как сетевой уровень, содержит небольшую таблицу, называемую кэшем ARP, которая сопоставляет IP-адреса адресам MAC. В Linux кэш ARP расположен в ядре. Чтобы просмотреть кэш ARP на компьютере, используйте команду arp. Как и для многих других сетевых команд, параметр — n здесь отключает обратный поиск DNS.
$ arp — n
Address Hwtype Hwaddr Flags Mask Iface
10.1.2.141 ether 00:11:32:0d: ca:82 C eth0
10.1.2.1 ether 00:24:a5:b5:a0:11 C eth0
10.1.2.50 ether 00:0c:41:f6:1c:99 C eth0
При загрузке компьютера кэш ARP пуст. Как же тогда MAC-адреса попадают в этот кэш? Все начинается тогда, когда компьютер желает отправить пакет другому хосту. Если целевой IP-адрес отсутствует в кэше ARP, выполняются следующие действия.
1. Хост-источник создает специальный кадр Ethernet, содержащий пакет запроса у кэша ARP тех адресов, которые соответствуют целевому IP-адресу.
2. Хост-источник передает этот кадр по всей физической сети в целевой подсети.
3. Если один из других хостов этой подсети знает правильный MAC-адрес, он создает ответный пакет и кадр, содержащий данный адрес, а затем отправляет его источнику. Зачастую отвечающий хост является целевым и просто отправляет в ответ собственный MAC-адрес.
4. Хост-источник добавляет пару адресов IP-MAC в кэш ARP и готов продолжить работу.
примечание
Помните о том, что кэш ARP применяется только для компьютеров локальных подсетей (загляните в раздел 9.4, чтобы определить ваши локальные подсети). Чтобы добраться до пунктов назначения за пределами подсети, хост отправляет пакет маршрутизатору, и эта задача в итоге переходит к кому-то другому. Конечно же, ваш хост должен знать MAC-адрес маршрутизатора и может использовать кэш ARP, чтобы выяснить адрес.
Единственная настоящая проблема с кэшем ARP может возникнуть, когда он становится устаревшим, если вы присвоили IP-адрес от одной карты сетевого интерфейса другой карте (например, при тестировании компьютера), поскольку у этих карт различные MAC-адреса. Система Unix делает недействительными записи в кэше ARP, если они неактивны в течение некоторого времени, поэтому здесь возникнет лишь небольшая задержка, вызванная недействующими данными. Можно немедленно удалить запись в кэше ARP с помощью такой команды:
# arp — d host
Можно также просмотреть кэш ARP для одного сетевого интерфейса с помощью команды:
$ arp — i interface
Страница руководства arp(8) содержит объяснение того, как вручную настроить записи в кэше ARP, но вам это вряд ли потребуется.
примечание
Не смешивайте кэш ARP с протоколом RARP (Reverse Address Resolution Protocol, протокол определения адреса по местоположению узла). Протокол RARP преобразует MAC-адрес обратно в имя хоста или в IP-адрес. До того как стал популярен протокол DHCP, некоторые бездисковые рабочие станции и другие устройства использовали протокол RARP для получения своей конфигурации, но сегодня он применяется редко.
9.23. Беспроводная сеть Ethernet
Беспроводные сети Ethernet (сети Wi-Fi) незначительно отличаются от проводных сетей. Подобно любым проводным аппаратным средствам, они обладают MAC-адресами и применяют кадры Ethernet, чтобы передавать и получать данные, в результате чего ядро Linux способно «общаться» с беспроводным сетевым интерфейсом во многом так же, как если бы это был проводной интерфейс. Все, что находится на сетевом уровне и выше, точно такое же; главные отличия — это дополнительные компоненты на физическом уровне, такие как частоты, идентификаторы сети, безопасность и т. д.
В отличие от проводных сетевых аппаратных средств, которые очень хороши при автоматической подстройке без лишней суеты под нюансы физической составляющей, конфигурация беспроводной сети допускает намного больше свободы. Чтобы беспроводной интерфейс работал корректно, в Linux необходимы дополнительные инструменты конфигурирования.
Вкратце рассмотрим дополнительные компоненты беспроводных сетей.
• Подробности передачи. Они содержат физические характеристики, такие как радиочастота.
Идентификация сети. Поскольку одну и ту же базовую среду могут совместно использовать несколько беспроводных сетей, должна быть возможность их различения. Параметр SSID (Service Set Identifier, идентификатор сервисного набора, известный также как «имя сети») является идентификатором беспроводной сети.
Управление. Хотя возможно настроить беспроводную сеть так, чтобы хосты взаимодействовали друг с другом напрямую, большинство беспроводных сетей управляется с помощью одной или нескольких точек доступа, через которые проходит весь трафик. Точки доступа часто выполняют функцию моста между беспроводной и проводной сетями, в результате чего обе они выглядят единой сетью.
Аутентификация. Вам может понадобиться ограничение доступа к беспроводной сети. Чтобы это выполнить, можно настроить точки доступа таким образом, чтобы они запрашивали пароль или какой-либо аутентификационный ключ, прежде чем начать взаимодействие с клиентом.
Шифрование. В дополнение к ограничению начального доступа к беспроводной сети, как правило, необходимо шифровать весь трафик, который передается с помощью радиоволн.
Конфигурация Linux, а также утилиты, которые работают с этими компонентами, расположены в нескольких областях системы. Некоторые находятся в ядре: Linux располагает набором расширений для работы с беспроводными сетями, стандартизирующими доступ к аппаратным средствам из пространства пользователя. По мере разрастания пространства пользователя беспроводная конфигурация может усложниться, поэтому большинство пользователей предпочитает использовать внешние графические интерфейсы, такие как апплет рабочего стола для менеджера NetworkManager, чтобы привести все в действие. Опять-таки иногда стоит посмотреть, что происходит за кулисами.
9.23.1. Утилита iw
Можно просмотреть и изменить конфигурацию устройств и сети в пространстве ядра с помощью утилиты iw. Чтобы ее использовать, обычно необходимо знать имя сетевого интерфейса для устройства, например wlan0. Вот пример, в котором выводится перечень доступных беспроводных сетей. Если вы находитесь в городе, будьте готовы к появлению длинного списка.
# iw dev wlan0 scan
примечание
Для того чтобы эта команда сработала, необходимо, чтобы сетевой интерфейс функционировал (если это не так, запустите команду ifconfig wlan0 up), но вам не потребуется настраивать какие-либо параметры сетевого уровня, например IP-адрес.
Если сетевой интерфейс подключился к беспроводной сети, можно просмотреть сведения о сети следующим образом:
# iw dev wlan0 link
Адрес MAC, показанный в отчете этой команды, является адресом точки доступа, к которой вы в данный момент подключены.
примечание
Утилита iw делает различие между именами физических устройств, такими как phy0, и именами сетевых интерфейсов, например wlan0, и позволяет вам изменить различные параметры в каждом случае. Можно даже создать несколько сетевых интерфейсов для единственного физического устройства. Тем не менее почти во всех основных случаях вы будете использовать имя сетевого интерфейса.
Для подключения сетевого интерфейса к незащищенной беспроводной сети воспользуйтесь такой командой:
# iw wlan0 connect network_name
Подключение к защищенным сетям — это совсем другая история. Для довольно ненадежной системы WEP (Wired Equivalent Privacy, протокол шифрования в беспроводной связи) можно использовать в команде iw параметр keys. Однако, если вы серьезно относитесь к защите, не следует применять протокол WEP.
9.23.2. Безопасность беспроводных сетей
Для большинства настроек беспроводной сети Linux опирается на демон wpa_supplicant, который управляет аутентификацией и шифрованием для интерфейса беспроводной сети. Этот демон может работать со схемами аутентификации WPA (Wi-Fi Protected Access, защищенный доступ к беспроводной сети) и WPA2, а также почти с любым типом шифрования, используемым в беспроводных сетях. При своем первом запуске этот демон читает конфигурационный файл (по умолчанию /etc/wpa_supplicant.conf) и пытается идентифицировать себя с точкой доступа, а затем установить связь на основе предоставленного имени сети. Система хорошо документирована; в частности, страницы руководства wpa_supplicant(1) и wpa_supplicant.conf(5) содержат множество подробностей.
Ручной запуск демона каждый раз, когда вам необходимо установить соединение, является слишком трудоемким. На самом деле уже само создание файла конфигурации довольно утомительно вследствие большого количества возможных вариантов. Чтобы усугубить ситуацию, все работы по запуску утилиты iw и демона wpa_supplicant всего лишь позволяют вашей системе физически подключиться к беспроводной сети, при этом не выполняется даже настройка сетевого уровня. Именно здесь такие менеджеры автоматической сетевой конфигурации, как NetworkManager, избавляют от большей части неприятных моментов. Хотя они не выполняют никакой работы самостоятельно, им известна правильная последовательность действий и необходимая конфигурация для каждого шага на пути к получению работающей беспроводной сети.
9.24. Резюме
Понимание места и роли различных сетевых уровней очень важно для усвоения того, как происходит работа с сетью в Linux и каким образом выполняется конфигурирование сети. Хотя мы рассмотрели только основы, более сложные темы, связанные с физическим, сетевым и транспортным уровнями, подобны тому, что вы увидели. Сами уровни зачастую делятся на более мелкие части из-за различных составляющих физического слоя беспроводной сети.
Значительная часть действий, которые вы наблюдали в этой главе, происходит в ядре с добавлением некоторых основных управляющих утилит из пространства пользователя, работающих с внутренними структурами данных ядра (например, с таблицами маршрутизации). Это традиционный способ работы с сетями. Однако некоторые задачи не подходят для ядра из-за своей сложности и требуемой от них гибкости. Тогда к делу подключаются утилиты из пространства пользователя. В частности, менеджер NetworkManager контролирует ядро и выполняет запросы, а затем управляет конфигурацией ядра. Еще один пример — поддержка протоколов динамической маршрутизации, таких как протокол BGP (Border Gateway Protocol, пограничный шлюзовый протокол), который используется в больших интернет-маршрутизаторах.
Возможно, к этому моменту вам немного наскучило конфигурирование сети. Перейдем к ее использованию на прикладном уровне.
отмечены дата и время запуска команды touch: 
и 
, а также перемещаться к предыдущим командам с помощью клавиш 
и 
. Такой способ работы является стандартным в большинстве систем Linux. 
ATA WDC WD3200AAJS-2 01.0 /dev/sda 
