FreeSource : AfanasovDmitry/Сеть/ЯдрёныйПутьПакета

Background

С самого начала для понимания adv linux routing мне не хватало понимания, что вообще происходит с пакетов в ядре linux. Так как мне не хочется травмировать свою же психику, в код я не лез, хотя, как говорят, там «самая полная документация» :) Но то что понял постараюсь выложить здесь.

2000 Вступление

Сначала определимся, что такое пакет. Вообще есть два вида «маршрутизации» – связи двух точек. Коммутация соединений и коммутация пакетов. В первом случае у нас устанавливается физическое подключение (которое характеризуется напряжением, сопротивлением, ещё кучей радиоэлектронных понятий), и электрончики по нему бегают до обрыва соединения. Банальный пример: телефоны. Такие «маршрутизаторы» называют ещё АТС.

Во втором же случае физическое соединение присутствует постоянно, просто связующая аппаратура перебрасывает не все «электрончики» от одной соединённой точки к другой, а ещё и пытается решить на основе дополнительных данных, что несут эти самые «электрончики», в какое соединение их бросать. Это локальная сеть; и занимаются описанным делом маршрутизаторы. Ethernet Switch'и тоже в какой-то мере, так как они анализируют ethernet frame'ы для выбора порта, куда выкидывать полученный frame.

Для работы пакетной коммутации соединения уже дожны быть скоммутированы, то есть пакетная коммутация работает поверх коммутации соединений. Что означает, что ваш ethernet провод должен быть воткнут в концентратор/коммутатор (hub/switch), в другую сетевую карту; АТС должна соеденить ваши модемы; etc.

Блок данных, что содержит коммутационную информацию я обзываю пакетом. Оффициально в Cтек OSI пакетом зовётся блок tcp/ip данных. Мне же проще всё считать пакетами, кроме случаев, когда необходимо их отличать.

Как пакеты передаются в физической среде: телефонной линии, xDSL соединении, ethernet – нас не интересует. Нас интересует, что происходит в между приходом пакета на аппаратуру компьютера и выходом. То есть место <физическая линия> --> компьютер --> физическая линия.

И наконец, рассматривается только Tcp/Ip протокол. С остальными не работал, хотя давно хочу изучить netbios/smb.

Приход

Вот сетевая железка у нас зафиксировала электромагнитную активность на своём входе. (в это время она ещё бывает подмигивает :). Так как железка умная, без чего при работе с пакетами ну просто никуда, то она из этой активности вытягивает весь пакет своего уровня. В ethernet это frame, в ATM ещё что-то, в X.25 – и вообще, пусть кто другой дополнит. Сам с удовольствием почитаю :)

Как это происходит в ppp соединениях? И вообще в point-to-point соединениях ещё на физическом уровне?

То есть железка принимает нолики-единички до тех пор, пока пакет не кончится. Определяет она это, анализируя заголовок – в ethernet, например, сетевая карта анализирует первые – чтоб не соврать – 20 байт, откуда берёт адрес, кому предназначался пакет (в данном случае его зовут frame) и длину пакета. Затем считывает остальные нолики-единички, пока длина не кончится. В случае же с ppp я точно сказать не могу.

Опять вопрос: а считывает именно чипсет сетевухи или её драйвер?

Типы сетевых соединений

Происходящее далее уже зависит от типа сети (соединения). Есть два типа:

Ссылки

Откопал тут более внятную доку по организации сетей. Надо бы самому почитать: Транспортная подсистема неоднородных сетей, Модель OSI.

Анализ пакета

Хардварная (железная, канальный с физическим уровнем) часть передала наверх пришедшие данные, удалив по пути свои заголовки. Теперь то, что для уровнем ниже было данными опять расщепляется на заголовок/данные.

В ethernet frame, как я помню (надо уточнить) заголовок содержит ещё и протокол, что идёт на следующем уровне. Как ip заголовок содержит, кто идёт за ним – udp, tcp, gre. На основе того номера определяется, кто будет анализировать всё это дело дальше.

На данном этапе пакет анализируется целиком, часто вплоть до прикладного уровня – сокетов. Исключения raw sockets, что читают сразу из интерфейса. Происходит это следущим образом

Анализ tcp/ip: после расшифровки ip заголовка, запускается анализ следующего в зависимости от указанного протокола. Как происходит анализ tcз, udp, icmp нас сейчас не волнует, интересен анализ 47 (gre) и 98 (ipip). Это туннели. Здесь данные после ip заголовка просто напросто передаются заново вниз, только от имени другого интерфейса, и происходит уже анализ как бы с нуля.

Замечание к предыдущему абзацу from Черносов Денис 26.03.2008

В нескольких статьях наткнулся на разные номера протоколов для туннелей. Обратился к первоисточнику:


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

После анализа

Всё, мы проанализировали пакет, заполнили структуру skb, и вот сдесь начинается самое интересное. Для ip протокола – остальные не рассматриваем.

Netfilter hooks (iptables)

Сейчас мы сразу попадаем в netfilter.