Руководство Freebsd icon

Руководство Freebsd


Смотрите также:
Руководство Freebsd...
Ермаков В. И. ред...
Avira AntiVir PersonalEdition...
Киев, пр-т Освободителей 25, кв. 15...
Техническое задание на разработку сайта...
Frenzy 0 информация о релизе...
Руководство по парашютной подготовке авиации досааф россии (рпп-2010) (далее Руководство)...
Методологическое руководство по мониторингу и оценке...
Методологическое руководство по мониторингу и оценке вич/спид, туберкулез и малярия июнь 2004 г...
Руководство пользователя Сетевой цифровой видеорекордер...
Руководство проведением конкурса Общее руководство, организацию подготовки...
Методическое руководство по дипломному проектированию...



страницы: 1   ...   19   20   21   22   23   24   25   26   27
вернуться в начало
^

27.3. Беспроводные сети


Текст предоставил Перевёл на русский язык Eric Anderson, Андрей Захватов.

27.3.1. Введение


Было бы весьма полезным иметь возможность использовать компьютер без хлопот, связанных с постоянно подключенным сетевым кабелем. FreeBSD может использоваться как клиент беспроводной сети, и даже в качестве ''точки доступа'' к ней.
^

27.3.2. Режимы работы беспроводной связи


Существуют два варианта конфигурации устройств беспроводного доступа 802.11: BSS и IBSS.
27.3.2.1. Режим BSS

Режим BSS является наиболее часто используемым. Режим BSS также называют режимом инфраструктуры. В этом режиме несколько точек доступа беспроводной сети подключаются к проводной сети передачи данных. Каждое беспроводная сеть имеет собственное имя. Это имя является идентификатором SSID сети.

Клиенты беспроводной сети подключаются к этим точкам доступа беспроводной сети. Стандарт IEEE 802.11 определяет протокол, используемый для связи в беспроводных сетях. Клиент сети беспроводного доступа может подключаться к некоторой сети, если задан её SSID. Клиент может также подключаться к любой сети, если SSID не задан.
^
27.3.2.2. Режим IBSS

Режим IBSS, также называемый ad-hoc, предназначен для соединений точка-точка. На самом деле существуют два типа режима ad-hoc. Один из них является режимом IBSS, называемый также режимом ad-hoc или IEEE ad-hoc. Этот режим определён стандартами IEEE 802.11. Второй режим называется демонстрационным режимом ad-hoc, или Lucent ad-hoc (или, иногда неправильно, режимом ad-hoc). Это старый, существовавший до появления 802.11, режим ad-hoc, и он должен использоваться только для старых сетей. В дальнейшем мы не будем рассматривать ни один из режимов ad-hoc.
^

27.3.3. Режим инфраструктуры

27.3.3.1. Точки доступа

Точки доступа представляют собой беспроводные сетевые устройства, позволяющие одному или большему количеству клиентов беспроводной сети использовать эти устройства в качестве центрального сетевого концентратора. При использовании точки доступа все клиенты работают через неё. Зачастую используются несколько точек доступа для полного покрытия беспроводной сетью некоторой зоны, такой, как дом, офис или парк.

Точки доступа обычно имеют несколько подключений к сети: адаптер беспроводной связи и один или большее количество сетевых ethernet-адаптеров для подключения к остальной части сети.

Точки доступа могут быть либо приобретены уже настроенными, либо вы можете создать собственную при помощи FreeBSD и поддерживаемого адаптера беспроводной связи. Несколько производителей выпускают точки беспроводного доступа и адаптеры беспроводной связи с различными возможностями.
^
27.3.3.2. Построение точки доступа с FreeBSD
27.3.3.2.1. Требования

Для того, чтобы создать беспроводную точку доступа на FreeBSD, вам нужно иметь совместимый адаптер беспроводной связи. На данный момент поддерживаются адаптеры только на основе набора микросхем Prism. Вам также потребуется поддерживаемый FreeBSD адаптер проводной сети (найти такой будет нетрудно, FreeBSD поддерживает множество различных устройств). В этом руководстве мы будем полагать, что вы будете строить сетевой мост (bridge(4)) для пропуска всего трафика между устройством беспроводной связи и сетью, подключенной к обычному Ethernet-адаптеру.

Функциональность hostap, которая используется FreeBSD для организации точки доступа, работает лучше всего с некоторыми версиями микрокода. Адаптеры Prism 2 должны использовать микрокод версии 1.3.4 или более новый. Адаптеры Prism 2.5 и Prism 3 должны использовать микрокод версии 1.4.9. Более старые версии микрокода могут работать нормально, а могут и некорректно. В настоящее время единственным способом обновления адаптеров является использование утилит обновления для Windows, которые можно получить у производителя ваших адаптеров.
27.3.3.2.2. Настройка

Первым делом убедитесь, что ваша система распознаёт адаптер беспроводной связи:

# ifconfig -a

wi0: flags=8843 mtu 1500

inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7

inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255

ether 00:09:2d:2d:c9:50

media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)

status: no carrier

ssid ""

stationname "FreeBSD Wireless node"

channel 10 authmode OPEN powersavemode OFF powersavesleep 100

wepmode OFF weptxkey 1

На данном этапе не беспокойтесь о деталях, просто убедитесь, что выдаётся нечто, указывающее на установленный адаптер беспроводной связи. Если при этом у вас есть проблемы с недоступностью интерфейса беспроводной связи, и вы используете PC Card, то обратитесь к страницам справочной системы, описывающим pccardc(8) и pccardd(8) для получения более полной информации.

Теперь вам нужно загрузить модуль для подготовки той части FreeBSD, что отвечает за организацию сетевых мостов, для работы с точкой доступа. Для загрузки модуля bridge(4) просто выполните следующую команду:

# kldload bridge

При загрузке модуля никаких сообщений об ошибках быть не должно. Если это всё же произошло, вам может потребоваться вкомпилировать код для модуля bridge(4) в ядро. В этом вам должен помочь раздел этого Руководства об организации сетевых мостов.

Теперь, когда вы завершили с той частью, что касается организации сетевого моста, нам нужно указать ядру FreeBSD, какие интерфейсы должны объединяться в сетевом мосте. Это мы делаем при помощи sysctl(8):

# sysctl net.link.ether.bridge.enable=1

# sysctl net.link.ether.bridge.config="wi0 xl0"

# sysctl net.inet.ip.forwarding=1

В версиях FreeBSD, предшествующих 5.2, вместо указанных нужно использовать следующие параметры:

# sysctl net.link.ether.bridge=1

# sysctl net.link.ether.bridge_cfg="wi0,xl0"

# sysctl net.inet.ip.forwarding=1

Теперь необходимо настроить адаптер беспроводной сети. Следующая команда заставит адаптер работать в режиме точки доступа:

# ifconfig wi0 ssid my_net channel 11 media DS/11Mbps mediaopt hostap up stationname "FreeBSD AP"

Строчка ifconfig(8) активизирует интерфейс wi0, конфигурирует его SSID как my_net, а имя станции как FreeBSD AP. media DS/11Mbps переводит адаптер в режим 11Mbps и нужен только для того, чтобы сработал параметр mediaopt. Параметр mediaopt hostap переводит интерфейс в режим точки доступа. Параметр channel 11 задаёт использование канала 802.11b. Страница справки по команде wicontrol(8) перечисляет корректные значения каналов для ваших нужд.

Теперь у вас должна получиться полнофункциональная работающая точка доступа. Настоятельно советуем прочесть страницы справочной по wicontrol(8), ifconfig(8), и wi(4) для получения дополнительной информации.

Также полагаем, что вы прочтёте следующий раздел о шифровании.
27.3.3.2.3. Информация о состоянии

После того, как точка доступа сконфигурирована и начала свою работу, операторам может понадобиться видеть клиентов, связанных с этой точкой. В любой момент оператор может набрать:

# wicontrol -l

1 station:

00:09:b7:7b:9d:16 asid=04c0, flags=3, caps=1, rates=f<1M,2M,5.5M,11M>, sig=38/15

Это показывает, что имеется одна связанная станция с перечисленными характеристиками. Выдаваемое значение сигнала должно использоваться только как сравнительный индикатор его силы. Его перевод в dBm или другие единицы измерения различаются в разных версиях микрокода.
27.3.3.3. Клиенты

Клиент в беспроводной сети представляет собой систему, которая обращается к точке доступа или непосредственно к другому клиенту.

Как правило, клиенты беспроводной сети имеют только один сетевой адаптер, а именно адаптер беспроводной сети.

Существует несколько различных способов конфигурации клиента беспроводной сети. Они основаны на различных режимах работы в беспроводной сети, обычно BSS (режим инфраструктуры, который требует точки доступа) или IBSS (ad-hoc или режим одноранговой сети). В нашем примере мы будем использовать самый популярный их них, режим BSS, для связи с точкой доступа.
27.3.3.3.1. Требования

Существует только одно жёсткое условие для настройки FreeBSD в качестве клиента беспроводной сети. Вам нужен адаптер беспроводной связи, поддерживаемый FreeBSD.
27.3.3.3.2. Конфигурация FreeBSD как клиента беспроводной сети

Перед тем, как подключиться к беспроводной сети, вам нужно будет узнать о ней несколько вещей. В этом примере мы подключаемся к сети, которая называется my_net, и шифрование в ней отключено.

Замечание: В этом примере мы не используем шифрование, но это небезопасно. В следующем разделе вы узнаете, как её включить, почему это так важно, и почему некоторые технологии шифрования всё же не могут полностью обеспечить вашу информационную безопасность.

Удостоверьтесь, что ваш адаптер распознаётся во FreeBSD:

# ifconfig -a

wi0: flags=8843 mtu 1500

inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7

inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255

ether 00:09:2d:2d:c9:50

media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)

status: no carrier

ssid ""

stationname "FreeBSD Wireless node"

channel 10 authmode OPEN powersavemode OFF powersavesleep 100

wepmode OFF weptxkey 1

Теперь мы можем изменить настройки адаптера на те, что соответствуют нашей сети:

# ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net

