| Главная > Операционные системы > Unix/QNX > |
| FAQ по FreeBSD 2.X, 3.X и 4.X. Работа в сети |
Chapter 10. Работа в сети
"Бездисковая загрузка" означает, что машина с 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 режима пользователя имеет параметр -nat. Если вы запустите ppp с параметром -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 10.14. Почему mountd продолжает выдавать сообщения ``can't change attributes'' и ``bad exports list'' на моем сервере NFS, работающем под управлением FreeBSD? В большинстве случаев проблема заключается в недостаточном понимании следующей фразы из справочной страницы по 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) <gfoster@driver.nsta.org>, с некоторыми незначительными добавлениями: Table 10-1. Сетевые карты созданые на основе наборе микросхем DEC PCI
Вы, наверное, обнаружили, что хост, к которому вы обратились, оказался на самом деле в другом домене; например, если вы находитесь в домене 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. Большое количество протестированных правил и природа этих правил не даёт представление о реальной жизни - они были использованы только для генерации информации о времени обработки. Вот несколько наблюдений, которые нужно иметь в виду для построении эффективного набора правил:
Возможно, потому что вы хотите выполнять трансляцию сетевых адресов (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. Во FreeBSD версий 3.0 и выше используется версия BIND, которая для исходящих запросов использует случайно выбираемый порт с большим номером. Если для исходящих запросов вы хотите использовать порт с номером 53 для работы за межсетевым экраном либо просто для собственного спокойствия, то можете попробовать настроить файл /etc/namedb/named.conf следующим образом: options { query-source address * port 53; }; Можете заменить символ * некоторым IP-адресом, если хотите настроить все еще жестче. Кстати, поздравляем. Прекрасно, что вы читаете вывод команды sockstat(1) и обращаете внимание на аномалии! Последние версии Sendmail поддерживают механизм посылки почты, который работает по порту 587. Эта возможность пока широко не используется, но ее популярность растет. Для работы программ, использующих Berkeley Packet Filter bpf(4) необходимо включение в ядро соответствующего драйвера. Перекомпилируйте ядро, добавив в его конфигурационный файл следующую строку: pseudo-device bpf # Berkeley Packet Filter Затем, после перезапуска системы, вам нужно создать соответствующий файл устройства. Это можно сделать, сменив текущий каталог на /dev и выполнив команду # sh MAKEDEV bpf0 Обратитесь к разделу руководства, посвящённому созданию файлов устройств за подробной информацией по этому вопросу. Используйте пакет SMBFS. В него включён набор изменений в ядре и пользовательские программы. Программы и информация доступны в виде порта net/smbfs из Коллекции Портов или как часть базовой системы в 4.5-RELEASE и более поздних версиях. 10.28. Что значат эти сообщения "icmp-response bandwidth limit 300/200 pps" в моих журнальных файлах? Это ядро сообщает вам, что имела место некоторая активность, приводящая к посылке большего количества ответных пакетов ICMP или сбросов TCP (RST), чем, как предполагается, это следует делать. Ответы ICMP часто генерируются в результате попыток подключения к незанятым портам UDP. Сбросы TCP генерируются в результате попыток подключения к неоткрытым портам TCP. Кроме всяких прочих, такие сообщения могут быть вызваны следующими действиями:
Первое число в сообщении указывает вам, какое количество пакетов ядро посылало бы при отсутствии ограничений, а второе число указывает лимит. Вы можете управлять этим ограничением при помощи системной переменной 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. |
Главная Алфавитный индекс Справка Добавить FAQ E-mail |
Новости Поиск по сайту |
© УкрFAQ 2002 |