Главная
страница 1

Лабораторная работа № 6

Принципы построения сетей TCP/IP v4



Copyright (c) 2008,2009 Nikolay A. Fetisov

Permission is granted to copy, distribute and/or modify this document

under the terms of the GNU Free Documentation License, Version 1.2

or any later version published by the Free Software Foundation;

with no Invariant Sections, no Front-Cover Texts, and no Back-Cover

Texts. A copy of the license is available as

http://www.gnu.org/licenses/fdl.html

Copyright (c) Николай Фетисов, 2008,2009,2010.

Настоящее пособие включает в себя документы, распространяющиеся на условиях GNU Free Documentation License, версия 1.1.

Каждый имеет право воспроизводить, распространять и/или вносить изменения в настоящий Документ в соответствии с условиями GNU Free Documentation License, Версией 1.2 или любой более поздней версией, опубликованной Free Software Foundation;

Данный Документ не содержит Неизменяемых разделов; Данный Документ не содержит текста, помещаемого на первой или последней страницах обложки.

Текст лицензии GNU FDL доступен по адресу: http://www.gnu.org/licenses/fdl.html

Теоретические сведения.

Введение


Одной из основных задач, решаемых вычислительными системами, является передача данных от одной системы к другой. Для обеспечения возможности такого объединения систем в компьютерные сети разработаны и широко применяются различные сетевые технологии. Реализация взаимодействий между компьютерными системами базируется на сетевых протоколах — наборах правил, позволяющих осуществлять соединение и обмен данными между двумя и более включёнными в сеть компьютерами. Разные протоколы зачастую описывают лишь разные стороны одного типа связи; взятые вместе, они образуют стек протоколов. Названия «протокол» и «стек протоколов» также указывают на программное обеспечение, которым реализуется протокол. Практически все существующие сейчас в мире компьютерные сети объединены или как минимум имеют шлюзы в глобальную компьютерную сеть Internet. Понимание основ Internet и лежащего в его основе протокола TCP/IP является в настоящее время необходимым для технического специалиста.

История развития Internet


В 1969 году в Министерстве обороны США (Department of Defense ) было решено построить сеть для передачи информации, которая сохраняла бы работоспособность в случае выхода из строя (уничтожения в ядерной войне) значительной части своих узлов. Разработка такой сети была поручена Агентству по перспективным исследовательским программам (DARPA, Defence Advanced Research Projects Agency). Непосредственные работы по созданию сети была поручена Калифорнийскому университету в Лос-Анджелесе, Стэнфордскому исследовательскому центру, Университету штата Юта и Университету штата Калифорния в Санта-Барбаре. Компьютерная сеть была названа ARPANET и в рамках проекта сеть объединила четыре вышеназванных научных учреждения. Первый сервер ARPANET был запущен 1 сентября 1969 года в Калифорнийском Университете.

В 1971 году для ARPANET была разработана первая программа для отправки электронной почты по сети, в 1973 году сеть стала международной — через трансатлантический телефонный кабель к ней были подключены организации из Великобритании и Норвегии. В 1970-х годах сеть в основном использовалась для обмена сообщениями электронной почты, включая первые появившиеся списки почтовой рассылки, новостные группы и доски объявлений.

Для работы ARPANET использовался сетевой протокол NCP. Параллельно с развитием сети велись работы по развитию и усовершенствованию этого протокола. В 1973 году Кан и Церф (Kahn, Cerf) начали работу над созданием протокола TCP/IP (Transmission Control Protocol/Internet Protocol), предназначенного для объединения разнородных компьютерных сетей, работающих на разных сетевых протоколах и технологиях, в единое целое. В виде стандартов протокол был оформлен в 1973-1974 гг, также при содействии DARPA, и в 1975 году была запущена первая тестовая сеть TCP/IP. В марте 1982 года Министерство обороны США (Department of Defense) приняло TCP/IP как стандартный протокол в своих сетях.

1 января 1983 года сеть ARPANET перешла с протокола NCP на TCP/IP и стала называться Internet.

В 1984 году была запущена система доменных имён DNS (Domain Name Service, DNS).

В 1984 году Национальный научный фонд США (NSF) основал обширную межуниверситетскую сеть NSFNet (National Science Foundation Network), которая была составлена из более мелких сетей, и к которой за год подключились около 10 тыс. компьютеров. ARPANET вошла в NSFNET в качестве национальной магистрали. С 1985 года началось подключения к NSFNET коммерческих организаций и частных сетей. К 1994 году процесс перевода Internet в коммерческое русло был завершён, в апреле 1994 году NFSNET была отключена. С тех пор глобальная сеть — это совокупность частных сетей, принадлежащих провайдерам Internet.


Стандартизация сетевых протоколов


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

