Вполне вероятно. Уж очень неуместны бывают сетевые кабеля, когда
хочется полистать какой-нибудь online-magazin в шезлонге на балконе...
Тем более, что декларируемые 54 Mbit/sec OFTM "выливаются" во вполне
приличные 20Mbit/sec. Не говоря уже о тех случаях, когда прокладка
кабеля просто не представляется возможной или уж вовсе "лениво"
дырявить очередное шлакобетонное перекрытие. С учётом нынешней
стоимости оборудования Wi-Fi (~20$ за адаптер и ~70$ за аналог hub-а)
ответ во многих случаях очевиден: полюбопытствовать - стоит.
802.11?
С учётом продекларированной "краткости", остановимся лишь на
стандартном, в настоящее время, 802.11g (54 Mbit/sec OFTM), добавив
лишь, что адаптеры 802.11g в абсолютном большинстве случаев
поддерживают и 802.11b (11 Mbit/sec). При обсуждении защиты не удастся
также обойти вниманием 802.11х, но об этом - ниже.
А почему, собственно, - Linux? К сожалению, реализация что поддержки
устройств, что протоколов обеспечения безопасности выполнена в
благородном *-nix семействе по-разному. Не пытаясь, в соответствии с
рекомендациями К. Пруткова "объять необъятное", придётся ограничиться
Linux. Тем более, что можно констатировать: в Linux поддержка
адаптеров, для которых и не для всех-то версий m$win находятся
драйвера, решена довольно успешно.
И почему - кратко? В соответствии с вышеупомянутыми рекомендациями К.
Пруткова. В затронутой теме отдельного разговора заслуживают, как
минимум: использование NDIS-драйверов под Linux, технические аспекты
Wi-Fi, создание ip-туннелей, вопросы аутентификации и шифрования...
Но, поскольку необъятное объять всё-таки не представляется возможным,
то лучше быть кратким.
Кроме того, я вообще не сторонник конкретных рецептов: слишком
неэффективно, принимая во внимание разнообразие систем на базе Linux,
не говоря уже о nix-ах "вообще". Не нужно себя обманывать: в каждом
конкретном случае самому разбираться всё равно придётся. Да и так ли
это плохо?
"Что есть сие?"
Для простоты и всё той же краткости будем считать, что Wi-Fi - тот же
Ethernet, только без кабелей. Хотя, справедливости ради, стоило бы
вспомнить, что первые устройства разрабатывались не как "расширение",
а, скорее, как альтернатива последнего. Но, это - дела минувшие, а
нынче адаптер с точки зрения ОС представляется как сетевой, к которому
приложимы все обычные средства управления и конфигурирования "a la"
ifconfig и т.д.
При ближайшем рассмотрении, однако, различия всё-таки обнаруживаются.
Так, для соединения адаптеров Ethernet нужен, как минимум
"кросс-кабель", а лучше - hub. То, что с Wi-Fi кабель не нужен -
разумеется, но, оказывается, вместе с ним пропадает и ограничение
"только два - или hub". Несколько Wi-Fi адаптеров легко могут общаться
между собой. У них это называется "Ad-Hoc". Отметим этот режим как
"вариант", но зададимся вопросом: а зачем тогда нужен упомянутый выше
аналог hub-а? Причин несколько, и чисто физические (большая пропускная
способность и лучшая, как правило, реализация радио-тракта) при этом
не главные. Важнее то, что Access Point (AP - для краткости. Именно
так называется этот самый аналог hub-а) - ключевой участник
организации защиты сети. Режим с AP называется "Infrastructure" и
имеет средства защиты, отсутствующие для режима Ad-Hoc. К тому же,
хорошо бы иметь возможность объединить нашу сеть Wi-Fi с какой-нибудь
локальной. Опять же: AP представляется для этого более подходящим
устройством, чем IBM PC с парой сетевых карт, одна из которых - Wi-Fi.
Сложив всё необходимое для работы AP в одну коробочку, производитель
задумался: а не назначить ли её ещё и роутером/файрволом "по
совместительству"? Ведь, практически, всё необходимое уже внутри...
Так появились Wi-Fi роутеры, которые, помимо функций AP, имеют порт
для подключения модема кабельного, ADSL и прочих в этом роде,
обеспечивающих соединение с Сетью. Если учесть, что такой роутер,
практически, не дороже обычной AP, то решение имеет хорошие
маркетинговые перспективы. Знакомимся поближе...
Включаем.
"Монтаж" PCI-, USB- или PCMCI- адаптера опускаю: по-моему, такая
информация унижает читателя. Теперь нужно обеспечить поддержку данного
устройства. В Linux, как известно, это достигается загрузкой
соответствующего модуля. Как правило: даже нескольких, но "затребовав"
с помощью modprobe нужный, можно быть уверенным в загрузке и всех, ему
необходимых. Это не совсем так для PCMCI и USB: тут кое о чём нужно
позаботиться самому... Однако, о чём это я? RTFM, поскольку сейчас
речь о Wi-Fi.
Один из вариантов получения нужного "драйвера" я всё же упомяну -
ndiswrapper. Вспомним, что производитель, как правило, снабжает свой
адаптер нужным драйвером и мы даже оплачиваем его при покупке. Драйвер
этот, как правило, для m$win, и уж, наверняка, в виде двоичного файла.
Обидно, но делать нечего. Кроме как попытаться использовать этот
драйвер. Для меня это второй известный случай успешного использования
проприетарного ПО, презентуемого в двоичном виде, под Linux (первый -
кодеки в mplayer). Итак:
* берём ndiswrapper с http://ndiswrapper.sourceforge.net
* make; make install;
* инсталлируем NDIS (win) драйвер командой:
ndiswrapper -i filename.inf
где filename.inf - inf-файл из состава драйвера;
* если в ответ на ndiswrapper -l вы получите что-то вроде:
Installed ndis drivers:
driver_name driver present, hardware present
- примите поздравления;
* позаботьтесь о том, чтобы модуль ndiswrapper был загружен (а
используете вы для этого rc.modules, modules.conf или нечто из
/etc/hotplug - ваше дело). В команде загрузки модуля в качестве
параметра if_name=desired_name можно указать имя сетевого
интерфейса, "появляющегося" после загрузки модуля. Если ничего не
указывать, имя будет - wlan0;
* позаботьтесь о том, чтобы этот новый интерфейс конфигурировался
при старте: вообще-то это делается командой ifconfig, но мало ли,
какими конфигурационными файлами и программами настройки
завуалировал этот факт мейнтейнер вашего дистрибутива...
Собственно - всё. Модуль может быть и другим, разумеется, если вы,
например, - счастливый обладатель адаптера, поддерживаемого ядром
Linux, но цель прежняя - получить сетевой интерфейс, идентифицируемый
(следовательно: и - конфигурируемый) стандартными средствами.
Соединяемся.
Итак, сетевой интерфейс имеем. Опять, однако, придётся вспомнить, что
это "не совсем ethernet". Или: ethernet, но "радио". На следующем
этапе потребуются утилиты Жана Турилеса (Jean Tourrilhes),
известные как "Wireless Tools". Их немного, а нам, для начала, хватит
и вовсе двух: iwlist и iwconfig. Запускаем:
iwlist wlan0 scan
и, если в доступном эфире адаптером обнаруживаются сигналы Wi-Fi, то
на экране можно будет прочесть достаточно подробный протокол.
Источником сигнала может быть только AP или другой адаптер,
разумеется. С AP, обычно, прилагается утилита конфигурации, которой
можно воспользоваться , "достучавшись" до AP через сетевой интерфейс
или последовательный порт (уж какой у данной AP есть). А вообще-то,
какой-то сигнал AP выдаст в эфир по включению и без настройки - и
достаточно для начала. Ну, а если решитесь сразу настраивать AP, то
совет только один: не надо сразу включать средства защиты. Никакие.
В отсутствие AP сигнал нам может подать только другой адаптер
(очевидно, что в отсутвие AP, адаптеров у вас должно быть два, как
минимум). Только вот адаптер-то по умолчанию выдавать ничего не будет.
Переходим к другой утилите - iwconfig. Вообще-то iwconfig - нормальная
консольная утилита, первым параметром ожидающая имя интерфейса, а
последующими - команду с параметрами. Команд этих сравнительно немного
и с их помощью можно сделать всё необходимое (нужно только не забыть,
что большая часть команд выполняют настройку адаптера, включает же
его, фактически, только одна - essid. Получается: именно она должна
быть последней в последовательности действий).
Привычнее, однако, настройка Wi-Fi выглядела бы при загрузке: как это
вам уже, надеюсь, удалось для драйвера адаптера и сетевого интерфейса.
Трудности здесь обычные: проистекающие от разнообразия дистрибутивов.
Для начала стоит выяснить: а нет ли в вашем дистрибутиве этих самых
"Wireless Tools"? Поскольку, если есть, то, вероятнее всего,
мейнтейнер уже включил в пакет файлы настройки и скрипты, нужные для
настройки и включения Wi-Fi. Если нет, то (спасибо Жану) придётся
почитать DISTRIBUTION.TXT, являющийся частью source-пакета. Сложного
там ничего нет: всё сводится к определению нескольких параметров в
качестве переменных среды и последовательному запуску iwconfig.
Параметры все описаны (man iwconfig), а на настоящем этапе потребуются
совсем не многие:
* ESSID (extended network name) - самый главный параметр. Имя сети.
Разумеется ESSID у устройств, связь между которыми нужно
установить, должен быть одинаковым - будь то AP или адаптер;
* MODE (Operation mode). При наличии AP - "Managed", в отсутствие -
"Ad-Hoc". В моде "Managed" адаптер, не обнаружив при старте сети с
ESSID, таким же, как его собственный, выключается. В моде "Ad-Hoc"
- работает постоянно: изображает из себя AP;
* CHANNEL - номер канала. Также один для всех клиентов создаваемой
сети. Если iwlist сообщил вам о наличии в эфире нескольких сетей,
занимающих, соответсвенно, несколько каналов, я думаю, вы
догадаетесь выбрать для своей - незанятый;
* RATE можно оставить "auto", в надежде, что будет выбрана
максимальная скорость (что практически всегда соответствует
действительности);
К остальным параметрам, включая вскоре потребующийся нам "Encryption
key", вернёмся чуть позднее.
iwconfig без параметров всегда покажет состояние интерфейсов Wi-Fi.
После выключения настроенного адаптера (аппаратно ли, из-за
"пропадания" AP в режиме Infrastructure) заново включить его можно
командой:
iwconfig wlan0 essid your_essid
где wlan0 - имя сетевого интерфейса, а your_essid - имя вашей сети.
Пока - всё. Итого, на данном этапе имеем:
* интерфейс wlan0, появившийся после загрузки драйвера;
* его сетевые настройки, выполненные обычным способом (dhcpcd,
ifconfig, route и т.д.);
* его специфические Wi-Fi настройки, выполненные iwconfig. Поскольку
эти настройки уже включают в себя данные об обнаруженной нами в
эфире с помощью iwlist сети, то результатом, трёх
вышеперечисленных пунктов должен быть, как минимум, успешный ping
до AP или другого адаптера.
Надеюсь, так оно и есть. Ну, а есть ping - получите и всё остальное. В
соответствии с наличием в вашей сети сетевых сервисов и настроек
маршрутизации. К Wi-Fi это отношения уже не имеет.
Защищаемся
Способы защиты передаваемой информации стали неотъемлемой частью
стандарта 802.11 по вполне очевидной причине: в иллюзию защищённости
кабеля ethernet пользовател поверит намного охотнее, чем в
защищённость данных, передаваемых через эфир. Правильно, в общем-то.
Хотя более незащищённой сети, чем сегмент ethernet, охватывающий жилой
дом или бизнес-центр, просто не бывает: не нужно быть хакером, чтобы
знать о существовании у ethernet-адаптера "promiscuous mode", а ПО
перехвата и парсинга пакетов даже писать не придётся: "бери - не
хочу". Ещё один, достойный сожаления, пример - домашний компьютер,
подключённый к Интернет со всеми мыслимыми и немыслимыми клиентами (в
терминологии m$win), запущенными сервисами и открытыми на этом
соединениипортами. Да мало ли ещё опасностей, намного более
неожиданных, чем "перехват" пакета Wi-Fi, ожидает неискушённого
пользователя в мире ip?... Ну, да это его проблемы. Вернёмся к 802.11.
Поскольку инженеры из IEEE, разрабатывая протокол, ориентировались
всё-таки не на "самоделкиных", расставляющих hub-ы в открытых
помещениях и не на win'98, нежданно-негаданно подключенную к Интернет,
то о защите они были обязаны задумываться с самого начала. Однако:
недостаточно, как вскоре выяснилось. Так называемый WEP (wired
equivalent privacy), использующий алгоритм шифрованиф RC4 при длине
ключа 40/104 бит очень скоро стал материалом для хрестоматийного
примера взлома защиты. Wi-Fi Alliance опять бросился дорабатывать
протокол (работа закончена в июле 2004-го), параллельно предлагая
временные альтернативы, такие как WPA (Wi-Fi Protected Access).
Проблема заключается в том, что новый стандарт должен стать правилом
для множества производителей, поставляющих аппаратуру Wi-Fi.
Перепрошивка потребуется десяткам миллионов уже существующих
устройств, а тем, для которых перепрошивка невозможна, просто
потребуется замена. По-моему, ребята немного "влипли"...
Что же, откажемся от таких привлекательные возможностей, пока
производители не защитят Wi-Fi должным образом? Не думаю. Во-первых,
возможность взлома ещё не означает его высокой вероятности. И PGP
можно взломать, только для этого нужны довольно приличные
вычислительные мощности. И то, что "легко" для ФБР, окажется "не по
зубам" соседскому "хакеру". Нужно только прикинуть, кому может
понадобиться ваша сеть и для чего. Так что, предлагаю оценить арсенал
средств защиты и решить, что стоит использовать, а что - нет. Итак,
имеем:
* вышеупомянутый WEP, поддерживаемый всеми устройствами Wi-Fi. Хоть
его и "ломают в порядке демонстрации", а использовать - нужно.
Особенно, если это единственно доступный аппаратно реализованный
способ шифрования (а для Ad-Hoc это так и есть). Разумеется,
предпочтительнее 104 битный ключ, почаще меняйте его, не держите
канал включённым без нужды - и, вероятнее всего, что с прецедентом
взлома столкнуться вам придётся не скоро.
При работе с iwconfig ключ шифрования помещается обычно в
переменную KEY ("Encryption key"). Ключ выражается обычно в
HEX-символах, выражению в ascii предшествует префикс s:. Если
ключей несколько, то все они перечисляются в одной переменной,
разделяемые пробелами, номерами ключа (в квадратных скобках) и
ключевым словом key;
* при использовании AP, запретите ей передавать essid
широковещательными посылками. Не Бог весть какая защита, но
случайно оказавшийся в зоне приёма адаптер автоматически в сеть,
по крайней мере, уже не войдёт;
* при наличии такой возможности - включите в AP контроль
MAC-адресов: пусть она обслуживает только "своих". Конечно, MAC
можно "выудить" из перехваченного пакета и подставить в свой...
будет кто-то из ваших соседей этим будет заниматься? Вам -
решать...
* WPA, тот самый продукт группы I (Security), занимавшейся
усовершенствованием механизмов защиты в рамках 802.11. Наверное,
не бывает ничего окончательно совершенного, но на настоящий момент
считается, что аутентификация в сочетании с алгоритмом шифрования
AES (это, правда, уже WPA2), обеспечивают достаточную защиту
Wi-Fi. Если оставаться в рамках продекларированной краткости, то
необходимым минимумом знаний по этому поводу будет только то, что
WPA - компромисс между существующим оборудованием и
усовершенствованными алгоритмами защиты. И компромисс этот состоит
в том, аппаратура по-прежнему использует RC4-шифрование, только
вот ключ к каждому пакету генерируется свой. Ключ этот может
генерироваться внешним сервером аутентификации (RADIUS, как
правило. Проприетарный сервер. Версия его входит в M$ IIS, если не
ошибаюсь), или - самими субъектами обмена. В соответсвии с этим
IEEE 802.1X определяет "WPA-Enterprise"(WPA with EAP) и
"WPA-Personal"(WPA-PSK) режимы. Лучшее известное мне описание
работы WPA читайте в составе wpa_supplicant. Последний,
кстати, реализовани и для m$win;
* последняя группа средств защиты хоть и не связана с Wi-Fi
непосредственно, но расценивается многими как наиболее
перспективная. Речь идёт о защите ip пакетов вне зависимости от
среды передачи. Ну, в самом деле: какая вам разница,
осуществляется передача в эфире, посредством витой пары или
оптоволоконного кабеля, если последние физически вами всё равно не
контролируются? Вполне естественно раздельно рассматривать
аутентификацию, шифрование и собственно транспорт. Оставив, таким
образом, "в ведении" Wi-Fi только голый TCP/IP - с единственно
обрабатываемым портом к какому-нубудь хорошо защищённому сервису,
предоставим последнему и аутентификацию, и шифрование в рамках
сеанса. Что будет толку от взлома WEP, если его результатом станет
лишь приглашение аутентифицироваться, да ещё и зашифрованное,
свят-свят... Угадываются всякие туннели, VPN-ы и т.п. Выбор
достаточно широк.
* проприетарные pptp и L2PT. Сервера отношения к Linux не имеют, но
почему бы и не быть их клиентами?
* Vtune
* CIPE
* SecurePoint & VPN - если вам требуется законченное решение в
виде iso-образа, мегабайт эдак на двести с лишним.
Наверняка существуют и ещё. Почему бы нет, если под Linux возможно
создание виртуальных туннелей хоть для фреймов ethernet, хоть для
ip-пакетов. "Твори, выдумывай, пробуй". Вот только необходимость иметь
хотя бы клиентов для m$win, ограничивает это разнообразие. Что ни
говори, а при обсуждении вопросов коммуникаций, игнорировать
существование win-хостов глупо...
Короче: выбрать есть из чего. И выбрать - нужно. Даже при полном
пренебрежении к вопросам защиты не стоит всё-таки уподобляться
оператору кабельных сетей, который вместо прокладки кабеля предлагает
применить Wi-Fi (за "не слабые", кстати, $200). И только месяц спустя
вы обнаруживаете, что к установленной на лестничной площадке AP ЛЮБОЙ
Wi-Fi клиент подключается АВТОМАТИЧЕСКИ. Оператору-то всё равно:
трафик оплатит подписавший договор, а вам?
Практикум
Ну, и несколько примеров...
* Пара компьютеров в квартире с периодической потребностью в обмене
по http, ftp, smb.
Мода - Ad-Hoc. Защита - WEP. В дополнение можно защитить сервисы
(https для http, запрет anonimous + хорошие пароли для ftp,
исключительно парольный доступ к smb-ресурам).
* Та же пара, но один из хостов имеет выход в Интернет, что
означает, как правило, потребность в почти постоянном соединении.
Поскольку в Ad-Hoc помимо WEP и защищаться-то особенно нечем, то
лучше на компьютере, имеющем выход в Интернет, запустить
vpn-сервер: pptp, если это ХР, CIPE или VTun, если это Linux.
Таким образом, в сравнительно "открытом" режиме (WEP, кстати,
стоит оставить) происходит только открытие сеанса связи с
vpn-сервером. Далее трафик шифруется по правилам созданного
туннеля.
* Несколько компьютеров в квартире и одно ADSL или кабельное
подключение к Интернет.
Infrastructure вместо Ad-Hoc, разумеется. AP с функциями роутера.
WEP, запрещение трансляции essid, контроль MAC-адресов - как
минимум. WPA-PSK - очень желательно. Хотя для этого и потребуется
позаботиться о наличии wpa_supplicant на всех хостах. Независимо
от ОС.
* Удалённое подразделение.
AP в основном офисе, клиенты - в удалённом подразделении. WEP,
запрещение трансляции essid, контроль MAC-адресов, WPA-PSK.
Вариант: создание туннеля между одним из компьютеров основного
офиса и одним из компьютеров подразделения. В этом случае можно
попытаться обойтись без AP, защищённость хороша настолько,
насколько защищён туннель. Существенным недостатком становится
обязательное включение упомянутой пары компьютеров для обеспечения
связи между офисом и подразделением и необходимость создания
кабельной сети в подразделении. Ещё вариант: связь между подсетями
офиса и подразделения обеспечивает пара AP в режиме WDS (Wireless
Distribution System). Если считать защищённость уровня WPA-PSK
достаточной и смириться с необходимостью монтажа ethernet-сегмента
в подразделении, получается довольно экономично.
* Wi-Fi, как альтернатива ethernet для ЛВС.
Теоретически - возможно, если хватит пропускной способности:
20Мбит всё же меньше 100-та, а с увеличением количества хостов
полоса пропускания сети ещё уменьшится... Очевидно, в данном
случае уже не обойтись без выделенного севера идентификации, Не
уверен также, что администрирование такой сети будет простым:
скорее, забот администратору прибавится. Предпочтительнее выглядит
простая Wi-Fi сеть, но жёстко контролируемый доступ к ресурсам:
эффективные механизмы идентификации, шифрование создаваемых между
клиентами и сервером туннелей... Принимая во внимание опыт
предоставления сервисов в Интернет, такая реализация
представляется лично мне более жизненной. Поживём - увидим.
Приведенные примеры - лишь иллюстрация того факта, что имеется
довольно много способов применить Wi-Fi с пользой. Не исключено, что
для кого-нибудь - уже сейчас.
Часть 2.
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 и запуск при загрузке в режиме демона:
Остальные (преимущественно прекомпилированные, с загрузкой в стиле
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 ещё не скоро станет
"само собой разумеющимся", любитель "поковыряться" в ПО увидит в этом
захватывающее развлечение. Ну, чем хуже преферанса (не говоря уже о
шахматах)?
Так вот, для вышеупомянутого ноутбука потребовалось:
* инсталлировать NDIS (win) драйвер командой
ndiswrapper -i your_driver.inf:
* обеспечить его загрузку с обязательной привязкой к eth1 (eth0 --
обычный ethernet). Например, командой
modprobe ndiswrapper if_name=eth1 в файле /etc/rc.local;
* наличные средства конфигурирования wi-fi сети никак не позволяли
перевести адаптер в режим Ad-Hoc (а именно это требовалось). В
конечном счёте, пришлось вручную отредактировать файл конфигурации
сети (/etc/network/interfaces). Фрагмент, описывающий wi-fi
адаптер выглядел, в конечном счёте, следующим образом:
* поскольку wi-fi адаптер включался аппаратными средствами только по
мере необходимости (а загрузка происходила при выключенном
адаптере как правило), то после включения требовалось установить
wi-fi соединение. Например, командой /sbin/iwconfig
eth1 essid *your_essid*;
* для удобства непривилегированного пользователя потребовалось
отредактировать /etc/sudoers (ну, не заставлять же его вводить
пароль каждый раз при включении wi-fi?) и поместить иконку запуска
на какую-нибудь из панелей/
Если вы ещё не забыли, то на сей раз мы говорим об AP и,
соответственно, о режиме Managed, а не Ad-Hoc. Тогда соответствующий
фрагмент /etc/network/interfaces булет выглядеть как:
* 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 с содержимым:
Наибольшим же недостатком NetworkManager, является, на мой взгляд то,
что он не обеспечивает соединение в режиме Ad Hoc. И, хотя, по оценкам
экпертов этот режим используют менее 10% провайдеров wi-fi сервиса,
лишиться в аэропорту доступа к Сети только потому, что сеть зала
ожидания попала в эти 10% - обидно.
Проблема известна. Желающие могут даже воспользоваться [77]патчем,
предлагаемым Роберотом Лав (Robert Love) и, будем надеяться, что в
очередной версии NetworkManager соединение в режиме Ad Hoc не будет
проблемой.
А пока NetworkManager не вполне соответствует нашим пожеланиям для
запрета его работы (без деинсталляции) нужно сначала остановить его
командами:
Выводы из этого всего достаточно обычны при оценке Linux-ПО:
* функциональность базового ПО находится на достаточно высоком
уровне;
* при наличии желания и определённой подготовки, достижение
положительного результата вполне вероятно;
* некоторые передовые разработки содержат инновационные моменты,
неизвестные доселе в распространяемом проприетарном ПО.
Автоматическое переключение сетей NetworkManager - как раз один
из них;
* дружественность пользовательского ПО оставляет желать лучшего. Как
и всегда, впрочем, уже хотя бы потому, что достижение этой самой
"дружественности" никогда не является приоритетом для
разработчика, а обратная связь в форме оплаты за получаемый
продукт по определению отсутствует.
Последнее, кстати, не означает невозможности появления как бесплатных,
так и коммерческих продуктов, использующих идеи или конкретные
разработки, зародившиеся в мире open source.
1168 Прочтений • [Wi-Fi в Linux. Краткий курс (wifi wireless hardware driver linux)] [08.05.2012] [Комментариев: 0]
Vova
