Wi-Fi все обо всем. Linux. Краткий курс.

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

Вполне вероятно. Уж очень неуместны бывают сетевые кабеля, когда хочется полистать какой-нибудь 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 с пользой. Не исключено, что для кого-нибудь - уже сейчас.

(С) Владимир Попов, взято тут: citkit.ru

 

Кстати у нас на работе вай фай постоянно сбоит. Когда работаю сварщики, особенно=)
А если серьезно, опиши плс способы заДОСивания каналов связт вай фай. Что то подобное, кстати, описано в августовском номере ксакепа. Если возьмещься, я тебе скину инфу!

 

Ещё можно рассмотреть вопрос с Linux'ом, установленным не со стороны пользователя, а на самой точке доступа/wi-fi роутере.
Установка Линукса осуществляется перепрошивкой.
Список поддерживаемых устройств здесь, сами прошивки скачивать с этого же сайта.
После перепрошивки первым делом подключаемся телнетом к точке, устанавливаем пароль командой passwd (устанавливается пароль для root), после чего перезагружаем точку и подключаемся к ней по ssh.
Изначально все интерфейсы завязаны в br0 (bridge) для максимальной доступности. Для нормальной работы достаточно указать, кому через что работать.
По умолчанию проводное соединие eth0, беспроводное eth1 (что странно, но факт ). Сделать это можно командами nvram set ...(например nvram set wan_ifname=eth0 ; nvram set lan_ifname=eth1 ). Командой nvram show можно просмотреть весь список настроек, соответственно увидеть что ещё надо поменять (ip-адреса, шифрование и т.д.). Настройки wl_... отвечают соответственно за беспроводное соединение. Перед каждой перезагрузкой для сохранения изменений (записи их в память) надо вводить команду nvram commit.
В результате кроме обычной настроки можно повысить мощность передатчика и даже поменять всякие там тайминги и т.д. памяти (сам так одну точку убил, пока не знаю, как восстановить)
Тему стоит развивать, ибо wi-fi рулит