 |
Алгоритм построения таблицы маршрутов
|
|
|
|
Уровни стека TCP/IP
Вот как традиционно протоколы TCP/IP вписываются в модель OSI:
Распределение протоколов по уровням модели OSI
Прикладной напр., HTTP, SMTP, SNMP, RTP, FTP, Telnet, SSH, SCP, SMB, NFS, RTSP, BGP
Представительский напр., XDR, ASN.1, AFP, TLS, SSL
Сеансовый напр., ISO 8327 / CCITT X.225, RPC, NetBIOS, ASP
Транспортный напр., TCP, UDP, SCTP, SPX, ATP, DCCP, GRE
Сетевой напр., IP, ICMP, IGMP, CLNP, OSPF, RIP, IPX, DDP, ARP, RARP
Канальный напр., Ethernet, Token ring, PPP, HDLC, X.25, Frame relay, ISDN, ATM, MPLS, Wi-Fi
Физический напр., электрические провода, радиосвязь, волоконно-оптические провода
Обычно в стеке TCP/IP верхние 3 уровня (прикладной, представительский и сеансовый) модели OSI объединяют в один — прикладной. Поскольку в таком стеке не предусматривается унифицированный протокол передачи данных, функции по определению типа данных передаются приложению. Упрощенно интерпретацию стека TCP/IP можно представить так:
7. Основные функции протокола IP.
Протокол Internet выполняет две главные функции: адресацию и фрагментацию
Функция или цель протокола Internet состоит в передаче датаграммы через набор объединенных компьютерных сетей. Это осуществляется посредством передачи датаграмм от одного модуля Internet к другому до тех пор, пока не будет достигнут получатель. Модули Internet находятся на хостах и шлюзах системы Internet. Датаграммы направляются с одного модуля Internet на другой через конкретные компьютерные сети, основанные на интерпретации Internet адресов. Таким образом, одним из важных механизмов протокола Internet является Internet адрес.
При передаче сообщений с одного Internet модуля на другой датаграммы могут нуждаться в прохождении через сети, для которых максимальный размер пакета меньше, чем размер датаграммы. Чтобы преодолеть эту сложность, в протокол Internet включен механизм фрагментации.
|
|
|
8. Общий сценарий работы модуля IP.
Протокол IP находится на межсетевом уровне стека протоколов TCP/IP. Функции протокола IP определены в стандарте RFC-791 следующим образом: “Протокол IP обеспечивает передачу блоков данных, называемых дейтаграммами, от отправителя к получателям, где отправители и получатели являются компьютерами, идентифицируемыми адресами фиксированной длины (IP-адресами). Протокол IP обеспечивает при необходимости также фрагментацию и сборку дейтаграмм для передачи данных через сети с малым размером пакетов”. Протокол IP является ненадежным протоколом без установления соединения. Это означает, что протокол IP не подтверждает доставку данных, не контролирует целостность полученных данных и не производит операцию квитирования (handshaking) - обмена служебными сообщениями, подтверждающими установку соединения с узлом назначения и его готовность к приему данных. Протокол IP обрабатывает каждую дейтаграмму как независимую единицу, не имеющую связи ни с какими другими дейтаграммами в Интернет. После того, как дейтаграмма отправляется в сеть, ее дальнейшая судьба никак не контролируется отправителем (на уровне протокола IP). Если дейтаграмма не может быть доставлена, она уничтожается. Узел, уничтоживший дейтаграмму, может оправить по обратному адресу ICMP-сообщение о причине сбоя.
Гарантию правильной передачи данных предоставляют протоколы вышестоящего уровня (например, протокол TCP), которые имеют для этого необходимые механизмы.Одна из основных задач, решаемых протоколом IP, - маршрутизация дейтаграмм, т.е. определение пути следования дейтаграммы от одного узла сети к другому на основании адреса получателя. Общий сценарий работы модуля IP на каком-либо узле сети, принимающего дейтаграмму из сети, таков: с одного из интерфейсов уровня доступа к среде передачи (например, с Ethernet-интерфейса) в модуль IP поступает дейтаграмма;
|
|
|
· модуль IP анализирует заголовок дейтаграммы;
· если пунктом назначения дейтаграммы является данный компьютер:
o если дейтаграмма является фрагментом большей дейтаграммы, ожидаются остальные фрагменты, после чего из них собирается исходная большая дейтаграмма;
o из дейтаграммы извлекаются данные и направляются на обработку одному из протоколов вышележащего уровня (какому именно - указывается в заголовке дейтаграммы);
· если дейтаграмма не направлена ни на один из IP-адресов данного узла, то дальнейшие действия зависят от того, разрешена или запрещена ретрансляция (forwarding) “чужих” дейтаграмм;
· если ретрансляция разрешена, то определяются следующий узел сети, на который должна быть переправлена дейтаграмма для доставки ее по назначению, и интерфейс нижнего уровня, после чего дейтаграмма передается на нижний уровень этому интерфейсу для отправки; при необходимости может быть произведена фрагментация дейтаграммы;
· если же дейтаграмма ошибочна или по каким-либо причинам не может быть доставлена, она уничтожается; при этом, как правило, отправителю дейтаграммы отсылается ICMP-сообщение об ошибке.
При получении данных от вышестоящего уровня для отправки их по сети IP-модуль формирует дейтаграмму с этими данными, в заголовок которой заносятся адреса отправителя и получателя (также полученные от транспортного уровня) и другая информация; после чего выполняются следующие шаги:
· если дейтаграмма предназначена этому же узлу, из нее извлекаются данные и направляются на обработку одному из протоколов транспортного уровня (какому именно - указывается в заголовке дейтаграммы);
· если дейтаграмма не направлена ни на один из IP-адресов данного узла, то определяются следующий узел сети, на который должна быть переправлена дейтаграмма для доставки ее по назначению, и интерфейс нижнего уровня, после чего дейтаграмма передается на нижний уровень этому интерфейсу для отправки; при необходимости может быть произведена фрагментация дейтаграммы;
· если же дейтаграмма ошибочна или по каким-либо причинам не может быть доставлена, она уничтожается.
Неотъемлемой частью IP-модуля является протокол ICMP (Internet Control Message Protocol), отправляющий диагностические сообщения при невозможности доставки дейтаграммы и в других случаях. Совместно с протоколом IP работает также протокол ARP (Address Resolution Protocol), выполняющий преобразования IP-адресов в MAC-адреса (например, адреса Ethernet).
|
|
|
9. Формат IP пакета.
В Интернет используется много различных типов пакетов, но один из основных - IP-пакет (RFC-791), именно он вкладывается в кадр Ethernet и именно в него вкладываются пакеты UDP, TCP. IP-протокол предлагает ненадежную транспортную среду. Ненадежную в том смысле, что не существует гарантии благополучной доставки IP-дейтограммы. Алгоритм доставки в рамках данного протокола предельно прост: при ошибке дейтограмма выбрасывается, а отправителю посылается соответствующее ICMP-сообщение (или не посылается ничего). Обеспечение же надежности возлагается на более высокий уровень (UDP или TCP). Формат IP-пакетов показан на рисунке 4.4.1.1.
Рис. 4.4.1.1. Формат дейтограммы Интернет
Поле версия характеризует версию IP-протокола (например, 4 или 6). Формат пакета определяется программой и, вообще говоря, может быть разным для разных значений поля версия. Только размер и положение этого поля незыблемы. Поэтому в случае изменений длины IP-адреса слишком тяжелых последствий это не вызовет. Понятно также, что значение поля версия во избежании непредсказуемых последствий должно контролироваться программой. HLEN - длина заголовка, измеряемая в 32-разрядных словах, обычно заголовок содержит 20 октетов (HLEN=5, без опций и заполнителя). Заголовок для IPv6 имеет размер в два раза больше, чем для IPv4. Поле полная длина определяет полную длину IP-дейтограммы (до 65535 октетов), включая заголовок и данные. Одно-октетное поле тип сервиса (TOS - type of service) характеризует то, как должна обрабатываться дейтограмма. Это поле делится на 6 субполей:
Субполе Приоритет предоставляет возможность присвоить код приоритета каждой дейтограмме. Значения приоритетов приведены в таблице (в настоящее время это поле не используется).
0 Обычный уровень
1 Приоритетный
2 Немедленный
3 Срочный
4 Экстренный
5 ceitic/ecp
6 Межсетевое управление
7 Сетевое управление
|
|
|
Формат поля TOS определен в документе RFC-1349. Биты C, D, T и R характеризуют пожелание относительно способа доставки дейтограммы. Так D=1 требует минимальной задержки, T=1 - высокую пропускную способность, R=1 - высокую надежность, а C=1 - низкую стоимость. TOS играет важную роль в маршрутизации пакетов. Интернет не гарантирует запрашиваемый TOS, но многие маршрутизаторы учитывают эти запросы при выборе маршрута (протоколы OSPF и IGRP).
Поля идентификатор, флаги (3 бита) и указатель фрагмента (fragment offset) управляют процессом фрагментации и последующей "сборки" дейтограммы. Идентификатор представляет собой уникальный код дейтограммы, позволяющий идентифицировать принадлежность фрагментов и исключить ошибки при "сборке" дейтограмм. Бит 0 поля флаги является резервным, бит 1 служит для управления фрагментацией пакетов (0 - фрагментация разрешена; 1 - запрещена), бит 2 определяет, является ли данный фрагмент последним (0 - последний фрагмент; 1 - следует ожидать продолжения). Поле время жизни (TTL - time to live) задает время жизни дейтограммы в секундах, т.е. предельно допустимое время пребывания дейтограммы в системе. При каждой обработке дейтограммы, например в маршрутизаторе, это время уменьшается в соответствии со временем пребывания в данном устройстве или согласно протоколу обработки. Если TTL=0, дейтограмма из системы удаляется. Во многих реализациях TTL измеряется в числе шагов, в этом случае каждый маршрутизатор выполняет операцию TTL=TTL-1. TTL помогает предотвратить зацикливание пакетов. Поле протокол аналогично полю тип в Ethernet-кадре и определяет структуру поля данные
Поле контрольная сумма заголовка вычисляется с использованием операций сложения 16-разрядных слов заголовка по модулю 1. Сама контрольная сумма является дополнением по модулю один полученного результата сложения. Обратите внимание, здесь осуществляется контрольное суммирование заголовка, а не всей дейтограммы. Поле опции не обязательно присутствует в каждой дейтограмме. Размер поля опции зависит от того, какие опции применены. Если используется несколько опций, они записываются подряд без каких-либо разделителей. Каждая опция содержит один октет кода опции, за которым может следовать октет длины и серия октетов данных.
11. Особые IP-адреса.
Имеются также специальные адреса, которые зарезервированы для 'несвязанных' сетей - которые является сетями, использующими IP, но не связаны с Internet, Эти адреса:
· Одна сеть класса 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
|
|
|
13.Формат заголовка IPv6.
| Version | Prio | Flow Label | ||
| Payload Length | Next Header | Hop Limit | ||
| Source Address | ||||
| Destination Address | ||||
Version (4 бита). Версия протокола. Значением этого поля равно 6.
Prio (4 бита). Приоритет. Поле приоритета позволяет отправителю назначать дейтаграмме определенный уровень приоритета по отношению к другим отправляемым пакетам. Возможные 16 значений этого поля разделены на две категории: значение поля от 0 до 7 используется для дейтаграмм, которые могут не передаваться при слишком переполненной линии. Сюда относится ТСР - трафик, передача e-mail, FTP, NFS, TELNET, X-interactive. Значения поля от 8 до 15 назначаются пакетам, которые должны быть отправлены при любом состоянии (кроме обрыва) линии. Например, приоритет 8 пользователь может назначить пакетам, которые он может позволить себе отправить в последнюю очередь при перегруженной линии, а приоритет 15 — в первую. Последние представляют пакеты реального времени с видео-, аудио- и аналогичными данными, которые должны передаваться с постоянной скоростью.
Flow Label (24 бита). Метка потока. Это поле может использоваться отправителем для того, чтобы помечать пакеты, которые требуют специальной обработки сетевыми модулями IPv6. Хосты или шлюзы, не поддерживающие этой опции, должны установить это поле в 0 и игнорировать при обработке пакета.
Поток представляет собой последовательность пакетов, отправляемых определенному получателю (или группе получателей), на пути к которым пакеты должны пройти специальную обработку (например, информация о прохождении определенного потока будет регистрироваться). Таких потоков между одними и теми же хостами может быть несколько, и значение этого поля позволяет идентифицировать отдельный поток. Если значение этого поля установлено в 0, то считается, что дейтаграмма не принадлежит ни к какому потоку. Меткой потока служит псевдо-случайное число в диапазоне 1 — FFFFFF. Это число также может служить хеш-ключом для шлюзов-обработчиков определенного потока.
Все пакеты, принадлежащие к одному потоку, должны отправляться по одному и тому же адресу назначения и с одним и тем же приоритетом. Кроме того, если одна из дейтаграмм потока содержит в своем заголовке какой-либо вложенный заголовок или опцию, все остальные пакеты потока тоже должны их содержать. Если шлюз, обрабатывающий пакет заметил отклонение состава дейтаграммы от других дейтаграмм потока, он генерирует ошибку потока и уведомляет об этом отправителя. Информация о потоке на шлюзе хранится в течение 6 секунд. Если за это время через шлюз не пройдет ни одной дейтаграммы потока, идентификатор данного потока освобождается. С другой стороны, хост отправителя, в случае перезапуска (инициализации) узла, не сможет ранее чем через 6 секунд организовать новый поток.
Payload Length (16 бит). Длина данных. Это длина данных пакета (в байтах), которые следуют за заголовком. Если величина этого поля равна 0, то длина данных дейтаграммы более 65535 и хранится в поле Jumbo Payload (сверхдлина) заголовка Hop-by-Hop Options (см. далее).
Поле протокола IPv4 Total Length было переименовано в протоколе IPv6 в поле Payload Length. Эти два поля сходны между собой, но не тождественны, поскольку поле Payload Length содержит длину данных после заголовка, в то время как поле Total Length учитывает длину заголовка.
Next Header (8 бит). Поле следующего заголовка. Это поле содержит информацию типа заголовка, который следует за заголовком IPv6.
Еще одно переименованное и измененное поле IPv4 — это поле Protocol. Оно превратилось в поле Next Header в IPv6. В IPv4 значение поля Protocol, например 6 для TCP или 17 для UDP, определяет, данные какого транспортного протокола следуют за IP-заголовком. В IPv6 поле Next Header позволяет вставлять дополнительные заголовки между данными IP и TCP или UDP. Оно также сообщает тип транспортных данных, следующих за основным или дополнительным IP-заголовком. Кроме того, так как поле Next Header предоставляет информацию о наличии дополнительных заголовков, следующих за основным, данный механизм исключает необходимость в поле Internet Header Length, или IHL.
Hop Limit (8 бит). Поле ограничения пересылок. Величина этого поля уменьшается на 1 при прохождении дейтаграммой шлюза или хоста. Если величина этого поля равна 0, дейтаграмма уничтожается.
Единица измерения в поле Time to Live в IPv4 — секунды. Однако при прохождении пакета через маршрутизатор, ввиду трудности определения времени ожидания в очереди, значение этого поля уменьшается реально на 1 секунду. Признав эффективность использования числа транзитных маршрутизаторов в качестве способа определения срока жизни пакета, IPng Directorate заменил поле Time To Live на поле Нор Limit в IPv6.
Source Address (128 бит). Адрес отправителя.
Destination Address (128 бит). Адрес получателя. Если в заголовке присутствует вложенный заголовок маршрутизации (Routing header), это поле может и не быть адресом назначения.
17.Внутренний протокол маршрутизации RIP
Этот протокол маршрутизации предназначен для сравнительно небольших и относительно однородных сетей (алгоритм Белмана-Форда). Протокол разработан в университете Калифорнии (Беркли), базируется на разработках фирмы Ксерокс и реализует те же принципы, что и программа маршрутизации routed, используемая в ОC Unix. Маршрут здесь характеризуется вектором расстояния до места назначения. Предполагается, что каждый маршрутизатор является отправной точкой нескольких маршрутов до сетей, с которыми он связан. Описания этих маршрутов хранится в специальной таблице, называемой маршрутной. Таблица маршрутизации RIP содержит по записи на каждую обслуживаемую машину (на каждый маршрут). Запись должна включать в себя:
IP-адрес места назначения.
Метрика маршрута (от 1 до 15; число шагов до места назначения).
IP-адрес ближайшего маршрутизатора (gateway) по пути к месту назначения.
Таймеры маршрута.
Первым двум полям записи мы обязаны появлению термина вектор расстояния (место назначение - направление; метрика - модуль вектора). Периодически (раз в 30 сек) каждый маршрутизатор посылает широковещательно копию своей маршрутной таблицы всем соседям-маршрутизаторам, с которыми связан непосредственно. Маршрутизатор-получатель просматривает таблицу. Если в таблице присутствует новый путь или сообщение о более коротком маршруте, или произошли изменения длин пути, эти изменения фиксируются получателем в своей маршрутной таблице.
Алгоритм построения таблицы маршрутов
В этом разделе для простоты будем называть таблицей маршрутов таблицу, являющуюся результатом деятельности протокола RIP, как описано выше, т.е. состоящую из строк с полями "Сеть", "Расстояние", "Следующий маршрутизатор". Записывать строку в таблице маршрутов будем следующим образом: А=2-> (3) Это означает, что расстояние от данного маршрутизатора до сети А равно 2, а дейтаграммы, следующие в сеть А, надо пересылать маршрутизатору (3). Вектором расстояний называется набор пар ("Сеть", "Расстояние до этой сети"), извлеченный из таблицы маршрутов. Каждую такую пару мы назовем элементом вектора расстояний. Мы будем записывать вектор расстояний в виде (А=2,В=1): это означает, что расстояние от данного маршрутизатора до сети А равно 2, до сети В - 1.
Расстояние до сети, к которой маршрутизатор подключен непосредственно, примем равным 1. Каждый маршрутизатор, на котором запущен модуль RIP, периодически широковещательно распространяет свой вектор расстояний. Вектор распространяется через все интерфейсы маршрутизатора, подключенные к сетям, входящим в RIP-систему. Каждый маршрутизатор также периодически получает векторы расстояний от других маршрутизаторов. Расстояния в этих векторах увеличиваются на 1, после чего сравниваются с данными в таблице маршрутов, и, если расстояние до какой-то из сетей в полученном векторе оказывается меньше расстояния, указанного в таблице, значение из таблицы замещается новым (меньшим) значением, а адрес маршрутизатора, приславшего вектор с этим значением, записывается в поле "Следующий маршрутизатор" в этой строке таблицы. После этого вектор расстояний, рассылаемый данным маршрутизатором, соответственно изменится.
Ограничения NAT
Существует четыре ограничения в режиме NAT о которых необходимо знать:
Ограничения протокола ICMP:
Многие часто используют сетевые утилиты отладки (ping или tracerouting) используют протокол ICMP для отправки и получения сообщений. Хотя поддержка ICMP протокола была значительно улучшена в VirtualBox 2.1 (ping теперь работает), но при работе с некоторыми утилитами возможны проблемы.
Широковещательные пакеты UDP:
Гостевые системы осуществляют ненадежное получение широковещательных пакетов, что сделано для улучшения производительности, они получают широковещательные пакеты только в определенный промежуток времени, после того как гость отсылает пакет UDP. Как следствие, протокол разрешения имен NetBios не всегда работает корректно (но WINS работает). В данном случае используйте обходной путь - вы можете использовать непосредственно IP адреса для доступа к сетевым ресурсам \\server\share.
Не поддерживается протоколы, такие как GRE:
Протоколы отличные от TCP и UDP не поддерживаются. Это означает что нельзя использовать VPN (PPTP от Microsoft). Существуют другие реализации VPN которые используют TCP и UDP.
Переброс портов хоста < 1024 невозможен:
На Unix системах (Linux, Solaris, MacOS X) нельзя использовать порты с номерами меньше 1024 в приложениях которые запущены не с правами root. В результате, если вы попытаетесь настроить переброс таких портов, то ВМ не запустится.
Эти ограничения обычно не влияют на обычное использование сети. Но наличие их в NAT режиме может приводить к проблемам в сетевой работе. Приведем пример - NFS, часто сервера настроены так, что отказывают в соединениях от непривилегированных портов (т.е. портов с номерами меньше 1024).
31. Межсетевой протокол управляющих сообщений.
Чтобы дать возможность шлюзам в интернете сообщать об ошибках или предоставлять информацию о нестандартных условиях работы, разработчики добавили механизм сообщений специального назначения в протоколы TCP/IP. Этот механизм, известный как Межсетевой Протокол Управляющих Сообщений(ICMP), считается необходимой частью IP и должен включаться в каждую реализацию IP.
Как и весь другой траффик, сообщения ICMP передаются по интернету в поле данных IP-дейтаграмм. Конечным назначением сообщений ICMP, тем не менее, является не прикладная программа или пользователь на машине назначения, а программное обеспечение IP на этой машине. То есть, когда прибывает сообщение ICMP об ошибке, его обрабатывает модуль программного обеспечения ICMP. Конечно, если ICMP определит, что ошибка была вызвана конкретным протоколом более высокого уровня или прикладной программой, он сообщит об этом соответствующему модулю.
Доставка сообщения ICMP
Сообщения ICMP требуют двух уровней инкапсуляции, как показано на рисунке 9.1. Каждое сообщения ICMP передается по интернету в поле данных IP-дейтаграммы, которая сама передается по каждой физической сети в поле данных кадра. Дейтаграммы, несущие сообщения ICMP маршрутизируются точно так же, как и дейтаграммы, несущие информацию для пользователей; для них не используются дополнительные приоритет или надежность. Поэтому, сами сообщения об ошибках могут быть потеряны или удалены. Более того, в уже переполненной сети сообщения об ошибках могут вызвать дополнительное переполнение. Исключение делается для процедур обработки ошибок, если IP-дейтаграмма, несущая сообщение ICMP, вызвала ошибку. Это исключение, установленное для того, чтобы избежать проблемы появления сообщений об ошибках, вызванных в свою очередь сообщениями об ошибках, определяет, что сообщения ICMP не генерируются для ошибок, появившихся из-за дейтаграмм, несущих сообщения об ошибках ICMP.
-------------------------------------- |заголовок | данные ICMP | | ICMP | | -------------------------------------- V V ------------------------------------------------- | заголовок| область данных дейтаграммы | |дейтаграмм| | ------------------------------------------------- V V-----------------------------------------------------------|заголовок| область данных кадра | |кадра | |Формат сообщения ICMP
Хотя каждое сообщение ICMP имеет свой собственный формат, все они начинаются с трех одинаковых полей: 8-битового целочисленного поля ТИП, которое идентифицирует сообщение, 8-битового поля КОД, которое обеспечивает более точную информацию о типе сообщения, и 16-битового поля КОНТРОЛЬНАЯ_СУММА(ICMP использует тот же самый аддитивный алгоритм, что и IP, но контрольная сумма ICMP учитывает только сообщение ICMP). Помимо того, сообщения ICMP, сообщающие об ошибках, всегда включают заголовок и первые 64 бита данных дейтаграммы, вызвавшей ошибку.
Причиной возвращения не только заголовка дейтаграммы, вызвавшей ошибку, является желание позволить получателю более точно определять, какие протоколы и какие прикладные программы ответственны за появление этой дейтаграммы. Как мы увидим позже, протоколы более высокого уровня в связке TCP/IP разрабатывались таким образом, что критическая информация закодирована в первых 64 битах.
Поле ТИП ICMP определяет смысл сообщения, а также его формат. Эти типы включают:
|
|
|
