Chapter 12. Работа в сети

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

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

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

Этот параметр изменит значение sysctl(8)-переменной net.inet.ip.forwarding на 1.

Кроме того, в большинстве случаев вам будет необходимо запустить программу маршрутизации, для того, чтобы объявить о появлении нового маршрутизатора другим системам в вашей сети; FreeBSD поставляется со стандартной для BSD-систем программой маршрутизации routed(8), в более сложных ситуациях вы можете попробовать GaTeD (доступный по адресу http://www.gated.org с ftp.gated.Merit.EDU), который поддерживает FreeBSD начиная с версии 3_5Alpha7.

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

Как правило, те, кто задает такие вопросы, имеют дома два компьютера, один с FreeBSD, а другой с Win95; идея состоит в использовании FreeBSD для подключения к Internet, а затем осуществлять выход в Internet из Windows95 через FreeBSD. На самом деле это просто особый случай предыдущего вопроса.

... и ответ на него - да! Во FreeBSD 3.x, ppp(8) режима пользователя имеет параметр -nat. Если вы запустите ppp(8) с параметром -nat, установив в файле /etc/rc.conf gateway_enable в значение YES и правильно настроите машину с Windows, то всё должно прекрасно заработать.

Более подробная информация о настройке может быть найдена в Подробном Учебнике по PPP Стива Симса (Steve Sims).

Если вы используете PPP режима ядра, или у вас Ethernet-подключение к Internet, можно воспользоваться командой natd(8). Пожалуйста, обратитесь к разделу о natd этого FAQ.

Это - результат конфликта между файлом cdefs.h в дистрибутиве и тем, что поставляется с FreeBSD. Достаточно удалить файл compat/include/sys/cdefs.h.

Да. Обратитесь к страницам справочника по командам slattach(8), sliplogin(8), ppp(8), и pppd(8). ppp(8) и pppd(8) могут обслуживать как входящие, так и исходящие соединения, когда как sliplogin(8) имеет дело исключительно со входящими соединениям, а slattach(8) - только с исходящими.

Более подробная информация об их использовании находится в разделе Руководства о протоколах PPP и SLIP.

Если вы имеете доступ в Internet только через командную строку оболочки, вам может подойти slirp. С его помощью можно получить (ограниченный) доступ к таким службам, как FTP и http прямо с вашей машины.

Если у вас есть локальная сеть (одна или больше машин), но только один IP адрес, предоставленный провайдером, вас может привлечь natd(8). natd позволяет подключить всю сеть к Internet, используя единственный IP адрес.

Программа ppp(8) имеет похожую встроенную возможность через параметр -nat. В обоих случаях используется библиотека alias (посмотрите справку по libalias(3)).

Для этого нужен соединительный шнур типа laplink и на обеих машинах должна быть включена поддержка драйвера lpt.

    # dmesg | grep lp
    lpt0 at 0x378-0x37f irq 7 on isa
    lpt0: Interrupt-driven
    lp0: TCP/IP capable interface

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

Настройте параметры сетевого интерфейса lp0 на обеих машинах, войдя администратором. Например, если вы хотите соединить хосты с именами max и moritz

                    max <-----> moritz
    IP Address    10.0.0.1      10.0.0.2

на машине max дайте команду

    # ifconfig lp0 10.0.0.1 10.0.0.2

на машине moritz запустите

    # 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                max.my.domain max
    10.0.0.2                moritz.my.domain

Для проверки работоспособности связи выполните следующие действия:

на машине max:

    # 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
    moritz             max              UH          4   127592       lp0
    # ping -c 4 moritz
    PING moritz (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

    --- moritz 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

В стандарте сетевого взаимодействия Беркли сетевые интерфейсы напрямую доступны только ядру. За дополнительной информацией обратитесь к файлу /etc/rc.network и страницам справочника, описывающим различные сетевые программы, упоминаемые здесь. Если всё это оставит вас в недоумении, почитайте книгу, описывающую администрирование сети в другой BSD-подобной операционной системе; с некоторыми незначительными исключениями, администрирование сети во FreeBSD в основном совпадает с SunOS 4.0 и Ultrix.

Добавьте netmask 0xffffffff в командной строке ifconfig(8) так, как это сделано здесь:

    # ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff

Если вы хотите задействовать другой разъём, то должны указать дополнительный параметр при вызове команды ifconfig(8). Разъёмом по умолчанию является link0. Чтобы задействовать разъём AUI, а не BNC, используйте link2. Эти флаги должны быть указаны с помощью переменных ifconfig_* в файле /etc/rc.conf (посмотрите справку по rc.conf(5)).

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

Подробности описаны в соответствующей главе Руководства, посвящённой NFS.

Некоторые версии NFS для Linux поддерживают запросы на монтирование только с привилегированного порта; попробуйте

    # mount -o -P linuxbox:/blah /mnt

Рабочие станции Sun под управлением SunOS 4.X поддерживают запросы на монтирование только с привилегированного порта; попробуйте

    # mount -o -P sunbox:/blah /mnt

В большинстве случаев проблема заключается в недостаточном понимании следующей фразы из справочной страницы по exports(5)

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

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

    /usr/src   client
    /usr/ports client

Здесь имееются две строки, описывающие свойства одной файловой системы, /usr, экспортируемой некоторому хосту с именем client. Правильный формат таков:

    /usr/src /usr/ports  client

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

Ниже дается пример правильно составленного списка экпортирования, где /usr и /exports являются локальными файловыми системами:

    # Экспортировать src и ports для client01 и client02, но только
    # client01 имеет на них права администратора
    /usr/src /usr/ports -maproot=0    client01
    /usr/src /usr/ports               client02
    # "Клиентские" машины имеют корень и могут выполнять монтирование
    # где угодно выше каталога.
    # Все остальные могут монтировать /exports/obj только для чтения
    /exports -alldirs -maproot=0      client01 client02
    /exports/obj -ro

Попробуйте отменить все расширения TCP в файле /etc/rc.conf (посмотрите справку по rc.conf(5)), изменив значение следующей переменной в NO:

    tcp_extensions=NO

Маршрутизаторы Annex фирмы Xylogic не работают по этой же причине, поэтому при подключении к ним вам нужно проделать то же самое.

Работа с многоадресной рассылкой по умолчанию полностью поддерживается версиями FreeBSD 2.0 и выше. Если вы хотите использовать ваш компьютер как маршрутизатор многоадресного трафика, вам нужно перекомпилировать ядро с включенной опцией MROUTING и запустить mrouted(8). Версии FreeBSD 2.2 и выше будут запускать mrouted(8) во время загрузки, если переменная mrouted_enable в файле /etc/rc.conf установлена в значение YES.

Приложения MBONE находятся в собственной категории портов, mbone. Если вы ищете приложения для организации конференций vic и vat, посмотрите там!

Вот список, составленный Гленом Фостером (Glen Foster) <[email protected]>, с некоторыми незначительными добавлениями:

Вы, наверное, обнаружили, что хост, к которому вы обратились, оказался на самом деле в другом домене; например, если вы находитесь в домене foo.example.org и хотите обратиться к хосту mumble в домене example.org, то должны указать его полное доменное имя, mumble.example.org, а не просто mumble.

Традиционно, это позволял делать ресолвер BSD BIND. Однако текущая версия bind (посмотрите справку по named(8)), поставляемая с FreeBSD, больше не добавляет имена доменов, отличающихся от того, в котором вы находитесь, для не полностью указанных имён хостов. Так что неполно указанный хост mumble будет найден либо как mumble.foo.example.org, либо будет искаться в корневом домене.

Это отличается от предыдущего поведения, при котором поиск продолжался в mumble.example.org и mumble.edu. Посмотрите RFC 1535 о причинах объявления такого поведения плохой практикой и даже ошибкой в безопасности.

Как хорошее решение, вы можете поместить строку

    search foo.example.org example.org

вместо ранее используемой

    domain foo.example.org

в файл /etc/resolv.conf (посмотрите справку по resolv.conf(5)). Однако удостоверьтесь, что порядок поиска не нарушает "границ полномочий между местным и внешним администрированием", как это названо в RFC 1535.

Если вы компилировали ядро с опцией IPFIREWALL, имейте в виду, что политика по умолчанию настроена как в 2.1.7R (она на самом деле изменилась во время разработки 2.1-STABLE), то есть указан запрет на прохождение всех пакетов, которые явно не разрешены.

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

    # ipfw add 65534 allow all from any to any

Также вы можете установить firewall_type='open' в файле /etc/rc.conf.

Более подробная информация о конфигурировании межсетевого экрана в FreeBSD находится в соответствующем разделе Руководства.

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

Следующие измерения были сделаны с использованием 2.2.5-STABLE на машине 486-66. IPFW был модифицирован для измерения времени, затрачиваемого внутри процедуры ip_fw_chk и вывода результатов на консоль каждую тысячу пакетов.

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

    # ipfw add deny tcp from any to any 55555

Это наихудший случай, так как все условия IPFW будут проверены перед тем, как будет принято окончательное решение о том, что пакет не соответствует условию (мы меняли номер порта). После 999 повторений этого условия находилось правило allow ip from any to any.

Второй набор был предназначен для быстрого прерывания процесса проверки условий:

    # ipfw add deny ip from 1.2.3.4 to 1.2.3.4

Неподходящий IP-адрес источника для указанного условия быстро вызывает пропуск этого правила. Как и ранее, последним правилом было allow ip from any to any.

Затраты на обработку пакета в первом случае было примерно 2.703 мс/пакет, или примерно 2.7 микросекунд на правило. Таким образом, теоретический предел скорости обработки пакетов с этими правилами равен примерно 370 пакетам в секунду. Предполагая использование Ethernet 10Мб/с с размером пакета примерно 1500, мы можем достигнуть только 55.5% использования пропускной способности.

В последнем случае на обработку каждого пакета было затрачено примерно 1.172мс, или около 1.2 микросекунд на правило. Теоретический предел обработки будет равен около 853 пакетам в секунду, что почти соответствует скорости 10Мб/с Ethernet.

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

• Поместите правило `established' в самое начало списка для обработки основного трафика TCP. Не помещайте перед ним никаких правил allow tcp.

• Старайтесь помещать часто вызываемые правила как можно раньше, а редко используемые - позже (без изменения политики, конечно). Вы можете выяснить частоту использования правил с помощью вывода статистики командой ipfw -a l.

Возможно, потому что вы хотите выполнять трансляцию сетевых адресов (NAT), а не просто перенаправлять пакеты. Правило "fwd" делает точно то, что означает; оно перенавравляет пакеты. Данные внутри пакета оно не меняет. Пусть, скажем, у нас имеется правило такого вида:

    01000 fwd 10.0.0.1 from any to foo 21

Когда пакет с адресом назначения foo достигает машины с этим правилом, то он перенаправляется на 10.0.0.1, но в нем остается адрес назначения foo! Адрес назначения пакета не меняется на 10.0.0.1. Большинство машин скорее всего отбросят полученный пакет, имеющий адрес назначения, им не соответствующий. Таким образом, правило "fwd" не часто работает так, как ожидает пользователь. Такое поведение является особенностью, а не ошибкой.

Обратитесь к FAQ о перенаправлении сервисов, руководству по natd(8) или одной из нескольких утилит для перенаправления в Коллекции Портов для того, чтобы сделать это правильно.

Вы можете перенаправить запрос на FTP (или другой сервис) с помощью пакаджа socket, доступного в дереве портов в категории "sysutils". Просто замените командную строку запуска сервиса на вызов socket, типа:

    ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp

где ftp.example.com и ftp являются соответственно хостом и портом для перенаправления.

Для FreeBSD имеются три средства управления трафиком. dummynet(4), интегрированный в систему FreeBSD (более точно, в ipfw(4)); свободно распространяемый ALTQ и коммерческий продукт Bandwidth Manager от Emerging Technologies.

Для работы программ, использующих Berkeley Packet Filter bpf(4) необходимо включение в ядро соответствующего драйвера. Перекомпилируйте ядро, добавив в его конфигурационный файл следующую строку:

    pseudo-device bpf  # Berkeley Packet Filter

Затем, после перезапуска системы, вам нужно создать соответствующий файл устройства. Это можно сделать, сменив текущий каталог на /dev и выполнив команду

    # sh MAKEDEV bpf0

Обратитесь к разделу руководства, посвящённому созданию файлов устройств за подробной информацией по этому вопросу.

Используйте пакет SMBFS. В него включён набор изменений в ядре и пользовательские программы. Программы и информация доступны в виде порта net/smbfs из Коллекции Портов или как часть базовой системы в 4.5-RELEASE и более поздних версиях.

Это ядро сообщает вам, что имела место некоторая активность, приводящая к посылке большего количества ответных пакетов ICMP или сбросов TCP (RST), чем, как предполагается, это следует делать. Ответы ICMP часто генерируются в результате попыток подключения к незанятым портам UDP. Сбросы TCP генерируются в результате попыток подключения к неоткрытым портам TCP. Кроме всяких прочих, такие сообщения могут быть вызваны следующими действиями:

• Лобовая атака типа отказ в обслуживании DoS (в отличие от атак в один пакет, которые используют конкретную брешь в защите).

• Сканирование портов в попытке осуществить подключение к большому количеству портов (в отличие от проб нескольких известных портов).

Первое число в сообщении указывает вам, какое количество пакетов ядро посылало бы при отсутствии ограничений, а второе число указывает лимит. Вы можете управлять этим ограничением при помощи системной переменной net.inet.icmp.icmplim приводимым ниже способом, где 300 является ограничением на количество посылаемых пакетов в секунду:

    # sysctl -w net.inet.icmp.icmplim=300

Если вы не хотите видеть подобные сообщения в журнальных файлах, но хотите использовать это ограничение в ядре, то можете использовать системную переменную net.inet.icmp.icmplim_output для подавления вывода, как это показано здесь:

    # sysctl -w net.inet.icmp.icmplim_output=0

И наконец, если вы хотите выключить это ограничение, то можете установить значение системной переменной net.inet.icmp.icmplim (смотрите пример выше) равным 0. Выключение этого лимита не приветствуется по причинам, перечисленным выше.

Это означает, что какое-то устройство в вашей локальной сети использует MAC-адрес в формате, не распознаваемом FreeBSD. Скорее всего, это происходит из-за того, что кто-то в сети эскспериментирует с сетевым адаптером. Чаще всего это происходит в сетях с кабельными модемами. Это безобидно и не должно влиять на производительность машины с FreeBSD.