Редактирование: UNИX, осень 2008, 06 лекция (от 05 ноября)

= Лекция =

== Вступление ==

Мы чересчур поспешно добрались до сетевого уровня TCP/IP, на котором решаются две задачи:

* задача глобальной идентификации

* задача доставки пакета, маршрутизации (в случае, если отправитель и получатель отделены последовательностью различных СПД)

Лектор напоминает, что если бы СПД была одна, и она была бы Ethernet, то этого уровня не было бы. Есть некий механизм порождения уникальности, ethernet-идентификатор, который можно было бы использовать, и задействовать для идентификации устройств - именно из уникального идентификатора, то есть MAC-адреса.

Необходимость ещё одного идентификатора также диктуется независимостью уровней.

Для идентификации на сетевом уровне вводится понятие IP-адрес. Он состоит из 4 байтов, эти 4 байта можно записывать в 10-м виде через точку: 127.0.0.1, их же можно записывать в 16-ричном виде, в 2-ном (только долго писать придётся), и принято различать... каждый такой адрес присваивается некоему сетевому интерфейсу, то есть, той дырке, той части системы, через которую пакеты переходят на уровень сетевой. Тут может происходить сборка-разборка пакетов.

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

Система там очень простая:

* A — первый бит адреса 0, один байт на адрес сети

* B — 10, два байта на адрес сети

* С — 110, три байта на адрес сети

Но это деление теперь тоже оказалось малоосмысленным, и все на это забили. В альте, например, выдаётся сетевая маска /24, даже если адрес 10.х.х.х.

 

Поскольку не все умеют корректно и правильно обрабатывать дырявые маски, и они мало где используются, то обычно маска определяется количеством единиц в ней: в адресе 210.111.18.2/24 маска 255.255.255.0 и подсеть 210.111.18.0.

Поскольку мы всех перенумеровали, то теоретически один абонент может передать другому данные. Но тут возникает несколько вопросов:

Откуда я знаю, что я такой адрес? От провайдера. А откуда у провайдера этот адрес? Наверное, есть орган (IANA), которая раздаёт адреса по-крупному. Например, 210.x.x.x выдан Китаю (?), и если спросить у неё про конкретный адрес, то она не ответит, скажет, все вопросу к Китаю. Там уже пошлют к провайдеру, там ещё к одному и так далее. Идея понятна: существует некая чисто административная иерархия по раздаче адресов в пространстве интернета. Эта иерархия держится на административных и отчасти топологических закономерностях — скажем, связность между двумя адресами 210.х.х.х выше, чем между ними и адресами из другой подсети.

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

Есть некий шаблон поведения, который, по крайней мере, не требует того, чтобы для каждого из таких компьютеров регистрировался IP-адрес, а в ряде случаев такое даже не нужно. Например, если у нас есть компьютерный класс, от при добавлении десятка компьютеров было бы очень неудобно ходить к провайдеру и регистрировать 10 адресов. Более того, в ряде случаев было бы хорошо скрывать диапазон адресов, используемых в локальной сети.

Есть ещё одна проблема: IP-шники начинают кончаться, и IANA выдаёт их неохотно.

Две последние проблемы решаются следующим образом:

* Существует технология подмены IP-адреса, про неё мы будем говорить, когда будем говорить про IP-уровень. Суть этой технологии (NAT) очень простая: есть компьютер с неважным IP-адресом, и посылает пакет в интернет, пакет проходит через некое устройство, которое запоминает историю пакета и его уникальные характеристики, подменяет IP и посылает наружу, когда приходит ответ, происходит обратная операция. Когда используют NAT, адреса в локалке никого не волнуют. Для того, чтобы это дело более менее ввести в какое-то русло...

На заре становления факультетского интернета были IBM RT, которые приехали неизвестно откуда. Приехали они с чистыми хардами, но на одной из машин оказался бэкап, с которого как-то развернули систему, и долгое время адреса в у них были такие же, как у MIT. Поскольку был NAT, то никто об этом не знал, но на сайт MIT'а было нельзя.

Чтобы такой проблемы не возникало, некоторые диапазоны адресов отведены под локальные сети:

Любой из них можно использовать для адресации в локальных сетях без проблем.

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

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

Сосредоточимся на одном из всего этого: есть абонент сети, и ... за это отвечает сетевая маска.

Есть довольно простой способ проверки (это часть сетевого протокола), принадлежит ли абонент локальной сети и, следовательно, доступен ли в пределах СПД, или же он ей не принадлежит и с ним надо что-то делать. Накладываем маску на адреса отправителя и получателя, и, если они совпадают, то они лежат в пределах локальной сети.