ISOC (http://isoc.org, Internet Society, общество Интернета) - международная некоммерческая образовательная организация, занимающаяся развитием и обеспечением доступности сети Интернет. Создана в 1992 году и насчитывает более 20 тысяч индивидуальных членов и более 100 организаций-членов в 180 странах мира. ISOC предоставляет организационную основу для множества других консультативных и исследовательских групп, занимающихся развитием Интернета, включая IETF и IAB.

IETF (http://ietf.org, Internet Engineering Task Force, проблемная группа проектирования Интернет) - открытое международное сообщество проектировщиков, учёных, сетевых операторов и провайдеров, созданное в 1986 году и занимающееся развитием протоколов и архитектуры Интернета. Вся техническая работа осуществляется в рабочих группах IETF и открыта для для публичного участия и обсуждения.

IAB (Internet Architecture Board) — группа технических советников ISOC, которая осуществляет надзорные функции за архитектурой Internet'а и созданием новых стандартов, а также консультации руководства ISOC по техническим, архитектурным и процедурным вопросам.

ICANN (Internet Corporation for Assigned Names and Numbers) — организация, занимающаяся вопросами распределения адресов IP и ведением перечней номеров портов стандартных протоколов. Непосредственно выделением адресов и номеров портов занимается IANA (Internet Assigned Numbers Authority).

Результаты работы комитетов IETF получают своё отражение в серии документов, известных как RFC (http://www.rfc-editor.org, Requests For Comments, запросы на комментарии). В виде RFC оформляются стандарты протоколов, предлагаемые технические изменения, информационные бюллетени, технические спецификации и точные определения по многим вопросам. Часть документов RFC возводятся IAB в статус Стандартов Интернет (англ. Internet Standard).

Документы RFC имеют порядковые номера. На апрель 2010 года принято порядка 5800 RFC. После принятия RFC никогда не меняются, хотя могут быть дополнены или признаны устаревшими в последующих RFC. Обновлённые документы должны содержать в себе всю актуальную информацию их предшественников. Ссылаться на документы RFC принято по их порядковому номеру, хотя каждый из них имеет и название.

Не все RFC содержат чисто техническую информацию, например, RFC5241 от 1 апреля 2008 года «Naming Rights in IETF Protocols» описывает порядок использования коммерческих брендов в качестве имен для описания понятий в сетевых протоколах, с целью получения дополнительного источника дохода для IETF, RFC5841 от 1 апреля 2010 года «TCP Option to Denote Pacjet Mood» вводит в заголовок пакетов TCP поле для отражения настроения пакета, а RFC5540 от 7 апреля 2009 года «40 Years of RFCs» - заметка, отмечающая 40-летие RFC.


Сетевая модель OSI ISO


Существует общая модель сетевых протоколов — так называемая модель OSI (Open System Interconnection, взаимодейстия открытых систем) ISO (International Organization for Standartization). Эта модель, разработанная в начале 80х годов прошлого века, описывает эталонную структуру взаимодействий компьютерных систем, которой желательно придерживаться при проектировании сетевых протоколов. В модели OSI проблема связи между компьютерами разделяется на семь уровней. Каждый уровень обслуживает свою часть процесса взаимодействия и реализует свои протоколы. Особенности реализации этих протоколов абстрагируются от вышестоящего уровня, которому предоставляются только определённые программные интерфейсы. Для передачи данных на каждом из уровней вызывается программные интерфейсы нижестоящего уровня. Уровни взаимодействуют только со своими соседями (т.е., например, уровень 5 может вызвать интерфейсы только уровня 4 и быть вызванным с уровня 6). Благодаря такой структуре можно считать, что взаимодействие систем друг с другом на каждом из уровней идёт только по реализованным на этом уровне протоколам, без учёта специфики более низких уровней, что позволяет упростить совместную работу сетевого оборудования программного обеспечения. Например, при обращении браузером к веб-серверу (на 7ом уровне модели OSI) неважно, какие аппаратные средства задействуются для передачи данных между этими программами.

В модели OSI ISO выделяются следующие 7 уровней:



  • 7ой - прикладной уровень (Application layer)

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

  • 6ой - уровень представления (Presentation layer)

Отвечает за преобразование протоколов и кодирование/декодирование данных. На этом уровне может осуществляться сжатие и распаковка данных, их кодирование и декодирование.

  • 5ый - сеансовый уровень (Session layer)

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

  • 4ый - транспортный уровень (Transport layer)

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

  • 3ий - сетевой уровень (Network layer)

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

  • 2ой - канальный уровень (Data Link layer)

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

  • 1ый - физический уровень (Physical layer)

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

Отметим, модель OSI ISO — модель эталонная, и реальные системы, в т.ч. протоколы TCP/IP, ей не вполне соответствуют.

Существует также упрощённый вариант модели OSI - модель DOD, по названию использующей её организации (Department of Defense — Министерство обороны США), в которой присутствуют 4 уровня — приложений (соответствующий 7, 6 и 5-му уровням OSI), транспортный (4-ый уровень), межсетевой (3ий уровень OSI) и сетевого интерфейса (2ой и 1ый уровень OSI).

Семейство протоколов TCP/IP


Как уже говорилось, для объединения компьютеров в рамках глобальной сети Internet используется семейство протоколов TCP/IP. За время существования протоколов разработано несколько их версий, из которых на данный момент широко используются TCP/IP v4 с 32-битной адресацией хостов (компьютеров - узлов сети), на смену которой идет TCP/IP v6 с 128-битной адресацией хостов. Версии v1-v3 предшествовали v4 и сейчас не используются, v5 описан в RFC1819 и официально называется ST2/ST2+.

На смену IPv4 IETF в начале 90-х готовила сразу несколько вариантов протоколов, четыре из которых были оформлены как v6,v7,v8 и v9. Из них выбран для дальнейшего развития был выбран v6, из остальных v7 был отвергнут из-за неполной спецификации, IPv9, технически самый лучший — по политическим причинам (он был основан на стандартах ISO, а не IETF), а v8 — проиграл из-за использования 64-битного адреса по сравнению со 128 битами IPv6.

Поскольку семейство протоколов TCP/IP было разработано до появления модели OSI ISO, то строго в рекомендации оно не укладывается и обычно представляется следующим образом:

В рамках семейства протоколов TCP/IP не определяются физический и канальный уровни. Протокол IP, разработанный специально для объединения разнородных сетей, способен работать поверх подавляющего большинства существующих протоколов этих уровней (и даже поверх самого себя).

Физический уровень описывает среду передачи данных и лежит ниже протоколов TCP/IP. Обычно в качестве среды передачи данных используют медный кабель, оптоволокно, радио — или ИК-излучение. Протоколы физического уровня описывают физические характеристики такой среды и принцип передачи данных (разделение каналов, модуляцию, амплитуду сигналов, частоту сигналов, способ синхронизации передачи, время ожидания ответа и максимальное расстояние).

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

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

Примеры протоколов канального уровня — Ethernet, IEEE 802.11 Wireless Ethernet, SLIP, Token Ring, ATM, PPP.

На сетевом уровне, предназначенном для передачи данных из одной сети в другую, используется протокол IP. Для идентификации каждого подсоединённого к Internet устройства (хоста), ему назначается уникальный адрес — в рамках IPv4 32-битное число. Хосты группируются в отдельные сети на базе их IP-адресов, и соответствующие протоколы машрутизации обеспечивают поиск маршрута для передачи пакетов от хоста одной сети к хосту другой — через некоторое число промежуточных сетей.

С развитием концепции глобальной сети в уровень были внесены дополнительные возможности по передаче из любой сети в любую сеть, независимо от протоколов нижнего уровня, а также возможность запрашивать данные от удалённой стороны, например в протоколе ICMP (который используется для передачи диагностической информации IP-соединения) и IGMP.

Вообще говоря, ICMP и IGMP расположены над IP и должны попасть на следующий — транспортный — уровень, но функционально являются протоколами сетевого уровня, и их невозможно вписать в модель OSI.

Пакеты сетевого протокола IP могут содержать код, указывающий, какой именно протокол следующего уровня нужно использовать, чтобы извлечь данные из пакета. Это число — уникальный IP-номер протокола. ICMP и IGMP имеют номера, соответственно, 1 и 2.

Протоколы транспортного уровня могут решать проблему негарантированной доставки сообщений, а также гарантировать правильную последовательность прихода данных. В стеке TCP/IP транспортные протоколы определяют для какого именно приложения предназначены эти данные.

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

UDP - протокол передачи датаграмм без установления соединения. Он является протоколом «ненадёжной» передачи, в смысле невозможности удостовериться в доставке сообщения адресату, а также возможного перемешивания пакетов.

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

И TCP, и UDP используют для определения протокола верхнего уровня число, называемое портом. Под номер порта в пакетах TCP и UDP отводится 2 байта, т.е. максимальное количество использующих стек TCP/IP приложений в системе — 65535. Реально операционными системами накладываются дополнительные ограничения.

Существует список стандартных портов TCP и UDP, зарезервированных под использование теми или иными приложениями. Например, на порту 80/tcp по стандарту может располагаться только веб-сервер, а на порту 53/udp — DNS-сервер. Для предотвращения несанкционированного использования зарезервированных портов приложениям непривилегированного пользователя запрещается использовать порты с значениями <1000.

Список стандартных портов TCP и UDP ведёт IANA.

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

Эти программы имеют свои собственные протоколы обмена информацией, например, HTTP для WWW, FTP (передача файлов), SMTP (электронная почта), SSH (безопасное соединение с удалённой машиной), DNS (преобразование символьных имён в IP-адреса) и многие другие.

В массе своей эти протоколы работают поверх TCP или UDP, и привязаны к определённому порту, например HTTP — к 80му.

Адресация в сетях IP


Протокол IP работает на 3ем уровне модели OSI ISO и передаёт данные через сетевые интерфейсы 2го уровня. В простейшем случае у компьютера имеется один сетевой интерфейс, который входит в одну сеть IP. В более сложных случаях в одном компьютере может быть несколько сетевых интерфейсов и он может входить одновременно в несколько сетей IP. Кроме того, любой сетевой интерфейс также может входить в несколько сетей IP.

Помимо физических интерфейсов у компьютера в сетях TCP/IP есть логический интерфейс обратной петли (loopback). Посланные на этот интерфейс пакеты сразу возвращаются с него же обратно. Наличие loopback-интерфейса позволяет использовать обмен данными между приложениями по протоколам TCP/IP в пределах одного компьютера, даже не имеющего физических интерфейсов для подключения к сети.

Каждому сетевому интерфейсу назначается один или несколько адресов IP — чисел длиной в 32 бита, или 4 байта. Согласно принятым соглашением эти адреса записываются в виде четырёх десятичных чисел по-байтно, причём отдельные числа разделяются точками, например, 193.233.70.1 . Каждая часть адреса IP может иметь значение от 0 до 255.

Адрес IP содержит адрес сети и адрес хоста в пределах сети. Для выделения адреса сети из адреса IP применяется битовая маска,

ip AND mask = lan; ip AND NOT mask = host

Здесь ip — адрес IP (число), mask — маска, lan — адрес сети, host — адрес хоста в сети, AND и NOT — логические операции.

Например, маска для IP 193.233.70.1 — 255.255.255.0. Адрес сети — 193.233.70.0, адрес хоста в этой сети — 0.0.0.1:

Адрес:

11000001

11000001

11101001

00000001




(193.233.70.1)

Маска:

11111111

11111111

11111111

00000000




(255.255.255.0)

Сеть:

11000001

11000001

11101001

00000000




(193.233.70.0)

Хост:

00000000

00000000

00000000

00000001




(0.0.0.1)

Сети в IP делятся на классы. Каждому классу соответствует своя маска. Класс сети конкретного адреса IP однозначно определяется по его первым нескольким битам.

Сети класса A:

Адреса с первым битом, равным 0

Маска 255.0.0.0

Допустимые адреса: 1.0.0.0 — 126.255.255.255

Две подсети имеет специальное значение: 0.0.0.0 - адрес текущей сети (служебное значение), 127.0.0.0 - сеть loopback-интерфейса. Адрес loopback-интерфейса, соответственно, обычно равен 127.0.0.1.

Класс B:

Адреса с первыми двумя битами, равными 10

Маска 255.255.0.0

Допустимые адреса: 128.0.0.0 — 191.255.255.255

Класс C:

Адреса с первыми тремя битами, равными 110

Маска 255.255.255.0

Допустимые адреса: 192.0.0.0 — 223.255.255.255

Класс D:

Адреса с первыми четырьмя битами, равными 1110

Сети 224.0.0.0-239.255.255.255 — широковещательные.

Класс E:


Сети с адресами 240.0.0.0-254.255.255.255 — зарезервированы.

Выделением адресов конкретным сетям, входящим в Internet, занимается ICANN (Internet Corporation for Assigned Names and Numbers). Адреса выделяются только в количестве, кратном соответствующему классу сетей. Обычно адреса выделяются сравнительно большими блоками провайдерам услуг Internet, которые, в свою очередь, перераспределяют их среди своих клиентов.

Как правило, организация не может получить необходимое количество IP-адресов для назначения их на каждый из своих компьютеров (мало того, на данный момент это или невозможно, или просто не имеет смысла). В этом случае можно самостоятельно, без получения разрешений от ICANN или провайдера, использовать адреса из диапазона, зарезервированного для частных сетей. К таким диапазонам согласно RFC1918 относятся:


  • одна сеть класса A: 10.0.0.0

  • 16 сетей класса B: 172.16.0.0 - 172.31.0.0

  • 256 сетей класса C: 192.168.0.0 - 192.168.255.0

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

В целом, адрес IP с учётом сетевой маски записывает в виде IP/MASK, например, 192.168.0.100/255.255.255.0, или 172.31.58.20/255.255.0.0. Учитывая, что в двоичной записи маски чередоваться нули и единицы не могут, и в ней всегда сначала идёт некоторое количество единичных разрядов, и следом — оставшиеся нулевые, можно использовать более короткую форму записи, вместо маски указывая число единиц в ней:

192.168.0.100/24, 172.31.58.20/16, 127.0.0.1/8

Даже самая маленькая сеть — класса C, содержит в себе 254 адреса. Как правило, на организацию такую сеть провайдер целиком не выделяет, предпочитая выделить из ней несколько подсетей. В этом случае маска не кончается на границе байта, и может адрес может иметь вид, например, 192.168.0.100/26.

В зависимости от адреса существуют несколько видов адресации в протоколе IP. К ним относится:


  • направленная адресация, когда адрес получателя — это адрес определённой машины в сети;

  • групповая адресация, когда адрес получателя выбирается из диапазона адресов класса D. Групповая адресация используется в специализированных приложениях типа видеоконференций;

  • широковещательная адресация, когда пакет предназначается для всех компьютеров в сети.

В последнем случае используется т.н. широковещательный адрес сети — адрес IP, в котором все биты поля адреса хоста равны 1.

Таким образом, для IP 192.168.230.50/28:

IP хоста — это 192.168.230.50, маска — 255.255.255.240 (28 бит).

Адресом сети является 192.168.230.48, а широковещательным адресом — 192.168.230.63. Всего в этой подсети доступно 14 адресов.

Минимальная по размерам IP-сеть - /30. Такие сети содержит всего по 2 адреса.

Маршрутизация в сетях TCP/IP


Internet представляет собой множество соединённых друг с другом сетей. В точках соединения сетей размещаются маршрутизаторы — сетевые устройства, имеющие два и более интерфейсов, входящих в разные сети. Через маршрутизаторы возможно передать пакет IP из одной сети в другую. Путь пакета от хоста-отправителя до хоста-получателя называется маршрутом.

Получив пакет (или пришедший из внешней сети со второго уровня модели OSI, или сформированный транспортным уровнем локального компьютера), протоколы сетевого уровня должны определить, в какую из возможных сетей данный пакет нужно отправить.

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

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

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

Рассмотрим для примера следующую сеть:



В данном случае имеется подсеть 192.168.230.96/29, в которой находится 4 хоста. Три из них имеют соединения с другими сетями: 192.168.230.98 — c сетью 192.168.230.0/24, 192.168.230.99 — с сетью 192.168.228.0/22, и 192.168.230.97 — с Internet.

На четвёртом, 192.168.230.100, таблица маршрутизации должна выглядеть следующим образом:

# ip route show

192.168.230.96/29 dev eth0 proto kernel scope link src 192.168.230.100

192.168.230.0/24 via 192.168.230.98 dev eth0

192.168.228.0/22 via 192.168.230.99 dev eth0

default via 192.168.230.97 dev eth0

Во-первых, пакеты для сети 192.168.230.96/29 данный хост должен отправлять просто на интерфейс eth0 — т.к. он входит в эту сеть. Этот маршрут устанавливается автоматически при назначении интерфейсу адреса IP.

Далее, пакеты для сети 192.168.230.0/24 должны отсылаться через шлюз 192.168.230.98 (вторая запись в таблице, «via» - «через», и также с интерфейса eth0).

С сетью 192.168.228.0/22 граничит шлюз 192.168.230.99 — третья запись в таблице. Ну и все остальные пакеты должны отсылаться в Internet — на шлюз 192.168.230.97. 'default' соответствует сети 0.0.0.0/0.0.0.0, т.е. всем возможным адресам.

При этом, перебор адреса идёт последовательно, от меньшей подсети к большей. Поэтому пакет для хоста, например, 192.168.230.150 будет отослан через шлюз 192.168.230.98 — этот адрес не входит в самую маленькую подсеть, 192.168.230.96/29, и входит в 192.168.230.0/24. Отметим, что этот хост входит и в подсеть 192.168.228.0/22, но она крупнее 192.168.230.0/24 — и выбрана не будет.


Система доменных имён DNS


Каждому хосту в Internet соответствует свой адрес. Для обращения одного хоста к другому — т.е., например, для запроса браузером на одной машине документа с веб-сервера на другой, необходимо знать адрес сервера. Однако использовать числовое значение адреса IP удобно только компьютерам — в отличии от пользователей. Поэтому существует возможность сопоставления адресу IP символьного имени, которое может иметь осмысленный для человека вид. Такое сопоставление можно организовать несколькими методами.

Самый простой из них — просто записать необходимые пары адрес-имя в файле конфигурации. В Unix-системах таким файлом является /etc/hosts, формат записи:

IP name [ name] [...]

Например,

$ cat /etc/hosts

127.0.0.1 localhost.localdomain localhost

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

Такой системой стала разработанная в 1983 году Полом Мокапетрисом система DNS (Domain Name Service, служба доменных имён, RFC1034 и RFC1035), которая позволила гибко и децентрализованно задавать имена хостов, делегирую полномочия изменять имена компьютеров в конкретных информационных системах администраторам этих систем.

Имена DNS структурированы и состоят из отдельных частей - доменов, разделённых точками. Домены имеют уровни, отсчитывающиеся с конца имени, и образуют дерево имён. Логический узел в дереве имён носит название «зона». В зонах хранятся записи об соответствии имён входящих в зону хостов их IP-адресам, а также ссылки на сервера DNS, обслуживающих зоны доменов более высокого уровня.

Домен нулевого уровня (корневой домен) содержит адреса серверов DNS доменов первого уровня, его зона хранится на корневых серверах DNS. Таких серверов на данный момент 13, их адреса известны и не меняются со временем.

Домены первого уровня — зоны ответственности отдельных государств («us», «ru», «ua», «uk», «tv» и т. п.) или независимые зоны ответственности («com», «org», «net», «edu» и т. п.). Для каждого доменов первого уровня существует организация, выдающая всем желающим абонентам имена, заканчивающиеся на «.домен». Эта организация также обязана организовать и поддерживать сервера DNS для своего домена первого уровня.

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

Получающаяся иерархическая система имен позволяет, пройдя по цепочке начиная от корневых серверов, узнать адрес сервера DNS для конкретного имени и узнать соответствующий адрес IP.

Клиенты системы DNS (приложения, работающие на компьютере) непосредственно к всей цепочке серверов DNS не обращаются. Вместо этого в настройках хоста указывается один или несколько серверов DNS, к которым он должен обращаться с запросами. Для Unix-систем список серверов DNS хранится в файле /etc/resolv.conf, который имеет вид

$ cat /etc/resolv.conf

search ddns.ossg.ru

nameserver 192.168.250.1

В одной или нескольких строках nameserver указываются адреса серверов DNS для данной системы, а в параметре search — список доменов по-умолчению. Перед тем, как обратится к серверам DNS, сначала проверяется файл /etc/hosts. Если нужного имени там не оказывается, выполняется запрос к одному из серверов DNS. Если этом сервер не отвечает, производится запрос к следующему серверу. Если получить IP для имени не удаётся, возвращается ошибка.

Рассмотрим работу системы DNS на примере. Для работы с серверами DNS, в т.ч. для получения адреса IP по доменному имени, можно использовать команду host из пакета bind-utils. Предположим, была вызвана команда host с параметром в виде имени хоста 'cbias.mpei.ac.ru'. Если в файле
/etc/hosts такой записи не обнаруживается, то клиентская библиотека DNS обращается с запросом к серверу из /etc/resolv.conf.

В свою очередь сервер DNS, получив запрос, разбирает доменное имя на составные части. Доменом первого уровня в данном случае является 'ru'. Следует запрос к одному из корневых серверов (его адрес известен заранее) о сервере имен, содержащем зону 'ru'. Результаты этого запроса можно посмотреть на клиенте, указав команде 'host' возвращать адрес сервера DNS, а не адрес хоста:

$ host -t NS ru.

ru name server ns.ripn.net.

ru name server ns2.nic.fr.

ru name server ns2.ripn.net.

ru name server ns5.msk-ix.net.

ru name server ns9.ripn.net.

ru name server sunic.sunet.se.

ru name server auth60.ns.uu.net.

Далее следует обращение к одному из полученных серверов с целью узнать сервер DNS для зоны ac.ru:

$ host -t NS ac.ru

ac.ru name server ns-soa.darenet.dk.

ac.ru name server dns.princeton.edu.

ac.ru name server ns1.free.net.

ac.ru name server ns2.free.net.

ac.ru name server sunic.sunet.se.

Продолжая запросы, сервер DNS находит, где хранится зона для mpei.ac.ru:

$ host -t NS mpei.ac.ru

mpei.ac.ru name server ns3.mpei.ac.ru.

mpei.ac.ru name server ns4.nic.ru.

mpei.ac.ru name server ns1.mpei.ac.ru.

mpei.ac.ru name server ns2.mpei.ac.ru.

Наконец, с одного из этих серверов возвращается адрес IP для нужного имени:

$ host cbias.mpei.ac.ru

cbias.mpei.ac.ru has address 193.233.68.98

Проводя поиск имени, сервер DNS запоминает полученные промежуточные результаты. Поэтому, при повторном запросе от клиента адреса cbias.mpei.ac.ru, сервер DNS сразу выдаст искомое значение из своего кэша, а при поиске адреса для записи itf.mpei.ac.ru — сразу обратится к серверам домена mpei.ac.ru. Всё это позволяет как убыстрить процесс разрешения имён, так и снизить нагрузку на сервера DNS в Internet.

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

Преобразование имени DNS в IP не обязательно однозначное: одному символьному имени может соответствовать несколько адресов IP:

$ host google.ru

google.ru has address 216.239.59.104

google.ru has address 72.14.221.104

google.ru has address 66.249.93.104

google.ru mail is handled by 10 smtp4.google.com.

google.ru mail is handled by 10 smtp1.google.com.

google.ru mail is handled by 10 smtp2.google.com.

google.ru mail is handled by 10 smtp3.google.com.

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

С другой стороны, и одному адресу может соответствовать несколько символьных имён, в т.ч. и из разных доменов:

$ host edu.cbias.ru

edu.cbias.ru has address 87.242.75.168

$ host edu.ossg.ru

edu.ossg.ru has address 87.242.75.168

Имена DNS никак не связаны с распределением адресов IP по сетям, что позволяет объединять в рамках одного домена (или одного имени) компьютеры, расположенные в разных физических сетях.

Помимо рассмотренного прямого преобразования имени DNS в адрес также существуют и обратное — определение символьного имени DNS по адресу IP. Из-за неоднозначности прямого соответствия доменного имени адресу IP для обратного преобразования используются специальные зоны и дерево доменов в домене .in-addr.arpa., а из-за существенно более редкой надобности в обратном преобразовании для значительного числа хостов определить доменное имя по их адресу IP нельзя.

Конфигурация сетей TCP/IP в Linux


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

Обмен данными в сети происходит через сетевые интерфейсы. Сетевые интерфейсы могут как соответствовать физическим устройствам компьютера (например, сетевым картам Ethernet), так представлять логические устройства. К последним относятся, например, интерфейсы PPP (Point-to-Point Protocol), работающие поверх последовательных модемных соединений и виртуальные сетевые интерфейсы, организующие передачу данных поверх других сетей.

Для передачи информации в сети помимо самих передаваемых данных требуется также знание того, с какого и на какой хост передаются эти данные. Поэтому для сетевых интерфейсов стандартное для Unix представление устройств как файлов не имеет смысла, и в каталог /dev/ соответствующие сетевым интерфейсам файлы устройств не отображаются. Работа с сетевыми интерфейсами осуществляется только через вызовы ядра, а на прикладном уровне — через наборы соответствующих утилит.

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

Сетевые интерфейсы представляют из себя абстрактные устройства, работающие на 3ем уровне модели OSI ISO. Для работы поверх них протоколов TCP/IP требуются дальнейшая настройка интерфейсов — назначение им адресов IP и создание записей в таблице маршрутизации.

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

Для автоматической конфигурации сетей TCP/IP обычно используются протоколы DHCP (Dynamic Host Configuration Protocol) и UPnP (Universal Plug and Play).

Протокол DHCP — клиент-серверный, широко используется для динамического назначения адресов IP компьютерам, подключенным к сетям Ethernet. Для его работы необходима настройка в сети одного или нескольких серверов DHCP, на системах со статически настроенными сетевыми интерфейсами. Клиент DHCP, при подключении к сети, отправляет в неё широковещательный пакет, в котором содержится запрос на получение им адреса IP. Сервер DHCP, получив такой пакет, выделяет клиенту один из адресов IP из используемой подсети, и дополнительно передаёт ему информацию о маршрутизации, серверах DNS и пр.

В отличии от DHCP, протокол UPnP не требует размещения в сети специализированного сервера. С другой стороны, в рамках протокола UPnP хосту неоткуда получить информацию о маршрутизации и серверах DNS, что сильно снижает его полезность. В целом, UPnP используется в операционных системах Microsoft Windows в качестве последнего источника получения адреса IP; он позволяет быстро и без каких-либо навыков объединить несколько компьютеров в сети на базе Ethernet и далее работать с общими сетевыми папками и принтерами в рамках протокола CIFS.

Для статической конфигурации сетевых интерфейсов в Linux существуют два отдельных набора утилит — net-scripts и iproute2. Первый из них морально устарел и не позволяет полностью использовать текущие возможности стека TCP/IP, однако ещё применяется в ряде дистрибутивов и во встраиваемых системах. Второй — iproute2 — более новый, обеспечивает больше возможностей, и рекомендован к использованию.

Рассмотрим возможности основной утилиты пакета iproute2 — команды ip.



Просмотр состояний физических интерфейсов осуществляется командой

# ip link show

1: lo: mtu 16436 qdisc noqueue

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

3: venet0: mtu 1500 qdisc noop

link/void

5: eth0: mtu 1500 qdisc noop

link/ether 00:18:51:51:1a:dc brd ff:ff:ff:ff:ff:ff

Здесь lo — локальный интерфейс обратной петли (loopback), venet0 и eth0 — два сетевых интерфейса. В ходе лабораторной работы пытаться настроить интерфейс venet0 не стоит, через него осуществляется связь с VPS. Если его отключить или неправильно сконфигурировать, связь по SSH оборвётся.

Видно, что, в отличии от venet0, eth0 не включён. Включить интерфейс можно командой

# ip link set eth0 up

# ip link show eth0

5: eth0: mtu 1500 qdisc noqueue

link/ether 00:18:51:51:1a:dc brd ff:ff:ff:ff:ff:ff

Посмотреть назначенные адреса на интерфейсе можно командой

# ip addr show

1: lo: mtu 16436 qdisc noqueue

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

3: venet0: mtu 1500 qdisc noop

link/void

inet 192.168.250.241/32 scope global venet0:1

5: eth0: mtu 1500 qdisc noqueue

link/ether 00:18:51:51:1a:dc brd ff:ff:ff:ff:ff:ff

Хотя мы и включили интерфейс eth0, адрес ему ещё не назначен. Назначим ему IP 192.168.230.100 из сети /29:

# ip addr add 192.168.230.100/29 dev eth0

# ip addr show eth0

5: eth0: mtu 1500 qdisc noqueue

link/ether 00:18:51:51:1a:dc brd ff:ff:ff:ff:ff:ff

inet 192.168.230.100/29 scope global eth0

После этого можно послать ICMP-запрос на назначенный адрес и, разумеется, получить ответ:

# ping 192.168.230.100

PING 192.168.230.100 (192.168.230.100) 56(84) bytes of data.

64 bytes from 192.168.230.100: icmp_seq=1 ttl=64 time=0.081 ms

64 bytes from 192.168.230.100: icmp_seq=2 ttl=64 time=0.144 ms

^C

--- 192.168.230.100 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1001ms

rtt min/avg/max/mdev = 0.081/0.112/0.144/0.033 ms

ping посылает пакеты ICMP 1 раз в секунду, прервать его выполнения можно клавишами Ctrl-C.

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

# ip addr add 192.168.210.100/25 dev eth0

[root@veth-test /]# ip addr show eth0

5: eth0: mtu 1500 qdisc noqueue

link/ether 00:18:51:51:1a:dc brd ff:ff:ff:ff:ff:ff

inet 192.168.230.100/29 scope global eth0

inet 192.168.210.100/25 scope global eth0

Удалить ненужный адрес можно командой

# ip addr del 192.168.210.100/25 dev eth0

[root@veth-test /]# ip addr show eth0

5: eth0: mtu 1500 qdisc noqueue

link/ether 00:18:51:51:1a:dc brd ff:ff:ff:ff:ff:ff

inet 192.168.230.100/29 scope global eth0

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

# ip route show

192.168.230.96/29 dev eth0 proto kernel scope link src 192.168.230.100

Мы видим только маршрут на сеть, в которую входит назначенный нами адрес IP, и в которую, очевидно, входит сетевой интерфейс. Эта запись была добавлена при выполнении 'ip addr add' автоматически.

Добавим маршрут на сеть 192.168.230.0/24 через шлюз 192.168.230.98:

# ip route add 192.168.230.0/24 via 192.168.230.98

# ip route show

192.168.230.96/29 dev eth0 proto kernel scope link src 192.168.230.100

192.168.230.0/24 via 192.168.230.98 dev eth0

Аналогично можно добавлять и удалять другие маршруты:

# ip route add 192.168.238.0/24 via 192.168.230.98

# ip route add 192.168.228.0/22 via 192.168.230.99

# ip route show

192.168.230.96/29 dev eth0 proto kernel scope link src 192.168.230.100

192.168.230.0/24 via 192.168.230.98 dev eth0

192.168.238.0/24 via 192.168.230.98 dev eth0

192.168.228.0/22 via 192.168.230.99 dev eth0

# ip route del 192.168.238.0/24 via 192.168.230.98

# ip route show

192.168.230.96/29 dev eth0 proto kernel scope link src 192.168.230.100

192.168.230.0/24 via 192.168.230.98 dev eth0

192.168.228.0/22 via 192.168.230.99 dev eth0

Маршрут по-умолчанию добавляется аналогично:

# ip route add default via 192.168.230.97

# ip route show

192.168.230.96/29 dev eth0 proto kernel scope link src 192.168.230.100

192.168.230.0/24 via 192.168.230.98 dev eth0

192.168.228.0/22 via 192.168.230.99 dev eth0

default via 192.168.230.97 dev eth0

После этого таблица статической маршрутизации будет полностью настроена в соответствии с приведённой выше схемой и будут доступны всех хосты из подсетей 192.168.230.0/24, 192.168.228.0/22.

Выполнение лабораторной работы.


Лабораторная работа посвящена изучению основ семейства протоколов TCP/IP и маршрутизации сетях на основе этих протоколов.
В каждую VPS добавлен интерфейс eth0.

Интерфейс eth0 входит в одну из 4 рабочих сетей 2 уровня OSI ISO, в каждой из которых присутствуют по две сети TCP/IP (3го уровень OSI ISO).

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

Известно, что для каждой из рабочих сетей 3го уровня доступны два маршрутизатора. Один из этих маршрутизаторов имеет адрес из списка:

172.17.52.58/22

172.18.116.100/25

172.18.126.87/26

172.20.57.121/28

172.21.34.84/23

172.22.234.142/21

172.24.4.195/27

172.24.214.50/24


адрес второго - первый или последний IP данной рабочей сети.
Адрес внешнего шлюза: 172.30.67.24

Адрес внутреннего сервера: 172.16.48.96


Требуется:

1) определить, в какие сети входит интерфейс eth0.

Для этого следует, рассчитав адреса сетей и диапазоны адресов в этих сетях, последовательно выбирать IP из каждой сети, назначать его интерфейсу, и пробовать получить ответ, посылая запрос маршрутизатору из этой сети. Для проверки доступности маршрутизатора следует использовать команду ping (формат вызова: ping [|]). Выбирая адрес IP, следует учитывать, что он должен быть уникальным — т.е. не должен совпадать ни с адресами каждого из шлюзов, ни с адресами других VPS в данной сети;
2) назначить интерфейсу два адреса IP из соответствующих сетей; определить адреса всех четырёх видимых из данной сети второго уровня шлюзов.
3) определить и задать статические маршруты до каждой из рабочих сетей, а также до сетей внешнего шлюза и внутреннего веб-сервера.

