Сетевое конфигурирование FreeBSD
Категория: Сети TCP/IP | Автор: admin | 17-03-2010, 02:34 | Просмотров: 7211

Во FreeBSD имеются самые современные инструменты из сетевого арсенала: два пакета межсетевой защиты (включая систему NAT), две реализации протокола РРР, поддержка протокола Т/ТСР (представляющего собой достаточно успешную попытку сделать Web-соединения более эффективными) и многое другое.

Основные сетевые параметры указываются в файле /etc/rc.conf. Стартовые сценарии читают также файл /etc/defaults/rc.conf, в котором задаются стандартные значения большинства переменных. Можно создать файл /etc/rc.conf.local, в котором будут храниться параметры, специфичные для заданного узла.

На самом деле перечисленные файлы представляют собой shell-сценарии, создающие среду для работы других стартовых сценариев. Формат этих файлов одинаков, а необходимость их существования объясняется тем, что разработчики хотели разделить конфигурационные данные на уровни и хранить их по отдельности. Файл /etc/defaults/rc.conf содержит начальные значения для большинства параметров. В файле /etc/rc.conf находятся параметры, которые являются локальными, но, возможно, они общие для нескольких машин FreeBSD. Файл rc.conf.local хранит установки, применимые лишь к локальной машине. Для простоты мы предполагаем, что в системе используются только файлы rc.conf.

Модифицировать файл /etc/defaults/rc.conf не нужно. Он полезен тем, что содержит практически полный список переменных, доступных для модификации, наряду с описанием их предназначения.

С точки зрения системного администратора, единственное заметное различие между FreeBSD 3.4 и 4.0 заключается в том, что стандартное ядро содержит больше драйверов сетевых устройств (общим числом 13), а также имеется встроенная поддержка стандарта IPv6.

 

Базовое конфигурирование

 

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

 

hostname="имя_узла"          # это обязательно!

ifconfig_xxx="inet IP-адрес" # конфигурация сетевого устройства

defaultrouter="шлюз"         # стандартный шлюз

 

 

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

network_interfaces="lo0 х10"

 

Статические маршруты задаются в переменной static_routes:

 

static_routes="backlan 212"           # список статических маршрутов

route_backlan="-net 10.0.2.0 132.236.212.2"

route_212="-net 132.236.212.64 -netmask 255.255.255.192 132.236.212.6"

 

 

Переменная static_routes содержит разделенный запятыми список имен маршрутов. Имя маршрута — это произвольная строка, определяющая переменную route_имя, в которой задаются аргументы для команды route add.

По умолчанию маршрутизация полностью запрещена. Поэтому в большинстве систем нужно либо указать стандартный маршрут, либо задать стандартные маршруты, либо активизировать демон routed или gated. (По умолчанию база данных NIS тоже отключена.)

 

Примеры конфигураций

 

Чтобы вручную сконфигурировать Ethernet-плату и задать стандартный маршрут, необходимо воспользоваться такими командами:

 

# ifconfig xl0 inet 192.108.21.11 netmask 0xffffff00

# route add default 192.108.21.254

 

 

Вторая из показанных команд эквивалентна следующей команде:

 

# route add -net 0.0 0.0 192.108.21.254
 

 

В отличие от большинства версий команды route, во FreeBSD эта команда требует наличия дефиса перед опцией, задающей тип маршрута (-net или -host), и не принимает счетчик числа переходов.

 

После выполнения указанных выше действий команды ifconfig и netstat –nr выдают такие результаты:

 

% ifconfig xl0

xl0:  flags=884 3<UP, BROADCAST, RUNNING,SIMPLEX,MULTICAST>mtu 1500

inet 192.108.21.11 netmask 0xffffff00 broadcast 192.108.21.2:

ether 00:60:97:9b:69:9a

media: l0baseT/UTP <half-duplex>

supported media: autoselect l00baseTX <full-duplex> 100baseTX

<half-duplex> l00baseTX l0baseT/UTP <full-duplex> l0baseT/UTP

10baseT/UTP <half-duplex>

 

% netstat -nr

Routing tables Internet:

Destination      Gateway          Flags   Refs   Use    Netif   Exp

default          192.108.21.254   UGSc     0      18    xl0

127.0.0.1        127.0.0.1        UH       0      3     lo0

192.108.21       link#l           UC       0      0     xl0

192.108.21.1     8:0:20:77:5e:a0  UHLW     2      2586  xl0     1160

192.108.21.246   0:30:f2:f:48:0   UHLW     0      0     xl0     303

192.108.21.254   0:0:с:14:82:81   UHLW     1      0     x10     1126

 

 

Флаги с и С в выводе команды netstat -nr говорят о том, что новые маршруты узла (три последние строки) должны быть автоматически сгенерированы и добавлены в таблицу маршрутизации при выборе локального сетевого маршрута или стандартного маршрута. Обратите внимание на то, что у каждого из новых маршрутов есть срок действия.

Необходимость увеличения таблицы маршрутизации объясняется двумя причинами. Первая из них заключается в том, что для маршрутов локальной сети таблица маршрутизации одновременно является ARP-таблицей. Обычно это разные таблицы, но в 4.4BSD они были объединены, и FreeBSD унаследовала это свойство. Вторая причина та, что FreeBSD пытается сохранять параметры соединений с внешними узлами (например, значение MTU для TCP-соединения), запоминая их в таблице маршрутизации. Тогда при последующих подключениях к тому же самому узлу можно будет повторно использовать эти параметры, не вычисляя их заново. Когда срок действия записи истекает, она удаляется из таблицы маршрутизации.

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

Следующий пример приведен в системе FreeBSD 4.0, где реализован как стек IPv4, так и стек IPv6. В обоих случаях конфигурирование интерфейса осуществляется посредством команды ifconfig:

 

% ifconfig fxp1

fxpl:  flags=8943<UP,BROADCAST,RUNNING,SIMPLEX, MULTICAST>mtu 1500

inet 135.197.1.116 netmask 0xffffff00 broadcast 135.197.1.255 inet6 fe80::208:c7ff:fe89:4f03%fxp1 prefixlen 64 scopeid 0x2 ether 00:08:c7:89:4f:03

     media: autoselect  (lOObaseTX <half-duplex>)  status:active

supported media: autoselect l00baseTX <full-duplex> l00baseTX 10baseT/UTP <full-duplex> 10baseT/UTP

 

 

Конфигурирование DHCP

 

Во FreeBSD имеется DHCP-клиент организации ISC. Он конфигурируется посредством файлов rc.conf. Стандартные значения в файле /etc/defaults/rc.conf таковы:

 

dhcp_program="/sfcin/dhclient"    # Путь к DHCP-клиенту

dhcp_flags=""                     # Флаги, передаваемые клиенту

 

 

Скорее всего, эти значения правильны; менять их требуется только в том случае, когда программа dhclient перемещается в другой каталог или вместо нее подставляется другая программа. Чтобы активизировать протокол DHCP для конкретного интерфейса, добавьте следующую строку в файл /etc/rc.conf:

ifconf_интерфейс="DHCP"    # Активизация DHCP для данного интерфейса

 

При такой конфигурации программа dhclient будет запущена на этапе начальной загрузки, если существует файл /etc/dhclient.conf. Эта программа отвечает за получение IP-адреса для интерфейса, задание стандартного маршрута, выбор правильного сервера имен и т.д.

Файл dhclient.conf — это текстовый конфигурационный файл произвольной формы, напоминающий аналогичный файл пакета BIND или DHCP-сервера ISC. С ним связано слишком много опций и параметров, чтобы все их можно было описать здесь. К счастью, стандартные установки в большинстве случаев подходят, поэтому можно оставить файл пустым.

Программа dhclient хранит информацию об арендованных параметрах в файле dhclient.leases, а свой идентификатор процесса — в файле /var/run/dhclient.pid.

 

Динамическое переконфигурирование и настройка

 

Узнать или задать значение переменной ядра во FreeBSD можно с помощью команды sysctl. Существуют сотни различных переменных, из которых около 65-ти связаны с конфигурированием сети. Подробное их описание можно получить на man-странице sysctl(3).

Команда sysctl -А выводит список переменных с их текущими значениями. В именах переменных, связанных с конфигурированием сети, присутствует компонент "net". Чтобы отобразить только их, задайте команду sysctl -А | grep net.

Если нужно узнать значение конкретной переменной, укажите ее имя в строке вызова команды sysctl. Например, посредством следующей команды можно определить, поддерживает ли система перенаправление IP-пакетов:

% sysctl net.inet.ip.forwarding

net.inet.ip.forwarding: 1

 

Значение 1 означает поддержку. Чтобы изменить значение переменной, укажите флаг -w и задайте новое значение через знак равенства:

 

% sudo sysctl -w net.inet.ip.forwarding=0

net.inet.ip.forwarding :  1 -> 0

 

 

Эта команда отключает перенаправление IP-пакетов.

 

Безопасность, брандмауэры, фильтрация и система NAT

 

В табл. 13.23 описано, как во FreeBSD реализован ряд технологий, касающихся безопасной работы в сети. О них кратко рассказывалось параграфе 13.9. В третьем столбце указаны переменные, посредством которых можно изменить соответствующую установку; эти переменные должны быть заданы в файле /etc/rc.conf, а не с помощью команды sysctl.

Таблица 13.23. Поддержка технологий, связанных с сетевой безопасностью, во FreeBSD

Технология

По умолчанию

Переменная файла rc.conf

Перенаправление IP-пакетов

отключено

gateway_enable

Переадресующие ICMP-пакеты

принимаются

icmp_drop_redirect1

Направленная маршрутизация

игнорируется

forward sourceroute и accept sourceroute

Широковещательные ping-пакеты

игнорируются

icmp bmcastecho

1   Имеется также переменная icmp_log_redirect, посредством которой включается регистрация ICMP-пакетов.

 

Лучше не применять компьютер, работающий под управлением UNIX (или Windows NT), в качестве брандмауэра, особенно в крупной организации где по сети передаются важные данные. Безопаснее и надежнее использовать специализированное оборудование, например систему Cisco PIX. В то же время программный брандмауэр на базе UNIX подойдет для домашнего компьютера, где пользователь регулярно обновляет систему, устанавливая самые последние "заплаты". Ниже мы опишем два пакета межсетевой защиты имеющихся во FreeBSD: ipfw и IPFilter.

Программа ipfw поддерживает концепцию "фиктивной" сети, посредством которой можно управлять Internet-трафиком, задавая ширину полосы пропускания и длину очередей ввода-вывода, а также имитируя задержки и потери. Изначально "фиктивная" сеть была задумана как средство устранения, заторов в TCP-каналах, но затем нашла много других применений. Сегодня она используется для ограничения ширины канала, занимаемого Web- или FTP-трафиком, и для управления загруженностью выделенных линий. Более подробная информация приведена на man-странице dummynet.

С программой ipfw легко работать, а ее синтаксис напоминает синтаксис списков доступа компании Cisco. Чтобы реализовать систему NAT посредством программы ipfw, воспользуйтесь утилитой natd в каталоге /sbin.

Подобно программе ipchains в Linux, программа ipfw вызывается по одном разу для каждого правила фильтрации. Таким образом, брандмауэр реализуется в виде shell-сценария, из которого вызывается последовательность команд ipfw. Ниже показан фрагмент этого файла, который поможет понять синтаксис команды. В данном примере de0 — это внешний интерфейс, a edl — внутренний. Третий параметр каждой строки задает номер правила. Правила обрабатываются по порядку, от младшего к старшему. Этот порядок, важен так как самое первое правило, которому соответствует проверяемый пакет определяет выполняемое действие.

# Файл программы ipfw для FreeBSD

# Сначала удаляем старые правила

ipfw -f flush

#Разрешаем все пакеты от DHCP-сервера и узла gw.syanck.net

ipfw add 500 allow ip from 128.138.129.136 to any

ipfw add 510 allow ip from 209.180.251.58 to any

# Разрешаем входной и выходной трафик SSH

ipfw add 600 allow tcp from any to any 22 via de0

ipfw add 605 allow tcp from any 22 to any in via de0

# Разрешаем ARP-пакетам проходить через мост

ipfw add 1000 allow udp from 0.0.0.0 2054 to 0.0.0.0

 

Другие правила разрешают входной и выходной DNS-трафик, доступ к внешнему Web-содержимому, DHCP-запросы и UDP-пакеты для программ traceroute и Quake (это студенческий компьютер). Весь трафик в пределах локальной сети также разрешен. Ведется "черный" список адресатов, обращающихся к DNS-серверу с запросами относительно несуществующих узлов. Весь остальной трафик из внешнего мира блокируется.

Пакет IPFilter, написанный Дарреном Ридом, заслуживает большего внимания, поскольку он совместим со многими другими версиями UNIX. В него входит программа ipf, конфигурирующая брандмауэр, программа ipfstat, отображающая список инсталлированных правил фильтрации, программа ipnat, реализующая систему NAT, и ряд других утилит. Пакет доступен по адресу

