Wi-Fi под Linux - краткий курс

"а оно вам надо?"

Вполне вероятно. Уж очень неуместны бывают сетевые кабели, когда хочется полистать какой-нибудь online-magazine в шезлонге на балконе... Тем более, что декларируемые 54 Mbit/sec "выливаются" во вполне приличные 20Mbit/sec. Не говоря уже о тех случаях, когда прокладка кабеля просто не представляется возможной или уж вовсе лениво дырявить очередное шлакобетонное перекрытие. С учетом нынешней стоимости оборудования Wi-Fi (~$20 за адаптер и ~$70 за аналог hub’а) ответ во многих случаях очевиден: полюбопытствовать - стоит.

802.11?

С учетом продекларированной "краткости", остановимся лишь на стандартном, в настоящее время, 802.11g (54 Mbit/sec), добавив лишь, что адаптеры 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, только без кабелей. Хотя, справедливости ради, стоило бы вспомнить, что первые устройства разрабатывались не как "расширение", а, скорее, как альтернатива последнего. Но, это - дела минувшие, а нынче адаптер с точки зрения ОС представляется как сетевой, к которому приложимы все обычные средства управления и конфигурирования вроде ifconfig и т.д.
При ближайшем рассмотрении, однако, различия все-таки обнаруживаются. Так, для соединения адаптеров Ethernet нужен, как минимум "кросс-кабель", а лучше – концентратор/коммутатор. То, что Wi-Fi кабель не нужен – само собой разумеется, но, оказывается, вместе с этим пропадает и ограничение "только два - или концентратор". Несколько Wi-Fi адаптеров легко могут общаться между собой. У них это называется Ad-Hoc. Отметим этот режим как "вариант", но зададимся вопросом: а зачем тогда нужен упомянутый выше аналог концентратора? Причин несколько, и чисто физические (большая пропускная способность и лучшая, как правило, реализация радиотракта) при этом не главные. Важнее то, что Access Point (AP - для краткости. Именно так называется этот самый аналог концентратора/коммутатора) - ключевой участник организации защиты сети. Режим с AP называется "Infrastructure" и имеет средства защиты, отсутствующие для режима Ad-Hoc. К тому же, хорошо бы иметь возможность объединить нашу сеть Wi-Fi с какой-нибудь локальной. Опять же: AP представляется для этого более подходящим устройством, чем IBM PC с парой сетевых карт, одна из которых - Wi-Fi.
Сложив все необходимое для работы AP в одну коробочку, производитель задумался: а не назначить ли ее еще и маршрутизатором/файрволлом по совместительству? Ведь, практически, все необходимое уже внутри... Так появились Wi-Fi-маршрутизаторы, которые, помимо функций AP, имеют порт для подключения кабельного модема, ADSL и прочих подобных вещей, обеспечивающих соединение с Сетью. Если учесть, что такой маршрутизатор практически не дороже обычной AP, то решение имеет хорошие маркетинговые перспективы. Знакомимся поближе...

включаем

"Монтаж" PCI-, USB- или PCMCIA- адаптера опускаю: по-моему, такая информация унижает читателя. Теперь нужно обеспечить поддержку данного устройства. В Linux, как известно, это достигается загрузкой соответствующего модуля. Как правило даже нескольких, но затребовав с помощью modprobe нужный, можно быть уверенным в загрузке и всех ему необходимых. Это не совсем так для PCMCIA и 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", в надежде, что будет выбрана максимальная скорость (что практически всегда соответствует действительности). К остальным параметрам вернемся чуть позднее.
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, охватывающий жилой дом или бизнес-центр, просто не бывает.

Поскольку инженеры из IEEE, разрабатывая протокол, ориентировались все-таки не на "самоделкиных", расставляющих хабы в открытых помещениях и не на win98, нежданно-негаданно подключенную к Интернет, то о защите они были обязаны задумываться с самого начала. Однако думали недостаточно, как вскоре выяснилось. Протокол 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-шифрование, только вот ключ к каждому пакету генерируется свой. Ключ этот может генерироваться внешним сервером аутентификации, или - самими субъектами обмена. В соответствии с этим 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;
- Vtune;
- CIPE;
- SecurePoint & VPN.

