Глава 27. Сложные вопросы работы в сети

Этот перевод может быть устаревшим. Для того, чтобы помочь с переводом, пожалуйста, обратитесь к Сервер переводов FreeBSD.

27.1. Краткий обзор

Эта глава охватывает множество различных сетевых тематик повышенной сложности.

После чтения этой главы вы будете знать:

  • Основные понятия о маршрутизации и маршрутах.

  • Как настроить IEEE 802.11 и Bluetooth®.

  • Как заставить FreeBSD работать в качестве сетевого моста.

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

  • Как настроить трансляцию сетевых адресов.

  • Как соединить два компьютера посредством PLIP.

  • Как настроить IPv6 на машине FreeBSD.

  • Как настроить ATM.

Перед чтением этой главы вы должны:

  • Понимать основы работы скриптов /etc/rc.

  • Свободно владеть основными сетевыми терминами.

  • Знать как настраивать и устанавливать новое ядро FreeBSD (Настройка ядра FreeBSD).

  • Знать как устанавливать дополнительное программное обеспечение сторонних разработчиков (Установка приложений. порты и пакеты).

27.2. Сетевые шлюзы и маршруты

Чтобы некоторая машина могла найти в сети другую, должен иметься механизм описания того, как добраться от одной машине к другой. Такой механизм называется маршрутизацией. "Маршрут" задаётся парой адресов: "адресом назначения" (destination) и "сетевым шлюзом" (gateway). Эта пара указывает на то, что если Вы пытаетесь соединиться с адресом назначения, то вам нужно устанавливать связь через "сетевой шлюз". Существует три типа адресов назначения: отдельные хосты, подсети и "маршрут по умолчанию" (default). "Маршрут по умолчанию" (default route) используется, если не подходит ни один из других маршрутов. Мы поговорим немного подробнее о маршрутах по умолчанию позже. Также имеется и три типа сетевых шлюзов: отдельные хосты, интерфейсы (также называемые "подключениями" (links)) и аппаратные адреса Ethernet (MAC-адреса).

27.2.1. Пример

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

% netstat -r
Routing tables

Destination      Gateway            Flags     Refs     Use     Netif Expire

default 	 outside-gw	    UGSc       37      418	ppp0
localhost	 localhost	    UH		0      181	 lo0
test0		 0:e0:b5:36:cf:4f   UHLW	5    63288	 ed0	 77
10.20.30.255	 link#1 	    UHLW	1     2421
example.com	 link#1 	    UC		0	 0
host1		 0:e0:a8:37:8:1e    UHLW	3     4601	 lo0
host2		 0:e0:a8:37:8:1e    UHLW	0	 5	 lo0 =>
host2.example.com link#1 	    UC		0	 0
224		 link#1 	    UC		0	 0

В первых двух строках задаются маршрут по умолчанию (который будет описан в следующем разделе) и маршрут на localhost.

Интерфейс (колонка Netif), который указан в этой таблице маршрутов для использования с localhost и который назван lo0, имеет также второе название, устройство loopback. Это значит сохранение всего трафика для указанного адреса назначения внутри, без посылки его по сети, так как он все равно будет направлен туда, где был создан.

Следующими выделяющимися адресами являются адреса, начинающиеся с 0:e0:…​. Это аппаратные адреса Ethernet, или MAC-адреса. FreeBSD будет автоматически распознавать любой хост (в нашем примере это test0) в локальной сети Ethernet и добавит маршрут для этого хоста, указывающий непосредственно на интерфейс Ethernet, ed0. С этим типом маршрута также связан параметр таймаута (колонка Expire), используемый в случае неудачной попытки услышать этот хост в течении некоторого периода времени. Если такое происходит, то маршрут до этого хоста будет автоматически удалён. Такие хосты поддерживаются при помощи механизма, известного как RIP (Routing Information Protocol), который вычисляет маршруты к хостам локальной сети при помощи определения кратчайшего расстояния.

FreeBSD добавит также все маршруты к подсетям для локальных подсетей (10.20.30.255 является широковещательным адресом для подсети 10.20.30, а имя example.com является именем домена, связанным с этой подсетью). Назначение link#1 соответствует первому адаптеру Ethernet в машине. Отметьте отсутствие дополнительного интерфейса для этих строк.

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

Строка host1 относится к нашему хосту, который известен по адресу Ethernet. Так как мы являемся посылающим хостом, FreeBSD знает, что нужно использовать loopback-интерфейс (lo0) вместо того, чтобы осуществлять посылку в интерфейс Ethernet.

Две строки host2 являются примером того, что происходит при использовании алиасов в команде ifconfig(8) (обратитесь к разделу об Ethernet для объяснения того, почему мы это делаем). Символ после интерфейса lo0 указывает на то, что мы используем не просто интерфейс loopback (так как это адрес, обозначающий локальный хост), но к тому же это алиас. Такие маршруты появляются только на хосте, поддерживающем алиасы; для всех остальных хостов в локальной сети для таких маршрутов будут показаны просто строчки link#1.

Последняя строчка (подсеть назначения 224) имеет отношение к многоадресной посылке, которая будет рассмотрена в другом разделе.

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

U

Up: Маршрут актуален.

H

Host: Адресом назначения является отдельный хост.

G

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

S

Static: Маршрут был настроен вручную, а не автоматически сгенерирован системой.