Замените 192.168.0.20 и 255.255.255.0 на правильные IP-адрес и сетевую маску в вашей проводной сети. Запомните, что наша точка доступа выступает в роли моста для данных между беспроводной и проводной сетями, так что они будут доступны для других устройств, находящихся в сети, как будто они тоже находятся в проводной сети.

Как только вы это выполнили, то сможете получить ping от хостов в проводной сети, как будто вы подключены посредством обычных проводов.

Если вы столкнулись с проблемами при работе в беспроводной сети, удостоверьтесь, что вы ассоциированы (подключены) с точкой доступа:

# ifconfig wi0

должна выдать некоторую информацию, и вы должны увидеть:

status: associated

Если статус не будет соответствовать associated, это может значить, что вы оказались вне зоны досягаемости точки доступа, включили шифрование или, возможно, имеются проблемы с конфигурацией.
27.3.3.4. Шифрование

Шифрование в беспроводной сети имеет важное значение, потому что у вас нет больше возможности ограничить сеть хорошо защищённой областью. Данные вашей беспроводной сети вещаются по всей окрестности, так что любой заинтересовавшийся может их считать. Вот здесь используется шифрование. Шифруя данные, посылаемые в эфир, вы делаете их прямой перехват гораздо более сложным для всех любопытных.

Двумя наиболее широко применяемыми способами шифрования данных между вашим клиентом и точкой доступа являются WEP и ipsec(4).
27.3.3.4.1. WEP

WEP является сокращением от Wired Equivalency Protocol (Протокол Соответствия Проводной сети). WEP является попыткой сделать беспроводные сети такими же надёжными и безопасными, как проводные. К сожалению, он был взломан и сравнительно легко поддаётся вскрытию. Это означает также, что он не тот протокол, на который следует опираться, когда речь идёт о шифровании критически важных данных.

Он лучше, чем ничего, так что используйте следующую команду для включения WEP в вашей новой точке доступа FreeBSD:

# ifconfig wi0 inet up ssid my_net wepmode on wepkey 0x1234567890 media DS/11Mbps mediaopt hostap

Вы можете включить WEP на клиенте следующей командой:

# ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net wepmode on wepkey 0x1234567890

Отметьте, что вы должны заменить 0x1234567890 на более уникальный ключ.
27.3.3.4.2. IPsec

ipsec(4) является гораздо более надёжным и мощным средством шифрования данных в сети. Этот метод определённо является предпочтительным для шифрования данных в беспроводной сети. Более детально ознакомиться с безопасностью и применением ipsec(4) вы можете в разделе об IPsec этого Руководства.
27.3.3.5. Утилиты

Имеется несколько утилит, которые можно использовать для настройки и отладки вашей беспроводной сети, и здесь мы попытаемся описать некоторые из них и что они могут делать.
27.3.3.5.1. Пакет bsd-airtools

Пакет bsd-airtools представляет собой полный набор инструментов, включая инструменты для проверки беспроводной сети на предмет взлома WEP-ключа, обнаружения точки доступа и тому подобное.

Утилиты bsd-airtools можно установить из порта net-mgmt/bsd-airtools. Информацию об установке портов можно найти в Главе Гл. 4 этого Руководства.

Программа dstumbler является инструментом, предназначенным для обнаружения точки доступа и выдачи отношения уровня сигнала к шуму. Если у вас с трудом получается запустить точку доступа, dstumbler может помочь вам начать.

Для тестирования информационной безопасности вашей беспроводной сети, вы можете воспользоваться набором ''dweputils'' (dwepcrack, dwepdump и dwepkeygen), который может помочь понять, является ли WEP подходящим решением для обеспечения ваших потребностей в информационной безопасности.
27.3.3.5.2. Утилиты wicontrol, ancontrol и raycontrol

Это инструменты, которые могут быть использованы для управления поведением адаптера беспроводной связи в сети. В примере выше мы выбирали wicontrol(8), так как нашим адаптером беспроводной сети был интерфейс wi0. Если у вас установлено устройство беспроводного доступа от Cisco, этим интерфейсом будет an0, и тогда вы будете использовать ancontrol(8).
27.3.3.5.3. Команда ifconfig

Команда ifconfig(8) может использоваться для установки многих из тех параметров, что задаёт wicontrol(8), однако работа с некоторыми параметрами в ней отсутствует. Обратитесь к ifconfig(8) для выяснения параметров и опций командной строки.
^
27.3.3.6. Поддерживаемые адаптеры
27.3.3.6.1. Точки доступа

Единственными адаптерами, которые на данный момент поддерживаются в режиме BSS (как точка доступа), являются те устройства, что сделаны на основе набора микросхем Prism 2, 2.5 или 3). Полный список можно увидеть в wi(4).
27.3.3.6.2. Клиенты 802.11b

Практически все адаптеры беспроводной связи 802.11b на данный момент во FreeBSD поддерживаются. Большинство адаптеров, построенных на основе Prism, Spectrum24, Hermes, Aironet и Raylink, будут работать в качестве адаптера беспроводной сети в режиме IBSS (ad-hoc, одноранговая сеть и BSS).
27.3.3.6.3. Клиенты 802.11a и 802.11g

Драйвер устройства ath(4) поддерживает 802.11a и 802.11g. Если ваша карта основана на чипсете Atheros, вы можете использовать этот драйвер.

К сожалению, все еще много производителей, не предоставляющих схематику своих драйверов сообществу open source, поскольку эта информация считается торговым секретом. Следовательно, у разработчиков FreeBSD и других операционных систем остается два варианта: разработать драйверы долгим и сложным методом обратного инжиниринга, или использовать существующие драйверы для платформ Microsoft Windows. Большинство разработчиков FreeBSD выбрали второй способ.

Благодаря усилиям Билла Пола (wpaul), начиная с FreeBSD 5.3-RELEASE существует ''прозрачная'' поддержка Network Driver Interface Specification (NDIS). FreeBSD NDISulator (известный также как Project Evil) преобразует бинарный драйвер Windows так, что он работает так же как и в Windows. Эта возможность всё ещё относительно нова, но в большинстве тестов она работает адекватно.

Для использования NDISulator потребуются три вещи:

1. Исходные тексты ядра

2. Бинарный драйвер Windows XP (расширение .SYS)

3. Файл конфигурации бинарного драйвера Windows XP (расширение .INF)

Вам может потребоваться компиляция драйвера оболочки мини порта ndis(4). Под root:

# cd /usr/src/sys/modules/ndis

# make && make install

Определите местоположение файлов для вашей карты. Обычно их можно найти на входящем в комплект CD или на Web-сайте поставщика. В нашем примере используются файлы W32DRIVER.SYS и W32DRIVER.INF.

Следующий шаг это компиляция бинарного драйвера в загружаемый модуль ядра. Чтобы сделать это, сначала зайдите в каталог модуля if_ndis и с правами root скопируйте туда драйверы Windows:

# cd /usr/src/sys/modules/if_ndis

# cp /path/to/driver/W32DRIVER.SYS ./

# cp /path/to/driver/W32DRIVER.INF ./

Теперь используйте утилиту ndiscvt для создания заголовка определения драйвера ndis_driver_data.h перед сборкой модуля:

# ndiscvt -i W32DRIVER.INF -s W32DRIVER.SYS -o ndis_driver_data.h

Параметры -i и -s задают соответственно файл настройки и бинарный файл. Мы используем параметр -o ndis_driver_data.h, поскольку Makefile при создании модуля будет обращаться именно к этому файлу.

Замечание: Некоторым драйверам Windows для работы требуются дополнительные файлы. Вы можете включить их параметром ndiscvt -f. Обратитесь к странице справочной системы ndiscvt(8) за дополнительной информацией.

Наконец, соберите и установите модуль драйвера:

# make && make install

Для использования драйвера необходимо загрузить соответствующие модули:

# kldload ndis

# kldload if_ndis

Первая команда загружает оболочку драйвера мини-порта NDIS, вторая загружает собственно сетевой интерфейс. Проверьте dmesg(8) на предмет ошибок загрузки. Если все прошло хорошо, вывод должен быть примерно таким:

ndis0: mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1

ndis0: NDIS API version: 5.0

ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5

ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps

ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps

Начиная с этого момента вы можете использовать устройство ndis0 как любое другое беспроводное устройство (например, wi0); в этой ситуации применима информация, приведенная в начале этой главы.

27.4. Bluetooth


Текст предоставил Pav Lucistnik.

27.4.1. Введение


Bluetooth является беспроводной технологией для создания персональных сетей на расстоянии не более 10 метров, работающей на частоте 2.4 ГГц, которая не подлежит лицензированию. Обычно такие сети формируются из портативных устройств, таких, как сотовые телефоны, КПК и лэптопы. В отличие от Wi-Fi, другой популярной беспроводной технологии, Bluetooth предоставляет более высокий уровень сервиса, например, файловые серверы типа FTP, передачу файлов, голоса, эмуляцию последовательного порта и другие.

Стек протоколов Bluetooth во FreeBSD реализован на основе технологии Netgraph (обратитесь к netgraph(4)). Широкий спектр USB-устройств Bluetooth поддерживается драйвером ng_ubt(4). Устройства Bluetooth на основе набора микросхем Broadcom BCM2033 поддерживается драйвером ng_bt3c(4). Устройства Bluetooth, работающие через последовательные и UART-порты, поддерживаются драйверами sio(4), ng_h4(4) и hcseriald(8). В этом разделе описывается использование Bluetooth-устройств, подключаемых через USB. Поддержка Bluetooth имеется во FreeBSD 5.0 и более новых версиях системы.
^

27.4.2. Подключение устройства


По умолчанию драйверы устройств Bluetooth поставляются в виде модулей ядра. Перед подключением устройства вам необходимо подгрузить драйвер в ядро:

# kldload ng_ubt

Если Bluetooth-устройство в момент запуска системы подключено, то загружайте модуль из файла /boot/loader.conf:

ng_ubt_load="YES"

Подключите ваше USB-устройство. На консоли (или в журнале syslog) появится примерно такое сообщение:

ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2

ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2

ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3,

wMaxPacketSize=49, nframes=6, buffer size=294

