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

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

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

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

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

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

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

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

 

Но это деление теперь тоже оказалось малоосмысленным, и все на это забили. В альте, например, выдаётся сетевая маска /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 показывается, насколько запись старая.

Сразу, чтобы было понятно, наша универсальная утилита ip это часть пакета iproute2, которая занимается чёрт знает всем, и, в частности, маршрутизацией. У утилиты ip есть команда neighbour. команда '''ip n''' выдаст ARP-таблицу, для тех, кто ещё помнит, есть '''arp -a'''. Внимательное изучение документации по ip, можно узнать, что можно прописывать статические ARP-записи. Можно ещё в этой таблице прописать чужой IP-адрес. Чем это отличается от alias? Чаще всего это бывает в следующих ситуациях: есть интернет, по нему есть ppp-канал, за которым машины с такой же подсетью, как и ваша. В этом случае на маршрутизаторе прописывается ещё одна arp-запись.

Что касается маршрутизации: здесь есть две проблемы. Первая проблема состоит в очень простом вопросе: мы выяснили, что наш пакет на уровне IP, мы его хотим послать абоненту, который не находится в нашей локальной сети. Что дальше? Видимо, послать его куда-то, причём в надежде, что оно пошло ещё дальше, и ещё дальше и так далее. В нашей сети не все <strike>йогурты</strike> абоненты одинаковы.

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

При этом что нужно сделать на клиенте: на ней нужно создать специальную запись, опять таки, внутри таблиц ядра, которая именовала эту машину маршрутизатором для... Есть команда '''ip route''', которая позволяет просмотреть все маршруты. Выполнив её...

Возвращаемся к вопросу идентификации. Мы помним, что все сетевые интерфейсы можно просмотреть командой '''ip link'''. С помощью '''ip addr''' можно просмотреть список всех интерфейсов и всю информацию, касающуюся сетевого уровня, присвоенную этим интерфейсам. По крайней мере, с точки зрения линукса, должен быть интерфейс, и на него уже навешивать параметры уровня сетевого. Для того, чтобы добавить адрес к интерфейсу, достаточно сказать '''ip addr add 210.11.70.8/24 dev eth0'''.

Некоторые узнают в этом синтаксис ifconfig. Естественно, поскольку ip это в первую очередь замена ему, и умеет всё и ещё больше. Только в ifconfig для добавления нескольких адресов необходимо было создать виртуальные интерфейсы... проделывать некое упражнение.

...

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

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

 

 

 

 

 

 

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Не все на него прореагируют.

Есть соединение точка-точка.

То есть, два абонента.

Ничего не нужно, только два адреса.

Если же это сеть с двумя абонентами, то длина сети будет 30, а не 31.

Потому что нужны два зарезервированных адреса.

Сеть класса C можно разделить на 64, а то и 63 сети.

Еще раз про маршрутизацию.

Алгоритм прост — просматриваем записи с точки зрения количетсва битов в сетевой маске.

Чем меньше бит в маске, тем меньше приоритет.

Это стандартный алгоритм маршрутизации, если не используется iproute.

Есть iproute2.

Представим ситуацию: есть пользователи, которые заплатили за Интернет, и которые не платят за Интернет, но которым его нужно предоставлять.

Маршрутизатор один, и есть два канала, один толще.

Тем, кто платит, канал толще.

Если у нас исключительно ip-адресация, то очевидно, что не определим, как маршрутизировать.

Чтобы определить, куда пересылать пакет, нужно анализировать не адрес получателя, а адрес отправителя.

Это — одна из первых задач принудительной маршрутизации.

Можно принимать сведения от файрволла.

Вспомним про проблемы глобальной маршрутизации.

Если бы было дерево, то был бы «маршрутизатор всего Интернета».

Вокруг него были бы террористы.

Есть «облачка», соединенные между собой.

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

Есть автономные системы, и есть достижимость между ними.

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

Если бы не было стратегии разбиения Интернета на автономные системы и достиижимости между ними, Интернета бы не было.

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

BGP, RIP, RIP2, EGP и другие.

Их довольно много, они разной степени замшелости.

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

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

Их мало.

Там вряд ли стоит Линукс, это может быть цисковская железка.

Тем не менее есть свободное ПО, которые более-менее нормально реализуют эти протоколы.

Это не часто встречающаяся задача.

Если возникает задача настроить под Линуксом такой протокол, профессионал посидит недельку и сделает все, что нужно.

</div>