C

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

W

WasCloned: Указывает на то, что маршрут был автоматически сконфигурирован на основе маршрута в локальной сети (Clone).

L

Link: Маршрут включает ссылку на аппаратный адрес Ethernet.

27.2.2. Маршруты по умолчанию

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

Если все известные маршруты не подходят, у системы имеется последняя возможность: маршрут "default". Это маршрут с особым типом сетевого шлюза (обычно единственным, присутствующим в системе), и в поле флагов он всегда помечен как c. Для хостов в локальной сети этот сетевой шлюз указывает на машину, имеющую прямое подключение к внешнему миру (неважно, используется ли связь по протоколу PPP, канал DSL, кабельный модем, T1 или какой-то другой сетевой интерфейс).

Если вы настраиваете маршрут по умолчанию на машине, которая сама является сетевым шлюзом во внешний мир, то маршрутом по умолчанию будет являться сетевой шлюз у Вашего провайдера Интернет (ISP).

Давайте взглянем на примеры маршрутов по умолчанию. Вот типичная конфигурация:

net routing

Хосты Local1 и Local2 находятся в нашей сети. Local1 подключён к ISP через коммутируемое соединение по протоколу PPP. Этот компьютер с сервером PPP подключён посредством локальной сети к другому шлюзовому компьютеру через внешний интерфейс самого ISP к Интернет.

Маршруты по умолчанию для каждой из ваших машин будут следующими:

ХостМаршрут по умолчаниюИнтерфейс

Local2

Local1

Ethernet

Local1

T1-GW

PPP

Часто задаётся вопрос "Почему (или каким образом) в качестве шлюза по умолчанию для машины Local1 мы указываем T1-GW, а не сервер провайдера, к которому подключаемся?".

Запомните, что из-за использования PPP-интерфейсом адреса в сети провайдера Интернет с вашей стороны соединения, маршруты для всех других машин в локальной сети провайдера будут сгенерированы автоматически. Таким образом, вы уже будете знать, как достичь машины T1-GW, так что нет нужды в промежуточной точке при посылке трафика к серверу ISP.

В локальных сетях адрес X.X.X.1 часто используется в качестве адреса сетевого шлюза. Тогда (при использовании того же самого примера) если пространство адресов класса C вашей локальной сети было задано как 10.20.30, а ваш провайдер использует 10.9.9, то маршруты по умолчанию будут такие:

ХостМаршрут по умолчанию

Local2 (10.20.30.2)

Local1 (10.20.30.1)

Local1 (10.20.30.1, 10.9.9.30)

T1-GW (10.9.9.1)

Вы можете легко задать используемый по умолчанию маршрутизатор посредством файла /etc/rc.conf. В нашем примере на машине Local2 мы добавили такую строку в файл /etc/rc.conf:

defaultrouter="10.20.30.1"

Это также возможно сделать и непосредственно из командной строки при помощи команды route(8):

# route add default 10.20.30.1

Для получения дополнительной информации об управлении таблицами маршрутизации обратитесь к справочной странице по команде route(8).

27.2.3. Хосты с двойным подключением

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

В одном случае у машины имеется два адаптера Ethernet, каждый имеющий адрес в разделенных подсетях. Как альтернативу можно рассмотреть вариант с одним Ethernet-адаптером и использованием алиасов в команде ifconfig(8). В первом случае используются два физически разделённые сети Ethernet, в последнем имеется один физический сегмент сети, но две логически разделённые подсети.

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

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

27.2.4. Построение маршрутизатора

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

gateway_enable=YES          # Set to YES if this host will be a gateway

Этот параметр изменит значение sysctl(8)-переменной net.inet.ip.forwarding в 1. Если вам временно нужно выключить маршрутизацию, вы можете на время сбросить это значение в 0.

Вашему новому маршрутизатору нужна информация о маршрутах для того, чтобы знать, куда пересылать трафик. Если ваша сеть достаточно проста, то вы можете использовать статические маршруты. С FreeBSD также поставляется стандартный даемон BSD для маршрутизации routed(8), который умеет работать с RIP (как версии 1, так и версии 2) и IRDP. Поддержка BGP v4, OSPF v2 и других сложных протоколов маршрутизации имеется в пакете net/zebra. Также существуют и коммерческие продукты, применяемые как более комплексное решение проблемы маршрутизации в сети, такие как GateD®.

27.2.5. Настройка статических маршрутов

27.2.5.1. Ручная настройка

Предположим, что у нас есть следующая сеть:

static routes

В этом сценарии, RouterA это наш компьютер с FreeBSD, который выступает в качестве маршрутизатора в сеть Интернет. Его маршрут по умолчанию настроен на 10.0.0.1, что позволяет ему соединяться с внешним миром. Мы будем предполагать, что RouterB уже правильно настроен и знает все необходимые маршруты (на этом рисунке все просто; добавьте на RouterB маршрут по умолчанию, используя 192.168.1.1 в качестве шлюза).

Если мы посмотрим на таблицу маршрутизации RouterA, то увидим примерно следующее:

% netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif  Expire
default            10.0.0.1           UGS         0    49378    xl0
127.0.0.1          127.0.0.1          UH          0        6    lo0
10.0.0/24          link#1             UC          0        0    xl0
192.168.1/24       link#2             UC          0        0    xl1

