Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

62 Глава 2. Доставка данных

да route системы Solaris существенно отличается в части синтаксиса. При ра-

боте с Solaris для вывода содержимого таблицы маршрутизации воспользуй-

тесь командой netstat

-nr.

Ключ

-г

предписывает отобразить таблицу марш-

рутизации, а ключ -п - использовать при этом числовой формат адресов.

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

ла. Это именно тот кольцевой адрес, о котором говорилось выше, как о заре-

зервированном номере сети. Каждая система использует кольцевой марш-

рут для отправки дейтаграмм самой себе, так что запись кольцевого марш-

рута присутствует в таблице маршрутизации любого узла. Флаг Н говорит о

том, что система Solaris создает маршрут к определенному узлу (127.0.0.1),

а не к целой сети (127.0.0.0). Мы еще вернемся к кольцевому интерфейсу,

когда будем говорить о настройке ядра и команде ifconfig. Сейчас же пред-

метом нашего интереса являются внешние маршруты.

В приведенной таблице есть и другая особая запись - та, что содержит слово

«default» в поле адресата. Это запись маршрута по умолчанию, а шлюз, ука-

занный в записи, является шлюзом по умолчанию. Маршрут по умолчанию -

еще один из ранее упомянутых зарезервированных номеров сетей. Шлюз по

умолчанию используется в том случае, если ни один из конкретных маршру-

тов таблицы не соответствует указанному сетевому адресу получателя. На-

пример, в таблице маршрутизации отсутствует запись для сети 192.168.16.0.

Получив дейтаграммы, адресованные получателю в этой сети, протокол IP

перешлет их через шлюз по умолчанию 172.16.12.1.

Все шлюзы, упоминаемые в таблице маршрутизации, принадлежат к сетям,

напрямую подключенным к локальной системе. Для последнего примера

это означает, что все адреса шлюзов начинаются с последовательности

172.16.12, вне зависимости от указанного адреса получателя. Это единст-

венная сеть, с которой напрямую связан узел из примера, а значит - единст-

венная сеть, в которую он может напрямую передавать данные. Шлюзы, ис-

пользуемые узлом для связи с остальным Интернетом, должны принадле-

жать к подсети этого узла.

Система Linux при выводе таблицы маршрутизации отображает данные по адрес-

ным маскам. Solaris 8 поддерживает адресные маски, просто не отображает их в

таблице маршрутизации.

Таблица маршрутизации

На рис. 2.4 уровень IP двух узлов и шлюза нашей воображаемой сети замене-

ны небольшими фрагментами таблицы маршрутизации, отражающими целе-

вые сети и шлюзы, через которые осуществляется доступ к ним. Предполо-

жим, что для сети 172.16.0.0 используется адресная маска 255.255.255.0.

Узел-источник (172.16.12.2), отправляя данные узлу-получателю (172.16.1.2),

при помощи адресной маски определяет, что в таблице маршрутизации необ-

ходимо искать адрес целевой сети 172.16.1.0. Таблица маршрутизации узла-

источника показывает, что данные, предназначенные сети 172.16.1.0, переда-

ются через шлюз 172.16.12.3. Узел-источник передает пакеты шлюзу. Шлюз

повторяет те же шаги и ищет целевой адрес в своей таблице маршрутизации.

Шлюз 172.16.12.3 выполняет прямую доставку через собственный интерфейс

172.16.1.5. Обратившись к таблицам маршрутизации на рис. 2.4, можно уви-

деть, что на каждом узле упоминаются только шлюзы, принадлежащие к се-

тям, доступным с этого узла напрямую. Данное обстоятельство иллюстрирует

тот факт, что шлюзом по умолчанию для адресов 172.16.12.2 и 172.16.12.3

является 172.16.12.1, но, поскольку узлу 172.16.1.2 недоступна напрямую

сеть 172.16.12.0, он определяет иной маршрут по умолчанию.

Таблица маршрутизации не содержит сквозных маршрутов. Маршрут ука-

зывает лишь следующий шлюз, то есть задает ровно один транзитный учас-

ток (hop) на пути к целевой сети.

Доставку данных узел возлагает на ло-

кальный шлюз, а шлюз в доставке данных полагается на другие шлюзы.

Дейтаграмма, переходя от одного шлюза к другому, рано или поздно дости-

гает узла, который напрямую подключен к целевой сети. Именно этот по-

следний шлюз доставляет данные узлу-получателю.

Для маршрутизации дейтаграмм между сетями протокол IP использует се-

