![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ-Index] [Глава 5 - Сборка системы из исходников] [Глава 7 - Клавиатура и дисплей]
В понимании этого документа вам поможет хотя бы краткое знакомство с пятой главой FAQ Сборка системы из исходников, а также с man-страницами ifconfig(8) и netstat(1).
Если вы сетевой администратор и настраиваете протоколы маршрутизации, т.е. используете OpenBSD в качестве маршрутизатора, или если вам нужно тщательно изучить организацию IP-сетей, мы настроятельно рекомендуем вам прочитать Understanding IP Addressing. Это отличный документ. Он содержит фундаментальную базу, знакомство с которой поможет при расчетах для работы с IP-сетями, особенно если вы отвечаете за более чем одну сеть.
Если же вы работаете с web, ftp или почтовыми серверми, вам может помочь RFC. Скорее всего вы не сможете прочитать его полностью. Но это и не нужно; выберите некоторые темы, которые вас заинтересовали, или те, которые имеют отношение к тому, что вы используете в вашей сети. RFC описывет принцип работы очень многих (тысячи) стандартов Internet-протоколов.
В OpenBSD сетевые интерфейсы называются по имени типа карты (используемого им драйвера), а не по типу соединения. Вы можете увидеть как проходит настройка вашей сетевой карты во время загрузки, используя команду dmesg(8). Вы также можете увидеть имя вашего сетевого интерфейса, используя команду ifconfig(8). Например, здесь вывод dmesg для сетевой карты Intel Fast Ethernet, который использует устройство, именуемое fxp.
fxp0 at pci0 dev 10 function 0 "Intel 82557" rev 0x0c: irq 5, address 00:02:b3:2b:10:f7 inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
Если вы не знаете имени вашего устройства, пожалуйста посмотрите на список поддерживаемой аппаратуры для вашей платформы. Вы найдете список множества распространенных имен карт и их OpenBSD имена устройств. Объедините короткое символьное имя устройства (например fxp) с числом, назначенным ядром, и вы получите имя интерфейса (например fxp0). Номер присваивается на основе различных критериев, в зависимости от карты и других деталей. Некоторым картам назначаются имена в зависимости от используемой ими шины. Другим могут быть имена по каким-то hardware-критериям или в зависимости от MAC-адреса.
Обратите внимание, что для информации обо всех найденных в системе сетевых устройств используется утилита ifconfig(8). Приведенный ниже пример показывает, что в системе найдено одно сетевое устройство fxp(4).
$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33200
priority: 0
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff000000
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:04:ac:dd:39:6a
priority: 0
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255
inet6 fe80::204:acff:fedd:396a%fxp0 prefixlen 64 scopeid 0x1
enc0: flags=0<>
priority: 0
groups: enc
status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33200
priority: 0
groups: pflog
Как вы видете, ifconfig(8) дает нам больше информации чем нам сейчас нужно. В примере карта уже настроена; мы видим имя её интерфейста - fxp0. О её настройке свидетельствуют также строка "inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255" и установленные флаги UP и RUNNING.
Обратите внимание, что несколько других виртуальных интерфейсов включены по умолчанию. Информацию о них вы можете найти в man-страницах:
В список других виртуальных интерфейсов, которые автоматически создаются, входят:Инициализация (создание) сетевых интерфейсов происходит во время загрузки при помощи /etc/hostname.if-файлов, где if - где имя вашего интерфейса. Например, как было показанно выше, имя должно быть /etc/hostname.fxp0.
Формат этого файла прост:
Более детальную информацию о формате этого файла вы можете найти в man-страницах hostname.if(5). Мы рекомендуем ознакомиться также и с более сложными примерами конфигурационных файлов.address_family address netmask broadcast [weitere Optionen]
Типичный интерфейс такого файла, сконфигурированного для адресов IPv4, должен выглядеть так:
$ cat /etc/hostname.fxp0 inet 10.0.0.38 255.255.255.0 NONE
В данном случае мы задаем адрес IPv4 (inet), IP адрес 10.0.0.38, маска подсети 255.255.255.0, широковещательный адрес не указан (будет установлен для данного случая по умолчанию в 10.0.0.255).
Вы должны также определить тип для Ethernet. Например, если бы вы захотели установить полный дуплексный режим 100baseTX.
inet 10.0.0.38 255.255.255.0 NONE media 100baseTX mediaopt full-duplex
(Разумеется, работа в полно-дуплексном режиме невозможна, если этот режим не установлен на обеих сторонах соединения!)
Возможно вы захотите использовать флаги, специфические на определенных интерфейсах. Формат файла hostname от этого сильно не изменится!
$ cat /etc/hostname.vlan0 inet 172.21.0.31 255.255.255.0 NONE vlan 2 vlandev fxp1
Возможно указать и символические имя, однако следует иметь ввиду: может получится так, что ваша служба разрешения доменных имен, резолвер, будет сконфигурирован или доступен только ПОСЛЕ установки шлюза по умолчанию. Поэтому лучше указывать IP-адрес или что-нибудь, указанное в файле /etc/hosts.10.0.0.1
В этом примере доменное имя по умолчанию example.com; имеются два сервера DNS с адресами 125.2.3.4 и 125.2.3.5; файл /etc/hosts будет использован до получения информации от DNS-серверов.search example.com nameserver 125.2.3.4 nameserver 125.2.3.5 lookup file bind
Как и практически во всех UNIX системах (да и многих не UNIX), есть файл /etc/hosts, который может быть использован для указания системы, которая не должна использоваться как DNS.
Если вы пользуетесь DHCP, почитайте пункт 6.4 - DHCP, где рассказывается об использовании файла resolv.conf.tail(5).
puffy.example.com
# sh /etc/netstart writing to routing socket: File exists add net 127: gateway 127.0.0.1: File exists writing to routing socket: File exists add net 224.0.0.0: gateway 127.0.0.1: File exists
Обратите внимание, появилось несколько ошибок. Выполняя этот сценарий вы изменяете существующие настройки. Например, некоторые маршруты уже присутствуют в таблице маршрутизации ядра. Начиная с этого момента система должна работать. Кроме того, вы можете убедиться, что ваш интерфейс был установлен правильно с помощью ifconfig(8).
Хотя в OpenBSD возможна полная переконфигурация сетевых настроек системы без перезагрузки, рестарт системы НАСТОЯТЕЛЬНО рекомендуется после значительного изменения конфигурации. Дело в том, что окружающая нашу систему среда может оказаться при загрузке несколько иной, чем когда система полностью запущена и работает. К примеру, вы указали DNS-сервер символическим именем во всех файлах, и у вас все работает после переконфигурации, однако после перезагрузки внешний DNS-сервер может оказаться недоступным, т.е. перенастройка сети окажется неправильной.
$ netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Mtu Interface default 10.0.0.1 UGS 0 86 - fxp0 127/8 127.0.0.1 UGRS 0 0 - lo0 127.0.0.1 127.0.0.1 UH 0 0 - lo0 10.0.0/24 link#1 UC 0 0 - fxp0 10.0.0.1 aa:0:4:0:81:d UHL 1 0 - fxp0 10.0.0.38 127.0.0.1 UGHS 0 0 - lo0 224/4 127.0.0.1 URS 0 0 - lo0 Encap: Source Port Destination Port Proto SA(Address/SPI/Proto) $ route show Routing tables Internet: Destination Gateway Flags default 10.0.0.1 UG 127.0.0.0 LOCALHOST UG localhost LOCALHOST UH 10.0.0.0 link#1 U 10.0.0.1 aa:0:4:0:81:d UH 10.0.0.38 LOCALHOST UGH BASE-ADDRESS.MCA LOCALHOST U
Это основная информация, которая вам понадобится для настройки вашей OpenBSD системы в качестве шлюза (также называемым маршрутизатором). Если вы используете OpenBSD в качестве маршрутизатора Internet, мы советуем прочитать инструкцию по установке пакетного фильтра, чтобы блокировать потенциально злонамеренный трафик. Также, из-за низкой доступности адресов IPv4 у местных провайдеров, вам возможно бужет интересно взглянуть на Network Address Translation (NAT) для получения информации о сохранении вашего диапазона IP-адресов.
GENERIC ядро собрано с поддержкой IP Forwarding, вам только нужно включить её. Вы можете сделать это, используя утилиту sysctl(8). Чтобы изменения стали постоянными, вы должны отредактировать файл /etc/sysctl.conf; добавьте в этот файл строку.
net.inet.ip.forwarding=1
Чтобы сохранить изменения, вы должны использовать утилит sysctl(8) до перезагрузки. Запомните: эти изменения не будет действовать после перезагрузки, и должны быть выполнениы от root.
# sysctl net.inet.ip.forwarding=1 net.inet.ip.forwarding: 0 -> 1
Теперь настраивайте маршруты на других хостах (с обеих сторон). Есть много вариантов настройки OpenBSD в качестве маршрутизатора. Например вы можете использовать OpenBGPD, ospfd(8), ospf6d(8), ldpd(8) и ripd(8). OpenBSD поддерживает в своей коллекции портов такие инструменты как bird, igmpproxy и quagga. OpenBSD поддерживает некоторые T1-, HSSI-, АТМ-, FDDI-, последовательные (PPP/SLIP) интерфейсы, и конечно же многие Ethernet-устройства (включая 10 Gb).
OpenBSD имеет простой механизм для установки IP псевдонимов (алиасов) для сетевых интерфейсов. Чтобы сделать это, просто отредактируйте файл /etc/hostname.<if>. Этот файл будет считан в процессе загрузки скриптом /etc/netstart(8), который является частью rc-системы загрузки. Для примера мы предполагаем, что пользователь имеет интерфейс dc0 и находится в сети 192.168.0.0. Другая важная информация:
Немного замечаний относительно алиасов: в OpenBSD вы используете только имя интерфейса. Нет различия между первым и вторым псевдонимами. В отличие от некоторых других операционных систем, OpenBSD не ссылается на них как dc0:0, dc0:1. Если вы ссылаетесь на специфический адрес IP псевдонима с помощью ifconfig или добавляете псевдоним, не забываете набирать "ifconfig int alias" вместо просто "ifconfig int" в командной строке. Вы можете удалить псевдонимы с помощью "ifconfig int delete".
Допустим, вы используете многочисленные IP-адреса, которые в той же подсети с псевдонимами, ваша установка netmask для каждого псевдонима становится 255.255.255.255. Им не нужно следовать за netmask первого связанного IP интерфейса. В этом примере /etc/hostname.dc0 - два псевдонима, которые добавлены к устройству dc0, которое, было сконфигурировано как 192.168.0.2 с маской сети 255.255.255.0.
# cat /etc/hostname.dc0 inet 192.168.0.2 255.255.255.0 NONE media 100baseTX inet alias 192.168.0.3 255.255.255.255 inet alias 192.168.0.4 255.255.255.255
Как только вы настроили этот файл, можно просто перезагрузиться, чтобы изменения вступили в силу. Вы можете, кстати, задать псевдонимы и вручную, используя утилиту ifconfig(8). Чтобы создать первый псевдоним, вы должны использовать команду:
(опять-таки рекомендуется перезагрузить систему, чтобы убедиться в корректности ваших настроек!)# ifconfig dc0 inet alias 192.168.0.3 netmask 255.255.255.255
Чтобы просмотреть псевдонимы:
$ ifconfig -A
dc0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
media: Ethernet manual
inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
inet 192.168.0.3 netmask 0xffffffff broadcast 192.168.0.3
Для того, чтобы использовать клиент DHCP dhclient(8), включенного в OpenBSD, отредактируйте /etc/hostname.xl0 (в предположении, что ваш основной Ethernet-интерфейс является xl0. Ваш может называться ep0 или fxp0 или любой другой). Все что вам нужно для настройки - написать в этом файле dhcp.
# echo dhcp > /etc/hostname.xl0
Это скажет OpenBSD автоматически запускать DHCP клиент при загрузке. OpenBSD получит свои IP-адрес, имя шлюза, а также адреса DNS серверов от DHCP сервера.
Если вы хотите запустить DHCP клиент из командной строки, убедитесь, что существует файл /etc/dhclient.conf, а затем сделайте:
# dhclient fxp0
Где fxp0 – интерфейс, для которого вы хотите получить сетевые настройки.
Независимо от того как вы запускаете DHCP клиент, вы можете отредактировать файл /etc/dhclient.conf, чтобы НЕ настраивать ваш DNS. Сначала раскомментируйте строки 'request' (эти строки - пример установок по умолчанию, но вам нужно раскомментировать их, чтобы перезаписать значения dhclient по умолчанию).
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;
и затем удалите domain-name-servers. Конечно, вы можете захотеть удалить host-name, или другие установочные параметры тоже.
Изменяя опции в вашем файле dhclient.conf(5), вы сообщаете DHCP клиенту как формировать ваш файл resolv.conf(5). DHCP клиент перезаписывает любую информацию в файле resolv.conf(5) в соответствии с полученной информацией от DHCP сервера. Следовательно, вы потеряете любые изменения, которые вы делали вручную в resolv.conf.
Есть два доступных механизма избежать этого:
Пример будет выглядеть так, если вы используете DHCP, но при этом хотите добавить lookup file bind в resolv.conf(5). созданный утилитой dhclient(8). Для этого нет опции в dhclient.conf, так что вы должны использовать resolv.conf.tail, чтобы сохранять это.
Теперь ваш resolv.conf(5) должен содержать в конце "lookup file bind".# echo "lookup file bind" > /etc/resolv.conf.tail
nameserver 192.168.1.1 nameserver 192.168.1.2 lookup file bind
Если вы хотите использовать OpenBSD в качестве сервера DHCP dhcpd(8), отредактируйте /etc/rc.conf.local, чтобы он содержал строку dhcpd_flags="". Например:
# echo 'dhcpd_flags=""' >>/etc/rc.conf.local
Это запустит dhcpd, который подхватит все NIC (сетевые интерфейсы), которые
перечислены в /etc/dhcpd.conf. Вы можете также указать конкретные
интерфейсы, а не все, назвав их явно, например,
dhcpd_flags="xl1 xl2 xl3".
Затем, отредактируйте /etc/dhcpd.conf. Опции в достаточной степени очевидны.
option domain-name "example.com";
option domain-name-servers 192.168.1.3, 192.168.1.5;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
range 192.168.1.32 192.168.1.127;
}
Это сообщит вашим клиентам DHCP, что domain = example.com добавлялся к запросам DNS (так, если пользователь набирает 'telnet joe', тогда запрос пойдет на joe.example.com) Это укажет им на серверы DNS 192.168.1.3 и 192.168.1.5. Для хостов, которые находятся в той же сети, что и ethernet интерфейс машины OpenBSD, который лежит в диапазоне 192.168.1.0/24, он назначит им адрес IP между 192.168.1.32 и 192.168.1.127. Он установит их шлюз по умолчанию в качестве 192.168.1.1.
Если вы хотите запустить dhcpd(8) из консоли, после редактирования /etc/dhcpd.conf сделайте:
# /etc/rc.d/dhcpd start
dhcpd(ok)
Если при конфигурации были допущенны ошибки, демон не будет запущен.
Вы получите сообщение о невозможности запуска ("dhcpd(failed)").
О причине проблемы вы всегда можете узнать из /var/log/message.
Если вы предоставляете сервис DHCP для Windows, вам возможно понадобится, чтобы dhcpd(8) давал клиенту адрес 'WINS' сервера. Для этого, просто добавьте следующую строку к вашему /etc/dhcpd.conf:
option netbios-name-servers 192.168.92.55;
(где 192.168.92.55 - IP вашего Windows или Samba сервера.) Смотрите dhcp-options(5) для подробностей об опциях, которые могут понадобиться вашим клиентам DHCP.
Point to Point Protocol (PPP) или протокол "точка-точка" обычно используется для создания соединения с вашим провайдером через модем. В OpenBSD существует 2 способа сделать это:
Как ppp так и pppd выполняют аналогичные функции различными путями. pppd работает с драйвером ядра ppp(4), тогда как ppp работает в простанстве пользователя с tun(4). В этом документе рассказывается только о пользовательском PPP-демоне, так как с ним легче работать и отлаживать. Для начала вам нужна некоторая информация о вашем провайдере:
Без некоторой из них вы можете обойтись, но все же она будет полезна в установке ppp. В качестве конфигурационного файла PPP-демона пользовательского уровня используется файл /etc/ppp/ppp.conf. Много полезных файлов вы найдете просматривая каталог /etc/ppp, который содержит различные конфигурационные файлы. Мы советуем вам изучить содержимое этого каталога.
Начальная установка PPP-демона сводится к редактированию вашего /etc/ppp/ppp.conf. Этого файла по умолчанию в системе нет, но есть файл /etc/ppp/ppp.conf.sample, от которого вы можете оттолкнуться, чтобы создать ваш новый ppp.conf. Здесь я начну с самой простой и, вероятно, наиболее используемой установки. Вот простенький файл ppp.conf, который устанавливает некоторые значения по умолчанию:
default: set log Phase Chat LCP IPCP CCP tun command set device /dev/cua01 set speed 115200 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
Секция после метки default: выполняться всякий раз. Здесь мы установили все наши главные настройки. С помощью "set log" мы задали наш уровень логирования. Он может быть изменен, ознакомьтесь с ppp(8) для более подробной информации по установке уровней логирования. Наше устройство устанавливается строкой "set device". Это устройство, на котором включен модем. В этом примере модем находится на 2-ом com-порту. Следовательно 1-ый com-порт должен быть на /dev/cua00. С помощью "set speed" мы установили скорость нашего диалап-соединения, а с помощью "set dial" мы установили наши диалап-параметры. С их помощью мы можем изменить наше время тайм-аута, и т.п.. Эта строка должна оставаться почти такой же не смотря ни на что.
Теперь мы можем идти далее и устанавить информацию специфическую для нашего провайдера. Мы сделаем это с помощью дополнения другими метками под нашей default: секции. Эта метка может быть названа как угодно - можете просто использовать имя вашего провайдера. Здесь я использую myisp: в качестве нашей метки. Вот простые настройки, включающие все, что нам нужно для получения нашего соединения:
myisp: set phone 1234567 set login "ABORT NO\\sCARRIER TIMEOUT 5 ogin:--ogin: ppp word: ppp" set timeout 120 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR enable dns
Здесь мы установили основную информацию специфичную для нашего провайдера. Первая опция "set phone" устанавливает ваш dial-up номер провайдера. "set login" устанавливает наши опции входа. Здесь мы установили тайм-аут на 5; это означает, что мы прервем нашу попытку входа после 5 секунд, если сигнал не будет обнаружен. В противном случае ждем отправленного "login:" и посылаем ваш логин и пароль.
В этом примере наше имя Username = ppp и Password = ppp. Эти значения должны быть изменены. Строка "set timeout" устанавливает тайм-аут бездействия для соединения в 120 секунд. Строка "set ifaddr" немного мудрена. Вот более исчерпывающее объяснение.
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
В вышеуказанной строке, мы имеем следующий формат "set ifaddr [meineAdr[/nn] [seineAdr[/nn] [netzmaske [startAdr]]]]". Так первый заданный IP это тот, который мы хотим в качестве нашего IP. Если у вас есть статический IP-адрес, установите его здесь. В нашем примере мы используем /0, который сообщает, что никакие биты этого IP-адреса не нуждаются в совпадении, и целая часть может быть заменена. Второй IP определен таким образом, каким мы его представляем как IP на другой стороне. Если вы знаете его вы можете установить его. Кроме того, в нашей строке мы не знаем, что будет назначено, так что мы позволяем им сообщить его нам. Третья опция - наша маска сети (netmask). Она здесь указана как 255.255.255.0. Тем не менее, только адрес в дипазоне myaddr будет принят. Это полезно, когда происходит согласование с некоторыми реализациями PPP, которые не назначат IP, если их peer запрашивают "0.0.0.0".
Следующая опция "add default HISADDR" используется для установки нашего маршрута по умолчанию для их IP. Это 'создает проблемы', в смысле, что если их IP должен изменяться, наш маршрут автоматически будет скорректирован. С помощью "enable dns" мы сообщаем нашему провайдеру аутентификации наших nameserver-адресов. НЕ делайте это, если вы запускаете локальный DNS, поскольку ppp просто обойдет его использование, вводя некоторые nameserver строки в /etc/resolv.conf.
Вместо традиционных методов входа (login), многие провайдеры теперь используют аутентификацию CHAP или PAP. Если это ваш случай, наша конфигурация будет выглядеть немного иначе:
myisp: set phone 1234567 set authname ppp set authkey ppp set login set timeout 120 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR enable dns
В вышеуказанном примере, мы определяем наше имя пользователя (ppp) и пароль (ppp), используя authname и authkey, соответственно. Нет необходимости определять какая из двух аутентификации (CHAP или PAP) использована - это согласовывается автоматически. "set login" просто определяется для попытки залогиниться, с именем пользователя и паролем, определенным прежде.
Теперь, когда мы настроили наш ppp.conf файл, мы можем начать попытки соединия с нашим провайдером. Я опишу подробно некоторые обычно используемые аргументы с ppp:
Если запуск вышеуказанных команд ни к чему не приводит, попробуйте выполнить /usr/sbin/ppp без опций. Это запустит ppp в интерактивном режиме. Опции могут передаваться поодиночке, чтобы проанализировать причину возникновения проблемы, читая сообщения об ошибках. Используя установку определенную выше, ppp будет вести лог в /var/log/ppp.log. Этот файл, также как и man-страницы, целиком содержит полезную информацию.
В некоторых ситуациях вам может понадобиться запускать ppp непосредственно для соединения или отключения. Для этих ситуаций вы можете создать два файла: /etc/ppp/ppp.linkup и /etc/ppp/ppp.linkdown. Конфигурацию можно посмотреть здесь:
Много провайдеров теперь предлагают xDSL сервисы, которые быстрее, чем традиционные dial-up методы. Это включает такие варианты как например, ADSL и SDSL. Хотя никакого физического набора номера не происходит, соединение все еще основано на POP-протоколе. Примеры:
PPPoE - Point to Point Protocol over Ethernet или "протокол точка-точка поверх Ethernet" представляет из себя метод для посылки PPP-пакетов в фреймах Ethernet. Point to Point Protocol over ATM (PPPoA) - обычно работает в сетях АТМ, как например те, которые используются в Великобритании и Бельгии.
Обычно это означает, что вы можете установить соединение с вашим провайдером, используя для этого только стандартную Ethernet-карту и основанный на Ethernet DSL модем (в противоположность к USB модему).
Если у вас есть модем, который поддерживает работу по протоколу PPPoE/PPPoA, то возможно сконфигурировать модем таким образом, чтобы он создавал такие соединения. Кроме того, если модем имеет режим "bridge", то, после его включения, получаем модем, пропускающий (pass through) пакеты PPPoE.
Основной программный интерфейс на PPPoE/PPPoA в OpenBSD - это pppoe(8), который является реализацией пользовательского уровня (почти такой же как и описанный нами ppp(8) выше). Реализация PPPoE в ядре, pppoe(4), является частью OpenBSD.
PPTP - Point to Point Tunneling Protocol или "Туннельный протокол точка-точка" является собственным протоколом компании Майкрософт. Клиент pptp доступен на интерфейсах с pppd(8) и способен соединяться с основанной на PPTP VPN, используемыми некоторыми кабельными и xDSL провайдерами. pptp сам должен быть установлен из пакетов или портов. Дальнейшие инструкции по установке и использованию pptp доступны в man-страницах, которые устанавливаются вместе с пакетом pptp.
ОЧЕНЬ МАЛОМУ количеству пользователей это действительно необходимо!
Из man-руководства для sysctl(8):
Установка списка резервных портов TCP, которые не должны быть распределены ядром
динамически:
# sysctl net.inet.tcp.baddynamic=749,750,751,760,761,871
Это может быть использовано для удержания демонов от захвата специфических
портов, которые нужны для функционирования других программ. Элементы cписка могут быть
разделены запятыми и/или интервалом.
Также возможно добавить или удалить порты из текущего списка:
# sysctl net.inet.tcp.baddynamic=+748
# sysctl net.inet.tcp.baddynamic=-871
Network File System (NFS или Сетевая Файловая Система) используется для совместного использования файловой системы по сети. Перед установкой NFS-сервера прочитайте следующие man-страницы:
В этом разделе приводятся шаги по простой установке NFS. В этом примере описывается NFS-сервер в LAN с клиентами из LAN. Здесь не обсуждаются вопросы безопасности NFS. Мы считаем, что вы уже установили фильтрацию пакетов или другую защиту с помощью фаервола для предотвращения доступа извне. Если вы разрешаете внешний доступ к серверу NFS, вам нужно быть особенно осторожным к сохранности данных; мы рекомендуем использовать IPSec. Иначе ваш трафик NFS будет потенциально доступен для посторонних. Существуют атаки с подменой IP-адреса на адрес, разрешенный сервером NFS. При правильной настройке IPSec защитит вас от этих видов атак.
Данные сервисы должны быть включены и запущены для работы сервера:
По умолчанию они выключены в OpenBSD. Добавьте следующее в rc.conf.local(8) для включения:
portmap_flags="" mountd_flags="" nfsd_flags="-tun 4"
Следующим шагом мы настроим список файловых систем, чтобы сделать доступным для клиентов монтирование.
В этом примере наш сервер имеет адреc 10.0.0.1 . Этот NFS-сервер обслуживает только клиентов из своей сети. Первый шаг в установке NFS - настройка файла /etc/exports. Этот файл содержит список файловых систем, доступных через NFS, а также определяет, кто имеет к ним доступ. В /etc/exports можно использовать различные опции, читайте о них в man-странице exports(5). Пример файла /etc/exports для рассматриваемого нами сервера:
# # NFS exports Database # See exports(5) for more information. Be very careful, misconfiguration # of this file can result in your filesystems being readable by the world. /work -alldirs -ro -network=10.0.0 -mask=255.255.255.0
Это означает, что локальная файловая система /work будет доступна через NFS. Опция -alldirs означает, что клиенты могут монтировать любую точку внутри /work как /work. Допустим, существует каталог /work/monday, клиенты могут монтировать /work (и иметь доступ внутри него ко всем файлам и каталогам) или же могут смонтировать /work/monday, получив доступ к файлам и каталогам только внутри него. Опция -ro устанавливает доступ только на чтение. Последние два аргумента означают, что только клиенты из сети 10.0.0.0 с маской 255.255.255.0 могут монтировать эту файловую систему. Это важно для серверов, которые доступны из различных сетей.
Еще одно замечание относительно безопасности. Не добавляйте файловую систему в /etc/exports без списка разрешенных хостов. Иначе любой, кто может видеть вашу машину по сети, сможет смонтировать экспортируемые NFS.
Теперь мы можем запустить сервер. Это можно сделать, включив сервис, используя инструкцию ниже и перезагрузку или запустив сервис вручную.
# /etc/rc.d/portmap start # /etc/rc.d/mountd start # /etc/rc.d/nfsd start
Параметр nfsd_flags включает TCP (-t) или UDP (-u) соединения, а также включает 4 подключения (-n) к запущенному nfsd. В файле rc.conf.local, используя параметр nfsd_flags, вы должны установить требуемое значение количества подключений к NFS-серверу, чтобы обеспечить возможностью обработки максимально требуемого количества запросов клиентов.
Теперь вы готовы к монтированию экспортируемой файловой системы клиентами.
Запомните: если вы внесли изменения в /etc/exports в то время как NFS уже работает, вы должны сообщить об этом mountd! Просто пошлите ему сигнал HUP:
# /etc/rc.d/mountd reload
NFS может быть смонтирована клиентом без запуска дополнительных сервисов или демонов. Все это монтируется как любая другая файловая система.
NFS монтируется с помощью mount(8), или, точнее, mount_nfs(8). Для монтирования каталога /work хоста 10.0.0.1 (помните, не обязательно использовать IP адрес; mount может использовать доменное имя хоста) в /mnt на локальной машине используйте:
# mount -t nfs 10.0.0.1:/work /mnt
Для монтирования при загрузке добавьте в /etc/fstab примерно следующее:
10.0.0.1:/work /mnt nfs rw 0 0
Не забывайте использовать 0 0 в конце данной строки файловой системы NFS, чтобы ваш компьютер не пытался запустить на ней fsck. При необходимости следует воспользоваться и другими безопасными опциями: noexec, nodev и nosuid. К примеру:
10.0.0.1:/work /mnt nfs rw,nodev,nosuid 0 0
В этом случае устройства и программы setuid с сервера NFS не смогут нарушить меры безопасности на клиенте NFS. Если вы не планируете запускать программы на клиенте NFS, добавьте noexec в этот список.
При обращении к монтируемому каталогу от пользователя root, сервер автоматически отображает root доступ к имени пользователя "nobody" и группе "nobody". Это важно знать при рассмотрении прав доступа к файлам. Например, возьмем файл с таким набором прав:
-rw------- 1 root wheel 0 Dec 31 03:00 _daily.B20143
Если этот файл находится в NFS, и пользователь root пытается получить доступ к этому файлу через тот или иной NFS-клиент, доступ будет запрещен. Это произойдет потому, что сервер использует учетные данные пользователя, "nobody", когда root пытается получить доступ к файлу. Поскольку пользователь nobody не имеет разрешения на доступ к файлу, в доступе будет отказано.
Пользователи и группы, которые должны иметь root-доступ, настраиваются с помощью файла exports(5) (на стороне сервера).
Для проверки, что сервис NFS работает должным образом, можно поверить RPC, которая регистрирует все запущенные демоны. Для этого используется rpcinfo(8).
$ rpcinfo -p 10.0.0.1
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 633 mountd
100005 3 udp 633 mountd
100005 1 tcp 916 mountd
100005 3 tcp 916 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
Есть также несколько утилит для просмотра происходящего с NFS. Одна из них showmount(8), которая показывает, какие файловые системы смонтированы и кем. Есть также nfsstat(1), которая покажет более подробную статистику. Для использования showmount(8), запустите /usr/bin/showmount -a host. Например:
$ /usr/bin/showmount -a 10.0.0.1 All mount points on 10.0.0.1: 10.0.0.37:/work
Как мы видим, машина с IP 10.0.0.37 примонтировала с сервера 10.0.0.1 каталог /work.
Bridge или Мост - это соединение между двумя или более раздельными сетями. В отличие от рутера, пакеты предаются между сетями "невидимо/прозрачно" - логически, две различных сети объединены в один сегмент с обоих сторон сетевого моста. Мост обеспечит транспорт перенаправлением пакетов из одной сети в другую, при этом обеспечив уменьшение трафика за счет перенаправления только тех пакетов, которые необходимы, при этом упростив схему сети.
Заметим, что в силу своей "невидимости/прозрачности", интерфейсы моста могут не иметь собственных IP-адресов. В этом случае интерфейсы могут быть эффективны в двух режимах работы, как часть моста и как обычный, автономый сетевой адаптер. Если никакой интерфейс не имеет IP, мост сможет передавать необходимые данные, но не будет удобен в удаленном управлении (что может использоваться как feature).
Мои старые компьютеры не имеют встроенного сетевого адаптора 10BASE-TX. В то же время имеются AUI- или AAUI-соединения, у меня нет возможности подключить их по коаксиалу. Одна из машин - OpenBSD терминал-сервер - имеет постоянное соединение с высокоскоростной сетью. Добавление дополнительной сетевой карты с возможностью подключения коаксиалом позволяет сделать мою машину мостом в коаксиальную сеть.
Теперь моя система имеет две NIC: Intel EtherExpress/100 ( fxp0) и 3c590-Combo card ( ep0) с коаксиальным портом. fxp0 обеспечивает связь с моей сетью и поэтому будет иметь IP-адрес, ep0 используется только как мост и не будет иметь IP-адрес. Машины, подключенные к коаксиальному сегменту будут работать как часть моей сети. Как мы это сделаем?
Файл hostname.fxp0 содержит конфигурационную информацию для карты fxp0. Эта машина использует DHCP, таким образом файл содержит:
$ cat /etc/hostname.fxp0 dhcp NONE NONE NONE
Здесь ничего необычного.
Карта ep0 немного отличается:
$ cat /etc/hostname.ep0 up media 10base2
Здесь мы указываем системе поднять интерфейс, используя для этого ifconfig(8), и устанавливаем в 10BASE-2 (coax). IP-адрес или какие-либо дополнительные настройки для интерфейса не указываем. Опции карты ep детально описываются в man-странице для ep.
Теперь мы должны создать мост. Мост инициализируется при помощи файла hostname.bridge0. Здесь приводится пример для нашего случая:
$ cat /etc/hostname.bridge0 add fxp0 add ep0 up
Это означает, что надо создать мост между двумя сетевыми картами, fxp0 и ep0, и активировать его. Не имеет значение в каком порядке перечислены карты. Помните, что мост симметричен, т.е. пакеты перенаправляются в обоих направлениях.
Ну вот и все! Перегружаемся и наслаждаемся работой моста.
Имейте ввиду, в силу специфики моста, трафик проходит через оба интерфейса, таким образом надо настраивать фильтрацию только на одном интерфейсе. Ваши правила вида "разрешено все" соответствуют нижеприведенному:
pass in on ep0 any pass out on ep0 any pass in on fxp0 any pass out on fxp0 any
Теперь, к примеру, мы желаем фильтровать трафик этих старых машин, пропуская только Web- и SSH-трафик. В этом случае мы собираемся пропускать весь входящий и исходящий трафик на интерфейсе ep0, но фильтруя его на fxp0, с использованием keep state для ответного трафика:
# Pass all traffic through ep0
pass in quick on ep0 all
pass out quick on ep0 all
# Block fxp0 traffic
block in on fxp0 all
block out on fxp0 all
pass in quick on fxp0 proto tcp from any to any port {22, 80} \
flags S/SA keep state
Обратите внимание, что этот набор правил предотвращает что-либо, но поступающий HTTP- и SSH-трафик от любой машины моста или любой из других узлов находится "за" ним. Другие результаты могут быть получены путем фильтрации другого интерфейса.
Для того, чтобы проверять и управлять мостом, который вы создали, используйте команду ifconfig(8), которая может также быть использована, чтобы создавать мост после загрузки.
Предположим, машина OpenBSD является сервером, т.е. источником загрузочных файлов (это НЕ обязательно), ваш dhcpd.conf файл DHCP-сервера должен иметь следующую строку:
filename "pxeboot";
чтобы DHCP-сервер попробовал использовать этот файл для загрузки рабочей станции.
Например:
shared-network LOCAL-NET {
option domain-name "example.com";
option domain-name-servers 192.168.1.3, 192.168.1.5;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
filename "pxeboot";
range 192.168.1.32 192.168.1.127;
default-lease-time 86400;
max-lease-time 90000;
}
}
Вы также должны запустить tftpd(8)-демон. Это обычно делается через inetd(8). По умолчанию в OpenBSD в файле inetd.conf есть строка, которая подходит для вас:
#tftp dgram udp wait root /usr/libexec/tftpd tftpd -s /tftpboot
в которой просто нужно удалить символ комментария '#' и послать inetd(8)
HUP-сигнал, чтобы перезагрузить /etc/inetd.conf. tftpd(8) обслуживает
файлы из конкретного каталога, в случае использования этой строки, имя каталога
- /tftpboot, который мы используем для этого примера. Понятное дело,
что этот каталог должен быть создан и там должно быть несколько файлов для
PXE-загрузки:
Когда ваши DHCP- и TFTP-сервера работают, вы можете проверить как это работает. Вы должны активизировать PXE-загрузку на вашей сетевой карте; обратитесь для этого к документации. Как только вы включите этот режим, вы должны увидеть что-то подобное:
Intel UNDI, PXE-2.0 (build 067)
Copyright (C) 1997,1998 Intel Corporation
For Realtek RTL 8139(X) PCI Fast Ethernet Controller v1.00 (990420)
DHCP MAC ADDR: 00 E0 C5 C8 CF E1
CLIENT IP: 192.168.1.76 MASK: 255.255.255.0 DHCP IP: 192.168.1.252
GATEWAY IP: 192.168.1.1
probing: pc0 com0 com1 apm pxe![2.1] mem[540k 28m a20=on]
disk: hd0*
net: mac 00:e0:c5:c8:cf:e1, ip 192.168.1.76, server 192.168.1.252
>> OpenBSD/i386 PXEBOOT 3.16
boot>
C этого момента, у вас есть стандартное приглашение загрузчика OpenBSD.
Если вы набираете "bsd.rd", то просто скачивается файл
bsd.rd с TFTP-сервера.
>> OpenBSD/i386 PXEBOOT 3.16
boot> bsd.rd
booting tftp:bsd.rd: 4375152+733120 [58+122112+105468]=0x516d04
entry point at 0x100120
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2012 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 5.1 (RAMDISK_CD) #95: Sun Feb 12 10:02:21 MST 2012
...
Теперь загружается ядро bsd.rd.
CARP (Common Address Redundancy Protocol) или "Протокол Избыточности Общего Адреса" представляет из себя инструмент для достижения резервирования системы, путем объединения компьютеров в единый виртуальный сетевой сегмент. Это позвиляет распределять нагрузку между машинами, а также, в случае проблем с той или иной системой, заменить ее другой из того же сегмента. CARP является усовершенствованным протоколом VRRP (Virtual Router Redundancy Protocol). Решение о его разработке было принято из-за того, что VRRP не достаточно свободен, в связи с патентом Cisco. Для получения дополнительной информации о происхождении CARP и юридических вопросах, связанных с VRRP, пожалуйста, посетите эту страницу.
Для того чтобы избежать юридических конфликтов, Ryan McBride (с помощью Michael Shalayeff, Marco Pfatschbacher и Markus Friedl) разработал CARP, чтобы он коренным образом был другим. Включение криптографии - одно из множеств изменений, но, пожалуй, наиболее значимое.
Как это работает: CARP является широковещательным протоколом. Он группирует несколько физических компьютеров вместе под одним или более виртуальными адресами. Одна из систем - мастер - отвечает на все пакеты предназначенные для группы, другие системы действуют как горячее резервирование. Независимо от IP- и MAC-адреса локального физического интерфейса, пакеты, посылаемые на CARP-адрес, возвращаются с CARP информацией.
В конфигурируемых интервалах, мастер оповещает о своей работе по IP-протоколу с номером 112. Если мастер становится offline, другие системы в CARP группе начинают оповещение. Хост, способный оповещать наиболее часто, становится новым мастером. Когда бывший мастер возвращается, она становится обычной частью сегмента, хотя, если это более желательно для одного хоста, чтобы он был мастером там, где это возможно (например, один хост является быстрым Sun Fire V120, а другие - сравнительно медленные SPARCstation IPCs), вы можете так сконфигурировать их.
Пока высоко избыточные и отказоустойчивые аппаратные средства минимизируют потребность в CARP, они не снимают вопрос о потребности в CARP. Отсутствует аппаратура отказоустойчивости, которая способна помогать, если кто-нибудь выдергивает шнур питания, или если ваш системный администратор наберет reboot не в том окошке. CARP упрощает процесс наложения заплаток и перезагрузки, делая этот процесс прозрачным для пользователей, а также упрощает процесс тестирования программного обеспечения или аппаратную модернизацию. Если какое-то железо вышло из строя, вы можете использовать резервы пока не почините или замените его.
Есть, тем не менее, ситуации в которых CARP не поможет. CARP спроектирован таким образом, что требует, чтобы участники группы находились в той же физической подсети со статическим адресом IP, хотя с введением директивы carpdev, нет более потребности в IP-адресах на физических интерфейсах. Аналогично, сервисы, требующие постоянное соединение с сервером (например, SSH или IRC), не будут точно переброшены в другую систему – все же в этом случае, CARP может попробовать снизить время простоя. CARP самостоятельно не синхронизирует данные между приложениями, это должно быть сделано через "альтернативные каналы", как например, pfsync(4) (для избыточной фильтрации), вручную дублируя данные между блоками при помощи rsync, или все, что соответствует вашему приложению.
Элементы управления CARP это sysctl(8) и ifconfig(8). Давайте посмотрим сначала на sysctls.
Первый параметр sysctl, net.inet.carp.allow, определяет может ли хост управлять CARP-пакетами полностью. Естественно, что это необходимо для использования CARP. Этот прараметр sysctl включен по умолчанию.
Второй, net.inet.carp.log, ведет лог изменения состояния CARP, проблем с пакетами, если такие имеются, и других ошибок. Установите этот параметр, если хотите иметь подробный журнал сообщений.
Третий, net.inet.carp.preempt включает естественный отбор из числа CARP хостов. Наиболее годный для работы (то есть, способный оповещать наиболее часто), станет мастером. Выключено по умолчанию, с той целью, чтобы система, которая не является мастером, не будет пытаться восстановить (установить) статус мастера.
Все эти переменные sysctl подробно описаны в man-странице sysctl(3).
В завершении конфигурации CARP мы обращаемся к ifconfig(8). Специфические CARP команды advbase и advskew имеют дело с интервалом между CARP оповещениями. Формула (в секундах) - это advskew поделеная на 256, затем добавленая к advbase. advbase может быть использована, чтобы уменьшить сетевой трафик или позволить более длинное время ожидания прежде, чем резервный хост примет эстафету; advskew позволяет вам управлять тем какой хост станет мастером без большой задержки в случае сбоев (если это потребуется).
Затем, pass устанавливает пароль, а vhid - виртуальный идентификационный номер хоста CARP группы. Вам нужно назначить уникальное число для каждой CARP группы, даже если бы (для целей балансировки нагрузки), они разделяют (share) тот же IP адрес. CARP ограничен 255 группами.
Наконец, carpdev определяет какой физический интерфейс принадлежит к конкретной группе CARP. По умолчанию, какой-либо интерфейс, имеющий IP-адрес в той же подсети, назначенной CARP интерфейсу, будет использован.
Давайте поместим все эти настройки вместе в основной конфигурации. Скажем, вы развертываете два идентично сконфигурированных Web-сервера, rachael (192.168.0.5) и pris (192.168.0.6), чтобы заменить более старую систему, которая была по адресу 192.168.0.7. Команды:
rachael# ifconfig carp0 create rachael# ifconfig carp0 vhid 1 pass tyrell carpdev fxp0 \ 192.168.0.7 netmask 255.255.255.0
создадут carp0-интерфейс и дадут ему vhid равным 1, пароль tyrell, и IP адрес 192.168.0.7 с маской 255.255.255.0. fxp0 будет назначачен в качестве элемента интерфейса. Чтобы сделать это постоянным после перезагрузки, вы можете создать /etc/hostname.carp0 файл, который выглядит примерно вот так:
Обратите внимание, что широковещательный адрес определен в этой строке, в дополнительнении к vhid и паролю. Отсутствие этого является причиной ошибок, так что это нужно заполнить.inet 192.168.0.7 255.255.255.0 192.168.0.255 vhid 1 pass tyrell carpdev fxp0
Сделайте тот же для pris. Какая угодно система, поднимающая интерфейс CARP впервые, будет мастером (в предположении, что параметр выключен; в противном случае это тоже истина, когда preempt включен).
Но скажем, вы не развертываете с нуля. rachael был уже на месте по адресу 192.168.0.7. Как вам работать с этим? К счастью, CARP может иметься дело с этой ситуацией. Вы просто назначаете адрес на CARP интерфейс и оставляете физический интерфейс определенный ключевым словом "carpdev" без IP адреса. Тем не менее, он стремится быть чистым, чтобы иметь IP для каждой системы - он делает индивидуальный мониторинг и доступ значительно проще.
Давайте добавим другой уровень сложности; мы хотим, чтобы rachael оставался мастером, когда это возможно. Есть несколько причин, почему нам это может понадобиться: аппаратные различия, простое предубеждение, "если эта система не является мастером, значит у нас проблема" или, зная по умолчанию мастера, не прибегать к помощи сценариев (scripting), чтобы выполнять анализ и отсылать по электронной почте выходные данные ifconfig.
На rachael, мы будем использовать sysctl, который мы создали выше, затем отредактируйте /etc/sysctl.conf, чтобы сохранить изменения.
rachael# sysctl net.inet.carp.preempt=1
Делаем конфигурацию для pris:
pris# ifconfig carp0 advskew 100
Это немного задерживает оповещения от pris, чтобы rachael был мастером, когда жив.
Обратите внимание, что если вы используете PF на CARP компьютере, вы должны разрешить пропускать (pass) "proto carp" на всех связанных интерфейсах, строкой аналогичной этой:
pass on fxp0 proto carp keep state
Пролетело несколько месяцев. Наша компания из предшествующего примера выросла, где единственный внутренний Web-сервер едва справляется с нагрузкой. Что делать? CARP спешит на помощь. Пора пробовать балансировку загрузки. Создайте новый CARP интерфейс и группу на rachael:
rachael# ifconfig carp1 create rachael# ifconfig carp1 vhid 2 advskew 100 pass bryant carpdev fxp0 \ 192.168.0.7 netmask 255.255.255.0
На pris мы создадим новую группу и интерфейс, затем установим sysctl параметр "preempt":
pris# ifconfig carp1 carp1 pris# ifconfig carp1 vhid 2 pass bryant carpdev fxp0 \ 192.168.0.7 netmask 255.255.255.0 pris# sysctl net.inet.carp.preempt=1
Теперь у нас есть две CARP группы с тем же IP адресом. Каждая группа ассиметрична по отношению к другому хосту, с той целью, чтобы rachael остался мастером оригинальной группы, а pris получит власть в новой.
Пока эти примеры для кластера из двух машин, однако те же принципы относятся к многим другим системам. Пожалуйста, обратите внимание, что не стоит ожидать, что вы достигнете идеального 50/50 распределения между двумя машинами. CARP использует хэш исходящих IP-адресов, чтобы определять какая система обработает запрос, скорее, чем по нагрузке.
OpenNTPD является попыткой решить некоторые из этих проблем, сделать программу синхронизации времени на вашем компьютере простой для администрирования, безопасной и совместимой с NTP. ntpd(8) использует легкий в понимании файл конфигурации /etc/ntpd.conf.
Просто запустив ntpd(8) с помощью rc.conf.local, вы включите синхронизацию времени на вашем компьютере с серверами pool.ntp.org (несколько time-серверов). Как только ваши часы будут синхронизированны, ntpd будет следить за их точностью, тем не менее, если ваши часы отстают или спешат на несколько минут, то вы можете перенастроить их. Это можно сделать вручную с помощью опции -s ntpd(8), либо изменить настройки времени вручную на аппаратном уровне.
Бывают случаи, при которых целесообразнее использовать демон ntpd от ntp.org. Тем менее, считается, что для подовляющего большинства пользователей OpenNTPD является более чем достаточным.
Более полный ответ на этот вопрос был дан одним из разработчиков OpenNTPD. Вы можете прочитать его тут.
Может случиться, что после того как ntpd(8) запущен, другие системы все равно не могут синхронизироваться с ним. Недавно запущенный ntpd(8) демон (например, если вы только что перезапустили его после модификации ntpd.conf) отказывается снабжать информацией клиентов, пока они сначала не отрегулируют свои собственные часы на разумный уровень точности. В то время как ntpd(8) рассматривает свою информацию о времени точной, он сообщает "clock now synced" в /var/log/daemon. Даже если системные часы безупречно точны, процессу синхронизации может порой потребоваться до 10 минут.
Устройства, основанные на этих чипах могут быть использованы наравне с другими сетевыми устройствами для подключения машины с OpenBSD к уже существующей беспроводной сети (см. соответствующие руководства man для получения исчерпывающей информации по этому поводу) используя стандартный ifconfig(8). Некоторые из устройств, работая в режиме "точки доступа", могут быть использованы непосредственно для создания полноценной беспроводной ТД, интегрированной в фаервол.
Стоит отметить, что при использовании беспроводных сетевых карт Intel необходимо установить соответствующее аппаратно-программное обеспечение (firmware), которое не является свободно распространяемым и, таким образом, не может быть включено в состав OpenBSD. Вы можете связаться с Intel и высказать им всё, что вы думаете по этому поводу или сообщить какое устройство вы приобрели взамен.
Еще один способ включения OpenBSD в беспроводную сеть состоит в совместном использовании обычной сетевой карты и внешней точки доступа. Очевидное преимущество: подобная схема позволяет удобно расположить антенну в месте, где сигнал будет наиболее качественным, что зачастую отнюдь не является местом непосредственно рядом с машиной.
"Equal-cost multipath routing" означает, что имеется несколько маршрутов в таблице маршрутизации к данной сети, например маршрут по умолчанию default route, 0.0.0.0/0. Когда ядро определяет, каким путем отправить пакет для данной сети, оно может выбрать любой из equal-cost маршрутов. В большинстве случаев такая маршрутизация используется для создания резервированного соединения с сетью логически более "корневого" уровня, например, подключения к сети Интернет.
Команда route(8) используется для добавления/удаления/изменения маршрутов в таблице маршрутизации routing table. Аргумент -mpath используется при добавлении multipath routes.
# route add -mpath default 10.130.128.1 # route add -mpath default 10.132.0.1
Проверим маршрутизацию:
# netstat -rnf inet | grep default default 10.130.128.1 UGS 2 134 - fxp1 default 10.132.0.1 UGS 0 172 - fxp2
В этом примере мы видим, что маршрут по умолчанию достижим используя 10.130.128.1 через интерфейс fxp1, а другой вариант - 10.132.0.1 и fxp2.
Используя файл mygate(5) мы не сможем настроить по умолчанию multipath default routes, нам потребуется еще отредактировать файлы hostname.if(5) для интерфейсов fxp1 и fxp2. Файл /etc/mygate нам надо будет удалить.
Не забудьте для использования multipath routes включить нужные опции sysctl(3).
# sysctl net.inet.ip.multipath=1 # sysctl net.inet6.ip6.multipath=1
Не забудьте отредактировать sysctl.conf(5), чтобы сохранить изменения.
А теперь попробуем выполнить трассировку разными маршрутами. Ядро будет распределять трафик в режиме балансировки (load balance) multipath route.
# traceroute -n 154.11.0.4 traceroute to 154.11.0.4 (154.11.0.4), 64 hops max, 60 byte packets 1 10.130.128.1 19.337 ms 18.194 ms 18.849 ms 2 154.11.95.170 17.642 ms 18.176 ms 17.731 ms 3 154.11.5.33 110.486 ms 19.478 ms 100.949 ms 4 154.11.0.4 32.772 ms 33.534 ms 32.835 ms # traceroute -n 154.11.0.5 traceroute to 154.11.0.5 (154.11.0.5), 64 hops max, 60 byte packets 1 10.132.0.1 14.175 ms 14.503 ms 14.58 ms 2 154.11.95.38 13.664 ms 13.962 ms 13.445 ms 3 208.38.16.151 13.964 ms 13.347 ms 13.788 ms 4 154.11.0.5 30.177 ms 30.95 ms 30.593 ms
Для дополнительной информации о способе выбора маршрута читайте RFC2992, "Analysis of an Equal-Cost Multi-Path Algorithm".
Стоит заметить, если интерфейс, используемый при multipath route потеряет соединение (например, нет carrier), ядро тем не менее все равно будет пытаться отправить через него пакеты. Конечно, этот трафик никуда не попадет. Очень рекомендуется использовать ifstated(8) для проверки доступности интерфейса и коррекции таблицы маршрутизации.
[FAQ-Index] [Глава 5 - Сборка системы из исходников] [Глава 7 - Клавиатура и дисплей]
![[zurück]](../../images/back.gif){kind=small}
www@openbsd.org