Для этого следует, последовательно прописывая маршруты для каждой из шести оставшихся сетей на один из двух известных маршрутизаторов, проверять их доступность командой ping до получения положительного результата;


4) изменить маршрут по-умолчанию для выхода в Internet через внешний шлюз;
5) настроить службу распознавания имён DNS.

В качестве сервера DNS следует выбрать адрес внешнего шлюза. Сервер DNS указывается в записи 'nameserver' в файле /etc/resolv.conf. После изменения файла следует выполнить команду

# update_chrooted all

Задания на лабораторную работу.

1) определить, в какие сети входит интерфейс eth0;

2) назначить интерфейсу два адреса IP из соответствующих сетей;

3) определить и задать статические маршруты до каждой из рабочих сетей, а также до сетей внешнего шлюза и внутреннего веб-сервера;

4) изменить маршрут по-умолчанию для выхода в Internet через внешний шлюз;

5) настроить службу распознавания имён DNS.



Цель работы: настроить сетевой интерфейс таким образом, чтобы можно было достичь каждой из сетей, а также хостов в Internet — как по адресу, так и по имени DNS.

Контрольные вопросы.


  1. Какие основные идеи заложены в сетевой модели OSI ISO?

  2. Какие основные протоколы относятся к стеку TCP/IP?

  3. Что такое адрес IP, форма его записи?

  4. Что такое сетевая и машинная части адреса IP?

  5. На какие классы разделяются адреса IP?

  6. Что такое сетевая маска, какие они бывают?

  7. Какие диапазоны адресов IP выделены для частных сетей?

  8. Зачем нужны протоколы UDP и TCP? Чем они отличаются?

  9. Что такое номер порта в протоколах TCP, UDP?

  10. Как производится маршрутизатизация в сетях TCP/IP?

  11. Что такое статический маршрут? Как он выглядит?

  12. Какой порядок выбора маршрута для IP-пакета? Что такое маршрут по-умолчанию?

  13. Зачем нужна система DNS?

  14. Каковы принципы работы системы DNS?