тевую часть адреса. Полный адрес, включающий информацию об узле, всту-

пает в игру в момент окончательной доставки, когда дейтаграмма достигает

целевой сети.

Рис. 2.4. Табличная маршрутизация

Как мы увидим в главе 7, некоторые из протоколов маршрутизации, такие как

OSPF и BGP, способны получать информацию по сквозной маршрутизации. Тем

не менее пакет все так же передается следующему маршрутизатору в цепочке.

Глава 2. Доставка данных

Разрешение адресов

Адрес IP и таблица маршрутизации направляют дейтаграмму в конкретную

физическую сеть, но при прохождении через определенную сеть данные обя-

заны подчиняться протоколам физического уровня этой сети. Физическая

сеть, на которой строится сеть TCP/IP, не воспринимает IP-адресацию. Фи-

зическая сеть определенного типа обычно реализует собственный, непохо-

жий на другие, способ адресации. Одной из задач протокола доступа к сети

является отображение адресов IP в адреса физической сети.

В качестве показательного примера данной функции уровня доступа к сети

можно привести преобразование адресов IP в адреса Ethernet. За решение

этой задачи отвечает протокол разрешения адресов (Address Resolution Pro-

tocol, ARP), определенный документом RFC 826.

Программный модуль ARP ведет таблицу соответствий между IP-адресами и

адресами Ethernet. Таблица создается динамически. Когда ARP получает за-

прос на преобразование адреса IP, выполняется поиск адреса в таблице. Если

адрес найден, протокол возвращает адрес Ethernet программе, от которой

исходил запрос. В противном случае ARP выполняет широковещательную

передачу всем узлам Ethernet-сети. Пакет содержит адрес IP, для которого

требуется определить адрес Ethernet. Если один из узлов, получивших па-

кет, опознал адрес в качестве собственного, то в ответ посылает свой Ether-

net-адрес узлу, от которого исходил запрос. Ответ заносится в таблицу ARP.

Команда агр выводит содержимое таблицы ARP. Чтобы отобразить полную

таблицу ARP, воспользуйтесь командой агр -а. Доступ к отдельной записи

можно получить, указав имя узла в качестве аргумента командной строки

агр. Например, получить запись для узла rodent из ARP-таблицы узла crab

можно с помощью команды:

Полученная таблица содержит информацию о том, что узел crab, ретрансли-

руя дейтаграммы, адресованные узлу rodent, помещает их в Ethernet-фрей-

мы и посылает их на Ethernet-адрес 00:50:ba:3f: с2:5е.

Одна из записей приведенной таблицы (rodent) была добавлена динамически

в результате запросов, выполненных узлом crab. Две записи (crab и

Отображение всех записей таблицы посредством ключа -а приводит к полу-

чению следующего результата:

Протоколы, порты и сокеты

224.0.0.0) являются статическими, они были созданы в процессе настройки

узла crab. Это видно по флагу S (static) в поле Flags. Специальная запись

224.0.0.0 относится ко всем групповым адресам. Флаг М (mapping) означает

отображение и назначается только записям для групповых адресов. В ши-

роковещательной среде Ethernet для окончательной доставки данных по

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

Флаг Р записи для узла crab означает, что запись подлежит «опубликова-

нию» . Флаг «публикации» указывает, что при получении ARP-запроса по IP-

адресу узла crab данная система отвечает Ethernet-адресом 00:00:c0:dd:d4:da.

Такое поведение вполне логично, поскольку речь идет об ARP-таблице на уз-

ле crab. Однако возможна публикация и Ethernet-адресов других узлов, не

только локального. Обслуживание ARP-запросов, адресованных другим

компьютерам, называется представительством ARP.

Допустим, система 24seven является сервером для удаленной машины clock,

которая подключается по коммутируемой телефонной линии. Чтобы не на-

страивать маршрутизацию в пользу удаленной системы, администратор сер-

вера 24seven может создать в таблице ARP статическую, публикуемую запись

с IP-адресом машины clock и Ethernet-адресом машины 24seven. Тогда сервер

24seven, получая ARP-запрос для IP-адреса clock, отвечает собственным Et-

hernet-адресом. В результате другие машины сети посылают пакеты, предна-

значенные системе clock, узлу 24seven. 24seven передает пакеты системе clock

по телефонной линии. Представительство ARP создается в целях обслужи-

вания запросов к системам, которые не могут делать этого самостоятельно.

Таблицы ARP обычно не требуют внимания администратора, поскольку соз-