С текущей таблицей маршрутизации RouterA не сможет достичь внутренней сети 2 (Internal Net 2). Один из способов обхода этой проблемы - добавление маршрута вручную. Следующая команда добавляет внутреннюю сеть 2 к таблице маршрутизации RouterA с 192.168.1.2 в качестве следующего узла:

# route add -net 192.168.2.0/24 192.168.1.2

Теперь RouterA сможет достичь любого хоста в сети 192.168.2.0/24.

27.2.5.2. Постоянная конфигурация

Предыдущий пример прекрасно подходит для настройки статического маршрута в работающей системе. Однако, проблема заключается в том, что маршрутная информация не сохранится после перезагрузки FreeBSD. Способ сохранения добавленного маршрута заключается в добавлении его в файл /etc/rc.conf:

# Добавление статического маршрута в Internal Net 2
static_routes="internalnet2"
route_internalnet2="-net 192.168.2.0/24 192.168.1.2"

В переменной static_routes находятся строки, разделенные пробелами. Каждая строка означает имя маршрута. В примере выше в static_routes есть только одна строка, это internalnet2. Затем мы добавили переменную route__internalnet2_, куда помещены все параметры, которые необходимо передать команде route(8). В примере выше была использована команда:

# route add -net 192.168.2.0/24 192.168.1.2

поэтому нам потребуется "-net 192.168.2.0/24 192.168.1.2".

Как было сказано выше, мы можем добавить в static_routes более чем одну строку. Это позволит создать несколько статических маршрутов. В следующем примере показано добавление маршрутов для сетей 192.168.0.0/24 и 192.168.1.0/24 (этот маршрутизатор не показан на рисунке выше:

static_routes="net1 net2"
route_net1="-net 192.168.0.0/24 192.168.0.1"
route_net2="-net 192.168.1.0/24 192.168.1.1"

27.2.6. Распространение маршрутов

Мы уже говорили о том, как мы задаем наши маршруты во внешний мир, но не упоминали о том, как внешний мир находит нас.

Мы уже знаем, что таблицы маршрутизации могут быть настроены так, что весь трафик для некоторого диапазона адресов (в нашем примере это подсеть класса C) может быть направлен заданному хосту в той сети, которая будет перенаправлять входящие пакеты дальше.

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

Существует система (подобная распределению информации DNS), которая отслеживает все назначенные пространства адресов и определяет точку подключения к магистрали Интернет. "Магистралью" называют главные каналы, по которым идет трафик Интернет внутри страны и по всему миру. Каждая магистральная машина имеет копию основного набора таблиц, согласно которой трафик для конкретной сети направляется по конкретному магистральному каналу, и затем, передаваясь по цепочке провайдеров, он достигает вашей сети.

Задачей вашего провайдера является объявить на магистрали о том, что он отвечает за подключение (и поэтому на него указывает маршрут) вашей сети. Этот процесс называется распространением маршрута.

27.2.7. Устранение неполадок

Иногда с распространением маршрута возникают проблемы, и некоторые сайты не могут к вам подключиться. Наверное, самой полезной командой для определения точки неверной работы маршрутизации является traceroute(8). Она также полезна и когда вы сами не можете подключиться к удаленной машине (то есть команда ping(8) не срабатывает).

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

За дополнительной информацией обратитесь к странице Справочника по traceroute(8).

27.2.8. Маршрутизация многоадресного трафика

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

options MROUTING

Кроме того, даемон многоадресной маршрутизации, mrouted(8), должен быть настроен посредством файла /etc/mrouted.conf на использование туннелей и DVMRP. Дополнительную информацию о настройки многоадресного трафика можно найти на страницах справочной системы, посвящённых даемону mrouted(8).

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

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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<ASSOC,AUTH>, caps=1<ESS>, 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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. Информацию об установке портов можно найти в Главе Установка приложений. порты и пакеты этого Руководства.

Программа 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: <Wireless-G PCI Adapter> 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

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.

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/shared/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> <Encryption> <Slot offset>
<Timing accuracy> <Switch> <Hold mode> <Sniff mode>
<Park mode> <RSSI> <Channel quality> <SCO link>
<HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD>
<Paging scheme> <Power control> <Transparent SCO data>
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 для выполнения не требуют прав администратора системы.

Протокол 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
  1. и так далее. Заметьте, что каждый сервис имеет перечень атрибутов (например, канал 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. Мосты

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. Выбор сетевого адаптера

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

Перед тем, как продолжить, сначала установите и протестируйте два сетевых адаптера.

27.5.3.2. Изменения в конфигурации ядра

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

options BRIDGE

в файл конфигурации вашего ядра, и перестройте ядро.

27.5.3.3. Поддержка функций брандмауэра

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

Если вам необходимо обеспечить прохождение не-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. Работа с бездисковыми станциями

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

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

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

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

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

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

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

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

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

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

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

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

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

Вся информация этого раздела была протестирована с релизом FreeBSD 5.2.1-RELEASE.

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 работают одинаково хорошо; тем не менее, поскольку ядро обычно позволяет loader(8) выполнить больше предварительной работы, метод PXE предпочтителен.

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

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

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

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

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

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

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; (1)
  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; (2)
    filename "/data/misc/kernel.diskless"; (3)
    option root-path "192.168.4.4:/data/misc/diskless"; (4)
  }
  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";
  }
}
1Этот параметр указывает dhcpd посылать значения деклараций host как имя хоста для бездисковой машины. Альтернативным способом было бы добавление option host-name margaux внутри объявлений host.
2Директива next-server определяет сервер TFTP или NFS, используемый для получения загрузчика или файла ядра (по умолчанию используется тот же самый хост, на котором расположен сервер DHCP).
3Директива filename определяет файл, который Etherboot или PXE будут загружать для следующего шага выполнения. Он должен быть указан в соответствии с используемым методом передачи. Etherboot может быть скомпилирован для использования NFS или TFTP. FreeBSD порт по умолчанию использует NFS. PXE использует TFTP, поэтому здесь применяются относительные пути файлов (это может зависеть от настроек TFTP сервера, но обычно довольно типично). Кроме того, PXE загружает pxeboot, а не ядро. Существуют другие интересные возможности, такие как загрузка pxeboot из каталога /boot FreeBSD CD-ROM (поскольку pxeboot(8) может загружать GENERIC ядро, это делает возможной загрузку с удаленного CD-ROM).
4Параметр 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 содержит подробную документацию, в основном предназначенную для систем 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. Смотрите комментарии в файле /usr/shared/examples/etc/make.conf.

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

