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

# iw wlan0 connect network_name

Подключение к защищенным сетям — это совсем другая история. Для довольно ненадежной системы WEP (Wired Equivalent Privacy, протокол шифрования в беспроводной связи) можно использовать в команде iw параметр keys. Однако, если вы серьезно относитесь к защите, не следует применять протокол WEP.

9.23.2. Безопасность беспроводных сетей

Для большинства настроек беспроводной сети Linux опирается на демон wpa_supp­licant, который управляет аутентификацией и шифрованием для интерфейса беспроводной сети. Этот демон может работать со схемами аутентификации 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, пограничный шлюзовый протокол), который используется в больших интернет-маршрутизаторах.

Возможно, к этому моменту вам немного наскучило конфигурирование сети. Перейдем к ее использованию на прикладном уровне.

10. Сетевые приложения и службы

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

Для выполнения своей работы сетевые клиенты подключаются к соответству­ющим сетевым серверам. Сетевые серверы Unix включаются в дело различными способами. Серверная команда может либо самостоятельно прослушивать порт, либо через вторичный сервер. В дополнение к этому у серверов нет общей базы данных конфигурации и широкого набора функций. Большинство серверов использует файл конфигурации для контроля своего поведения (хотя для такого файла и нет установленного формата), а многие применяют также системную службу syslog для записи уведомлений. Мы рассмотрим некоторые распространенные серверы, а также ин­струменты, которые помогут вам понять и отладить работу сервера.

Сетевые клиенты используют протоколы и интерфейсы транспортного уровня операционной системы, поэтому важно понимать основы транспортных уровней TCP и UDP. Начнем рассмотрение сетевых приложений, поэкспериментировав с сетевым клиентом, который использует протокол TCP.

10.1. Основные понятия о службах

Службы TCP являются одними из самых простых для понимания, поскольку они построены на несложных, непрерывных двухсторонних потоках данных. Вероятно, лучший способ увидеть, как они работают, — «пообщаться» с веб-сервером напрямую через TCP-порт 80 и получить представление о том, как данные перемещаются через это соединение. Запустите, например, такую команду для подключения к веб-серверу:

$ telnet www.wikipedia.org 80

Вы должны увидеть в ответ нечто подобное:

Trying some address...

Connected to www.wikipedia.org.

Escape character is '^]'.

Теперь введите:

GET / HTTP/1.0

Нажмите клавишу Enter дважды. Сервер должен отправить в виде ответа некоторое количество HTML-текста, а затем разорвать соединение.

Это упражнение говорит нам о том, что:

• на удаленном хосте есть процесс веб-сервера, прослушивающий TCP-порт 80;

• клиентом, который инициировал соединение, являлась команда telnet.

примечание

Команда telnet изначально была предназначена для осуществления входа на удаленные хосты. Хотя вход на удаленный сервер с помощью команды telnet без использования технологии Kerberos совершенно не защищен (как вы увидите далее), клиент telnet может быть полезен для отладки удаленных служб. Команда telnet не работает с протоколом UDP или любым транспортным уровнем, отличным от TCP. Если вы ищете сетевой клиент общего назначения, попробуйте команду netcat, описанную в подразделе 10.5.3.

В приведенном выше примере вы вручную выполнили взаимодействие с веб-сервером в сети с помощью команды telnet, использовав протокол HTTP (Hypertext Transfer Protocol, протокол передачи гипертекста) прикладного уровня. Хотя в обычных условиях вы воспользовались бы браузером для установления подобного соединения, немного отойдем от команды telnet и применим команду, которая знает, как «говорить» с прикладным уровнем HTTP. Мы используем утилиту curl со специальным параметром, чтобы записать подробности ее взаимодействия:

$ curl —trace-ascii trace_file http://www.wikipedia.org/

примечание

В вашей версии ОС может не оказаться встроенной утилиты curl, но, если она понадобится, ее установка не должна вызвать трудностей.

Вы получите обширный отчет в формате HTML. Проигнорируйте его (или перенаправьте в устройство /dev/null) и вместо этого посмотрите только что созданный файл trace_file. При условии, что соединение оказалось успешным, первая часть этого файла, в том месте, где команда curl пытается установить TCP-соединение с сервером, должна выглядеть так:

== Info: About to connect to www.wikipedia.org port 80 (#0)

== Info: Trying 10.80.154.224... == Info: connected

Все, что вы видели до сих пор, происходит на транспортном уровне или под ним. Однако, если это соединение оказывается успешным, команда curl пытается отправить запрос («заголовок»); именно в этот момент в дело вступает прикладной уровень:

=> Send header, 167 bytes (0xa7)

0000: GET / HTTP/1.1

0010: User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS