После того, как мы разобрались с основными протоколами и IP-адресами, не плохо было бы понять, как все это вместе стыкуется и работает. В заголовках протоколов нет наименований протоколов, а есть только номера. Кроме того, данные каждому приложению также доставляются с использованием номеров, которые называются портами. Пара - протокол и порт - позволяет стеку протоколов TCP/IP доставить данные нуждающемуся в них приложению. Увидеть номера протоколов можно в файле /etc/protocols или прочитать в RFC Assigned Numbers.
Содержание файла /etc/protocols:
Ix: {3} more protocols
#
# Internet (IP) protocols
#
# $Id: protocols,v 1.2.8.1 1995/08/30 06:19:30 davidg Exp $
# from: @(#)protocols 5.1 (Berkeley) 4/17/89
#
# Updated for FreeBSD based on RFC 1340, Assigned Numbers (July 1992).
#
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # Internet Group Management
ggp 3 GGP # gateway-gateway protocol
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
st 5 ST # ST datagram mode
tcp 6 TCP # transmission control protocol
egp 8 EGP # exterior gateway protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
hmp 20 HMP # host monitoring protocol
xns-idp 22 XNS-IDP # Xerox NS IDP
rdp 27 RDP # "reliable datagram" protocol
iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4
xtp 36 XTP # Xpress Tranfer Protocol
idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport
rsvp 46 RSVP # Resource ReSerVation Protocol
vmtp 81 VMTP # Versatile Message Transport
ospf 89 OSPFIGP # Open Shortest Path First IGP
ipip 94 IPIP # Yet Another IP encapsulation
encap 98 ENCAP # Yet Another IP encapsulation
Как видно из содержания файла protocols, практически всем основным протоколам присвоены номера. Другой группой магических цифр являются номера портов, которые закреплены за информационными сервисами Internet.
Информационный сервис - это прикладная программа, которая осуществляет обслуживание на определенном порте TCP или UDP. Собственно WKS - это и есть совокупность этих сервисов Internet. К сервисам относятся: доступ в режиме удаленного терминала, доступ к файловым архивам FTP, доступ к серверам World Wide Web и т. п. Распределение сервисов по портам можно найти в файле /etc/services. Сам файл сервисов очень большой, поэтому приведем только небольшой его фрагмент с наиболее интересными и популярными сервисами.
Фрагмент содержания файла /etc/services:
quest:/etc:\[2\]>cat services tcpmux 1/tcp # TCP port service multiplexer echo 7/tcp echo 7/udp ... ftp 21/tcp # 22 - unassigned telnet 23/tcp # 24 - private smtp 25/tcp mail # 26 - unassigned time 37/tcp timserver time 37/udp timserver rlp 39/udp resource # resource location whois 43/tcp nicname domain 53/tcp nameserver # name-domain server domain 53/udp nameserver bootps 67/tcp # BOOTP server bootps 67/udp bootpc 68/tcp # BOOTP client bootpc 68/udp tftp 69/udp gopher 70/tcp # Internet Gopher gopher 70/udp finger 79/tcp www 80/tcp http # WorldWideWeb HTTP www 80/udp # HyperText Transfer Protocol
Среди сервисов, определенных в этом фрагменте, есть не только информационные сервисы типа World Wide Web или Gopher, но и протокол маршрутизации RIP, и протокол удаленной загрузки bootp, и сервис доменных имен BIND, и другие протоколы, которые нацелены на повышение работы сети и чрезвычайно полезны при администрировании сети.
При работе через стек протоколов TCP/IP сообщения, которыми обмениваются приложения, сначала инкапсулируются в сегменты TCP или дейтаграммы UDP, при этом указывается соответствующий порт транспортного протокола. Потом транспортные протоколы мультиплексируются в IP, который запоминает номер протокола. Все IP-пакеты передаются по сети получателю, где происходит обратная операция изъятия информации из оболочки TCP/IP. Сначала по номеру протокола в модуле IP выделенные данные пересылаются соответствующему протоколу транспортного уровня. На транспортном уровне по номеру порта получателя определяется какому сервису данные посланы. Все это графически изображено на рисунке 2.19.
Рис. 2.19. Использование номеров портов и номеров протоколов для передачи данных
Однако, этим механизм взаимодействия приложений в рамках TCP/IP не исчерпывается. Дело в том, что кроме статически назначенных WKS существуют еще динамически назначаемые сервисы.
Динамически назначаемые номера портов TCP и UDP используются для того, чтобы можно было организовать обслуживание множества запросов по сети к одному WKS. В том же примере стрелочки только в одном направлении указаны не случайно. К серверу протокола HTTP могут обращаться сразу несколько клиентов, следовательно должен быть механизм, который бы позволил распараллелить их обслуживание. Таким механизмом служит динамическое назначение портов (рисунок 2.20). Происходит это назначение в момент установки соединения. Клиент, запрашивая обслуживание, обращается к сервису по номеру порта WKS, но при этом сообщает, что принимать ответы он будет по номеру порта, отличному от WKS. Таким образом, сервер может обслуживать запросы к одному и тому же порту WKS, используя разные порты при ответе. Образующаяся при этом пара (IP-адрес, номер порта) называется сокетом (буквально "розетка"). Таким образом, можно сказать, что http-сервер для обслуживания использует сокет, например, 144.206.130.137;80, а клиент, который к нему обращается, сокет 144.206.130.138;8080. Графически определение сокета можно продемонстрировать на примере протокола TCP.
Рис. 2.20. Динамическое назначение портов. Образование сокетов
Описывая взаимодействие в рамках TCP/IP обмена, мы до сих пор обходили стороной вопросы связанные с тем, как пакет реально транспортируется по сети. Все наши примеры ограничивались работой в рамках локальной сети. Теперь пора поговорить о том, как осуществляется передача пакетов по сети, или в терминах сетевого обмена - маршрутизация.
Как уже было сказано раньше, протокол IP не является протоколом ориентированным на соединение. Следовательно, решение о направлении IP-пакета на тот или иной сетевой интерфейс принимается шлюзом в момент прохождения через него пакета. Данное решение принимается на основании таблицы маршрутов, имеющаяся на каждом компьютере, который поддерживает стек протоколов TCP/IP.
Прежде чем перейти к описанию самой процедуры, введем пример сети, на которой будем рассматривать маршрутизацию пакетов (рисунок 2.21).
Рис. 2.21. Пример фрагмента локальной сети
На рисунке 2.21 изображены два фрагмента подсетей (144.206.160.0 и 144.206.128.0) сети класса B (144.206.0.0). Машина с интерфейсами, которые имеют адреса 144.206.160.32 и 144.206.130.137 - это шлюз между двумя подсетями, а машина с адресом сетевого интерфейса 144.206.130.3 - это шлюз сети с другой сетью, которая подключена к Internet.
Рассмотрим сначала путь пакета от машины с адресом 144.206.160.40 к машине с адресом 144.206.160.33. Предположим, что к этой машине пользователь 144.206.160.40 еще не обращался. В рамках такого обмена машине достаточно знать только свой IP-адрес. Прежде чем отправить пакет, модуль ARP проверит, существует ли соответствие между IP-адресом получателя и физическим адресом какого-либо интерфейса включенного в локальную сеть. В нашем случае такого соответствия еще нет, поэтому в сеть будет отправлен широковещательный запрос на получение физического адреса по заданному IP-адресу. В ответ машина 144.206.160.33 сообщит свой адрес, после чего пакет будет отправлен в сеть. В поле физического адреса в фрейме протокола канального уровня будет указан адрес машины 144.206.160.33. Вообще говоря, такая процедура была разработана для Ethernet, но в последнее время ARP стали применять и для других физических сред, в частности, для FrameRelay.
Теперь отправим пакет машине из другой подсети 144.206.130.138. В этом случае на широковещательный запрос мы ответа не получим. Но пакет отправлять как-то надо. Для этой цели в описании маршрутов пакетов всегда есть IP-адрес, на который следует отправлять пакеты по умолчанию, если нет другого способа их рассылки. Естественно, что это адрес шлюза. Для машины 144.206.160.40 таким адресом является адрес 144.206.160.32. Физический адрес этого интерфейса получают точно также, как мы до этого получили физический адрес интерфейса 144.206.160.33. Принципиальное различие здесь заключается в том, что в первом случае адреса получателя и отправителя во фрейме физического протокола совпадали с адресами, которые указаны для IP-адресов из IP-пакета в таблице ARP. В случае шлюза здесь можно обнаружить несоответствие. Во фрейме в качестве получателя будет указан адрес интерфеса 144.206.160.32, в то время как в IP-пакете будет указан IP-адрес 144.206.130.138. Но ведь этому IP-адресу соответствует совсем другой физический адрес. Если быть более точным, то другой адрес будет соответствовать в сети Ethernet, если же речь идет о FrameRelay, то там может применяться относительная система адресации, что может приводить к равенству физических адресов.
Получив таким образом пакет модуль IP машины шлюза определяет, что это не его адрес указан в IP-пакете. После такого открытия IP-модуль шлюза принимает решение о дальнейшей отправке пакета. Отправлять пакет в тот же интерфейс, из которого он получен - бессмысленно, поэтому модуль IP никогда не отправляет пакеты назад. Следовательно, происходит поиск нужного интерфейса и через него снова рассылается широковещательный запрос ARP. В нашем случае такой запрос вернет для IP-адреса 144.206.130.138 физический адрес машины и пакет будет отправлен по этому адресу.
Если пакет отправляется в Internet, то шлюз не найдет физического адреса машины, и будет вынужден воспользоваться адресом рассылки по умолчанию. Таким образом, пакет попадет на шлюз через 144.206.130.3 и там будет решаться его судьба.
При рассмотрении стека протоколов TCP/IP на компьютере с одним сетевым интерфейсом было не очень понятно, зачем IP дублирует физический адрес, например, Ethernet, ведь каждому адресу Ethernet ставился в соответствие один IP-адрес. При рассмотрении архитектуры стека протоколов шлюза этот вопрос становится более понятным.
Из рисунка 2.22 видно, что таблица ARP создается для каждого интерфейса. Для получения таких таблиц можно использовать команду arp, где в качестве аргумента надо указать имя интерфейса. Модуль IP для шлюза общий и таблица маршрутов, а именно, она и используется модулем для перенаправления пакетов на интерфейсы, также общая.
Прежде чем перейти к описанию таблицы маршрутов и способам управления ею, обратим свое внимание на способы настройки сетевых интерфейсов, т.к. без них никакой стек протоколов работать с сетью не будет.
Рис. 2.22. Архитектура шлюза 144.206.130.137-144.206.160.32
Прежде чем начать описание настроек сетевых интерфейсов, обратим свое внимание на особенности операционной системы, которая должна работать с сетью TCP/IP. Чаще всего при этом подразумевается операционная система Unix. Мы не будем отступать от этой традиции. Рассмотрим настройку ОС вручную, а не с использованием диалоговых средств, которые широко применяются в HP-UX, IRIX, SCO и т. п. В Unix все равно все сводится к выполнению тех же самых команд, но только программами или скриптами. Администратор всегда может воспользоваться интерфейсом командной строки, чтобы поправить настройки, выполненные ранее рекомендованными в руководстве по администрированию средствами.
Для того, чтобы система работала со стеком протоколов TCP/IP необходимо соответствующим образом настроить ядро системы. В системах клона BSD конфигурация определяется в фале типа /usr/sys/conf, Например, во FreeBSD 2.x, - это файл /sys/i386/conf/GE-NERIC, если речь идет о только что установленной системе.
Обычно, на основе этого файла делают копию, которую называют local, и в этой копии проводят изменения настроек. В этом файле следует определить, чаще всего раскомментировать, строки, которые определяют сетевые интерфейсы, например, ed0 или ed1, если речь идет о Ethernet. Кроме этого, если машина будет работать шлюзом, нужно указать опцию GATEWAY, если нужно использовать распределенную файловую систему, то нужно заказать также соответствующие опции. Для таких протоколов, как SLIP и PPP, нужно определить еще и псевдоустройства. Ниже приведен пример такого файла конфигурации, точнее фрагмент.
Файл конфигурации ядра FreeBSD 2.x.
quest:/usr/src/sys/i386/conf:\[6\]>cat QUEST options NFS #Network File System options GATEWAY #Host is a Gateway (forwards packets) device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device ed0 at isa? port 0x280 net irq 9 iomem 0xd8000 vector edintr device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr pseudo-device loop pseudo-device ether pseudo-device log pseudo-device sl 2
Из этого фрагмента видно, что данная машина позволяет работать с распределенной файловой системой, является шлюзом, имеет два сетевых интерфейса Ethernet: ed0 и ed1, а также еще два интерфейса на последовательных портах: sl0 и sl1, что соответствует портам sio0 и sio1.
Для того, чтобы данная конфигурация была реализована, надо пересобрать ядро. Для этого выполняется процедура генерации make-файлов, и после этого выполняется программа make. Как только новое ядро собрано его можно копировать в корень на место существующего ядра, но при этом надо не забыть сохранить старое ядро. Обычно Unix позволяет указать при загрузке имя файла ядра, что позволит загрузиться на машине, новое ядро которой оказалось неработоспособным.
В системах клона System 5, настройки ядра распределены по многим фалам. Здесь лучше воспользоваться стандартными средствами конфигурации типа SAM в HP-UX, т.к. можно просто забыть что-нибудь подправить.
При настройках Windows NT систему можно сконфигурировать для работы с сетями TCP/IP как при установке, так и потом, по мере необходимости. Правда отложенная конфигурация приведет к перезагрузке системы. Настраивается сеть из меню network в меню control panel. Там также определяется тип интерфейса и копируется с дистрибутива драйвер для данного интерфейса. Потом для интерфейса определяется семейство протоколов, где среди протоколов Microsoft можно найти и TCP/IP. Далее интерфейсу назначается IP-адрес, определяется шлюз и сервер доменных имен. Другие параметры, типа сервиса WINS (Windows Internet Name System), мы рассматривать не будем, т.к. это касается только Windows, а не Internet вообще.
При установке стека TCP/IP на машины с операционной системой MS-DOS следует иметь в виду, что здесь надо установить все выше описанное, но только в отличии от выше перечисленных операционных систем все программное обеспечение является прикладными задачами, а не частью операционной системы, поэтому никакой перенастройки ядра не происходит. Общая схема машины с OC MS-DOS, поддерживающей стек TCP/IP будет выглядеть так, как показано на рисунке 2.23.
Рис. 2.23. Структура стека программного обеспечения для поддержки стека протоколов TCP/IP на персональном компьютере
Естественно, что все эти модули, которые представлены на рисунке 2.23 должны быть указаны в файлах config.sys и autoexec.bat. Примеры содержания файлов autoexec.bat и config.sys приведены ниже и основаны они на настройке персонального компьютера notebook, который работает с сетью либо через сетевой PCMCI-адаптер Ethernet, либо через PCMCI-модем, что и отражено в вариантной загрузке.
Пример файла autoexec.bat
@ECHO OFF set tz=MSK set temp=c:\temp set tmp=c:\temp PATH C:\WINWORD;C:\;C:\NC5;C:\WINDOWS;C:\DOS;C:\UT;C:\ME;c:\spelchek\g4; c:\spelchek\logs;c:\photo; goto %config% :Network PATH %PATH%c:\network\tel;c:\network\xfs; :Dial-in :Local LH CYRILLIC LH C:\DOS\SHARE.EXE /l:500 /f:5100 nc
При работе через сетевой адаптер все интерфейсы устанавливаются только в config.sys, а в autoexec.bat подправляется только переменная окружения PATH.
Содержание файла config.sys
[menu] menuitem=Local, Load Computer without any drivers. menuitem=Network, Start Computer with Ethernet Network Conection. menuitem=Dial-in, Start Computer in Local Mode with Dial-in Connection. [common] rem common statments [Local] rem ordinal [Network] rem network interface installation device=c:\network\pktdrv\accopen.exe /int=5 /port=300 /mem=0000 DEVICE=C:\DOS\HIMEM.SYS DEVICE=c:\dos\emm386.exe noems [Dial-in] DEVICE=C:\DOS\HIMEM.SYS DEVICE=c:\dos\emm.386.exe noems ; PCMCI modem DEVICEHIGH=C:\PCMCIA\SSVADEM.SYS DEVICEHIGH=C:\PCMCIA\AMICS.SYS DEVICEHIGH=C:\PCMCIA\PCMODEM.SYS
Впрочем, для различных систем и для различных пакетов, настройки могут довольно сильно отличаться, но структура всегда будет одной и той же.
Таким образом, после сборки нового ядра в системах Unix и Windows NT, или после выполнения настройки MS-DOS в системе появляются сетевые интерфейсы, стек протоколов TCP/IP и возможность совместной настройки интерфейсов и стека протоколов.
Настройкой сетевых интерфейсов называют определение параметров обмена данными через сетевой интерфейс и присвоение ему IP-адреса. Сначала разберем, как это делается для интерфесов Ethernet, а потом уже для последовательных портов.
2.8.1. Настройка Ethernet-интерфейса
В данном случае никаких параметров настраивать не надо. Следует только назначить IP-адрес. Делается это по команде ifconfig:
/usr/paul>ifconfig ed0 inet 144.206.130.138 netmask 255.255.224.0
В данном случае интерфесу ed0 назначается адрес 144.206.130.138, при этом на сети установлена маска 255.255.224.0. В общем случае команда ifconfig имеет следующий формат:
ifconfig interface address_family [address [dest_address]] [parameters]
В этой команде параметры означают следующее:
interface - имя сетевого интерфейса;
address_famaly - тип адреса. В нашем случае - это inet, т.е. адрес Internet. Данное значение задается по умолчанию;
address - IP-адрес источника. Обычно в этом поле указывают IP-адрес который назначается сетевому интерфейсу. Если речь идет об интерфейсе Ethernet то этого адреса достаточно для его настройки.
dest_address - IP-адрес получателя. Данный адрес указывается для интерфейсов типа "точка-точка", например, для SLIP (sl0) или PPP (ppp0). В таких соединениях к концам линии связи подключены только два интерфейса и надо задать адрес обоих. В предыдущем поле (address) задают адрес своего интерфейса, а в данном поле интерфейса, установленного на другом конце линии.
В качестве параметров можно указать маску сети, как это сделано в примере. Этот параметр - обязательный. Существуют и другие параметры, например адрес широковещания, но их используют редко и обычно в данном случае их значения назначаются по умолчанию, так, например, адрес широковещания по умолчанию ограничен локальной сетью, и это правильно, т.к. нет нужды "светиться" за пределами своего шлюза.
Команда ifconfig может быть использована и для получения информации об интерфейсе. Для этого в ней надо указать только имя:
quest:/usr/src/sys/i386/conf:\[14\]>ifconfig ed1
ed1: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX>
inet 144.206.130.138 netmask ffffe000 broadcast 144.206.159.255
quest:/usr/src/sys/i386/conf:\[15\]>
В данном случае была запрошена информация об интерфейсе ed1. Из отчета видно, какие флаги установлены для данного интерфейса и какой адрес ему назначен. С точки зрения администратора важно, что этот интерфейс в данный момент работоспособен (флаг UP) и не используется для сканирования пакетов в сети. Сканированию пакетов мы уделим достаточно внимания в разделе, посвященном вопросам безопасности сети.
Однако более исчерпывающую статистику можно получить при помощи команды netstat:
quest:/usr/src/sys/i386/conf:\[19\]>netstat -ain Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 <Link>0.0.1b.12.32.46 52848 0 45380 0 0 ed0 1500 144.206.192 144.206.192.1 52848 0 45380 0 0 ed1 1500 <Link>0.0.1b.12.32.32 659682 2354 45708 276 4423 ed1 1500 144.206.128 144.206.130.138 659682 2354 45708 276 4423 lo0 65535 <Link> 138 0 138 0 0 lo0 65535 127 127.0.0.1 138 0 138 0 0 sl0* 296 <Link> 0 0 0 0 0 sl1* 296 <Link> 0 0 0 0
В данном отчете перечислены все сетевые интерфейсы, минимальные размеры фреймов, которые могут передаваться через них, сети и IP-адреса данного хоста на этих сетях, сколько пакетов через интерфейс было принято, сколько из них было поврежденных, сколько пакетов было отправлено и сколько из них было поврежденных и, в заключении, число коллизий, зарегистрированное интерфейсом. Кроме того, в данном отчете указаны еще и Ethernet-адреса интерфейсов.
Кроме этого, следует обратить внимание интерфейс lo0, который закреплен за петлей 127.0.0.1. Для этого интерфейса также нужна команда ifconfig.
/usr/paul> ifconfig lo0 inet localhost
В данном случае имя localhost будет заменено на 127.0.01.
Но Ethernet - это только один из интерфейсов, которые могут быть использованы при подключении к сети. Кроме него довольно популярны интерфейсы подключения через последовательные порты.
2.8.2. Настройка SLIP
С последовательным портом работают через псевдоустройство sl0, которое и является интерфейсом последовательного порта. Для сцепления sl0 c устройством служит команда slattach:
/usr/paul/slattach /dev/cuaa0 144.206.160.100 144.206.160.101
Однако, формат slattach от одной системы к другой существенно изменяется. Так в ряде случаев сначала выдается команда slattach, которая присоединяет интерфейс к порту, а затем на нее выдается команда ifconfig для интерфейса sl.
/usr/paul>slattach -c -s 38400 /dev/sio01 /usr/paul>ifconfig sl1 inet 144.206.160.100 144.206.160.101 netmask 255.255.224.0
В данном случае определен интерфейс для обмена данными по протоколу SLIP с компрессией, со скоростью на порту 38400, через порт /dev/sio01.
Как показывает практика, доступ по протоколу SLIP обычно организуют для удаленных пользователей, которые через данный шлюз хотят работать с Internet. Однако, не всегда можно "зацепиться" за модем надежно. Кроме того, на одном и том же порту могут обслуживаться как терминальные пользователи, так и пользователи Internet, а кроме того, туда же можно подключать и пользователей UUCP. В этом случае гораздо разумнее вместо slattach воспользоваться командой sliplogin. Данная команда также имеется не во всех операционных системах. Но обычно во всех есть ее аналог.
Суть sliplogin заключается в том, что пользователь, который дозвонился и работает в режиме удаленного терминала, имеет возможность самостоятельно запустить из этого режима присоединение sl интерфейса и его настройку на IP-адреса и параметры сессии. Это же дает возможность провайдерам, устанавливая стеки TCP/IP на персональных компьютерах, включать в их настройки скрипты, которые автоматически производят аутентификацию в удаленной машине и конфигурирование интерфейса для работы по SLIP.
Выглядит это следующим образом:
Из этого режима обычно самостоятельно не выходят: либо обрывается связь, либо происходит какое-нибудь другое чрезвычайное событие. Поэтому систему настраивают таким образом, чтобы она сама завершала задачу и клала трубку на модеме.
Sliplogin управляется тремя файлами slip.hosts, slip.login и slip.logout. В файле slipl.host перечисляются пользователи, которым разрешено запускать sliplogin, и какие адреса при этом назначаются, а также тип протокола SLIP (с компрессией или без нее). Ниже приведен пример такого файла:
quest:/etc:\[7\]>cat slip.hosts paul 144.206.192.99 144.206.192.100 255.255.224.0 ; alex 144.206.130.138 144.206.192.102 255.255.224.0 compress dimag 144.206.192.99 144.206.192.103 255.255.224.0 dima 144.206.192.99 144.206.192.104 255.255.224.0 vovka 144.206.192.99 144.206.192.105 255.255.224.0 maverick 144.206.192.99 144.206.192.106 255.255.224 0 arch1996 144.206.192.99 144.206.192.107 255.255.224.0
Однако, этого мало. Фактически, sliplogin выполняет slattach на порт, через который работает пользователь, но после этого этот порт надо сконфигурировать. Для этой цели служит скрипт slip.login:
quest:/etc:\[8\]>cat slip.login #!/bin/sh /sbin/ifconfig sl$1 $4 $5 netmask $6 >> /tmp/sliplogin.log exit 0 quest:/etc:\[9\]>
После того, как соединение разорвалось, следует убрать все процессы которые им были вызваны. Для этой цели служит скрипт sliplogout.
quest:/etc:\[9\]>cat slip.logout
#!/bin/sh
PATH=:/bin:/sbin:/usr/bin:/usr/sbin:
export PATH
(ps ax | egrep 'sliplogin | slattach' | grep $3 |grep -v grep | awk '{print $1;}'
| xargs kill ) >> /tmp/sliplogin.log
quest:/etc:\[10\]>
Смысл написанного в этом файле заключается в том, что бы найти все остатки от sliplogin и по команде kill прервать их выполнение.
Однако для выделенных телефонных каналов обычно применяется другой протокол, а именно PPP.
2.8.3. Настройка интерфейса PPP
В различных системах настройка интерфейсов PPP производится по-разному. Поэтому мы снова будем основываться на примере BSDI и FreeBSD. Для работы через PPP в этих системах используется либо демон pppd, либо прикладная программа ppp. Обычно демон используется для выделенных линий и для приема звонков на выделенном под PPP порте. Программа ppp используется для запуска из командной строки.
Для того, чтобы использовать демона в файле конфигурации ядра, необходимо определить псевдоустройство ppp(0-1). Демона помещают в файл начальной загрузки. Настройки демона производятся при помощи файла настроек:
vega-gw: {6} cat options
/dev/cuaa2
57600
194.190.135.22:194.190.135.21
netmask 255.255.255.252
passive
defaultroute
#debug
local
#kdebug 7
В данном примере мы используем файл /etc/ppp/options. В нем определяется порт, через который настраивается интерфейс, скорость на порте, адрес интерфейса и адрес ответного интерфейса провайдера, маска, установленная на сети провайдера, команда passive, которая заставляет оставлять данный интерфейс постоянно в таблице маршрутов, определение его как шлюза по умолчанию, и определяет его управление с локальной машины. Кроме этого, в данном файле есть еще и закомментированные опции, которые использовались автором во время отладки соединения. Включение этих двух опций приводит к полному дампированию пакетов PPP, что позволяет выяснить причины отсутствия соединения или плохого соединения.
В данном случае мы отлаживали соединение с relarn, где на конце relarn пакеты принимал маршрутизатор CISCO.
Если надо устанавливать соединение с удаленной машины со шлюзом, то вместо SLIP можно также использовать PPP. Но только в этом случае лучше всего использовать программу ppp. Она также настраивается через свой файл конфигурации, пример которого приведен ниже:
vega-gw: {7} cat ppp.conf
default:
set device /dev/cuaa0
set speed 38400
disable lqr
deny lqr
# set debug level LCP
relarn:
set ifaddr 194.190.135.22 194.190.135.21
add 0 255.255.255.252 194.190.135.21
Надеюсь, что значение параметров в этом файле понятно и без лишних комментариев.
Главной особенностью программы ppp является то, что ее можно запустить в интерактивном режиме, по мере ее работы менять тип информации, который подлежит отладке.
При использовании и ppp, и pppd команды ifconfig на интерфейсы выдавать не надо, т.к. эти команды сами производят их настройку.
В заключении разговора о настройке интерфейсов приведем пример таблицы интерфейсов с машины, где работает сразу три разных интерфейса:
vega-gw: {9} netstat -ain
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
ed1 1500 <Link>00.20.c5.00.35.c4 10574 0 10223 0 2
ed1 1500 194.226.43 194.226.43.1 10574 0 10223 0 2
lp0* 1500 <Link> 0 0 0 0 0
lo0 16384 <Link> 357 0 357 0 0
lo0 16384 127 127.0.0.1 357 0 357 0 0
ppp0 1500 <Link> 58000 0 55347 0 0
ppp0 1500 194.190.135 194.190.135.22 58000 0 55347 0 0
ppp1* 1500 <Link> 0 0 0 0 0
sl0* 552 <Link> 20570 1 21281 0 0
sl0* 552 194.226.43 194.226.43.99 20570 1 21281 0 0
sl1* 552 <Link> 0 0 0 0 0
tun0* 1500 <Link> 0 0 0 0 0
В этой таблице можно найти интерфейс Ethernet (ed1), интерфейс PPP (ppp0) и интерфейс SLIP (sl1), которые находятся в активном состоянии и принимают и отправляют пакеты.
Через интерфейс ed1 (IP-адрес: 144.226.43.1) доступна сеть 144.226.43.0, через интерфейс ppp0 (IP-адрес: 194.190.135.22) доступна сеть 144.190.135.0, которая является путем в Internet, через sl0 (IP-адрес: 194.226.43.99) работает удаленный пользователь.
Назад | Содержание | Вперед