Intro
Нижеследующее можно считать продолжением "Краткого курса" (Wi-Fi. Linux. Краткий курс), написанного полтора года назад. Поэтому, во-первых, не буду повторяться и, во-вторых, постараюсь остаться в рамках продекларированной краткости.
Итак, исходим из того, что wi-fi адаптер мы подключили, Wireless Tools Жана Турилеса (Jean Tourrilhes) пользоваться научились и даже связали два компьютера в режиме Ad-Hoc. Используемая защита при этом — WEP, поскольку никакой другой в данном режиме и не бывает. Теперь предположим, что то ли Access Point-ы резко подешевели, то ли благосостояние повысилось, то ли очередное "окабеление" в офисе решено заменить переходом на wi-fi — мало ли. Но дальнейшие наши упражнения будут касаться этих самых AP.
WPA
И первое преимущество, которое мы получаем вместе с AP, это то, что можем использовать WPA (Wi-Fi Protected Access) — усовершенствованный протокол безопасности, пришедший на смену WEP (Wired Equivalent Privacy). Если быть точным, то этих WPA даже два: WPA и WPA2 (промежуточная и окончательная реализации стандарта IEEE 802.11i). Говорить кратко о методах защиты — неблагодарное занятие. В рамках "Краткого курса" достаточно знать, что всё крутится вокруг того, как шифровать трафик и как генерировать для этого шифрования ключи. Выбор будут ограничивать AP, которая, как и я "не может объять необъятное" и всегда имеет конечную функциональность, и ваши ресурсы, которые могут позволить иметь независимые генераторы ключей и сервера аутентификации или — нет.
Если с AP мы в общем-то ничего особенного сделать не можем (рассчитывать на upgrade только что купленного устройства, как правило, не приходится), то с компьютерами — просто обязаны, поскольку далеко не все дистрибутивы Linux включают в себя поддержку WPA по умолчанию. Пакет, который нам нужен уже упоминался: wpa_supplicant. А будете вы его собирать сами или воспользуетесь прекомпилированным — дело ваше.
Дальнейшие действия сводятся к настройке wpa_supplicant, разнообразной настолько, насколько разнообразны методы защиты wi-fi соединения. К счастью, пакет включает в себя подробную документацию и примеры, практически полностью вышеупомянутое разнообразие покрывающие. И всё бы хорошо, если бы не разнообразие дистрибутивов. Часть дистрибутивов (преимущественно sorce based, c BSD-стилем загрузки) используют wpa_supplicant примерно так, как рекомендуют авторы (конфигурационный файл /etc/wpa_supplicant.conf и запуск при загрузке в режиме демона: wpa_supplicant -eth0 -c/etc/wpa_supplicant.conf -d). Остальные (преимущественно прекомпилированные, с загрузкой в стиле Sys V) используют, как правило, свои конфигурационные файлы и скрипты, запускающие, в свою очередь wpa_supplicant и wpa_cli (консольный фронтенд к wpa_supplicant).
При всей симпатии к дистрибутивам sorce based и нежелании изучать причудливую логику создателей дистрибутивов прекомпилированных, не могу не заметить, что Linux уже популярен настолько, что программисты и администраторы, для которых знание "почему и как" — обязанность, нынче явно в меньшинстве. Так что придётся и мне "отступить от принципов" и иллюстрировать сказанное на примере Ubuntu (6.10 LTS Dapper).
Африка...
Конечно, хорошо бы такому "дружественному к пользователю" дистрибутиву и настраиваться без его [пользователя] участия. Тогда и говорить было бы не о чем, но... Первый же ноутбук с Ubuntu, попавший ко мне для настройки wi-fi, оказался к автоконфигурированию этого самого wi-fi не способным. Вот возможные причины, кратко:
- драйвер адаптера (он же модуль ядра) может просто отсутствовать;
- пока linux находится в состоянии становления (а это его перманентное состояние), для одного и того же адаптера может существовать несколько драйверов (например: bcm43xx и ndiswrapper для адаптеров от BroadCom) и рассчитывать на автоматический выбор одного из них не приходится. Я уже не говорю о том, что для осуществления этого выбора потребуются минимальные знания по поводу загрузки модулей;
- адаптеры wi-fi часто (у ноутбуков — как правило. Энергосбережение, понимаете ли...) имеют собственные средства включения/выключения, которые почти никогда универсальным драйвером не обслуживаются;
- не все драйверы поддерживаются wpa_supplicant. Не исключено, что выбор, осуществлённый на предыдущем этапе, придётся пересмотреть, когда дело дойдёт до WPA;
- большое разнообразие протоколов как обмена, так и защиты соединения.
Трудности на этом не исчерпываются (на очереди поведение при "засыпании", множественность присутствующих сетей и т.д.), но и перечисленного достаточно. Приходится признать, что это тот случай, когда открытых спецификаций производителей особенно не хватает. Но, "тут уж — что уж"...
Оптимистический взгляд на происходящее состоит, однако, в том, что хотя для "простого пользователя" wi-fi под Linux ещё не скоро станет "само собой разумеющимся", любитель "поковыряться" в ПО увидит в этом захватывающее развлечение. Ну, чем хуже преферанса (не говоря уже о шахматах)?
Так вот, для вышеупомянутого ноутбука потребовалось:
Если вы ещё не забыли, то на сей раз мы говорим об AP и, соответственно, о режиме Managed, а не Ad-Hoc. Тогда соответствующий фрагмент /etc/network/interfaces булет выглядеть как:
iface eth1 inet dhcp
wpa-driver wext
wpa-ssid *your_wpa_essid*
wpa-ap-scan 1
wpa-proto WPA
wpa-pairwise TKIP
wpa-group TKIP
wpa-key-mgmt WPA-PSK
wpa-psk *your_HEX_passcode*
Как нетрудно заметить, на сей раз используется dhcp, входящий в состав AP. А вот что означают параметры, передаваемые wpa_supplicant:
- wpa-driver wext — стандартный драйвер, использующийся обычно с ndiswrapper;
- wpa-ap-scan 1 — "1" — с передачей в эфир ESSID, "2" без передачи;
- wpa-proto WPA — протокол шифрования. "RSN" — WPA(2), "WPA" — WPA(1);
- wpa-pairwise TKIP и wpa-group TKIP — CCMP" для AES WPA(2), "TKIP" для TKIP WPA(1);
- wpa-key-mgmt WPA-PSK — тип аутентификации. "WPA-PSK" — разделяемые ключи, "WPA-EAP" выделенный сервер аутентификации;
- wpa-psk ХХХХ...ХХХХ — ключ PSK, получаемый, как вывод команды wpa_passphrase 'your_essid' 'your_ascii_key'
Поскольку wpa_supplicant — демон (в отличие от утилит из состава Wireless Tools), то трудности с асинхронным аппаратным включением адаптера снимаются: загрузка с выключенным адаптером проходит нормально, аппаратное включение инициирует получение ip-адреса, выделяемого DHCP сервером вне зависимости от того происходила загрузка с включённым или выключенным адаптером. Я бы сказал, что такой вариант — наиболее близкий аналог поведения ОС семейства MS Windows: настраиваем "ручками" — пользуемся "полуавтоматом" (переключение между сетями — вручную).
А — попроще?
Можно. Даже — нужно. Потому как затем и wi-fi у ноутбука, чтобы можно было им воспользоваться дома, на работе, в аэропорту, гостинице и т.п. Создавать соединение описанным выше способом где-нибудь в интернет-кафе выглядит явным извращением. И попытки упростить, если не полностью автоматизировать этот процесс ведутся.
Прежде всего, в рамках "unix-way" напрашивается создание надстроек над безукоризненными, в общем-то, в своём качестве Wireless Tools и wpa_supplicant. По этому пути пошли создатели wifi-radar. Python и Gtk-2 — вполне подходящие для этой задачи инструменты. Мне, правда, пришлось немного повозиться, пока я добился от wifi-radar работоспособности, но — возможно. Знай, следи за "эфиром" и подключайся к наиболее подходящей в данный момент сети. Некоторые трудности, однако, остаются. Всё то же асинхронное аппаратное включение, например. Есть, одним словом, над чем работать.
И — работают. В недрах Gnome разрабатывается так называемый NetworkManager — демон, задачей которого является поддержание активного сетевого соединения при любых условиях. NetworkManager использует wpa_supplicant, но уже не использует Wireless Tools. Демон этот ориентирован исключительно на десктопы (на ноутбуки — прежде всего), интегрирован с hal и dbus (что не позволяет ему работать в "чистой" консоли), и, вообще... специфичен. Не unix-boy, я бы сказал. Но и задача — специфична. Приходится считаться.
NetworkManager настолько специфичен, что обычной инсталляцией отделаться не удастся. Загрузив пакет (а заодно и его фронтенды: апплет network-manager-gnome для Gnome или knetworkmanager для KDE), потребуется:
- удалить все конфигурации из /etc/network/interfaces;
- создать файл /etc/default/wpasupplicant и внести в него строку: ENABLED=0;
- выполнить sudo /etc/init.d/dbus restart;
- загрузить апплет командой nm-applet;
- если после этого иконка NetworkManager не появится на панели, то, очевидно, на панели отсутствует "область уведомления" (Notification Area).
Интеграция с hal/dbus не всегда обеспечивает желаемый результат. Так, вполне может оказаться, что, после загрузки с аппаратно выключенным адаптером, NetworkManager ни одной Wireless Network вам не предложит: сколько этот адаптер ни включай/выключай. Разумеется, sudo /etc/init.d/dbus restart спасает положение, но это значит, что и при наличии NetworkManager опять потребуется иконка-запускатель и редактирование /etc/sudoers (рано или поздно вам надоест вводить пароль при каждом включении сети).
Несколько огорчают бессмысленные попытки поиска "пропавшей" сети, после того, как вы аппаратно выключаете адаптер, но продолжается это сравнительно недолго. При повторном включении адаптера соединение автоматически не восстанавливается (как можно было бы ожидать): приходится "вручную" выбирать нужную сеть. Из этого можно сделать вывод, что аппаратное включение адаптера не является событием для hal а, следовательно, и dbus нечего передавать апплету NetworkManager-а. Подход wpa_supplicant (периодической опрос) оказался в данном случае более эффективным.
Ещё одна неприятная мелочь — это то, что ключ доступа к сети nm-applet хранит в так называемых "брелоках" (keyrings), для доступа к которым тоже нужно пройти идентификацию. Так что даже избавившись от запроса пароля на выполнение необходимого каждый раз после аппаратного выключения адаптера (sudo /etc/init.d/dbus restart), По крайней мере один раз (при первом включении) потребуется идентифицироваться для доступа к своему keyrings. Справедливости ради отмечу, что в следующей версии Ubuntu (7.04) уже имеется достаточно известный пакет pam_keyrings (известный в Debian и его клонах как libpam-keyring), который автоматически выдаёт пароль регистрации пользователя в ответ на запрос идентификации к keyring. Для Ubuntu Dapper (6.10) можно самому странслировать pam_keyrings, но только исходники нужно взять версии 0.8.
На этом этапе можно попытаться сохранять работоспособность NetworkManager при переходе в suspend или hibernate. Для этого нужно создать файл /etc/acpi/suspend.d/07-network-manager.sh с содержимым:
#!/bin/sh
/etc/dbus-1/event.d/25NetworkManager stop
и файл
/etc/acpi/resume.d/63-network-manager.sh с содержимым:
#!/bin/sh
/etc/dbus-1/event.d/25NetworkManager start
Наибольшим же недостатком NetworkManager, является, на мой взгляд то, что он не обеспечивает соединение в режиме Ad Hoc. И, хотя, по оценкам экпертов этот режим используют менее 10% провайдеров wi-fi сервиса, лишиться в аэропорту доступа к Сети только потому, что сеть зала ожидания попала в эти 10% — обидно.
Проблема известна. Желающие могут даже воспользоваться патчем, предлагаемым Роберотом Лав (Robert Love) и, будем надеяться, что в очередной версии NetworkManager соединение в режиме Ad Hoc не будет проблемой.
А пока NetworkManager не вполне соответствует нашим пожеланиям для запрета его работы (без деинсталляции) нужно сначала остановить его командами:
sudo /etc/dbus-1/event.d/26NetworkManagerDispatcher stop
sudo /etc/dbus-1/event.d/25NetworkManager stop
А затем создать два файла:
/etc/default/NetworkManager
/etc/default/NetworkManagerDispatcher
Поместив в них по одному слову:
exit.
Coda
Выводы из этого всего достаточно обычны при оценке Linux-ПО:
- функциональность базового ПО находится на достаточно высоком уровне;
- при наличии желания и определённой подготовки, достижение положительного результата вполне вероятно;
- некоторые передовые разработки содержат инновационные моменты, неизвестные доселе в распространяемом проприетарном ПО. Автоматическое переключение сетей NetworkManager — как раз один из них;
- дружественность пользовательского ПО оставляет желать лучшего. Как и всегда, впрочем, уже хотя бы потому, что достижение этой самой "дружественности" никогда не является приоритетом для разработчика, а обратная связь в форме оплаты за получаемый продукт по определению отсутствует.
Последнее, кстати, не означает невозможности появления как бесплатных, так и коммерческих продуктов, использующих идеи или конкретные разработки, зародившиеся в мире open source.
Автор: Владимир Попов
Источник: www.posix.ru