Замечание: Стек протоколов Bluetooth запускается вручную во FreeBSD 6.0, и во FreeBSD 5.X, перед 5.5. Это делается автоматически через devd(8) во FreeBSD 5.5, 6.1 и в более новых версиях.

Скопируйте файл /usr/share/examples/netgraph/bluetooth/rc.bluetooth в какое-нибудь подходящее место, например, в файл /etc/rc.bluetooth. Этот скрипт используется для запуска и остановки работы Bluetooth-стека. Перед отключением устройства рекомендуется остановить его работы, хотя (обычно) это не фатально. При запуске стека вы получите сообщения, подобные следующим:

# /etc/rc.bluetooth start ubt0

BD_ADDR: 00:02:72:00:d4:1a

Features: 0xff 0xff 0xf 00 00 00 00 00

<3-Slot> <5-Slot>










Max. ACL packet size: 192 bytes

Number of ACL packets: 8

Max. SCO packet size: 64 bytes

Number of SCO packets: 8
^

27.4.3. Host Controller Interface (HCI)


Host Controller Interface (HCI) предоставляет интерфейс для управления контроллером передатчика и менеджером соединений, а также доступ к данным о состоянии оборудования и его управляющим регистрам. Этот интерфейс предоставляет унифицированный метод доступа к передающим возможностям Bluetooth. Уровень HCI на управляющей машине обменивается данными и командами с микрокодом HCI в оборудовании Bluetooth. Драйвер для Host Controller Transport Layer (то есть физической шины) предоставляет обоим слоям HCI возможность обмениваться данными друг с другом.

Для одного Bluetooth-устройства создаётся один узел Netgraph типа hci. HCI-узел обычно подключается к узлу драйвера устройства Bluetooth (входящий поток) и к узлу L2CAP (исходящий поток). Все операции с HCI должны выполняться на узле HCI, но не на узле драйвера устройства. В качестве имени по умолчанию для узла HCI используется ''devicehci''. Дополнительные подробности можно найти на справочной странице ng_hci(4).

Одной из самой часто выполняемой задач является обнаружение Bluetooth-устройств в радиусе RF-доступности. Эта операция называется опросом (inquiry). Опрос и другие операции, связанные с HCI, выполняются при помощи утилиты hccontrol(8). Пример ниже показывает, как найти доступные устройства Bluetooth. Список таких устройств должен быть получен в течение нескольких секунд. Заметьте, что удалённые устройства будут отвечать на опрос, если только они находятся в режиме обнаруживаемости (discoverable).

% hccontrol -n ubt0hci inquiry

Inquiry result, num_responses=1

Inquiry result #0

BD_ADDR: 00:80:37:29:19:a4

Page Scan Rep. Mode: 0x1

Page Scan Period Mode: 00

Page Scan Mode: 00

Class: 52:02:04

Clock offset: 0x78ef

Inquiry complete. Status: No error [00]

BD_ADDR является уникальным адресом устройства Bluetooth, вроде MAC-адресов сетевых адаптеров. Этот адрес необходим для дальнейшей работы с устройством. Адресу BD_ADDR можно присвоить удобное для чтения имя. Файл /etc/bluetooth/hosts содержит информацию об известных хостах Bluetooth. В следующем примере показано, как получить имя, назначенное удалённому устройству:

% hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4

BD_ADDR: 00:80:37:29:19:a4

Name: Pav's T39

Если вы выполните опрос на другом Bluetooth-устройстве, но ваш компьютер будет опознан как ''your.host.name (ubt0)''. Имя, назначаемое локальному устройству, может быть в любой момент изменено.

Система Bluetooth предоставляет услуги по соединениям типа точка-точка (при этом задействованы только два устройства Bluetooth) или точка-ко-многим-точкам. В последнем случае соединение используется совместно несколькими устройствам Bluetooth. В следующем примере показывается, как получить список активных для локального устройства соединений:

% hccontrol -n ubt0hci read_connection_list

Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State

00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN

Идентификатор соединения (connection handle) полезен, когда необходимо прекратить соединение. Заметьте, что обычно нет нужды делать это вручную. Стек будет автоматически разрывать неактивные соединения.

# hccontrol -n ubt0hci disconnect 41

Connection handle: 41

Reason: Connection terminated by local host [0x16]

Обратитесь к помощи посредством hccontrol help для получения полного списка доступных HCI-команд. Большинство команд HCI для выполнения не требуют прав администратора системы.
^

27.4.4. Logical Link Control and Adaptation Protocol (L2CAP)


Протокол L2CAP (Logical Link Control and Adaptation Protocol) предоставляет услуги по работе с данными, как ориентированные на соединения, так и без ориентации на них, протоколам более высокого уровня с возможностями мультиплексирования и обеспечением операций по сегментации и обратной сборке. L2CAP позволяет протоколам более высокого уровня и приложениям передавать и получать пакеты данных L2CAP длиной до 64 Кбайт.

L2CAP основан на концепции каналов. Каналом является логическое соединение поверх соединения по радиоканалу. Каждый канал привязан к некоторому протоколу по принципу многие-к-одному. Несколько каналов могут быть привязаны к одному и тому же протоколу, но канал не может быть привязан к нескольким протоколам. Каждый пакет L2CAP, получаемый каналом, перенаправляется к соответствующему протоколу более высокого уровня. Несколько каналов могут совместно использовать одно и то же радиосоединение.

Для одного Bluetooth-устройства создается один узел Netgraph типа l2cap. Узел L2CAP обычно подключается к узлу Bluetooth HCI (нижестоящий) и узлам Bluetooth-сокетов (вышестоящие). По умолчанию для узла L2CAP используется имя ''devicel2cap''. Для получения дополнительной информации обратитесь к справочной странице по ng_l2cap(4).

Полезной является программа l2ping(8), которая может использоваться для проверки связи с другими устройствами. Некоторые реализации Bluetooth могут не возвращать все данные, посылаемые им, так что 0 bytes в следующем примере - это нормально.

# l2ping -a 00:80:37:29:19:a4

0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0

0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0

0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0

0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0

Утилита l2control(8) используется для выполнения различных операций с узлами L2CAP. В этом примере показано, как получить список логических соединений (каналов) и перечень радиосоединений локального устройства:

% l2control -a 00:02:72:00:d4:1a read_channel_list

L2CAP channels:

Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State

00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN

% l2control -a 00:02:72:00:d4:1a read_connection_list

L2CAP connections:

Remote BD_ADDR Handle Flags Pending State

00:07:e0:00:0b:ca 41 O 0 OPEN

Ещё одним диагностическим инструментом является btsockstat(1). Она выполняет действия, подобные тем, что обычно выполняет netstat(1), но со структурами данных, связанных с работой в сети Bluetooth. В примере ниже описывается то же самое логическое соединение, что и с l2control(8) выше.

% btsockstat

Active L2CAP sockets

PCB Recv-Q Send-Q Local address/PSM Foreign address CID State

c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN

Active RFCOMM sessions

L2PCB PCB Flag MTU Out-Q DLCs State

c2afe900 c2b53380 1 127 0 Yes OPEN

Active RFCOMM sockets

PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State

c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN
^

27.4.5. Протокол RFCOMM


Протокол RFCOMM эмулирует последовательные порты поверх протокола L2CAP. Он основан на ETSI-стандарте TS 07.10. RFCOMM представляет собой простой транспортный протокол, с дополнительными возможностями по эмуляции 9 цепей последовательных портов RS-232 (EIATIA-232-E). Протокол RFCOMM поддерживает одновременно до 60 соединений (каналов RFCOMM) между двумя устройствами Bluetooth.

В рамках RFCOMM полный коммуникационный маршрут включает два приложения, работающие на разных устройствах (конечные коммуникационные точки) с коммуникационным сегментом между ними. RFCOMM предназначен для сокрытия приложений, использующих последовательные порты устройств, в которых они расположены. Коммуникационный сегмент по сути является Bluetooth-связью от одного устройства к другому (прямое соединение).

RFCOMM имеет дело с соединением между устройствами в случае прямого соединения, или между устройством и модемом в сетевом случае. RFCOMM может поддерживать и другие конфигурации, такие, как модули, работающие через беспроводную технологию Bluetooth с одной стороны и предоставляющие проводное соединение с другой стороны.

Во FreeBSD протокол RFCOMM реализован на уровне сокетов Bluetooth.
^

27.4.6. Pairing of Devices


По умолчанию связь Bluetooth не аутентифицируется, поэтому любое устройство может общаться с любым другим. Устройство Bluetooth (например, сотовый телефон) может задать обязательность аутентификации для предоставления определённого сервиса (в частности, услугу доступа по коммутируемой линии). Bluetooth-аутентификация обычно выполняется через PIN-коды. PIN-код представляет из себя ASCII-строку длиной до 16 символов. Пользователь обязан ввести один и тот же PIN-код на обоих устройствах. Как только он введёт PIN-код, оба устройства сгенерируют ключ связи. После этого ключ может быть сохранён либо в самом устройстве, либо на постоянном носителе. В следующий раз оба устройства будут использовать ранее сгенерированный ключ соединения. Процедура, описанная выше, носит название подгонки пары (pairing). Заметьте, что если ключ связи потерян любой из сторон, то подбор пары должен быть повторен.

За обработку всех запросов на Bluetooth-аутентификацию отвечает даемон hcsecd(8). По умолчанию файл конфигурации называется /etc/bluetooth/hcsecd.conf. Пример раздела, содержащего информацию о сотовом телефоне с явно заданным PIN-кодом ''1234'' приведен ниже:

device {

bdaddr 00:80:37:29:19:a4;

name "Pav's T39";

key nokey;

pin "1234";

}

Кроме длины, на PIN-коды не накладывается никаких ограничений. Некоторые устройства (например, Bluetooth-гарнитуры) могут иметь фиксированный встроенный PIN-код. Параметр -d позволяет запустить hcsecd(8) как нефоновый процесс, что облегчает просмотр происходящих событий. Задайте получение парного ключа на удалённом устройстве и инициируйте Bluetooth-соединение с этим устройством. Удалённое устройство должно подтвердить получение пары и запросить PIN-код. Введите тот же самый код, что находится в hcsecd.conf. Теперь ваш ПК и удалённое устройство спарены. Альтернативным способом является инициация процесса создания пары на удалённом устройстве.