http://coombs.anu.edu.au/~avalon/ip-filter.html

 

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

option IPFILTER

option IPFILTER_LOG

 

Пакет IPFilter проводит четкое разграничение между фильтрацией пакетов и системой NAT, а не смешивает их подобно программе ipchains в Red Hat. На man-страницах ipf(l) и ipf(5) описан язык задания фильтров и приведено множество примеров.

Программа ipf читает файл (по умолчанию это /etc/ipf.rules), в котором заданы правила следующего вида:

действие in|out  [quick] условие...

 

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

  • pass — принять пакет;
  • block — удалить пакет;
  • log — зарегистрировать пакет в системе Syslog;
  • count — вести подсчет пакетов, соответствующих данному правилу.

 

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

Описанное поведение прямо противоположно работе программ ipchains и ipfw, поэтому в Linux брандмауэр работает быстрее: при первом же совпадении обработка пакета прекращается. Программу ipf удобно применять для реализации так называемого консервативного брандмауэра, в котором самое первое правило запрещает все пакеты, а остальные правила разрешают пакеты конкретных типов.

 

В табл. 13.24 даны примеры условий, которые можно задавать в программе ipf. Это лишь вершина айсберга. Полная информация приведена на man-странице, посвященной программе ipf.

Таблица 13.24. Примеры условий в программе ipf

Условие

Назначение

on интерфейс

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

proto протокол

Отобрать пакеты, соответствующие указанному протоколу: tcp, udp или icmp

from исходный_адрес

Фильтрация на основании адреса отправителя: машинный адрес, сетевой адрес или any

to целевой_адрес

Фильтрация на основании адреса получателя: машинный адрес, сетевой адрес или any

port = номер_порта

Фильтрация в соответствии с номером порта, который может быть задан по имени (из файла /etc/services) или номеру; вместо знака = может быть любой другой арифметический оператор (<, >, <=, >=)

flags спецификация_флагов

Фильтрация на основании флагов заголовка ТСР-пакета

icmp-type номер

Фильтрация на основании типа и кода ICMP

keep state

Сохранить информацию о состоянии сеанса; обычно это нужно, чтобы отличать рабочие TCP-сеансы от новых сеансов

 

Давайте повторно реализуем цепочку правил, описанную ранее в параграфе, посвященном Red Hat, но на этот раз вместо программы ipchains применим программу ipf. Как и раньше, мы предполагаем, что интерфейс ррр0 — это соединение с Internet, а интерфейс eth0 — локальная Ethernet-плата. Следующие правила разрешают весь локальный трафик и запрещают пакеты, поступающие по частным адресам из внешнего мира:

pass in on eth0 all

pass in on lo all

block in quick on ppp0 from 192.168.0.0/16 to any

block in quick on ppp0 from 172.16.0.0/12 to any

block in quick on ppp0 from 10.0.0.0/8 to any

 

Чтобы блокировать пакеты программы telnet, но разрешить почтовые и SSH-соединения, воспользуемся такими правилами:

block in proto tcp from any to any port = 23

pass in on ppp0 proto tcp from any to any port = 25

pass in on ppp0 proto tcp from any to any port = 22

 

 

Последние два правила должны также включать предложения flags и keep-state, чтобы предотвратить перехват TCP-соединений. Обратитесь к параграфу 21.9 и man-странице ipf(5), где подробно описано, какие правила нужно задавать и как их записывать. Те, кто работает в операционной системе OpenBSD, могут просмотреть файл /usr/share/ipf. В нем содержится множество примеров команд ipf и ipnat.

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

Синтаксис правил NAT, задаваемых в программе ipnat, напоминает синтаксис правил программы ipf. Эти правила тоже упорядочены, но в обратной последовательности: действие выбирается на основании первого подошедшего правила.

Вот несколько примеров правил программы ipnat (они задаются в файле ipnat.rules):

map ррр0 192.168.1.0/24 -> 128.138.198.0/26 portmap tcp/udp 20000: 65000

map ppp0 192.168.1.0/24 -> 128.138.198.0/26

Опять-таки, мы предполагаем, что ррр0 — это интерфейс доступа в Internet, а локальным компьютерам назначаются адреса из диапазона частных адресов. Эти правила связывают адреса из сети /24 с адресами сети /26. Поскольку в сеть /26 может входить в четыре раза меньше узлов, чем в сеть /24, существует вероятность, что в какой-то момент целевых адресов окажется недостаточно. Но предложение portmap расширяет диапазон адресов, разрешая назначать каждому адресу 45000 различных портов.