Для использования 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 о необходимости перечитать свой файл конфигурации. Файл /etc/rc.conf должен содержать строку inetd_enable="YES" для корректного исполнения команды

    # /etc/rc.d/inetd restart

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

    # /etc/rc.d/mountd restart

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 (посмотрите файл NOTES).

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

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

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

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

hints		"GENERIC.hints"

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

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

27.6.2.7.1. Использование процедуры make world

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

#!/bin/sh
export DESTDIR=/data/misc/diskless
mkdir -p ${DESTDIR}
cd /usr/src; make buildworld && make buildkernel
cd /usr/src/etc; make distribution

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

27.6.2.8. Настройка области подкачки

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

27.6.2.8.1. Подкачка через NFS

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

# dd if=/dev/zero of=/path/to/swapfile bs=1k count=1 oseek=100000

Для активации этого файла подкачки следует добавить в файл rc.conf строку

swapfile=/path/to/swapfile

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 и использование devfs(5) для создания файлов устройств прозрачно для пользователя.

27.7. ISDN

Полезным источником информации о технологии ISDN и его аппаратном обеспечении является Страница Дэна Кегела (Dan Kegel) об ISDN.

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

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

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

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

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

27.7.1. Адаптеры ISDN

Реализация ISDN во FreeBSD поддерживает только стандарт DSS1/Q.931 (или Евро-ISDN) при помощи пассивных адаптеров. Поддерживаются некоторые активные адаптеры, прошивки которых поддерживают также другие сигнальные протоколы; также сюда включена поддержка адаптеров 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/shared/examples/isdn/ вашей системы FreeBSD или на домашней странице isdn4bsd, на которой также размещены ссылки на советы, замечания по ошибкам и более подробную информацию, например, на руководство по isdn4bsd.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10 Base 2 Ethernet

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

Пример 2. Центральный офис или другая локальная сеть

Сеть построена в топологии звезды на основе 10 Base T Ethernet ("витая пара").

Схема сети с ISDN

Одним большим преимуществом большинства маршрутизаторов/мостов является то, что они позволяют иметь 2 отдельных независимых соединения PPP к 2 различным сайтам одновременно. Это не поддерживается в большинстве TA, кроме специальных (обычно дорогих) моделей, имеющих по два последовательных порта. Не путайте это с балансировкой нагрузки, MPP и так далее.

Это может оказаться весьма полезной особенностью, например, если у вас имеется постоянное ISDN-соединение в вашем офисе, и вы хотите им воспользоваться, но не хотите задействовать дополнительный канал ISDN на работе. Маршрутизатор, расположенный в офисе, может использовать выделенное соединение по каналу B (64 Кбит/с) для Интернет, и одновременно другой канал B для отдельного соединения для передачи данных. Второй канал B может использоваться для входящих, исходящих и динамически распределяемых соединений (MPP и так далее) совместно с первым каналом B для повышения пропускной способности.

Мост Ethernet также позволяет вам передавать больше, чем просто трафик IP. Вы сможете передавать IPX/SPX и любые другие протоколы, которые вы используете.

27.8. Даемон преобразования сетевых адресов (natd)

27.8.1. Обзор

Даемон преобразования сетевых адресов (Network Address Translation) во FreeBSD, широко известный как natd(8), является даемоном, который принимает входящие IP-пакеты, изменяет адрес отправителя на адрес локальной машины и повторно отправляет эти пакеты в потоке исходящих пакетов. natd(8) делает это, меняя IP-адрес отправителя и порт таким образом, что когда данные принимаются обратно, он может определить расположение источника начальных данных и переслать их машине, которая запрашивала данные изначально.

Чаще всего NAT используется для организации так называемого Совместного Использования Интернет.

27.8.2. Настройка

Из-за исчерпания пространства адресов в IPv4 и увеличения количества пользователей высокоскоростных каналов связи, таких, как кабельное подключение или DSL, необходимость в решении по Совместному Использованию Интернет растёт. Возможность подключить несколько компьютеров через единственное соединение и IP-адрес делает natd(8) подходящим решением.

Чаще всего у пользователя имеется машина, подключенная к кабельному каналу или каналу DSL с одним IP-адресом и есть желание использовать этот единственный подключенный компьютер для организации доступа в Интернет другим компьютерам в локальной сети.

Для этого машина FreeBSD, находящаяся в Интернет, должна выступать в роли шлюза. Эта шлюзовая машина должна иметь два сетевых адаптера-один для подключения к маршрутизатору Интернет, а другой для подключения к ЛВС. Все машины в локальной сети подключаются через сетевой концентратор или коммутатор.

Существует много способов подсоединить локальную сеть к Internet через шлюз FreeBSD. Этот пример показывает шлюз c двумя сетевыми картами.

Структура сети

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

27.8.3. Настройка

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

options IPFIREWALL
options IPDIVERT

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

options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_VERBOSE

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

gateway_enable="YES" (1)
firewall_enable="YES" (2)
firewall_type="OPEN" (3)
natd_enable="YES"
natd_interface="fxp0" (4)
natd_flags="" (5)
1Указывает машине выступать в качестве шлюза. Выполнение команды sysctl net.inet.ip.forwarding=1 приведёт к тому же самому результату.
2При загрузке включает использование правил брандмауэра из файла /etc/rc.firewall.
3Здесь задается предопределенный набор правил брандмауэра, который разрешает все. Посмотрите файл /etc/rc.firewall для нахождения дополнительных типов.
4Указывает, через какой интерфейс передавать пакеты (интерфейс, подключенный к Интернет).
5Любые дополнительный параметры, передаваемые при запуске даемону 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, а в качестве маршрутизатора по умолчанию должен быть задан 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, соответствующий клиенту локальной сети.

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

-redirect_address 192.168.0.2 128.1.1.2
-redirect_address 192.168.0.3 128.1.1.3

Как и для -redirect_port, эти аргументы также помещаются в строку natd_flags="" файла /etc/rc.conf или передаются через конфигурационный файл. При перенаправлении адресов нет нужды в перенаправлении портов, потому что перенаправляются все данные, принимаемые для конкретного IP-адреса.

Внешние IP-адреса машины с natd должны быть активизированы и являться синонимами для внешнего интерфейса. Обратитесь к rc.conf(5), чтобы это сделать.

27.9. IP по параллельному порту (PLIP)

PLIP позволяет нам работать с TCP/IP по параллельному порту. Это полезно для машин без сетевых адаптеров или для установки на лэптопы. В этом разделе мы обсудим:

  • создание кабеля для параллельного порта (laplink).

  • Соединение двух компьютеров посредством PLIP.

27.9.1. Создание параллельного кабеля

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

Таблица 1. Распайка кабеля для параллельного порта для сетевой работы
A-nameA-EndB-EndОписаниеPost/Bit
....
DATA0
-ERROR
....
....
2
15
....
....
15
2
....

Data

....
0/0x01
1/0x08
....
....
DATA1
+SLCT
....
....
3
13
....
....
13
3
....

Data

....
0/0x02
1/0x10
....
....
DATA2
+PE
....
....
4
12
....
....
12
4
....

Data

....
0/0x04
1/0x20
....
....
DATA3
-ACK
....
....
5
10
....
....
10
5
....

Strobe

....
0/0x08
1/0x40
....
....
DATA4
BUSY
....
....
6
11
....
....
11
6
....

Data

....
0/0x10
1/0x80
....
GND
18-25
18-25

GND

-

27.9.2. Настройка PLIP

Прежде всего вы должны найти laplink-кабель. Затем удостоверьтесь, что на обоих компьютерах в ядро включена поддержка драйвера lpt(4):

# grep lp /var/run/dmesg.boot
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port

Управление параллельным портом должно выполняться по прерываниям. Файл /boot/device.hints должен содержать следующие строки:

hint.ppc.0.at="isa"
hint.ppc.0.irq="7"

Затем проверьте, что файл конфигурации ядра имеет строку device plip, или загружен ли модуль ядра plip.ko. В обоих случаях интерфейс работы с сетью по параллельному порту должен присутствовать на момент использования команды ifconfig(8).

# ifconfig plip0
plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500

Подключите кабель laplink к параллельным интерфейсам на обоих компьютерах.

Настройте параметры сетевого интерфейса с обеих сторон, работая как пользователь root. К примеру, если вы хотите соединить хост host1, на котором работает FreeBSD 4.X, с хостом host2 под управлением FreeBSD 5.X:

                 host1 <-----> host2
IP Address    10.0.0.1      10.0.0.2

Настройте интерфейс на машине host1, выполнив:

# ifconfig plip0 10.0.0.1 10.0.0.2

Настройте интерфейс на машине host2, выполнив:

# ifconfig lp0 10.0.0.2 10.0.0.1

Теперь вы должны получить работающее соединение. Пожалуйста, прочтите страницы руководства по lp(4) и lpt(4) для выяснения деталей.

Вы должны также добавить оба хоста в /etc/hosts:

127.0.0.1               localhost.my.domain localhost
10.0.0.1                host1.my.domain host1
10.0.0.2                host2.my.domain

Чтобы проверить работу соединения, перейдите к каждому хосту и выполните тестирование соединения с другой машиной посредством команды ping. К примеру, на машине host1:

# ifconfig lp0
lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000
# netstat -r
Routing tables