Наверняка существуют и другие. Почему бы нет, если под Linux возможно создание виртуальных туннелей хоть для фреймов Ethernet, хоть для IP- пакетов. "Твори, выдумывай, пробуй". Вот только необходимость иметь хотя бы клиентов для m$win, ограничивает это разнообразие. Что ни говори, а при обсуждении вопросов коммуникаций, игнорировать существование win-хостов глупо...

Короче: выбрать есть из чего. И выбрать - нужно. Даже при полном пренебрежении к вопросам защиты не стоит все-таки уподобляться оператору кабельных сетей, который вместо прокладки кабеля предлагает применить Wi-Fi. И только месяц спустя вы обнаруживаете, что к установленной на лестничной площадке AP ЛЮБОЙ Wi-Fi клиент подключается АВТОМАТИЧЕСКИ. Оператору-то все равно: трафик оплатит подписавший договор, а вам?

практикум

Ну, и напоследок несколько примеров.

Пример 1.Пара компьютеров в квартире с периодической потребностью в обмене по HTTP, FTP, SMB.
Режим - Ad-Hoc. Защита - WEP. В дополнение можно защитить сервисы: HTTPS для HTTP, запрет anonymous + хорошие пароли для FTP, исключительно парольный доступ к SMB-ресурсам.

Пример 2.Та же пара, но один из хостов имеет выход в Интернет, что означает, как правило, потребность в почти постоянном соединении. Поскольку в Ad-Hoc помимо WEP и защищаться-то особенно нечем, то лучше на компьютере, имеющем выход в Интернет, запустить VPN-сервер. Таким образом, в сравнительно открытом режиме (WEP, кстати, стоит оставить) происходит только открытие сеанса связи с VPN-сервером. Далее трафик шифруется по правилам созданного туннеля.

Пример 3.Несколько компьютеров в квартире и одно ADSL или кабельное подключение к Интернет.
Infrastructure вместо Ad-Hoc, разумеется. AP с функциями роутера. WEP, запрещение трансляции essid, контроль MAC-адресов - как минимум. WPA-PSK - очень желательно. Хотя для этого и потребуется позаботиться о наличии поддержки WPA на всех хостах.

Пример 4.Удаленное подразделение.
AP в основном офисе, клиенты - в удаленном подразделении. WEP, запрещение трансляции essid, контроль MAC-адресов, WPA-PSK. Вариант: создание туннеля между одним из компьютеров основного офиса и одним из компьютеров подразделения. В этом случае можно попытаться обойтись без AP, защищенность хороша настолько, насколько защищен туннель. Существенным недостатком становится обязательное включение упомянутой пары компьютеров для обеспечения связи между офисом и подразделением и необходимость создания кабельной сети в подразделении. Еще вариант: связь между подсетями офиса и подразделения обеспечивает пара AP в режиме WDS (Wireless Distribution System). Если считать защищенность уровня WPA-PSK достаточной и смириться с необходимостью монтажа Ethernet-сегмента в подразделении, получается довольно экономично.

Пример 5.Wi-Fi, как альтернатива Ethernet для ЛВС.
Теоретически - возможно, если хватит пропускной способности: 20 Мбит все же меньше 100, а с увеличением количества хостов полоса пропускания сети еще уменьшится... Очевидно, в данном случае уже не обойтись без выделенного севера идентификации, Не уверен также, что администрирование такой сети будет простым, скорее, забот администратору даже прибавится. Предпочтительнее выглядит простая Wi-Fi сеть, но жестко контролируемый доступ к ресурсам: эффективные механизмы идентификации, шифрование создаваемых между клиентами и сервером туннелей... Принимая во внимание опыт предоставления сервисов в Интернет, такая реализация представляется лично мне более жизненной. Поживем - увидим.

Приведенные примеры - лишь иллюстрация того факта, что имеется довольно много способов применить Wi-Fi с пользой. Не исключено, что для кого- нибудь - уже сейчас.



Владимир Попов, posix.ru.