Первое правило регулирует весь трафик TCP и UDP, но не затрагивает ICMP, так как в этом протоколе нет понятия порта. Второе правило задает перехват всех ICMP-сообщений; должна быть сделана попытка вернуть их узлу-отправителю. Если ядро не может однозначно определить, кто должен принять заданное ICMP-сообщение, оно осуществляет широковещательную рассылку пакета. Любая машина, которая получит не предназначенный ей пакет, должна удалить его.

На домашнем компьютере пользователю может быть предоставлен реальный IP-адрес провайдера или адрес, полученный от DHCP-сервера провайдера. Если выделяется статический адрес, нужно в строке тар задать для целевого адреса суффикс /32 и достаточно широкий диапазон номеров портов. Если же при каждом подключении адрес назначается заново, воспользуйтесь нотацией 0/32, которая заставит программу ipnat получить адрес непосредственно от сетевого интерфейса. Например, ниже показана строка для случая, когда динамически назначается один единственный адрес:

mар ррр0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:65000

 

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

# ipf -Е -Fa -f /etc/ipf.rules

# ipnat -CF -f /etc/ipnat.rules

# ipmon -D -s

 

Флаг -E команды ipf разрешает фильтрацию, флаги -Fa вызывают сброс существующих правил для всех потоков, а флаг -f задает чтение новых правил из файла /etc/ipf.rules. Точно так же в случае программы ipnat сначала удаляются старые правила, а затем загружаются новые из файла /etc/ipnat.rules. Программа ipmon выполняется в качестве демона, отслеживая пакеты, которые регистрируются программой ipf на псевдоустройстве /dev/ipl, и направляя их системе Syslog.

По умолчанию FreeBSD предполагает, что в качестве системы фильтрации используется программа ipfw, а не ipf. Нужно придумать новые переменные, которые включали бы фильтрацию программы ipf в файле rc.conf, и задать соответствующие строки в стартовом сценарии rc.network. Возьмите за образец строки вызова программы ipfw. Редактирование файла rc.network мы оставляем читателям в качестве домашнего задания; укажем лишь, что система NAT конфигурируется посредством переменных natd_*:

natd_program="/usr/sbin/ipnat"

natd_enable="YES"

natd_interface="xxx"                # имя устройства или IP-адрес

natd_flags="-f /etc/ipnat.rules"    # плюс любые необходимые флаги

 

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

 

Конфигурирование РРР

 

Во FreeBSD имеются две реализации протокола РРР: одна в самом ядре, а другая — на пользовательском уровне. Пользовательская программа называется ррр. Она использует драйвер IP-туннелей и файл конфигурации /etc/ppp/ppp.conf. Эта программа работает медленнее, чем аналогичный модуль ядра, но у нее есть много дополнительных особенностей. Она подробно описана в соответствующих man-страницах, поэтому мы не будем рассказывать о ней так же детально, как о реализации РРР уровня ядра.

Программа ррр требует, чтобы в ядро было включено псевдоустройство tun и существовали файлы /dev/tun0, /dev/tun1 и т.д. Она конфигурируется посредством файла ppp.conf; его образец расположен в каталоге /etc/ррр и содержит примеры всех опций, которые могут когда-либо понадобиться Существует также ряд вспомогательных файлов. Файл ррр.deny содержит список пользователей (например, root и bin), которым запрещается вызывать программу ррр. Файл ррр.shells включает список каталогов для всех доступных интерпретаторов команд; программа ррр запрещает доступ в систему пользователям, чей интерпретатор не указан в списке.

Запись default в файле ppp.conf задает такие параметры, как скорость передачи в бодах, файл устройства для модема, опции регистрации и порядок подключения. Далее следуют записи для всех узлов, с которыми могут быть установлены РРР-соединения, например:

allow user имя_локалъного_пользователя

netblazer800:

set phone номер_телефона

set login "ABORT NO\sCARRIER TIMEOUT 5 ogin:— - ogin: имя

word: пароль"

set timeout 120

delete ALL

add default HISADDR

 

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

РРР-модуль ядра использует демон pppd. Его регистрационные файлы также хранятся в каталоге /etc/ррр, основные из них — это options и ppp.deny. Они обычно служат в качестве дополнения к локальным файлам терминального сервера на противоположном конце соединения. Например, файл options.netblazer содержит параметры конкретного устройства, а файл chat.netblazer — регистрационную информацию. Во FreeBSD имеются образцы конфигурационных файлов для нескольких РРР-сценариев; они расположены в каталоге /usr/share/examples.