Литература





  1. Георгий Курячий, Кирилл Маслинский
    «Введение в ОС Linux» - учебное пособие по работе с операционной системой Linux, распространяется на условиях лицензии GNU FDL:
    http://heap.altlinux.org/issues/textbooks/LinuxIntro.george/index.html

  2. Робачевский А.М., Немнюгин С.А., Стесик О.Л. Операционная система UNIX. – 2 изд., СПб.: BHV – Санкт-Петербург, 2005. – 636 с.

  3. Документы RFC: http://www.rfc-editor.org

  4. Эви Немет, Гарт Снайдер, Скотт Сибасс, Трент Р. Хейн.
    UNIX: Руководство системного администратора. 3-е изд. -
    СПб.: BHV - Санкт-Петербург, 2005 — 925 c.

Текст лицензии GNU FDL можно найти по адресу: http://www.gnu.org/licenses/fdl.html



Смотрите также:
Лабораторная работа №6 Принципы построения сетей tcp/ip v4 Copyright (c) 2008,2009 Nikolay A. Fetisov
273.09kb.
1 стр.
Лабораторная работа №3 Принципы построения сетей tcp/ip copyright (c) 2008,2009,2010 Nikolay A. Fetisov
423.63kb.
3 стр.
Лабораторная работа №2 Знакомство с языком gpss
50.61kb.
1 стр.
Лабораторная работа №1 «Файловые менеджеры»
89.6kb.
1 стр.
Лабораторная работа по химии, физике, биологии, т е. по естественно-научным предметам. На уроках русского языка и литературы термин «лабораторная работа»
261.84kb.
1 стр.
Лекции Тема Общие принципы построения ЭВМ принципы построения и архитектура ЭВМ
48.3kb.
1 стр.
Принципы построения образовательных курсов по свободному по на базе операционной системы Linux
27.23kb.
1 стр.
Лабораторная работа Процедуры настройки параметров персептронных нейронных сетей. Правила настройки
76.71kb.
1 стр.
Курс «Современные технологии построения компьютерных сетей с использованием Microsoft Windows Server 2008 R2»
53.51kb.
1 стр.
Лабораторная работа №5 Лабораторная работа выполняется согласно выбранной теме курсовой работы!!! Количество таблиц в бд: от 4 до 6
46.6kb.
1 стр.
Ним «Современные и перспективные технологии построения сенсорных сетей»
112.6kb.
1 стр.
Лабораторная работа №1 Построение детерминированного синтаксического анализатора
278.71kb.
1 стр.