Во FreeBSD 5.5, 6.1 и в более новых, следующая строка может быть добавлена к /etc/rc.conf, чтобы hcsecd запускался автоматически во время старта системы:

hcsecd_enable="YES"

Ниже даётся пример выдачи протокола команды hcsecd:

hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4

hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist

hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4

hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4

hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists

hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4
^

27.4.7. Service Discovery Protocol (SDP)


Протокол обнаружения сервисов SDP даёт возможность клиентским приложениям осуществлять поиск услуг, предоставляемых серверными приложениями, а также характеристик этих услуг. В перечень атрибутов сервиса включается тип класса предлагаемого сервиса и информация о механизме или протоколе, требуемом для использования сервиса.

SDP подразумевает коммуникации между SDP-сервером и SDP-клиентом. Сервер поддерживает список сервисов, в котором описываются параметры сервисов, связанных с сервером. Каждая запись об услуге содержит информацию об одном сервисе. Клиент может запросить информацию об определённом сервисе, обслуживаемом SDP-сервером, выдавая SDP-запрос. Если клиент или приложение, связанное с клиентом, решат воспользоваться сервисом, то для его использования необходимо открыть отдельное соединение к устройству, предоставляющему сервис. SDP предоставляет механизм обнаружения услуг и их параметров, но не даёт механизма использования этих сервисов.

Обычно SDP-клиент выполняет поиск услуг на основе некоторых желаемых характеристик услуг. Однако иногда возникает необходимость выяснить полный перечень типов услуг, предоставляемых SDP-сервером, не имея никакой информации об имеющихся сервисах. Такой процесс всех предлагаемых сервисов называется обзором (browsing).

Bluetooth SDP сервер sdpd(8) и клиент с интерфейсом командной строки sdpcontrol(8) включены в стандартную поставку FreeBSD. В следующем примере показано, как выполнять запрос на SDP-обзор.

% sdpcontrol -a 00:01:03:fc:6e:ec browse

Record Handle: 00000000

Service Class ID List:

Service Discovery Server (0x1000)

Protocol Descriptor List:

L2CAP (0x0100)

Protocol specific parameter #1: u/int/uuid16 1

Protocol specific parameter #2: u/int/uuid16 1


Record Handle: 0x00000001

Service Class ID List:

Browse Group Descriptor (0x1001)


Record Handle: 0x00000002

Service Class ID List:

LAN Access Using PPP (0x1102)

Protocol Descriptor List:

L2CAP (0x0100)

RFCOMM (0x0003)

Protocol specific parameter #1: u/int8/bool 1

Bluetooth Profile Descriptor List:

LAN Access Using PPP (0x1102) ver. 1.0

... и так далее. Заметьте, что каждый сервис имеет перечень атрибутов (например, канал RFCOMM). В зависимости от сервиса вам может потребоваться где-то сохранить эти атрибуты. Некоторые реализации Bluetooth не поддерживают просмотр сервисов и могут возвращать пустой список. В этом случае возможен поиск конкретной услуги. В примере ниже показано, как выполнить поиск службы OBEX Object Push (OPUSH):

% sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH

Во FreeBSD предоставление сервисов клиентам Bluetooth осуществляется сервером sdpd(8). Во FreeBSD 5.5, 6.1 и в более новых, следующая строка может быть добавлена в файл /etc/rc.conf:

sdpd_enable="YES"

После этого sdpd даемон может быть запущен с помощью:

# /etc/rc.d/sdpd start

Во FreeBSD 6.0, и во FreeBSD 5.X перед 5.5, sdpd не интегрирован в скрипты загрузки системы. Он должен запускаться автоматически командой:

# sdpd

Приложение на локальном сервере, желающее предоставить сервис Bluetooth удаленным клиентам, регистрирует сервис через локального даемона SDP. Пример такого приложения — rfcomm_pppd(8). После запуска оно регистрирует Bluetooth LAN сервис через локального даемона SDP.

Список сервисов, зарегистрированных через локальный SDP сервер, может быть получен путем выдачи запроса на просмотр SDP через локальный контрольный канал:

# sdpcontrol -l browse
^

27.4.8. Доступ к сети по коммутируемой линии связи (DUN) и по протоколу PPP (LAN)


Модуль работы с коммутируемым доступом к сети (DUN - Dial-Up Networking) в большинстве случаев используется с модемами и сотовыми телефонами. Этот модуль покрывает следующие случаи:

• сотовый телефон или модем используется вместе с компьютером в качестве беспроводного модема для подключения к серверу коммутируемого доступа в Интернет, или другой коммутируемой услуге;

• сотовый телефон или модем используется компьютером для приёма входящих соединений.

Модуль доступа к сети по протоколу PPP (Network Access with PPP - LAN) может использоваться в следующих ситуациях:

• доступ к ЛВС для одного Bluetooth-устройства;

• доступ к ЛВС для нескольких Bluetooth-устройств;

• связь между двумя ПК (при помощи протокола PPP поверх эмулируемого последовательного канала связи).

Во FreeBSD оба случая реализуются при помощи сервисных программ ppp(8) и rfcomm_pppd(8) - это обработчик, преобразующий RFCOMM-соединения Bluetooth в нечто, с чем может работать PPP. Перед тем, как использовать любой модуль, в файле /etc/ppp/ppp.conf должна быть создана новая PPP-метка. Примеры использования можно найти в справочной странице к rfcomm_pppd(8).

В следующем примере rfcomm_pppd(8) будет использоваться для открытия RFCOMM-соединения к удалённому устройству с BD_ADDR 00:80:37:29:19:a4 на DUN RFCOMM-канале. Реальный номер RFCOMM-канала будет получаться с удалённого устройства через SDP. Возможно указать RFCOMM-канал вручную, и в этом случае rfcomm_pppd(8) не будет выполнять SDP-запрос. Для нахождения RFCOMM-канала на удалённом устройстве используйте утилиту sdpcontrol(8).

# rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup

Для того, чтобы организовать сервис Network Access with PPP (LAN), необходимо запустить сервер sdpd(8). В файле /etc/ppp/ppp.conf должна быть создана новая запись для клиентов LAN. Примеры можно найти в справке по rfcomm_pppd(8). Наконец, запустите RFCOMM PPP сервер на существующем номере канала RFCOMM. Сервер RFCOMM PPP автоматически зарегистрирует Bluetooth LAN сервис через локальный SDP даемон. В примере ниже показано, как запустить сервер RFCOMM PPP.

# rfcomm_pppd -s -C 7 -l rfcomm-server
^

27.4.9. OBEX Object Push (OPUSH) Profile


OBEX является широко используемым протоколом для простой передачи файлов между мобильными устройствами. В основном он используется в коммуникациях через инфракрасный порт для передачи файлов между ноутбуками или КПК, а также для пересылки визитных карточек или календарных планов между сотовыми телефонами и другими устройствами с персональными информационными менеджерами.

Сервер и клиент OBEX реализованы в виде пакета стороннего разработчика obexapp, который доступен в виде порта comms/obexapp.

Клиент OBEX используется для посылки или приёма объектов с сервера OBEX. Объектом, к примеру, может быть визитная карточка или указание. Клиент OBEX может получить номер RFCOMM-канала, указав вместо него имя сервиса. Поддерживаются следующие имена сервиса: IrMC, FTRN и OPUSH. Канал RFCOMM можно задать его номером. Ниже даётся пример сеанса OBEX, где с сотового телефона забирается объект с информацией об устройстве, а новый объект (визитная карточка) передаётся в каталог сотового телефона.

% obexapp -a 00:80:37:29:19:a4 -C IrMC

obex> get telecom/devinfo.txt devinfo-t39.txt

Success, response: OK, Success (0x20)

obex> put new.vcf

Success, response: OK, Success (0x20)

obex> di

Success, response: OK, Success (0x20)

Для того, чтобы предоставить сервис OBEX Push, должен быть запущен сервер sdpd(8). Должен быть создан корневой каталог, в котором будут сохраняться все поступающие объекты. По умолчанию корневым каталогом является /var/spool/obex. Наконец, запустите OBEX сервер на существующем номере канала RFCOMM. OBEX сервер автоматически зарегистрирует сервис OBEX Object Push через локального даемона SDP. В примере ниже показано, как запустить OBEX-сервер.

# obexapp -s -C 10
^

27.4.10. Профиль последовательного порта (SPP)


Профиль последовательного порта (SPP - Serial Port Profile) позволяет Bluetooth-устройствам осуществлять эмуляцию последовательного порта RS232 (или подобного). Этот профиль покрывает случаи, касающиеся работы унаследованных приложений с Bluetooth в качестве замены кабельному соединению, при это используется абстракция виртуального последовательного порта.

Утилита rfcomm_sppd(1) реализует профиль последовательного порта. В качестве виртуального последовательного порта используется псевдо-терминал. В примере ниже показано, как подключиться к сервису Serial Port удалённого устройства. Заметьте, что вы не указываете RFCOMM-канал - rfcomm_sppd(1) может получить его с удалённого устройства через SDP. Если вы хотите переопределить это, укажите RFCOMM-канал явно в командной строке.

# rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6

rfcomm_sppd[94692]: Starting on /dev/ttyp6...

После подключения псевдо-терминал можно использовать как последовательный порт:

# cu -l ttyp6
^

27.4.11. Решение проблем

27.4.11.1. Удалённое устройство не подключается

Некоторые старые Bluetooth-устройства не поддерживают переключение ролей. По умолчанию, когда FreeBSD подтверждает новое соединение, она пытается выполнить переключение роли и стать ведущим устройством. Устройства, которые это не поддерживают, не смогут подключиться. Заметьте, что переключение ролей выполняется при установлении нового соединения, поэтому невозможно выяснить, поддерживает ли удалённое устройство переключение ролей. На локальной машине имеется возможность отключить переключение ролей при помощи HCI-параметра:

# hccontrol -n ubt0hci write_node_role_switch 0
^
27.4.11.2. Что-то идёт не так, можно ли посмотреть, что в точности происходит?

Да, можно. Воспользуйтесь пакетом стороннего разработчика, hcidump который доступен в виде порта comms/hcidump. Утилита hcidump похожа на tcpdump(1). Она может быть использована для вывода на терминал содержимого Bluetooth-пакетов и сбрасывать пакеты Bluetooth в файл.

27.5. Мосты


Текст создал Steve Peterson.

27.5.1. Введение


Иногда полезно разделить одну физическую сеть (такую, как сегмент Ethernet) на два отдельных сегмента сети без необходимости создания подсетей IP и использования маршрутизатора для соединения сегментов. Устройство, которое соединяет две сети на такой манер, называется ''сетевым мостом'' (''bridge''). Система FreeBSD с двумя сетевыми адаптерами может выступать в роли моста.

Мост работает на основе изучения адресов уровня MAC (адресов Ethernet) устройств на каждом из своих сетевых интерфейсах. Он перенаправляет трафик между двумя сетями, только когда адреса отправителя и получателя находятся в разных сетях.

По многим параметрам мост работает также, как коммутатор Ethernet с малым количеством портов.
^

27.5.2. Ситуации, когда можно использовать мосты


На сегодняшний день есть две ситуации, когда можно использовать мост.
27.5.2.1. Большой трафик в сегменте

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

Давайте рассмотрим в качестве примера газету, в которой редакторский и производственный отделы находятся в одной и той же подсети. Пользователи в редакторском отделе все используют сервер A для служб доступа к файлам, а пользователи производственного отдела используют сервер B. Для объединения всех пользователей используется сеть Ethernet, а высокая нагрузка на сеть замедляет работу.

Если пользователи редакторского отдела могут быть собраны в одном сегменте сети, а пользователи производственного отдела в другом, то два сетевых сегмента можно объединить мостом. Только сетевой трафик, предназначенный для интерфейсов с ''другой'' стороны моста, будет посылаться в другую сеть, тем самым снижая уровень нагрузки на каждый сегмент сети.
^
27.5.2.2. Сетевой экран с возможностями фильтрации/ограничения пропускной способности трафика

Второй распространённой ситуацией является необходимость в обеспечении функций сетевого экрана без трансляции сетевых адресов (NAT).

Для примера можно взять маленькую компанию, которая подключена к своему провайдеру по каналу DSL или ISDN. Для неё провайдер выделил 13 глобально доступных IP-адресов для имеющихся в сети 10 персональных компьютеров. В такой ситуации использование сетевого экрана на основе маршрутизатора затруднено из-за проблем с разделением на подсети.

Брандмауэр на основе моста может быть настроен и включен между маршрутизаторами DSL/ISDN без каких-либо проблем с IP-адресацией.
^

27.5.3. Настройка моста

27.5.3.1. Выбор сетевого адаптера

Для работы моста требуются по крайней мере два сетевых адаптера. К сожалению, не все сетевые адаптеры во FreeBSD 4.0 поддерживают функции моста. Прочтите страницу Справочника по bridge(4) для выяснения подробностей о поддерживаемых адаптерах.

Перед тем, как продолжить, сначала установите и протестируйте два сетевых адаптера.
^
27.5.3.2. Изменения в конфигурации ядра

Для включения поддержки функций сетевого моста в ядре, добавьте строчку

options BRIDGE

в файл конфигурации вашего ядра, и перестройте ядро.
^
27.5.3.3. Поддержка функций брандмауэра

Если вы планируете использовать мост в качестве брандмауэра, вам нужно также добавить опцию IPFIREWALL. Прочтите Гл. 26, содержащую общую информацию о настройке моста в качестве брандмауэра.

Если вам необходимо обеспечить прохождение не-IP пакетов (таких, как ARP) через мост, то имеется опция брандмауэра, которую можно задать. Это опция IPFIREWALL_DEFAULT_TO_ACCEPT. Заметьте, что при этом правило, используемое брандмауэром по умолчанию, меняется на разрешительное для всех пакетов. Перед тем, как задавать эту опцию, убедитесь, что вы понимаете работу вашего набора правил.
^
27.5.3.4. Поддержка функций ограничения пропускной способности

Если вы хотите использовать мост в качестве машины, ограничивающей пропускную способность, то добавьте в файл конфигурации ядра опцию DUMMYNET. Дополнительную информацию можно почерпнуть из страницы Справочника по dummynet(4).
^

27.5.4. Включение функций моста


Добавьте строку

net.link.ether.bridge.enable=1

в файл /etc/sysctl.conf для включения функций моста во время работы системы, и строку:

net.link.ether.bridge.config=if1,if2

для включения функций моста для указанных интерфейсов (замените if1 и if2 на имена двух ваших сетевых интерфейсов). Если вы хотите, чтобы проходящие через мост пакеты фильтровались посредством ipfw(8), вы должны также добавить строчку:

net.link.ether.bridge.ipfw=1

Для версий FreeBSD, предшествующих FreeBSD 5.2-RELEASE, нужно использовать следующие строки:

net.link.ether.bridge=1

net.link.ether.bridge_cfg=if1,if2

net.link.ether.bridge_ipfw=1
^

27.5.5. Дополнительные замечания


Если вы хотите осуществлять удалённый доступ на мост через ssh(1) из сети, то корректно назначить одному из сетевых адаптеров IP-адрес. Общепринято, что назначение адреса обоим сетевым адаптерам является не самой хорошей идеей.

Если в вашей сети присутствует несколько мостов, не должно быть более одного маршрута между любыми двумя рабочими станциями. С технической точки зрения это означает отсутствие поддержки протокола spanning tree.

Сетевой мост может увеличить задержки в замерах командой ping(8), особенно для трафика между двумя разными сегментами.
^

27.6. Работа с бездисковыми станциями


Текст обновил Jean-Franзois Dockиs. Реорганизовал и улучшил Alex Dupre.

Машина с FreeBSD может загружаться по сети и работать без наличия локального диска, используя файловые системы, монтируемые с сервера NFS. Кроме стандартных конфигурационных файлов, не нужны никакие модификации в системе. Такую систему легко настроить, потому что все необходимые элементы уже готовы:

• Имеется по крайней мере два возможных способа загрузки ядра по сети:

• PXE: Система Intel Preboot eXecution Environment является формой загрузочного ПЗУ, встроенного в некоторые сетевые адаптеры или материнские платы. Обратитесь к справочной странице по pxeboot(8) для получения более полной информации.

• Порт Etherboot (net/etherboot) генерирует код, который может применяться в ПЗУ для загрузки ядра по сети. Код может быть либо прошит в загрузочный PROM на сетевом адаптере, либо загружен с локальной дискеты (или винчестера), или с работающей системы MS-DOS. Поддерживаются многие сетевые адаптеры.

• Примерный скрипт (/usr/share/examples/diskless/clone_root) облегчает создание и поддержку корневой файловой системы рабочей станции на сервере. Скрипт, скорее всего, потребует некоторых настроек, но он позволит вам быстро начать работу.

• Стандартные файлы начального запуска системы, располагающиеся в /etc, распознают и поддерживают загрузку системы в бездисковом варианте.

• Подкачка, если она нужна, может выполняться через файл NFS либо на локальный диск.

Существует много способов настройки бездисковой рабочей станции. При этом задействованы многие компоненты, и большинство из них могут быть настроены для удовлетворения ваших вкусов. Далее будет описаны варианты полной настройки системы, при этом упор будет делаться на простоту и совместимость с стандартной системой скриптов начальной загрузки FreeBSD. Описываемая система имеет такие характеристики:

• Бездисковые рабочие станции совместно используют файловую систему / в режиме только чтения, а также используют /usr совместно тоже в режиме только чтения.

Корневая файловая система является копией стандартной корневой системы FreeBSD (обычно сервера), с некоторыми настроечными файлами, измененными кем-то специально для бездисковых операций или, возможно, для рабочей станции, которой она предназначена.

Части корневой файловой системы, которые должны быть доступны для записи, перекрываются файловыми системами mfs(8) (FreeBSD 4.X) или md(4) (FreeBSD 5.X). Любые изменения будут потеряны при перезагрузках системы.

• Ядро передается и загружается посредством Etherboot или PXE, и в некоторых ситуациях может быть использован любой из этих методов.

Предостережение: Как описано, эта система не защищена. Она должна располагаться в защищенной части сети, а другие хосты не должны на нее полагаться.

Вся информация этого раздела была протестирована с релизами FreeBSD 4.9-RELEASE и 5.2.1-RELEASE. Текст структурирован преимущественно для использования с 4.X. Отличия для 5.X упоминаются особо.
^

27.6.1. Общая информация


Настройка бездисковых рабочих станций относительно проста, но в то же время легко сделать ошибку. Иногда сложно диагностировать эти ошибки по нескольким причинам. Например:

• Параметры компиляции могут по-разному проявлять себя во время работы.

• Сообщения об ошибках бывают загадочны или вовсе отсутствуют.

В данной ситуации некоторые знания, касающиеся используемых внутренних механизмов, очень полезны при разрешении проблем, которые могут возникнуть.

Для выполнения успешной загрузки необходимо произвести несколько операций:

• Компьютеру необходимо получить начальные параметры, такие как собственный IP адрес, имя исполняемого файла, корневой каталог. Для этого используются протоколы DHCP или BOOTP. DHCP это совместимое расширение BOOTP, используются те же номера портов и основной формат пакетов.

Возможна настройка системы для использования только BOOTP. Серверная программа bootpd(8) включена в основную систему FreeBSD.

Тем не менее, у DHCP есть множество преимуществ над BOOTP (лучше файлы настройки, возможность использования PXE, плюс многие другие преимущества, не относящиеся непосредственно к бездисковым операциям), и мы в основном будем описывать настройку DHCP, с эквивалентными примерами для bootpd(8), когда это возможно. Пример конфигурации будет использовать пакет ISC DHCP (релиз 3.0.1.r12 был установлен на тестовом сервере).

• Компьютеру требуется загрузить в локальную память одну или несколько программ. Используются TFTP или NFS. Выбор между TFTP или NFS производится во время компилирования в нескольких местах. Часто встречающаяся ошибка это указание имен файлов для другого протокола: TFTP обычно загружает все файлы с одного каталога сервера, и принимает имена файлов относительно этого каталога. NFS нужны абсолютные пути к файлам.