Показанные ниже конфигурационные файлы описывают РРР-соединение между домашним компьютером Эви Немет и университетом штата Колорадо. Первый файл содержит глобальные параметры демона pppd, второй — параметры подключения к древнему терминальному серверу Netblazer, установленному на факультете вычислительной техники, а третий файл — это диалоговый сценарий, осуществляющий регистрацию на сервере:

% cat /etc/ppp/options

# Глобальные РРР-параметры

lock            # всегда блокировать используемое устройство

asyncmap 0x00000000

crtscts         # использовать аппаратное управление потоком

modem           # использовать управляющие сигналы модема

defaultroute    # добавить стандартный маршрут через РРР-интерфейс

mru 552         # MRU/MTU 512  (данные)  + 40  (заголовок)

mtu 552

 

% cat /etc/ppp/options.netblazer

# Файл параметров конкретного РРР-соединения

128.138.198.47:128.138.243.167      # локальный:удаленный IP-адрес

netmask 255.255.255.0               # маска подсети

/dev/cuaa2                        # используется третий последов, порт

57600                             # скорость соединения в бодах

# persist                         # пытаться повторно подключиться

                                  # в случае неудачи

# holdoff 5                       # ждать 5 секунд между попытками

connect "/usr/bin/chat -v -f /etc/ppp/chat.netblazer"

disconnect "/etc/ppp/hangup"      # пытаться отсоединиться корректно

 

% cat /etc/ppp/chat.netblazer

ABORT BUSY ABORT  'MO CARRIER'

TIMEOUT 5 OK-‘’-'' ATZ OK-+++ATHZ-OK АТDТномер_телефона

TIMEOUT 60 CONNECT   ''

TIMEOUT 10 ogin:—ogin: Pevi

ssword: пароль

'Packet mode enabled'

 

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

В нашей системе регистрационные РРР-имена — это имена пользователей, перед которыми ставится префикс 'Р'. Так их легче запоминать.

Для запуска демона pppd необходимо задать такую команду:

% sudo pppd file /etc/ppp/options.netblazer

 

 

Демону можно передавать аргументы в командной строке, а также посредством файлов /etc/ppp/options, ~/.ррр и /etc/ppp/options.терминальный_сервер.

Чтобы разорвать РРР-соединение, нужно просто уничтожить демон рррd:

% sudo kill 'cat /var/run/ррр0.pid'

 

Если компьютер является портативным и периодически подключается к сети посредством Ethernet-платы, а не протокола РРР, то перед запуском демона pppd будет существовать стандартный маршрут через сетевой интерфейс Ethernet. К сожалению, демон pppd не умеет удалять этот маршрут и устанавливать свой собственный, что логично было, бы ожидать. Для устранения этой проблемы нужно перед запуском демона удалять стандартный маршрут. Мы рекомендуем написать маленький сценарий ррр.up, осуществляющий эту задачу автоматически.

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

% ifconfig ppp0

ppp0: flags=805KUP, POINTOPOINT, RUNNING, MULTICAST> mtu 552

inet 128.138.198.47 —> 128.138.243.167 netmask 0xffffff00

 

% netstat -nr

Routing tables

Internet:

Destination      Gateway          Flags   Refs   Use    Netif   Expire

default          128.138.243.167  UGSc    3      0      ppp0

127.0.0.1        127.0.0.1        UH      0      0      lo0

128.138.243.167    128.138.198.47 UH      4      0      ppp0

 

С помощью команды pppstats можно узнать статистику РРР-соединений

% pppstats

     IN    PACK   СОМР  UNC  ERR |   OUT   PACK   COMP   UNC   NON-VJ

1647029    5101   4596  157  0   |203582   5051   4566   210   275

 

В столбце COMP отображается число пакетов, для которых применяется сжатие TCP-заголовка, а в столбце UNC — соответственно число пакетов без сжатия. Подробнее об этом можно узнать в документе RFC 1144.

 

Особенности сетевого конфигурирования

 

Команда route во FreeBSD не понимает параметр, задающий число переходов. Если же по ошибке указать его, команда воспримет это число как сетевую маску. Таким образом, "безобидный" счетчик 1 будет проинтерпретирован как маска 0.0.0.1, которая сделает все маршруты, включая стандартный, совершенно бесполезными.


 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page