даются автоматически очень надежным протоколом ARP. Но если возника-

ют осложнения, таблицы ARP могут редактироваться вручную. Более под-

робная информация по теме содержится в разделе «Диагностирование при

помощи команды агр» главы 13.

Протоколы, порты и сокеты

Когда маршрутизация по сети завершена, данные попадают на конечный

узел, и их следует передать соответствующему пользователю или процессу.

По мере продвижения данных вверх или вниз по уровням TCP/IP возникает

необходимость передавать их нужному протоколу на каждом из уровней.

Система должна обладать способностью передавать данные многих прило-

жений - посредством не столь многочисленных транспортных протоколов -

протоколу Internet. Объединение многих источников данных в один поток

называется мультиплексированием.

Данные, поступающие из сети, необходимо демультиплексировать: разде-

лить в целях доставки различным процессам. Для решения этой задачи в IP

транспортные протоколы определяются номерами протоколов, а приложе-

ния определяются номерами портов в транспортных протоколах.

Отдельные протоколы и номера портов зарезервированы за широко извест-

ными службами (well-known services). Широко известные службы - это

Глава 2. Доставка данных

стандартные сетевые протоколы (например, FTP и Telnet), имеющие широ-

кое распространение в сети. Номера протоколов и номера портов назначают-

ся широко известным службам организацией IANA (Internet Assigned Num-

bers Authority). Официально зарегистрированные номера задокументирова-

ны на сайте http://www.iana.org. Unix-системы хранят определения номеров

протоколов и портов в паре текстовых файлов.

Номера протоколов

Номер протокола хранится в одном из байтов третьего слова заголовка

дейтаграммы. Значение определяет протокол уровня над IP, которому сле-

дует передавать данные.

Номера протоколов для Unix-систем определяются в файле /etc/protocols.

Файл имеет простую табличную структуру и содержит пары, состоящие из

имен протоколов и связанных с ними номеров. Каждая строка таблицы со-

держит одну запись: формальное имя протокола, отделенное от номера про-

токола пробельными символами. Номер протокола отделен пробельными

символами от «псевдонима» протокола. Комментарии в таблице начинают-

ся с символа #. Пример файла /etc/protocols приводится ниже:

Протоколы, порты и сокеты

Приведенная распечатка представляет содержимое файла /etc/protocols ра-

бочей станции под управлением Solaris 8. Данный перечень номеров никоим

образом не претендует на полноту. Если заглянуть в раздел Protocol Num-

bers веб-сайта организации IANA, можно обнаружить гораздо больше номе-

ров протоколов. Однако система может включать лишь те номера протоко-

лов, которые используются в работе. Даже приведенный пример содержит

больше номеров, чем на практике потребуется данной конкретной рабочей

станции; так, вторая половина таблицы может использоваться только в сис-

темах, работающих по протоколу IPv6. Разумеется, если ваша система не

работает с IPv6 или какими-либо вообще протоколами из перечисленных,

поводов для опасений нет - лишние записи не причинят вреда.

Каков же смысл этой таблицы? Когда поступает дейтаграмма, адрес получа-

теля которой совпадает с локальным IP-адресом, уровень IP обязан передать

дейтаграмму одному из транспортных протоколов, расположенных уровнем

выше. Решение о том, какому протоколу передать дейтаграмму, IP прини-

мает на основе номера протокола, содержащегося в дейтаграмме. Из табли-

цы можно видеть, что если номер протокола для дейтаграммы равен 6, про-

токол Internet доставляет дейтаграмму протоколу TCP; если номер протоко-

ла равен 17, IP доставляет дейтаграмму протоколу UDP. TCP и UDP - это те

две службы транспортного уровня, которые нас интересуют, но все протоко-

лы, перечисленные в первой половине таблицы, напрямую используют

службу доставки дейтаграмм протокола IP. Некоторые из таких протоколов -

ICMP, EGP и GGP - упоминались ранее. О других речь не шла, но, по правде

говоря, второстепенные протоколы не имеют значения для настройки и со-

провождения сети TCP/IP.

Номера портов

Итак, протокол IP передал поступившие данные транспортному протоколу.

Транспортный протокол, в свою очередь, передает данные соответствующе-

му прикладному процессу. Прикладные процессы (известные также в ка-

честве сетевых служб) определяются 16-битными номерами портов. Номер

порта источника (определяет процесс, отправивший данные) и номер порта

получателя (определяет процесс, которому данные предназначены) содер-

жатся в первом слове заголовка каждого сегмента TCP и пакета UDP.

Номера портов до 1024 зарезервированы под широко известные службы (та-

кие как FTP и Telnet) и назначаются организацией IANA. Широко извест-

ные номера портов считаются «привилегированными» и не должны ассоци-

ироваться с пользовательскими процессами. Порты с номерами с 1024 по

49151- «зарегистрированные». IANA по мере возможности ведет реестр

служб, использующих порты указанного интервала, но данный список не

имеет руководящей силы. Номера портов с 49152 по 65 535 считаются «част-

ными». Частные номера портов могут использоваться в любых целях.

Номера портов не уникальны для всего диапазона протоколов транспортно-

го уровня, хотя уникальны для каждого протокола в отдельности. Иными

словами, протоколы TCP и UDP могут использовать - и используют - одина-

Глава 2. Доставка данных

ковые номера портов. Именно сочетание номеров порта и протокола точно

определяет конкретный процесс, которому предназначены данные.

Номера портов для Unix-систем определяются в файле / etc / services. Сетевых

приложений существует гораздо больше, чем протоколов транспортного уров-

ня, как можно видеть из размеров таблицы /etc/services. Ниже приводится

фрагмент файла /etc/services рабочей станции под управлением Solaris 8:

Формат данного файла схож с форматом файла /etc/protocols. Каждая одно-

строчная запись начинается с формального имени службы, отделяемого про-

бельными символами от пары номер порта/протокол. Номера портов до-

полняются именами транспортных протоколов потому, что с одинаковыми

номерами портов могут работать различные транспортные протоколы. Не-

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

сутствовать после пары номер/протокол.

Пара файлов /etc/protocols и /etc/services предоставляет всю информацию,

необходимую для доставки данных соответствующему приложению. Дейта-

грамма передается получателю на основе адреса, указанного в пятом слове

заголовка дейтаграммы. Используя номер протокола из третьего слова заго-

ловка дейтаграммы, протокол IP выполняет доставку данных надлежащему

протоколу транспортного уровня. Первое слово данных, полученных транс-

портным протоколом, содержит номер порта получателя, который позволя-

ет передать данные уровнем выше, конкретному приложению. Процесс до-

ставки отражен на рис. 2.5.

Несмотря на внушительные размеры, файл /etc/services содержит номера

портов далеко не всех важных сетевых служб. Так, в нем отсутствуют номе-

Протоколы, порты и сокеты

Рис. 2.5. Номера протоколов и портов

ра портов для служб RPC (Remote Procedure Call, удаленный вызов проце-

дур), перечисленных в файле services. Компания Sun разработала свой метод

резервирования портов для служб RPC, не связанный с получением широко

известного номера от IANA. Службы RPC обычно используют зарегистриро-

ванные номера портов, не требующие официальных процедур для присвое-

ния. Когда запускается служба RPC, она регистрирует свой номер порта при

помощи программы portmapper. portmapper отслеживает номера портов, заня-

тых службами RPC. Когда клиент обращается к службе RPC, он посылает

запрос демону portmapper, работающему на сервере, с целью получения номе-

ра порта, назначенного службе. Клиент может легко обнаружить службу

portmapper, поскольку ей назначен широко известный порт с номером 111.

portmapper делает возможной установку широко применяемых служб без не-

обходимости получать широко известный номер официальным путем.

Сокеты

Широко известные порты - это стандартизированные номера, дающие воз-

можность удаленным системам обращаться к сетевым службам через зара-

нее известные порты. Такая возможность упрощает процесс подключения,

поскольку и адресат и отправитель заранее знают, что данные, адресован-

ные конкретному процессу, пройдут через определенный порт. Так, все сис-

темы, предоставляющие доступ по протоколу Telnet, используют для этой

цели порт 23.

Не менее важен и второй тип номера порта, известный в качестве динамичес-

ки выделяемого порта. Как следует из названия, динамически выделяемые

Глава 2. Доставка данных

порты не назначаются заранее: они назначаются процессам по мере необхо-

димости. Механизм гарантирует, что двум различным процессам не будут

назначены одинаковые номера портов и что выделяемые порты лежат вне

диапазона широко известных номеров, то есть имеют номера, большие 1024.

Динамически выделяемые порты обеспечивают гибкость, необходимую для

реализации многопользовательских систем. Если пользователю telnet назна-

чается порт с номером 23 как для источника, так и для получателя, какие но-

мера портов следует назначить второму пользователю, работающему с telnet