Internet:
Destination        Gateway          Flags     Refs     Use      Netif Expire
host2              host1              UH          0       0       lp0
# ping -c 4 host2
PING host2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms
64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms

--- host2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms

27.10. IPv6

IPv6 (также называемый IPng "IP next generation" - следующее поколение IP) является новой версией широко известного протокола IP (называемого также IPv4). Как и другие современные системы *BSD, FreeBSD включает эталонную реализацию IPv6 от KAME. Так что система FreeBSD поставляется со всем, что вам нужно для экспериментирования с IPv6. Этот раздел посвящён настройке и запуску в работу IPv6.

В начале 1990-х люди стали беспокоиться о быстро иссякающем адресном пространстве IPv4. Принимая во внимание темпы роста Интернет, имелись основные проблемы:

  • Нехватка адресов. Сегодня это не такая большая проблема, так как стали применяться адресные пространства для частных сетей (RFC1918) (10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/24) и технология преобразования сетевых адресов (NAT - Network Address Translation).

  • Таблицы маршрутов становятся чересчур большими. Это всё ещё является проблемой сегодня.

IPv6 решает эти и многие другие вопросы:

  • 128-битное адресное пространство. Другими словами, теоретически доступны 340,282,366,920,938,463,463,374,607,431,768,211,456 адреса. Это означает плотность примерно в 6.67 * 10^27 адресов IPv6 на квадратный метр нашей планеты.

  • Маршрутизаторы будут хранить в своих таблицах только агрегированные адреса сетей, что уменьшает средний размер таблицы маршрутизации до 8192 записей.

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

  • Автоматическая настройка адреса (RFC2462)

  • Групповые адреса ("один к нескольким из многих")

  • Обязательные адреса множественной рассылки

  • IPsec (IP security - безопасный IP)

  • Упрощённая структура заголовка

  • Мобильный IP

  • Механизмы преобразования IPv6-в-IPv4

Для получения дополнительной информации посмотрите:

27.10.1. Основы адресации IPv6

Существуют различные типы адресов IPv6: одноадресные (Unicast), групповые (Anycast) и многоадресные (Multicast).

Адреса типа Unicast хорошо всем известны. Пакет, посланный на такой адрес, достигает в точности интерфейса, который этому адресу соответствует.

Адреса типа Anycast синтаксически неотличимы от адресов Unicast, но они адресуют группу интерфейсов. Пакет, направленный такому адресу, попадёт в ближайший (согласно метрике маршрутизатора) интерфейс. Адреса Anycast могут использоваться только маршрутизаторами.

Адреса типа Multicast идентифицируют группу интерфейсов. Пакет, посланный на такой адрес, достигнет всех интерфейсов, привязанных к группе многоадресного вещания.

Широковещательные адреса IPv4 (обычно xxx.xxx.xxx.255) выражаются адресами многоадресного вещания IPv6.

Таблица 2. Зарезервированные адреса IPv6
IPv6 адресДлина префикса (биты)ОписаниеЗаметки

::

128 бит

нет описания

cf. 0.0.0.0 в IPv4

::1

128 бит

loopback адрес

cf. 127.0.0.1 в IPv4

::00:xx:xx:xx:xx

96 бит

встроенный IPv4

Нижние 32 бита это адрес IPv4. Также называется "IPv4 совместимым IPv6 адресом"

::ff:xx:xx:xx:xx

96 бит

Адрес IPv6, отображенный на IPv4

Нижние 32 бита это адрес IPv4. Для хостов, не поддерживающих IPv6.

fe80:: - feb::

10 бит

link-local

cf. loopback адрес в IPv4

fec0:: - fef::

10 бит

site-local

ff::

8 бит

широковещательный

001 (основание 2)

3 бит

global unicast

Все global unicast адреса присваиваются из этого пула. Первые три бита "001".

27.10.2. Чтение адресов IPv6

Каноническая форма представляется в виде x:x:x:x:x:x:x:x, где каждый символ "x" является 16-разрядным числом в шестнадцатеричной форме. К примеру, FEBC:A574:382B:23C1:AA49:4592:4EFE:9982

Часто в адресе присутствуют длинные строчки, заполненные нулями, поэтому одна такая последовательность на адрес может быть сокращена до "::". Кроме того, до трех ведущих "0" на шестнадцатеричную четверку могут быть пропущены. К примеру, fe80::1 соответствует канонической форме fe80:0000:0000:0000:0000:0000:0000:0001.

В третьей форме последние 32 бита записываются в широко известном (десятичном) стиле IPv4 с точками "." в качестве разделителей. Например, f2002::10.0.0.1 соответствует (шестнадцатеричному) каноническому представлению 2002:0000:0000:0000:0000:0000:0a00:0001, которое, в свою очередь, равнозначно записи 2002::a00:1.

Теперь читатель должен понять следующую запись:

# ifconfig
rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
         inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255
         inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1
         ether 00:00:21:03:08:e1
         media: Ethernet autoselect (100baseTX )
         status: active

fe80::200:21ff:fe03:8e1%rl0 является автоматически настроенным локальным адресом. Он генерируется из MAC адреса в процессе автоматической конфигурации.

Для получения дополнительной информации о структуре адресов IPv6 обратитесь к RFC3513.

27.10.3. Настройка подключения