• Необходимо инициализировать и выполнить возможные промежуточные программы загрузки и ядро. В этой области существует несколько важных вариаций:

• PXE загрузит pxeboot(8), являющийся модифицированной версией загрузчика третьей стадии FreeBSD. loader(8) получит большинство параметров, необходимых для старта системы, и оставит их в окружении ядра до контроля передачи. В этом случае возможно использование ядра GENERIC.

Etherboot, непосредственно загрузит ядро, с меньшей подготовкой. Вам потребуется собрать ядро со специальными параметрами.

PXE и Etherboot работают одинаково хорошо с системами 4.X. Поскольку ядро 5.X обычно позволяет loader(8) выполнить больше предварительной работы, метод PXE на системах 5.X предпочтителен.

Если ваш BIOS и сетевые карты поддерживают PXE, используйте его. Однако, все же возможен запуск системы 5.X с Etherboot.

• Наконец, компьютеру требуется доступ к файловым системам. NFS используется во всех случаях.

Обратитесь также к странице справочника diskless(8).
^

27.6.2. Инструкции по настройке

27.6.2.1. Конфигурация с использованием ISC DHCP

Сервер ISC DHCP может обрабатывать как запросы BOOTP, так и запросы DHCP.

Начиная с релиза 4.9, ISC DHCP 3.0 не включается в поставку системы. Сначала вам нужно будет установить порт net/isc-dhcp3-server или соответствующий пакет.

После установки ISC DHCP ему для работы требуется конфигурационный файл (обычно называемый /usr/local/etc/dhcpd.conf). Вот прокомментированный пример, где хост margaux использует Etherboot, а хост corbieres использует PXE:

default-lease-time 600;

max-lease-time 7200;

authoritative;


option domain-name "example.com";

option domain-name-servers 192.168.4.1;

option routers 192.168.4.1;


subnet 192.168.4.0 netmask 255.255.255.0 {

use-host-decl-names on; 

option subnet-mask 255.255.255.0;

option broadcast-address 192.168.4.255;


host margaux {

hardware ethernet 01:23:45:67:89:ab;

fixed-address margaux.example.com;

next-server 192.168.4.4; 

filename "/data/misc/kernel.diskless"; 

option root-path "192.168.4.4:/data/misc/diskless"; 

}

host corbieres {

hardware ethernet 00:02:b3:27:62:df;

fixed-address corbieres.example.com;

next-server 192.168.4.4;

filename "pxeboot";

option root-path "192.168.4.4:/data/misc/diskless";

}

}

 Этот параметр указывает dhcpd посылать значения деклараций host как имя хоста для бездисковой машины. Альтернативным способом было бы добавление option host-name margaux внутри объявлений host.

 Директива next-server определяет сервер TFTP или NFS, используемый для получения загрузчика или файла ядра (по умолчанию используется тот же самый хост, на котором расположен сервер DHCP).

 Директива filename определяет файл, который Etherboot или PXE будут загружать для следующего шага выполнения. Он должен быть указан в соответствии с используемым методом передачи. Etherboot может быть скомпилирован для использования NFS или TFTP. FreeBSD порт по умолчанию использует NFS. PXE использует TFTP, поэтому здесь применяются относительные пути файлов (это может зависеть от настроек TFTP сервера, но обычно довольно типично). Кроме того, PXE загружает pxeboot, а не ядро. Существуют другие интересные возможности, такие как загрузка pxeboot из каталога /boot FreeBSD CD-ROM (поскольку pxeboot(8) может загружать GENERIC ядро, это делает возможной загрузку с удаленного CD-ROM).

 Параметр root-path определяет путь к корневой файловой системе, в обычной нотации NFS. При использовании PXE, можно оставить IP хоста отключенным, если параметр ядра BOOTP не используется. Затем NFS сервер может использоваться так же, как и TFTP.
^
27.6.2.2. Настройка с использованием BOOTP

Далее описана эквивалентная конфигурация с использованием bootpd (для одного клиента). Она будет располагаться в /etc/bootptab.

Пожалуйста, отметьте, что Etherboot должен быть откомпилирован с нестандартной опцией NO_DHCP_SUPPORT для того, чтобы можно было использовать BOOTP, и что для работы PXE необходим DHCP. Единственным очевидным преимуществом bootpd является его наличие в поставке системы.

.def100:\

:hn:ht=1:sa=192.168.4.4:vm=rfc1048:\

:sm=255.255.255.0:\

:ds=192.168.4.1:\

:gw=192.168.4.1:\

:hd="/tftpboot":\

:bf="/kernel.diskless":\

:rp="192.168.4.4:/data/misc/diskless":


margaux:ha=0123456789ab:tc=.def100


^
27.6.2.3. Подготовка программы загрузки при помощи Etherboot

