 |
|
|
|
Всегда на связи, или IP-роуминг: вводный курс
Всегда на связи, или IP-роуминг: вводный курс Сегодняшний мир – мир мобильности. Действительно, для того чтобы быть в курсе событий уже не надо находиться на одном месте. Те, кто пользуется мобильными устройствами, имеют большие возможности по выбору каналов для доступа в Интернет – встроенный модем, Ethernet, Wi-Fi, GPRS и пр. Чтобы оценить прогресс в этой области, достаточно вспомнить изменения, произошедшие в обычной телефонной связи с появлением сотовой. Сегодня пользователи мобильных сетей третьего поколения могут просматривать фильмы из Интернета прямо на своем телефоне. Пользователи мобильных компьютеров также хотят пользоваться Интернетом всегда и везде, однако поход за «настоящей мобильностью» еще только начинается. В недалеком будущем планируется покрыть беспроводными сетями целые города. Не надо путать настоящую мобильную работу с тем, что мы имеем сегодня. В настоящей мобильной сети активные сеансы не прерываются, когда пользователь меняет точку доступа в Интернет. Все необходимые переключения производятся автоматически, подобно тому, как это происходит при перемещении абонента мобильной телефонной связи от одной соты к другой. Конечно, между мобильной связью и TCP-сеансами существует множество отличий, однако с ростом популярности различных видов мобильных компьютеров возможность подобного «IP-роуминга» быстро найдет свое применение. Основная проблема состоит в том, что один и тот же компьютер в различное время имеет разный IP-адрес, что не вполне соответствует понятию «настоящая мобильность», поскольку применяемые сейчас протоколы определяют место назначения пакетов на основе IP-адресов, которые привязываются к конкретному сетевому интерфейсу. Для наиболее популярного в Интернете транспортного протокола TCP сеанс идентифицируется четырьмя параметрами: IP-адресом источника, IP-адресом приемника и двумя номерами портов. Потеря любой из этих составляющих ведет к прекращению сеанса. Поэтому все изменения точек прикрепления, а значит, и IP-адресов после перехода в другую сеть ведут к неизбежным потерям активных связей, а значит, и к отсутствию мобильности как таковой. Данная проблема не могла остаться незамеченной, и на сегодняшний момент уже существуют технологии, позволяющие закрепить за компьютером постоянный IP-адрес. Первые официальные документы по этой теме датированы октябрем 1996 года: RFC 2002 «IP Mobility Support». Последний и пока окончательный вариант «IP Mobility Support for IPv4» известен под номером 3344 и датирован августом 2002 года. В этом документе определены расширения протокола, допускающие маршрутизацию IP-датаграмм на мобильные компьютеры в Интернете, абсолютно прозрачную для приложений и протоколов более высокого уровня вроде TCP. В схеме, предлагаемой RFC 3344, компьютер всегда идентифицируется своим домашним адресом, независимо от текущей точки доступа в Интернет, хотя, естественно, в новой точке и получает новый адрес. Протокол предоставляет заботу о регистрации нового адреса домашнему агенту (Home Agent – HA). Такой агент распознает сеансы связи, заботится об их сохранении и пересылает датаграммы, предназначенные мобильному компьютеру (mobile node – MN) на его новый адрес, используя специальный IP-туннель. При этом, когда MN находится в домашней сети, обмен происходит обычным образом. Однако когда компьютер перемещается в другую сеть и получает новый IP-адрес (его называют «care-of»-адресом), он сообщает последний своему HA, который в свою очередь подтверждает или отклоняет регистрацию. «Care-of»-адрес может быть получен различными методами. В общем случае его выдает «посторонний агент» (Foreign Agent – FA). При этом различают два альтернативных способа выдачи такого адреса. В первой схеме, известной как «foreign agent care-of address», «care-of»-адрес является IP-адресом FA, который и поддерживает один из концов IP-туннеля (другой конец в любом случае принадлежит HA). Получив информацию из туннеля, FA декапсулирует пакет, после чего передает его в сеть, где он подхватывается мобильным компьютером. Второй способ, «co-located care-of address», заключается в выдаче «care-of»-адреса непосредственно мобильному компьютеру. В этом случае MN является конечной точкой туннеля и сам занимается декапсуляцией пакетов. Агенты Foreign Agent и Home Agent сообщают о своем присутствии посредством сообщений «Agent Advertisement». При необходимости мобильный узел может сам дополнительно попросить такое сообщение от локальных агентов, используя сообщение «Agent Solicitation». Сообщения «Agent Solicitation» используются для определения маршрутизатора в новой сети и обнаружения любых изменений в установках FA. По ответам на эти сообщения MN определяет, где он находится – в своей домашней сети или в чужой. При возврате мобильного узла из внешней сети в домашнюю он отменяет внешнюю регистрацию у домашнего агента посредством пары сообщений «Registration Request» и «Registration Reply». Таким образом, сообщения «Agent Advertisement» преследуют несколько целей: обнаружение мобильных компьютеров, выдачу «care-of»- адресов, назначение новых параметров маршрутизации, информирование мобильного компьютера об особенностях работы FA (например, наличии альтернативных методов инкапсуляции). Информация, отправленная на домашний адрес мобильного узла, перехватывается домашним агентом и переправляется по туннелю на «care-of»-адрес либо через FA, который в свою очередь зная, где сейчас MN, передает информацию ему (схема «foreign agent care-of address»), либо непосредственно к MN. Для успешной доставки требуется, чтобы «care-of»-адрес выступал в качестве адреса назначения каждого из пакетов. Когда пакет приходит на «care-of»-адрес, происходит обратное преобразование, и пакет снова в качестве адреса назначения получает домашний адрес мобильного узла. Так как служебная информация для протоколов более высокого уровня остается постоянной, то все активные сеансы начатые, например, в домашней сети, не будут разорваны. В обратном направлении информация проходит обычным путем, используя стандартные механизмы IP-маршрутизации и не обязательно затрагивая домашнего агента. В качестве IP-адреса приемника выступает адрес узла, с которым в данный момент установлено соединение, а в качестве адреса источника – домашний адрес компьютера, т.е. HA. При отправлении, как и при приеме пакета, MN может сам заниматься отправкой или делать это через FA. При перемещении MN он снова регистрируется у нового FA, после чего информация направляется по новому «care-of»-адресу. Некоторые реализации позволяют назначить мобильному компьютеру сразу несколько «care-of»-адресов, в этом случае HA пересылает информацию по всем известным ему адресам. Такой подход может быть полезен при постоянном перемещении клиентов. В течение последних лет стартовало несколько проектов, реализующих идею Mobile IP. К сожалению, большая часть этих программ развивается не очень активно, и в результате готовые реализации можно найти только для старых ядер Linux версий 2.0 и 2.2. Среди этих проектов следует упомянуть Linux Mobile IP [1] и Mosquito Net Mobile IP [2]. Довольно неплохие наработки имеются у проекта Dynamics Mobile IP [3]. Кроме ядер Linux версий 2.2 и 2.4, это приложение посредством Cygwin портировано и в Microsoft Windows (98SE, ME, NT4, 2000). К сожалению, с осени 2001 года Dynamic Mobile IP больше не развивается. Подход, заложенный в rfс 3344, имеет и недостатки. Самые существенные среди них – это большое количество туннелей, серьезная нагрузка на домашнего агента, от исправной работы которого, по сути, и зависит возможность реализации вышеописанной схемы и достижимость мобильного узла. Эту проблему может решить централизованное управление всей системой, а не контроль за отдельными сеансами. В таком случае возможно резервирование информации. Кроме того, централизация позволит оптимизировать связи, уменьшить количество туннелей, облегчит управление и защиту. Но, наверное, самым большим недостатком является необходимость использования дополнительного программного обеспечения, декапсулирующего пакеты и обеспечивающего взаимодействие с FA, на клиентских компьютерах, а также сам факт существования FA. Учитывая сегодняшнее разнообразие операционных систем и устройств, придется либо адаптировать программу для всех систем, либо унифицировать оборудование в отдельно взятой организации, что не всегда приемлемо и возможно. Опять же убедить провайдера или системного администратора в установке постороннего ПО или устройства не всегда удается, поэтому говорить о глобальной мобильности пока еще рано, а вот в отдельной компании все вышеописанное вполне возможно. Проект TMIP Другой весьма интересной альтернативой Mobile IP являются разработки открытого проекта TMIP (Transparent Mobile IP). С их помощью каждый мобильный узел с произвольным внешним IP-адресом также будет всегда идентифицироваться по одному домашнему IP-адресу, который не будет зависеть от местоположения компьютера. Кроме этого, TMIP гарантирует, что все активные сеансы TCP не будут разорваны при перемещении. Отличие этого проекта от Mobile IP состоит в том, что на стороне клиента не применяется никакого дополнительного программного обеспечения, а также не происходит вмешательства в структуру IP-стека. Для обеспечения связей между узлами, сеть сама изменяется, используя технику IP-туннелей. Сеть TMIP состоит из одного-двух реестров Mobile Location Register (MLR), нескольких корреспондентских узлов (Correspondent Nodes – CN) и мобильных клиентских станций (Mobile Station – MS). MLR предназначен для руководства клиентами (точнее, их Ethernet MAC-адресами), выяснения текущей позиции в сети и распределения IP. Для этого MLR хранит в памяти местоположение всех клиентских станций. При обнаружении новой станции он регистрирует ее, отмечая родительский и текущий CN. Так как потеря этой информации критична, то, как правило, применяется резервирование. Присоединением мобильных узлов занимается CN. Происходит это так. Мобильный компьютер, находясь в одной из сетей, получает IP-адрес при помощи интегрированного в CN сервера DHCP. Когда узел мигрирует в другую сеть и попадает к новому CN, этот переход обнаруживается при помощи различных методов, после чего новый CN вступает в контакт с исходным (родительским) CN (обслуживающим домашнюю сеть узла) и, возможно, с предыдущим CN (обслуживающим сеть, откуда узел только что ушел). Вся необходимая информация берется у MLR. На этом этапе возможна повторная аутентификация клиента, в результате которой разрешается или запрещается дальнейшая работа. В настоящий момент она производится только на основе МАС-адресов. Абсолютно прозрачно, в пределах одной транзакции (в две стадии) узел передается новому CN с обновленными параметрами сети и старым IP-адресом. При этом миграции клиентов не влияют на таблицы маршрутизации конкретного сегмента сети. Исходящие от мобильного узла пакеты достигают места назначения обычным путем. Учитывая, что их исходный адрес не всегда соответствует текущему положению узла, родительский CN (при помощи MLR) узнает текущую позицию узла (точку доступа) и пересылает ответные пакеты нужному CN по туннелю. Последний в свою очередь передает их в локальную сеть, где они перехватываются мобильным компьютером. При таком подходе максимально возможное число туннелей, которые можно получить, равняется n * (n – 1), где n – общее число CN в сети. Установка и настройка TMIP Основной сайт проекта расположен по адресу: http://www.slyware.com/projects_tmip.shtml. Здесь можно найти документацию, а исходные тексты доступны с http://tmip.sourceforge.net. Текущая версия утилиты – 0.14a, архив имеет имя tmip_0.14a_release.tar.gz. Как вариант можно использовать пре-релиз tmipcore_0.5a-pre.tar.gz. Из принципа работы системы TMIP следует, что настраивать необходимо один-два MLR и несколько CN. Клиентские компьютеры не требуют настроек, но для упрощения работы они должны получать IP-адрес при помощи DHCP. MLR и CN должны работать под управлением ОС Linux, в которой необходимо установить библиотеку libpcap и включить поддержку «IP: Tunneling» в ядре (вкладка «Networking Options»). Рассмотрим процедуру установки TMIP. В первую очередь распакуем полученный архив. Для компиляции MLR следует зайти в подкаталог mlrd и дать команду «make», а образовавшийся в итоге исполняемый файл mlrd скопировать, например, в /usr/local/sbin. Аналогично поступаем с CN, работа которого управляется при помощи демона tmipd. Для компиляции демона необходимо выполнить команду «make» в каталоге tmipd. Для работы первичного и вторичного MLR-серверов необходимы два конфигурационных файла. Первый, mlrd-primary.rc, может выглядеть так: # mlrd-primary.rc # CN должны использовать аналогичное имя сети network_name my-tmip-mobility port 6554 foreground true log_file /var/log/mlrd.log status_file /var/log/mlrd.status logtrue # строка ниже указывает на вторичный MLR-сервер cc_mlr secondary.my-tmip-mobility.com:5555 Для вторичного сервера используется файл mlrd-secondary.rc. # mlrd-secondary.rc network_name my-tmip-mobility port 5555 foreground true log_file /var/log/mlrd.log status_file /var/log/mlrd.status log true grant primary.my-tmip-mobility.com После этого можно запустить mlrd. # /usr/local/sbin/mlrd -f mlrd-primary.rc
Аналогично запускаем сервис и на вторичном MLR-сервере. # /usr/local/sbin/mlrd -f mlrd-secondary.rc Теперь приступаем к настройке CN. Пример конфигурационного файла с детальными описаниями настроек находится в подкаталоге tmipd и называется tmipd.rc. # tmipd.rc mlr primary.my-tmip-mobility.com cn_name wlan. primary.my-tmip-mobility cn_if eth0 mobile_if wlan0 # или как вариант #mobile_if eth0 network_name my-tmip-mobility # следующая опция понадобится при запуске нескольких копий CN на одном компьютере # tunnel_prefix tmip # разрешить регистрацию только занесенных в базу MLR-хостов registered_only false # чистка туннеля при запуске purge_tunnels true # так как CN занимается распределением адресов, то реализована возможность задания диапазона addr_pool wlan0 * * # или как вариант # addr_pool eth1 10.10.15.32 +10.10.15.48 dns_server 10.10.15.7 debug_level 2 log true log_file /var/log/tmipd.log status_file /var/log/tmipd.status foreground true # pid_file /var/run/tmipd.pid # настройка сервера DHCP enable_dhcp true # domain_name my-tmip-mobility.com # dhcp_lease_time 300 # DHCP lease time in seconds # возможно игнорирование перемещения отдельных клиентов # ignore_mac aa:bb:cc:11:22:33 Для проверки работоспособности системы запустите: # /usr/local/sbin/tmipd -Ef tmipd.rc
Просмотрите полученные сообщения. Если все прошло нормально, то каждый CN должен соединяться с MLR по протоколу TCP, порт 6554 и обмениваться информацией с остальными CN по порту 5554. После этого можно произвести запуск в рабочем режиме. # /usr/local/sbin/tmipd
Все сообщения об ошибках, регистрациях новых узлов находятся в файле журнала. # cat /var/log/tmipd.log Если включена опция «registered_only true», то в регистрации компьютеров, не занесенных в базу MLR, будет отказано. В журнале это выглядит так.
Для регистрации компьютеров, просмотра записей и обновления информации в MLR используется специализированный инструмент mlrp_query, компиляция которого производится в одноименном подкаталоге. Так, например, чтобы привязать компьютер с МАС-адресом 00:0D:18:01:1C:05 к CN 10.10.15.1 в MLR, находящемуся по адресу 10.10.15.100, следует выполнить команду. # mlrp_query -M10.10.15.100 -A -m00:0D:18:01:1C:05 -p10.10.15.1 Кроме того, в настоящее время идет разработка веб-инструмента, предназначенного для регистрации мобильных клиентов и вывода различной статистической информации. После произведенных настроек клиенты могут спокойно перемещаться по сетям. Единственной проблемой может стать использование на компьютере сменных адаптеров (например, PCMCIA), которые имеют различный MAC-адрес. Единственно возможным выходом в такой ситуации будет подмена МАС-адреса. # /sbin/ifconfig wlan0 hw ether 00:0D:18:01:1C:05 Проблемы Mobile IP Чтобы не создавать идеальную картину мобильного мира, просто необходимо сказать пару слов и о проблемах. Основной помехой при использовании Mobile IP являются защитные механизмы, так как реализовать подмену IP-адресов не просто, а очень просто. Поэтому описанные выше схемы потребуют введения дополнительной идентификации или шифрования трафика. Решений многих проблем ожидают от перехода на IPv6, для которого разрабатывается ряд расширений, позволяющих направлять потоки непосредственно на мобильный узел, полностью отказавшись от HA и FA [15]. Например, расширение Neighbor Discovery позволяет сообщать домашнему маршрутизатору о своем местонахождении и таким образом корректировать маршрут. Вероятно, по этой причине подавляющее большинство информации по вопросу Mobile IP имеет чисто теоретический и рекомендательный характер, так как после глобального перехода на IPv6 (когда это еще будет?) картина сильно изменится, и многие проблемы, если не отпадут полностью, будут выглядеть совсем иначе. Во всяком случае во время эксперимента в Гонконге, проходившего осенью 2000 года в сетях WiFi и GPRS использовался именно IPv6, а для связи с остальными узлами применялись специальные шлюзы (см. например: http://www.tdap.co.uk/uk/archive/mobile/mob(ipv6_0103).html). Кроме того, использование IPsec для аутентификации источника и защиты целостности данных в IPv6 позволяет повысить безопасность таких соединений. Далее, не исключена возможность пропадания пакетов по причине их устаревания и отсечки межсетевым экраном, так как настройки большинства провайдеров исключают выход из сети пакетов с «неродным» IP-адресом. Было предложено несколько вариантов выхода из ситуации [16], самым простым из которых является обратный туннель от HA. Кроме того, судя по сообщениям, основные поставщики маршрутизаторов уже имеют модели, адаптированные под технологии Mobile IP. Проблема сохранения активных связей при перемещении пользователей назревает уже давно. По мере увеличения количества мобильных пользователей она будет становиться более остро. Вероятнее всего, ни о какой глобальной мобильности в настоящее время не может быть и речи. К сожалению, текущие реализации протоколов и операционных систем просто не предусматривают этого. Наверное, мобильность будет доступна только тем, кто использует для выхода в Интернет GPRS-модем. Вероятно, ситуацию может изменить вмешательство в IP-стек, ведь только в этой ситуации будут работать системы защиты информации вроде VPN. Однако разработки проекта TMIP и других вполне пригодны для использования на отдельно взятом предприятии и могут служить реальной заменой табличкам, извещающим об окончании зоны действия той или иной точки доступа. Поход за «настоящей мобильностью» еще только начинается! Ссылки:
|
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