=== Случай 1. Локальная сеть. ARP ===

Что в этом случае делать: заворачиваем в ethernet-фрейм и посылаем, поскольку знаем его идентификатор, MAC-адреса. А откуда мы его знаем? Есть СПД, где заранее известны все идентификаторы, это статические сети, например в рамках вычислительного кластера. В реальной жизни бывает всё не так. В общем случае нам неизвестен интерфейсный идентификатор абонента, известен только IP.

Для того, чтобы выполнить операцию нахождения соответствия между MAC-адресами и IP-адресами (интерфейсным и сетевым адресами), мы должны иметь некую таблицу соответствий, и существует протокол (ARP), который как раз занимается переводом из адреса уровня сетевого в адрес уровня интерфейсного. Там богатый спектр верхних и нижних уровней, и, в частности, переводит из IP в MAC. Поддержка ARP — неотъемлемое свойство практически любой машины, подключенной к интернету. Протокол ARP широковещательный, его пакеты направляются сразу всем (в поле MAC-адреса стоят все 1), и тип этого пакета — ARP-запрос. В нём написано? "Чей такой вот IP?". Этот пакет все получают, и та машина, чей IP, отвечает: "Это ARP-ответ", поскольку адрес содержится в фрейме. После этого таблица пополняется.

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

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

 

 

 

 

 

 

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

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

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

В случае соединения точка-точка, нам вообще не нужно пользоваться механизмом сеть-подсеть. Если это подключение не точка-точка, то сколько тогда надо бит? 2, не 1. Сеть /30. Это к тому, насколько максимум подсетей можно разрезать подсеть класса C: не на 256, и не на 128, а на 64, или даже 63.

Алгоритм маршрутизации достаточно прост: мы просматриваем строчки таблицы маршрутизации, где сначала абоненты локальной сети, потом записи вида пересылки через абонентов и последней будет по умолчанию. Это всё стандартный алгоритм маршрутизации, если не использовать хитрые штуки '''ip route'''. Ибо не зря iproute2. Ибо такой способ маршрутизации весьма неэффективен в случае сложной маршрутизации. В случае настройки простой маршрутизации он вполне хорош.

Например, в случае, когда нужно предоставить различную скорость доступа для разных категорий пользователей, для определения того, куда пересылать пакет, нужно изучать адрес отправителя, а не адрес получателя. Тут мы наталкиваемся на ситуацию, что в адресе отправителя ничего про это не говорится. Эта задача одна из первых возникает в задаче принудительной маршрутизации, она называется source-based routing. Разумеется, раз пошла такая пьянка, то пошли всякий примеси. Например, пакеты одного класса можно пересылать через быстрый и тонкий канал, другого — через тонкий и медленный. Или если пакет из привилегированного сеанса, от обработать его привилегированно. Вообще говоря, можно подменить стандартный процесс маршрутизации, маршрутизируя по правилам какое состояние в системе и какими свойствами обладает приехавший пакет.

Пристальный анализ документации к утилите ip покажет, что там достаточно много разных действий.

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

В реальности имеются некие облачка (внутри которых уже очень часто бывают деревья), и между ними неплохо было бы устроить какую-то сеть, и поддерживать информацию о:

* Уметь в случае пропадания достижимости гибко перестраивать этот маршрут

С точки зрения деревообр. кусочка это выглядит так: сначала передавали их через одно место, потом через другое.

Если бы не было такой стратегии разю. интернета на авт. системы и отслеживания достижимости, то никакого интернета бы не было. Эта проблема это тоже проблема маршрутизации. Первая проблема — маршрутизация изнутри, вторая — маршрутизация снаружи.

Существует несколько протоколов разной степени замшелости, которые описывают поведение авт. систем: BGP, RIP, RIP2, EGP. Реализация такого протокола есть функция не столько рабочей машины, скорее всего вы даже такую машину не увидите, это очень редкий компьютер, и на нём совсем не обязательно линукс или что-то юникс-подобное. Сущ. прогр. продукты, которые реализуют эти протоколы маршрутизации, наиболее известный это Zebra и выросщий из неё ... . Проблема в том, что это вообще не очень часто решающаяся задача, и если юникс-гуру дали такую задачу, то он возьмёт ту же ..., посидит над неё неделю и сделает так, что бы оно работало. Но есть фирмы, которые занимаются продажей такого железа.

О протоколах этого уровня в следующий раз.

= Конспект Kda =

<div style="font-size:50%">