Сайт Etherboot (http://etherboot.sourceforge.net) содержит подробную документацию (http://etherboot.sourceforge.net/doc/html/userman/t1.html), в основном предназначенную для систем Linux, но несомненно, она полезна. Далее будет просто кратко описано, как вы должны использовать Etherboot в системе FreeBSD.

Сначала вы должны установить пакет или порт net/etherboot.

Вы можете изменить настройку Etherboot (например, для использования TFTP вместо NFS) путем редактирования файла Config в каталоге исходных текстов Etherboot.

В нашей ситуации мы будем использовать загрузочную дискету. Для других методов (PROM или программа MS-DOS) пожалуйста, обратитесь к документации по Etherboot.

Для создания загрузочной дискеты, вставьте дискету в дисковод на машине, где установлен Etherboot, затем перейдите в каталог src в дереве Etherboot и наберите:

# gmake bin32/devicetype.fd0

devicetype зависит от типа адаптера Ethernet на бездисковой рабочей станции. Обратитесь к файлу NIC в том же самом каталоге для определения правильного значения для devicetype.
^
27.6.2.4. Загрузка с PXE

По умолчанию, pxeboot(8) загружает ядро через NFS. Он может быть скомпилирован для использования вместо него TFTP путем указания параметра LOADER_TFTP_SUPPORT в /etc/make.conf. Смотрите комментарии в /etc/defaults/make.conf (или /usr/share/examples/etc/make.conf систем 5.X) с инструкциями.

Есть два не документированных параметра make.conf, которые могут быть полезны для настройки бездискового компьютера с последовательной консолью: BOOT_PXELDR_PROBE_KEYBOARD, и BOOT_PXELDR_ALWAYS_SERIAL (последняя существует только в FreeBSD 5.X).

Для использования PXE при загрузке компьютера вам обычно потребуется выбрать параметр Boot from network (загрузка по сети) в настройках BIOS, или нажать функциональную клавишу во время загрузки PC.
^
27.6.2.5. Настройка серверов TFTP и NFS

Если вы используете PXE или Etherboot, настроенные для использования TFTP, вам нужно включить tftpd на файловом сервере:

1. Создайте каталог, файлы которого будет обслуживать tftpd, например, /tftpboot.

2. Добавьте в ваш /etc/inetd.conf такую строчку:

tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot

Замечание: Бывает, что некоторым версиям PXE требуется TCP-вариант TFTP. В таком случае добавьте вторую строчку, заменяющую dgram udp на stream tcp.

3. Укажите inetd на повторное чтение своего конфигурационного файла:

# kill -HUP `cat /var/run/inetd.pid`

Вы можете поместить каталог tftpboot в любом месте на сервере. Проверьте, что это местоположение указано как в inetd.conf, так и в dhcpd.conf.

Во всех случаях, вам также нужно включить NFS и экспортировать соответствующую файловую систему на сервере NFS.

1. Добавьте следующее в /etc/rc.conf:

nfs_server_enable="YES"

2. Экспортируйте файловую систему, в которой расположен корневой каталог для бездисковой рабочей станции, добавив следующую строку в /etc/exports (подправьте точку монтирования и замените margaux corbieres именами бездисковых рабочих станций):

/data/misc -alldirs -ro margaux corbieres

3. Укажите mountd на повторное чтение настроечного файла. На самом деле если вам потребовалось на первом шаге включить NFS в /etc/rc.conf, то вам нужно будет выполнить перезагрузку.

# kill -HUP `cat /var/run/mountd.pid`
^
27.6.2.6. Построение ядра для бездисковой рабочей станции

При использовании Etherboot, вам потребуется создать конфигурационный файл ядра для бездискового клиента со следующими параметрами (вдобавок к обычным):

options BOOTP # Use BOOTP to obtain IP address/hostname

options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info

Вам может потребоваться использовать BOOTP_NFSV3, BOOT_COMPAT и BOOTP_WIRED_TO (посмотрите LINT в 4.X или NOTES в 5.X).

Эти имена параметров сложились исторически, и могут немного ввести в заблуждение, поскольку включают необязательное использование DHCP и BOOTP в ядре (возможно включение обязательного использования BOOTP или DHCP use).

Постройте ядро (обратитесь к Гл. 8) и скопируйте его в каталог, указанный в dhcpd.conf.

Замечание: При использовании PXE, сборка ядра с вышеприведенными параметрами не является совершенно необходимой (хотя желательна). Включение этих параметров приведет к выполнению большинства DHCP запросов во время загрузки ядра, с небольшим риском несоответствия новых значений и значений, полученных pxeboot(8) в некоторых особых случаях. Преимущество использования в том, что в качестве побочного эффекта будет установлено имя хоста. Иначе вам потребуется установить имя хоста другим методом, например в клиент-специфичном файле rc.conf.

Замечание: Для включения возможности загрузки с Etherboot, в ядро 5.X необходимо включить устройство hints. Вам потребуется установить в файле конфигурации следующий параметр (см. файл комментариев NOTES):

hints "GENERIC.hints"
^
27.6.2.7. Подготовка корневой файловой системы

Вам нужно создать корневую файловую систему для бездисковых рабочих станций, в местоположении, заданном как root-path в dhcpd.conf. В следующем разделе описаны два способа, чтобы сделать это.
27.6.2.7.1. Использование скрипта clone_root

Это самый простой способ создания корневой файловой системы, но на данный момент он не поддерживается в FreeBSD 4.X. Этот shell скрипт находится в /usr/share/examples/diskless/clone_root, и требует настройки, по крайней мере, задания того места, где будет создана файловая система (переменная DEST).

Прочтите комментарии в начале скрипта для получения указаний. Там описано, как строится основная файловая система, и как файлы могут быть выборочно заменены версиями, предназначенными для работы без диска, для подсети или для отдельной рабочей станции. Также здесь даются примеры бездисковых файлов /etc/fstab и /etc/rc.conf.

Файлы README в /usr/share/examples/diskless много интересной информации, но вместе с другими примерами из каталога diskless они на самом деле описывают метод настройки, который отличается от того, что используется в clone_root и стартовых скриптах системы из /etc, этим несколько запутывая дело. Используйте их только для справки, за исключением того случая, когда вы выберете метод, ими описываемый, и тогда вам нужны исправленные скрипты rc.
27.6.2.7.2. Использование стандартной процедуры make world

Этот метод может быть применен к FreeBSD 4.X или 5.X и установит новую систему (не только корневую) в DESTDIR. Все, что вам потребуется сделать, это просто выполнить следующий скрипт:

#!/bin/sh

export DESTDIR=/data/misc/diskless

mkdir -p ${DESTDIR}

cd /usr/src; make world && make kernel

cd /usr/src/etc; make distribution

Как только это будет сделано, вам может потребоваться настроить /etc/rc.conf и /etc/fstab, помещенные в DESTDIR, в соответствии с вашими потребностями.
^
27.6.2.8. Настройка области подкачки

Если это нужно, то файл подкачки, расположенный на сервере, можно использовать посредством NFS. Один из методов, используемых для этого, не поддерживается в релизах 5.X.
27.6.2.8.1. Подкачка по NFS в FreeBSD 4.X

Местоположение и размер файла подкачки могут быть указаны FreeBSD-специфичными параметрами BOOTP/DHCP 128 и 129. Примеры файлов настройки для ISC DHCP 3.0 или bootpd приведены ниже:

1. Добавьте следующие строки в dhcpd.conf:

# Global section

option swap-path code 128 = string;

option swap-size code 129 = integer 32;


host margaux {

... # Standard lines, see above

option swap-path "192.168.4.4:/netswapvolume/netswap";

option swap-size 64000;

}

swap-path это путь к каталогу, где находятся файлы подкачки. Название каждого файла имеет вид swap.client-ip.

Старые версии dhcpd использовали синтаксис option option-128 "..., который больше не поддерживается.

Во /etc/bootptab будет использоваться такой синтаксис:

T128="192.168.4.4:/netswapvolume/netswap":T129=0000fa00

Замечание: В файле /etc/bootptab размер файла подкачки должен быть записан в шестнадцатеричном формате.

2. На файловом сервере NFS создайте файл (или файлы) подкачки:

# mkdir /netswapvolume/netswap

# cd /netswapvolume/netswap

# dd if=/dev/zero bs=1024 count=64000 of=swap.192.168.4.6

# chmod 0600 swap.192.168.4.6

192.168.4.6 является IP-адресом бездискового клиента.

3. На файловом сервере NFS, в /etc/exports добавьте такую строку:

/netswapvolume -maproot=0:10 -alldirs margaux corbieres

Затем укажите mountd на повторное чтение файла exports, как описано ранее.
27.6.2.8.2. Подкачка по NFS в FreeBSD 4.X

Положение и размер файла подкачки могут быть указаны в FreeBSD-специфичных параметрах BOOTP/DHCP с номерами 128 и 129. Ниже приведены примеры файлов настройки для ISC DHCP 3.0 или bootpd:

1. Добавьте следующие строки к dhcpd.conf:

# Global section

option swap-path code 128 = string;

option swap-size code 129 = integer 32;


host margaux {

... # Standard lines, see above

option swap-path "192.168.4.4:/netswapvolume/netswap";

option swap-size 64000;

}

swap-path это путь к каталогу, где расположены файлы подкачки. Файлы называются swap.client-ip.

Старые версии dhcpd используют синтаксис option option-128 "..., которые более не поддерживаются.

/etc/bootptab вместо этого использует следующий синтаксис:

T128="192.168.4.4:/netswapvolume/netswap":T129=0000fa00

Замечание: В /etc/bootptab, размер подкачки должен вычисляться в шестнадцатеричном формате.

2. Создайте на NFS сервере с файлами подкачки файлы:

# mkdir /netswapvolume/netswap

# cd /netswapvolume/netswap

# dd if=/dev/zero bs=1024 count=64000 of=swap.192.168.4.6

# chmod 0600 swap.192.168.4.6

192.168.4.6 это IP адрес бездискового клиента.

3. На файловом сервере NFS с файлами подкачки добавьте следующую строку к /etc/exports:

/netswapvolume -maproot=0:10 -alldirs margaux corbieres

Затем заставьте mountd перечитать конфигурационные файлы как было показано выше.
^
27.6.2.9. Различные проблемы
27.6.2.9.1. Работа с /usr, доступной только для чтения

Если бездисковая рабочая станция настроена на запуск X, вам нужно подправить настроечный файл для XDM, который по умолчанию помещает протокол ошибок в /usr.
27.6.2.9.2. Использование не-FreeBSD сервера

Если сервер с корневой файловой системой работает не под управлением FreeBSD, вам потребуется создать корневую файловую систему на машине FreeBSD, а затем скопировать ее в нужно место, при помощи tar или cpio.

В такой ситуации иногда возникают проблемы со специальными файлами в /dev из-за различной разрядности целых чисел для старшего/младшего чисел. Решением этой проблемы является экспортирование каталога с не-FreeBSD сервера, монтирование его на машине с FreeBSD и запуск скрипта MAKEDEV на машине с FreeBSD для создания правильных файлов устройств (во FreeBSD 5.0 и более поздних версиях используется devfs(5) для создания файлов устройств прозрачно для пользователя, запуск MAKEDEV в этих версиях бессмысленно).

27.7. ISDN


Полезным источником информации о технологии ISDN и его аппаратном обеспечении является Страница Дэна Кегела (Dan Kegel) об ISDN (http://www.alumni.caltech.edu/~dank/isdn/).

Быстрое введение в ISDN:

• Если вы живёте в Европе, то вам может понадобиться изучить раздел об ISDN-адаптерах.

• Если вы планируете использовать ISDN в основном для соединений с Интернет через провайдера по коммутируемому, не выделенному соединению, рекомендуется посмотреть информацию о терминальных адаптерах. Это даст вам самую большую гибкость и наименьшее количество проблем при смене провайдера.

• Если вы объединяете две локальные сети или подключаетесь к Интернет через постоянное ISDN-соединение, рекомендуем остановить свой выбор на отдельном мосте/маршрутизаторе.

Стоимость является важным фактором при выборе вашего решения. Далее перечислены все возможности от самого дешевого до самого дорогого варианта.
^

27.7.1. Адаптеры ISDN


Текст предоставил Hellmuth Michaelis.

Реализация ISDN во FreeBSD поддерживает только стандарт DSS1/Q.931 (или Евро-ISDN) при помощи пассивных адаптеров. Начиная с FreeBSD 4.4 поддерживаются некоторые активные адаптеры, прошивки которых поддерживают также другие сигнальные протоколы; также сюда впервые включена поддержка адаптеров ISDN Primary Rate (PRI).

Пакет программ isdn4bsd позволяет вам подключаться к другим маршрутизаторам ISDN при помощи IP поверх DHLC, либо при помощи синхронного PPP; либо при помощи PPP на уровне ядра с isppp, модифицированного драйвера sppp(4), или при помощи пользовательского ppp(8). При использовании пользовательского ppp(8) возможно использование двух и большего числа B-каналов ISDN. Также имеется приложение, работающее как автоответчик, и много утилит, таких, как программный модем на 300 Бод.

Во FreeBSD поддерживается все возрастающее число адаптеров ISDN для ПК, и сообщения показывают, что они успешно используются по всей Европе и других частях света.

Из пассивных адаптеров ISDN поддерживаются в основном те, которые сделаны на основе микросхем Infineon (бывший Siemens) ISAC/HSCX/IPAC ISDN, а также адаптеры ISDN с микросхемами от Cologne Chip (только для шины ISA), адаптеры PCI с микросхемами Winbond W6692, некоторые адаптеры с набором микросхем Tiger300/320/ISAC и несколько адаптеров, построенных на фирменных наборах микросхем, такие, как AVM Fritz!Card PCI V.1.0 и AVM Fritz!Card PnP.

На данный момент из активных адаптеров ISDN поддерживаются AVM B1 (ISA и PCI) адаптеры BRI и AVM T1 PCI адаптеры PRI.

Документацию по isdn4bsd можно найти в каталоге /usr/share/examples/isdn/ вашей системы FreeBSD или на домашней странице isdn4bsd (http://www.freebsd-support.de/i4b/), на которой также размещены ссылки на советы, замечания по ошибкам и более подробную информацию, например, на руководство по isdn4bsd (http://people.FreeBSD.org/~hm/).

Если вы заинтересованы в добавлении поддержки для различных протоколов ISDN, не поддерживаемых на данный момент адаптеров ISDN для PC или каких-то других усовершенствованиях isdn4bsd, пожалуйста, свяжитесь с Hellmuth Michaelis .

Для обсуждения вопросов, связанных с установкой, настройкой и устранением неисправностей isdn4bsd, имеется список рассылки freebsd-isdn (http://lists.FreeBSD.org/mailman/listinfo/freebsd-isdn).

subscribe freebsd-isdn
^

27.7.2. Терминальные адаптеры ISDN


Терминальные адаптеры (TA) для ISDN выполняют ту же роль, что и модемы для обычных телефонных линий.

Большинство TA используют стандартный набор AT-команд Hayes-модемов, и могут использоваться в качестве простой замены для модемов.

TA будут работать точно так же, как и модемы, за исключением скорости соединения и пропускной способности, которые будут гораздо выше, чем у вашего старого модема. Вам потребуется настроить PPP точно также, как и в случае использования модема. Проверьте, что вы задали скорость работы последовательного порта максимально высокой.

Главным преимуществом использования TA для подключения к провайдеру Интернет является возможность использования динамического PPP. Так как пространство адресов IP истощается все больше, большинство провайдеров не хочет больше выдавать вам статический IP-адрес. Большинство же маршрутизаторов не может использовать динамическое выделение IP-адресов.

TA полностью полагаются на даемон PPP, который используете из-за его возможностей и стабильности соединения. Это позволяет вам при использовании FreeBSD легко заменить модем на ISDN, если у вас уже настроено соединение PPP. Однако, в тоже время любые проблемы, которые возникают с программой PPP, отражаются и здесь.

Если вы хотите максимальной надёжности, используйте PPP на уровне параметра ядра, а не пользовательский PPP.

Известно, что следующие TA работают с FreeBSD:

• Motorola BitSurfer и Bitsurfer Pro

• Adtran

Большинство остальных TA, скорее всего, тоже будут работать, производители TA прилагают все усилия для обеспечения поддержки практически всего набора стандартных AT-команд модема.

Как и в случае модемов проблемой использования внешнего TA является потребность в хорошем последовательном адаптере на вашем компьютере.

Вы должны прочесть учебник Последовательные устройства во FreeBSD (http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/serial-uart/index.html) для того, чтобы в деталях понять работу последовательных устройств и осознать различие между асинхронными и синхронными последовательными портами.

TA, работающий со стандартным последовательным (асинхронным) портом PC, ограничивает вас скоростью 115.2 Кбит/с, хотя реально у вас соединение на скорости 128 Кбит/с. Чтобы использовать 128 Кбит/с, которые обеспечивает ISDN, полностью, вы должны подключить TA к синхронному последовательному адаптеру.

Не обманывайте себя, думая, что покупка встроенного TA поможет избежать проблемы синхронности/асинхронности. Встроенные TA просто уже имеют внутри стандартный последовательный порт PC. Все, что при этом достигается - это экономия дополнительных последовательного кабеля и электрической розетки.

Синхронный адаптер с TA по крайней мере так же быстр, как и отдельный маршрутизатор, а если он работает под управлением машины класса 386 с FreeBSD, то это гораздо более гибкое решение.

Выбор между использованием синхронного адаптера/TA или отдельного маршрутизатора в большей степени является религиозным вопросом. По этому поводу в списках рассылки была некоторая дискуссия. Рекомендуем поискать в архивах (http://www.FreeBSD.org/search/index.html) обсуждение полностью.
^

27.7.3. Отдельные мосты/маршрутизаторы ISDN


Мосты или маршрутизаторы ISDN не так уж специфичны для FreeBSD или для любой другой операционной системы. Для более подробного описания технологий маршрутизации и работы мостов, пожалуйста, обратитесь к справочникам по сетевым технологиям.

В контексте этого раздела термины маршрутизатор и сетевой мост будут использоваться как взаимозаменяемые.

Вместе с падением цен на простые мосты/маршрутизаторы ISDN, они становятся все более популярными. Маршрутизатор ISDN представляет собой маленькую коробочку, которая подключается непосредственно в вашу сеть Ethernet, и поддерживает связь с другим мостом/маршрутизатором. Всё программное обеспечение для работы по PPP и другим протоколам встроено в маршрутизатор.

Маршрутизатор обладает гораздо большей пропускной способностью, чем стандартный TA, так как он использует полное синхронное соединение ISDN.

Основной проблемой с маршрутизаторами и мостами ISDN является то, что их совместная работа с оборудованием других производителей может оказаться под вопросом. Если вы собираетесь подключаться к провайдеру, то вы должны обсудить с ним то, что вам нужно.

Если вы планируете объединить два сегмента локальной сети, например, домашнюю сеть с сетью офиса, это самое простое решение с минимальными издержками на обслуживание. Так как вы покупаете оборудование для обоих сторон соединения, то можете быть уверены, что связь будет работать нормально.

Например, для соединения домашнего компьютера или сети подразделения к сети центрального офиса, может использоваться такая настройка:

^ Пример 27-1. Офис подразделения или домашняя сеть

Сеть построена в топологии общей шины на основе 10 base 2 Ethernet (''thinnet'' - ''тонкий Ethernet''). Подключите маршрутизатор к сетевому кабелю с помощью трансивера AUI/10BT, если это нужно.



Подобная конфигурация часто используется для совместного использования доступа в Интернет. Одна из подключенных к локальной сети машин подключается к Интернет. Остальные машины работают с Интернет посредством этой ''шлюзовой'' машины.

27.8.3. Настройка


В файле конфигурации ядра должны присутствовать следующие параметры:

options IPFIREWALL

options IPDIVERT

Дополнительно, если это нужно, можно добавить следующее:

options IPFIREWALL_DEFAULT_TO_ACCEPT

options IPFIREWALL_VERBOSE

В файле /etc/rc.conf должны быть такие строки:

gateway_enable="YES" 

firewall_enable="YES" 

firewall_type="OPEN" 

natd_enable="YES"

natd_interface="fxp0" 

natd_flags="" 

 Указывает машине выступать в качестве шлюза. Выполнение команды sysctl net.inet.ip.forwarding=1 приведёт к тому же самому результату.

 При загрузке включает использование правил брандмауэра из файла /etc/rc.firewall.

 Здесь задается предопределенный набор правил брандмауэра, который разрешает все. Посмотрите файл /etc/rc.firewall для нахождения дополнительных типов.

 Указывает, через какой интерфейс передавать пакеты (интерфейс, подключенный к Интернет).

 Любые дополнительный параметры, передаваемые при запуске даемону natd(8).

При использовании вышеуказанных параметров в файле /etc/rc.conf при загрузке будет запущена команда natd -interface fxp0. Эту команду можно запустить и вручную.

Замечание: Если для передачи natd(8) набирается слишком много параметров, возможно также использовать конфигурационный файл. В этом случае имя настроечного файла должно быть задано добавлением следующей строки в /etc/rc.conf:

natd_flags="-f /etc/natd.conf"

Файл /etc/natd.conf будет содержать перечень конфигурационных параметров, по одному в строке. К примеру, для примера из следующего раздела будет использоваться такой файл:

redirect_port tcp 192.168.0.2:6667 6667

redirect_port tcp 192.168.0.3:80 80

Для получения более полной информации о конфигурационном файле прочтите страницу справки по natd(8) относительно параметра -f.

Каждой машине и интерфейсу в ЛВС должен быть назначен IP-адрес из адресного пространства частных сетей, как это определено в RFC 1918 (ftp://ftp.isi.edu/in-notes/rfc1918.txt), а в качестве маршрутизатора по умолчанию должен быть задан IP-адрес машины с natd из внутренней сети.

Например, клиенты A и B в ЛВС имеют IP-адреса 192.168.0.2 и 192.168.0.3, а интерфейс машины с natd в локальной сети имеет IP-адрес 192.168.0.1. Маршрутизатором по умолчанию для клиентов A и B должна быть назначена машина с natd, то есть 192.168.0.1. Внешний, или Интернет-интерфейс машины с natd не требует особых настроек для работы natd(8).
^

27.8.4. Перенаправление портов


Минусом использования natd(8) является то, что машины в локальной сети недоступны из Интернет. Клиенты в ЛВС могут выполнять исходящие соединения во внешний мир, но не могут обслуживать входящие. Это является проблемой при запуске служб Интернет на клиентских машинах в локальной сети. Простым решением является перенаправление некоторых портов Интернет машины с natd на клиента локальной сети.

Пусть, к примеру, сервер IRC запущен на клиенте A, а Web-сервер работает на клиенте B. Чтобы это работало, соединения, принимаемые на портах 6667 (IRC) и 80 (Web), должны перенаправляться на соответствующие машины.

Программе natd(8) должна быть передана команда -redirect_port с соответствующими параметрами. Синтаксис следующий:

-redirect_port proto targetIP:targetPORT[-targetPORT]

[aliasIP:]aliasPORT[-aliasPORT]

[remoteIP[:remotePORT[-remotePORT]]]

В примере выше аргументы должен быть такими:

-redirect_port tcp 192.168.0.2:6667 6667

-redirect_port tcp 192.168.0.3:80 80

При этом будут перенаправлены соответствующие порты tcp на клиентские машины в локальной сети.

Аргумент -redirect_port может использоваться для указания диапазонов портов, а не конкретного порта. Например, tcp 192.168.0.2:2000-3000 2000-3000 будет перенаправлять все соединения, принимаемые на портах от 2000 до 3000, на порты от 2000 до 3000 клиента A.

Эти параметры можно указать при непосредственном запуске natd(8), поместить их в параметр natd_flags="" файла /etc/rc.conf, либо передать через конфигурационный файл.

Для получение информации о других параметрах настройки обратитесь к справочной странице по natd(8)
^

27.8.5. Перенаправление адреса


Перенаправление адреса полезно, если имеется несколько адресов IP, и они должны быть на одной машине. В этой ситуации natd(8) может назначить каждому клиенту ЛВС свой собственный внешний IP-адрес. Затем natd(8) преобразует исходящие от клиентов локальной сети пакеты, заменяя IP-адреса на соответствующие внешние, и перенаправляет весь трафик, входящий на некоторый IP-адрес, обратно конкретному клиенту локальной сети. Это также называют статическим NAT. К примеру, пусть IP-адреса 128.1.1.1, 128.1.1.2 и 128.1.1.3 принадлежат шлюзовой машине natd. 128.1.1.1 может использоваться в качестве внешнего IP-адреса шлюзовой машины natd, тогда как 128.1.1.2 и 128.1.1.3 будут перенаправляться обратно к клиентам ЛВС A и B.

Синтаксис для -redirect_address таков:

-redirect_address localIP publicIP

localIP

Внутренний IP-адрес клиента локальной сети.

publicIP

Внешний IP, соответствующий клиенту локальной сети.




Скачать 14.45 Mb.
оставить комментарий
страница22/27
Дата18.10.2011
Размер14.45 Mb.
ТипРуководство, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы: 1   ...   19   20   21   22   23   24   25   26   27
отлично
  1
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Документы

Рейтинг@Mail.ru
наверх