в то же время? В целях однозначного определения каждого соединения в ка-

честве номера исходного порта используется динамически выделенный но-

мер, а в качестве номера целевого порта - широко известный номер службы.

В примере с программой telnet первому пользователю назначается случай-

ный номер исходного порта и номер целевого порта 23 (telnet). Второму

пользователю назначается другой случайный номер исходного порта и тот

же номер для целевого порта. Именно пара номеров портов, исходного и це-

левого, однозначно определяет каждое сетевое соединение. Узлу-получате-

лю известен номер исходного порта, поскольку информация о нем включает-

ся как в заголовки сегментов TCP, так и в заголовки пакетов UDP. Оба узла

знают номер целевого порта, поскольку он является широко известным.

Обмен номерами портов при установлении связи TCP показан на рис. 2.6.

Узел-источник случайным образом выбирает исходный порт, в данном при-

мере - 3044, и посылает сегмент с указанием исходного порта 3044 и целево-

го порта 23. Узел-получатель принимает сегмент и отвечает номером исход-

ного порта 23 и номером целевого порта 3044.

Сочетание IP-адреса и номера порта называется сокетом (socket). Сокет од-

нозначно определяет любой сетевой процесс сети Интернет. Иногда термины

«сокет» и «номер порта» используются в качестве взаимозаменяемых. Более

того, широко известные службы часто называют «широко известными соке-

тами». В контексте нашего разговора «сокет» - это сочетание адреса IP и но-

мера порта. Пара сокетов - сокет узла-получателя и сокет узла-источника -

определяет соединение для протоколов, ориентированных на работу с соеди-

нениями, таких как TCP.

Рис. 2.6. Обмен номерами портов

Резюме

Разовьем пример динамически назначаемых портов и широко известных

портов. Предположим, что пользователь узла 172.16.12.2 использует Telnet

для подключения к узлу 192.168.16.2. Узел 172.16.12.2 является источни-

ком. Пользователю динамически назначается уникальный номер порта

3382. Выполняется подключение к службе telnet удаленного узла, которому,

в соответствии со стандартом, назначен широко известный порт 23. Сокетом

источника соединения будет 172.16.12.2.3382 (IP-адрес 172.16.12.2 плюс

номер порта 3382). Сокетом другого конца соединения - 192.168.16.2.23

(адрес 192.168.16.2, порт 23). Порт целевого сокета известен обеим систе-

мам, поскольку является широко известным. Порт исходного сокета извес-

тен обеим системам, поскольку узел-источник сообщил второй стороне сокет

источника, запрашивая соединение. Таким образом, пара сокетов известна

и той, и другой машине. Сочетание двух сокетов однозначным образом опре-

деляет установленное соединение; никакое другое соединение в сети Интер-

нет не будет иметь совпадающей пары сокетов.

Резюме

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

Интернет - от конкретного процесса на исходном компьютере к взаимо-

действующему процессу на другом конце света. В TCP/IP для идентифика-

ции компьютеров сети применяется общая система уникальных адресов.

Номера протоколов и номера портов позволяют однозначно определять

пользовательские процессы, работающие на компьютерах сети.

Маршрутизация направляет дейтаграммы, предназначенные удаленному

процессу, по лабиринтам глобальной сети. При этом часть адреса IP исполь-

зуется для определения целевой сети. В каждой системе существует таблица

маршрутизации, определяющая пути отправки данных в удаленные сети.

Обычно таблица маршрутизации содержит маршрут по умолчанию, исполь-

зуемый в случаях, когда отсутствует маршрут в конкретную удаленную

сеть. Маршрут лишь указывает на следующий компьютер в пути к получа-

телю данных. В TCP/IP применяется система транзитной маршрутизации,

позволяющая шаг за шагом перемещать дейтаграммы ближе к адресату, по-

ка они не достигнут целевой сети.

Внутри целевой сети окончательная доставка осуществляется на основе пол-

ного IP-адреса (включающего номер узла), посредством преобразования это-

го адреса в адрес физического уровня. В качестве примера протокола, осу-

ществляющего преобразование IP-адресов, можно привести протокол разре-

шения адресов (Address Resolution Protocol, ARP). Протокол ARP преобра-

зует адреса IP в адреса Ethernet для окончательной доставки.

Первые две главы были посвящены структуре стека протоколов TCP/IP и

механизму передачи данных по сети. В следующей главе мы поднимемся по

стеку протоколов, чтобы изучить сетевые службы, упрощающие настройку

и работу в сети.