На данный момент существуют четыре способа подключиться к другим хостам и сетям IPv6:

  • Подключиться к экспериментальному 6bone

  • Получить сеть IPv6 от вышестоящего провайдера. Для получения рекомендаций обратитесь к вашему провайдеру Интернет.

  • Туннелировать посредством 6-в-4 (RFC3068)

  • Использовать порт net/freenet6, если вы используете коммутируемое соединение.

Здесь мы будем рассматривать подключение к 6bone, так как на данный момент это является самым популярным способом.

Сначала взгляните на сайт 6bone и найдите ближайшую к вам точку подключения к 6bone. Напишите ответственному и при некоторой удаче вам дадут инструкции по настройке соединения. Обычно это касается настройки туннеля GRE (gif).

Вот типичный пример настройки туннеля gif(4):

# ifconfig gif0 create
# ifconfig gif0
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
# ifconfig gif0 tunnel MY_IPv4_ADDR  MY_IPv4_REMOTE_TUNNEL_ENDPOINT_ADDR
# ifconfig gif0 inet6 alias MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR MY_IPv6_REMOTE_TUNNEL_ENDPOINT_ADDR

Замените слова, написанные заглавными буквами, информацией, которую вам дал вышестоящий узел 6bone.

При этом установится туннель. Проверьте работу туннеля утилитой ping6(8) с адресом ff02::1%gif0. Вы должны получить два положительных ответа.

Если вы заинтригованы адресом ff02:1%gif0, скажем, что это адрес многоадресного вещания. %gif0 указывает на использование такого адреса с сетевым интерфейсом gif0. Так как мы выполняем ping над адресом многоадресного вещания, то другая сторона туннеля также должна ответить.

Теперь настройка маршрута к вашей вышестоящей точке подключения 6bone должна быть весьма проста:

# route add -inet6 default -interface gif0
# ping6 -n MY_UPLINK
# traceroute6 www.jp.FreeBSD.org
(3ffe:505:2008:1:2a0:24ff:fe57:e561) from 3ffe:8060:100::40:2, 30 hops max, 12 byte packets
     1  atnet-meta6  14.147 ms  15.499 ms  24.319 ms
     2  6bone-gw2-ATNET-NT.ipv6.tilab.com  103.408 ms  95.072 ms *
     3  3ffe:1831:0:ffff::4  138.645 ms  134.437 ms  144.257 ms
     4  3ffe:1810:0:6:290:27ff:fe79:7677  282.975 ms  278.666 ms  292.811 ms
     5  3ffe:1800:0:ff00::4  400.131 ms  396.324 ms  394.769 ms
     6  3ffe:1800:0:3:290:27ff:fe14:cdee  394.712 ms  397.19 ms  394.102 ms

Эта выдача будет отличаться от машины к машине. Теперь вы должны суметь достигнуть сайта IPv6 www.kame.net и увидеть танцующую черепаху - в случае, если ваш браузер поддерживает IPv6, как, например, www/mozilla или Konqueror, который входит в x11/kdebase3, или www/epiphany.

27.10.4. DNS в мире IPv6

Для IPv6 использовались два типа записей DNS. IETF объявил записи A6 устаревшими. Стандартом на данный момент являются записи AAAA.

Использование записей AAAA достаточно просто. Назначение вашему имени хоста нового адреса IPv6 достигается просто добавлением:

MYHOSTNAME           AAAA    MYIPv6ADDR

к вашему первичному файлу DNS зоны. В случае, если вы не обслуживаете собственные зоны DNS, обратитесь к вашему провайдеру DNS. Имеющиеся версии bind (версий 8.3 и 9) и dns/djbdns (с патчем IPv6) поддерживают записи AAAA.

27.10.5. Внесение необходимых изменений в /etc/rc.conf

27.10.5.1. Настройки клиентов IPv6

Эти установки помогут вам настроить компьютер, который будет работать в сети как клиент, а не как маршрутизатор. Для включения настройки интерфейсов через rtsol(8) при загрузке, все, что вам потребуется, это добавить следующую строку:

ipv6_enable="YES"

Для статического присвоения IP адреса, такого как 2001:471:1f11:251:290:27ff:fee0:2093, интерфейсу fxp0, добавьте:

ipv6_ifconfig_fxp0="2001:471:1f11:251:290:27ff:fee0:2093"

Для назначения маршрутизатором по умолчанию 2001:471:1f11:251::1, добавьте следующую строку к /etc/rc.conf:

ipv6_defaultrouter="2001:471:1f11:251::1"

27.10.5.2. Настройки маршрутизатора/шлюза IPv6

Этот раздел поможет вам использовать инструкции, которые выдал провайдер туннеля, например, 6bone, и сделать эти настройки постоянными. Для восстановления туннеля при загрузке системы используйте в /etc/rc.conf нижеприведенные настройки.

Задайте список туннельных интерфейсов (Generic Tunneling interfaces), которые необходимо настроить, например gif0:

gif_interfaces="gif0"

Для настройки интерфейса с локальным подключением на MY_IPv4_ADDR к удаленной точке REMOTE_IPv4_ADDR:

gifconfig_gif0="MY_IPv4_ADDR REMOTE_IPv4_ADDR"

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

ipv6_ifconfig_gif0="MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR"

Затем все, что вам потребуется сделать, это добавить маршрут по умолчанию для IPv6. Это другая сторона туннеля IPv6:

ipv6_defaultrouter="MY_IPv6_REMOTE_TUNNEL_ENDPOINT_ADDR"

27.10.5.3. Настройка туннелирования IPv6

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

ipv6_gateway_enable="YES"

27.10.6. Распространение маршрутов и автоматическая настройка хостов

Этот раздел поможет вам настроить rtadvd(8) для распространения маршрута IPv6 по умолчанию.

Для включения rtadvd(8) вам понадобится добавить в /etc/rc.conf следующую строку:

rtadvd_enable="YES"

Важно указать интерфейс, на котором выполняется запрос маршрутизатора IPv6. Например, для указания rtadvd(8) использовать fxp0:

rtadvd_interfaces="fxp0"

Теперь мы должны создать файл настройки, /etc/rtadvd.conf. Вот пример:

fxp0:\
        :addrs#1:addr="2001:471:1f11:246::":prefixlen#64:tc=ether:

Замените fxp0 на интерфейс, который вы будете использовать.

Затем, замените 2001:471:1f11:246:: на префикс вашего размещения.

Если у вас выделенная подсеть /64, больше ничего менять не потребуется. Иначе, вам потребуется изменить prefixlen# на корректное значение.

27.11. Асинхронный режим передачи (ATM)

27.11.1. Классическая настройка IP через ATM (PVC)

Классический IP через ATM (CLIP) это простейший метод использования асинхронного режима передачи (Asynchronous Transfer Mode, ATM) с IP. Он может быть использован с коммутируемыми подключениями (switched connections, SVC) и с постоянными подключениями (permanent connections, PVC). В этом разделе будет описано как настроить сеть на основе PVC.

27.11.1.1. Полностью объединенные конфигурации

Первый метод для настройки CLIP с PVC это подключение каждого компьютера к каждому в сети с выделенным PVC. Хотя настройка проста, она непрактична для большого количества компьютеров. В примере предполагается, что в сети есть четыре компьютера, каждый подключенный к ATM сети с помощью карты ATM адаптера. Первый шаг это планирование IP адресов и ATM подключений между компьютерами. Мы используем:

ХостIP адрес

hostA

192.168.173.1

hostB

192.168.173.2

hostC

192.168.173.3

hostD

192.168.173.4

Для сборки полностью объединенной сети нам потребуется по одному ATM соединению между каждой парой компьютеров:

КомпьютерыVPI.VCI соединение

hostA - hostB

0.100

hostA - hostC

0.101

hostA - hostD

0.102

hostB - hostC

0.103

hostB - hostD

0.104

hostC - hostD

0.105

Значения VPI и VCI на каждом конце соединения конечно могут отличаться, но для упрощения мы предполагаем, что они одинаковы. Затем нам потребуется настроить ATM интерфейсы на каждом хосте:

hostA# ifconfig hatm0 192.168.173.1 up
hostB# ifconfig hatm0 192.168.173.2 up
hostC# ifconfig hatm0 192.168.173.3 up
hostD# ifconfig hatm0 192.168.173.4 up

предполагая, что ATM интерфейс называется hatm0 на всех хостах. Теперь PVC необходимо настроить на hostA (мы предполагаем, что ATM коммутаторы уже настроены, вам необходимо свериться с руководством на коммутатор за информацией по настройке).

hostA# atmconfig natm add 192.168.173.2 hatm0 0 100 llc/snap ubr
hostA# atmconfig natm add 192.168.173.3 hatm0 0 101 llc/snap ubr
hostA# atmconfig natm add 192.168.173.4 hatm0 0 102 llc/snap ubr

hostB# atmconfig natm add 192.168.173.1 hatm0 0 100 llc/snap ubr
hostB# atmconfig natm add 192.168.173.3 hatm0 0 103 llc/snap ubr
hostB# atmconfig natm add 192.168.173.4 hatm0 0 104 llc/snap ubr

hostC# atmconfig natm add 192.168.173.1 hatm0 0 101 llc/snap ubr
hostC# atmconfig natm add 192.168.173.2 hatm0 0 103 llc/snap ubr
hostC# atmconfig natm add 192.168.173.4 hatm0 0 105 llc/snap ubr

hostD# atmconfig natm add 192.168.173.1 hatm0 0 102 llc/snap ubr
hostD# atmconfig natm add 192.168.173.2 hatm0 0 104 llc/snap ubr
hostD# atmconfig natm add 192.168.173.3 hatm0 0 105 llc/snap ubr

Конечно, вместо UBR может быть использован другой тип, если ATM адаптер поддерживает это. В этом случае имя типа дополняется параметрами трафика. Помощь по atmconfig(8) может быть получена командой:

# atmconfig help natm add

или на странице справочника atmconfig(8).

Та же настройка может быть выполнена через /etc/rc.conf. Для hostA это будет выглядеть примерно так:

network_interfaces="lo0 hatm0"
ifconfig_hatm0="inet 192.168.173.1 up"
natm_static_routes="hostB hostC hostD"
route_hostB="192.168.173.2 hatm0 0 100 llc/snap ubr"
route_hostC="192.168.173.3 hatm0 0 101 llc/snap ubr"
route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr"

Текущий статус всех маршрутов CLIP может быть получен командой:

hostA# atmconfig natm show

Изменено: 11 декабря 2021 г. by Sergio Carlavilla Delgado