Как работает интернет. Для анархистов (и не только). Часть 2. Маршрутизация⁠⁠

Побыстрее, увы, не получилось :(. Но наконец 2 часть готова, публикую. Также, анонс того, что планируется дальше - в планах перейти к служебным аспектам работы интернета, таким как получение адресов, распознавание имен, NAT и т.п. Еще дальше - прокси, VPN, TOR и так далее (но еще посмотрим).

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

Он делается за счет ввода адреса более высокого, 3 уровня, ip-адреса. Об этом мы и поговорим в данной статье.

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

Ниже будет рассматриваться понятие инкапсуляции.

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

Так вот, почтальонам не надо знать адрес и разбираться в каракулях кому и куда, им достаточно знать информацию — «взять в одной коробке — положить в другую». Поэтому, чтобы упростить (и ускорить) им работу, и применяется инкапсуляция — чтобы каждый участник процесса быстро и без особых затруднений находил необходимую ему информацию и мог ее изменять.

То есть вы пишете письмо на листке бумаги и кладете в конверт. На конверте пишете адрес получателя и отправителя. Далее этот конверт вы кладете во второй конверт, на котором пишете «из почтового ящика дома 8 — до коробки с письмами на почте».

Почтальон, который заберет письмо, прочитает эту инструкцию и отнесет письмо на почту. Там сортировщик возьмет письмо из коробки, откроет внешний конверт, прочитает адрес. Определит, куда его надо дальше нести, положит в новый конверт, на котором снова напишет краткие инструкции — из коробки А в коробку Б. И так далее.

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

Итак, каждому пользователю сети, помимо позывного, присваивается (процедуру присвоения адреса пока опустим) еще искусственный адрес, состоящий из двух частей — собственно, ip-адрес и маска подсети. А также вводится понятие маршрутизации.

Зачем это нужно?

Адрес (IP-адрес, адрес 3 уровня модели OSI) — это уникальный идентификатор пользователя сети (как устройства, т.е. компьютера). Фактически, когда мы в прошлой статье описывали ARP (процесс выяснения позывного, который будет использоваться для перестукивания), в качестве описания соседа-анархиста в реальных сетях выступает именно ip-адрес. То есть компьютеры не запрашивают — кто здесь Celeron с 2 гигабайтами оперативной памяти, а спрашивают — кто здесь с адресом 1.1.1.1? Ответь, какой у тебя позывной/MAC? (откуда компьютеры узнают, какой именно ip им нужен — обсудим позже).

Маска подсети — определяет, какая часть из этого идентификатора определяет не только конкретного пользователя, но и его расположение в глобальной сети.

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

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

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

Особенно это важно, когда речь идет о маршрутизаторах, о которых ниже. Когда определяется, куда пересылать сообщение, учитывается не просто кто является следующей точкой передачи (next hop), но и то, через какой интерфейс самого пользователя до этого next hop-а можно добраться.

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

Рассмотрим это на примере.

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

Пусть у нашего заключенного адрес 1.2.3.4 и маска подсети 255.255.255.0. Что это значит?

Это значит, что 1.2.3 определяют его адрес сети, а .4 — уже его адрес в этой сети (подробнее про расчет масок подсетей можно почитать здесь). И значит все пользователи с адресами 1.2.3.0-255 — находятся с ним в одной подсети.

Соответственно, если он хочет отправить сообщение на адрес 1.2.3.5, он для начала проверяет, находится ли получатель с ним в одной подсети (в данном случае - да).

Далее, раз ответ положительный, то он действует ровно по тому же алгоритму, который был описан в предыдущих статьях, то есть рассылает широковещательный запрос, чтобы узнать MAC-позывной получателя, и так далее. Только вместо описания (рыжий колченогий анархист), которое мы ранее приводили в качестве примера, выступают просто ip-адреса, которые, по сути, уникальным образом характеризуют получателя. Поскольку одинаковые ip адреса в одном широковещательном домене (на одном коммутаторе) — признак ошибки! Работать сеть так не будет или будет через раз :). Данный случай нам, на самом деле, не особенно интересен, ведь он был рассмотрен ранее.

Интереснее, что происходит в обратной ситуации, когда адрес (допустим, 5.6.7.8) лежит вне сети отправителя.

В таком случае отправитель сразу (без всяких широковещательных рассылок) обращается к своей таблице маршрутизации.

Рассмотрим самый простой случай: в ней только один маршрут — по умолчанию, который как бы говорит: все, что не знаешь, куда послать (не относится к твоей сети и нет конкретного правила-маршрута, соответствующего данному получателю) — шли сюда. И в качестве адреса, осуществляющего пересылку, указывается адрес маршрутизатора.

Что же такое маршрутизатор? Это, условно говоря, еще один заключенный, который имеет интерфейсы-трубы (и адреса) в разных подсетях и осуществляет передачу из одной подсети — в другую. Пусть его MAC-позывной такой и будет - Маршрутизатор.

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

А вот тут начинается интересное. Дальше отправитель смотрит в свою arp-таблицу, где, как вы помните, у него записаны соответствия описаний-ip-адресов и MAC-позывных. Допустим, у него есть уже соответствие для адреса 1.2.3.1 (если нет, пойдет ARP, описанный в предыдущих статьях).

Тогда он формирует пакет следующим образом.

Упаковывает (инкапсулирует) данные, добавляет к ним заголовок 3 уровня.

В заголовке 3 уровня (т.е. где описания-адреса) пишет: отправитель - 1.2.3.4, получатель - 5.6.7.8

Полученный пакет упаковывает еще раз, добавляя к ним заголовки 2 уровня.

В них пишет: отправитель - Редиска (т.е. собственный позывной). Получатель - Маршрутизатор (т.е. MAC-позывной маршрутизатора из своей ARP-таблицы, не конечного получателя!).

И передает.

Что происходит далее?

Коммутатор (как мы помним, это отдельное устройства-заключенный, которое осуществляет пересылку сообщений между камерами внутри одной подсети), получив пакет, смотрит заголовки 2 уровня. И видит вполне конкретного получателя (Маршрутизатор), которому и передает данные, определив порт по FIB (таблице соответствия MAC-позывных и портов-труб).

Поскольку получатель этот и есть Маршрутизатор, то он видит в заголовке 2 уровня себя и принимает пакет. Для дальнейшей обработки распаковывает его и смотрит заголовки 3 уровня. И видит, что получателем указан некто 5.6.7.8, то есть не он. Но поскольку Маршрутизатор — маршрутизатор, он не выбрасывает этот пакет (как поступил бы любой другой компьютер-заключенный (за исключением стукачей-снифферов, которые записывают даже данные, предназначенные не им)), а начинает определять, куда же ему это сообщение переотправить.

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

Допустим, он находит у себя маршрут, который говорит, что подсеть 5.6.7.0/24 (эта запись обозначает адреса 5.6.7.0-255 и аналогична маске 255.255.255.0) находится на узле 8.9.0.1.

После этого маршрутизатор снова запаковывает пакет, добавляя к нему новые заголовки 2 уровня (заголовки 3 уровня остаются без изменений!).

В итоге в заголовках вторго уровня получается следующее. Отправитель — Маршрутизатор (он сам). Получатель — Маршрутизатор2 (позывной маршрутизатора с адресом 8.9.0.1, который Маршрутизатор получает из своей ARP-таблицы или путем ARP-запроса).

После чего Маршрутизатор передает это сообщение через свой интерфейс (с адресом, допустим, 8.9.0.2), который смотрит в подсеть, содержащую в себе адрес 8.9.0.1 (т.е. не через тот же, через который сообщение было получено).

Далее повторяется схема описанная выше — коммутатор принимает, смотрит заголовки 2 уровня, передает в нужный порт . Тут, в принципе, надо сказать, что два маршрутизатора могут быть соединены и напрямую (труба идет от одного к другому без промежуточных камер), и коммутатор будет не нужен. Просто второй маршрутизатор сразу начнет распаковывать данные, без дополнительной передачи. Маршрутизатор2 принимает пакет в соответствии с заголовками 2 уровня (т.е. что получатель он) — распаковывает, смотрит на заголовок 3 уровня. И видит, что пакет предназначен не ему лично, но должен быть передан дальше.

Допустим, наша искомая сеть 5.6.7.0/24 — подключена к Маршрутизатору2 напрямую. Тогда он определяет MAC получателя по ARP-таблице, пакует данные заголовком 2 уровня, где отправитель — он сам, а получатель — уже позывной реального получателя (Сосиска), и передает.

Пользователь 5.6.7.8 (он же Сосиска), получив пакет, видит заголовок 2 уровня и понимает, что это ему. Распаковывает, видит свой ip-адрес и еще раз убеждается, что это ему. И начинает читать данные.

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

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

На практике, конечно, никто не делает бесконечные сети, поскольку тут также, как и в коммутаторах, может возникнуть зацикливание, когда ввиду определенной настройки маршрутов пакет будет бесконечно перемещаться между маршрутизаторами. Для защиты от этого придуман механизм TTL (Time to live - время жизни): при отправке в заголовок третьего уровня добавляется счетчик времени жизни пакета (как правило, 255). Каждый маршрутизатор, когда осуществляет пересылку, уменьшает этот счетчик на 1. Когда TTL достигает 0, маршрутизатор, на котором это произошло, просто удаляет сообщение.

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

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

То есть, выше мы рассматривали подсеть 1.2.3.0/24. Однако к одному маршрутизатору (номер 1) могут быть подключены, например, подсети 1.2.0.0/24, 1.2.1.0/24, 1.2.2.0/24 ….1.2.255.0/24. И тогда на соседнем маршрутизаторе маршрут, указывающий, какие сети доступны через маршрутизатор 1, будет нужен всего один — 1.2.0.0/16 (а не 256 маршрутов), поскольку эта подсеть включает в себя все вышенаписанные. То есть благодаря подсетям можно осуществлять суммирование маршрутов.

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

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

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

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

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

В отличие от ip-адреса, который является абсолютно искусственным конструктом и может быть любым — MAC-адрес является физической характеристикой оборудования. То есть современное оборудование в большинстве случаев позволяет подменять его. Но если это не было сделано, то, зная MAC (зафиксировав на коммутаторе факт обращения с одного порта на другой отправителя с определенным MAC-ом) и получив доступ к оборудованию (компьютеру) и сверив MAC-адрес — можно (хоть и шатко) пришить это оборудование к делу.

Но, как мы написали выше — получатель (или любой промежуточный маршрутизатор, кроме первого) не знает вашего MAC-а, в отличие от IP. И, следовательно, чтобы его выяснить (для привязки вашего компьютера к делу), он должен проследить ваш IP до первого маршрутизатора (который даст MAC-адрес из своей ARP-таблицы) и точки физического подключения к сети (коммутатора) (он даст порт).

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

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

Тут важно заметить, что, разумеется, одной этой особенности маршрутизации абсолютно недостаточно для того, чтобы считать себя анонимным и защищенным в сети Интернет. ЭТО НЕ ТАК! Но именно дальнейшее развитие принципа инкапсуляции, позволяющего скрывать MAC-адрес от промежуточных устройств, позволяет таким средствами как TOR или VPN обеспечивать анонимность активистам. Но о них мы поговорим отдельно.

Также отметим, что мы, разумеется, рассмотрели далеко не все аспекты коммутации. Пропущены виртуальные частные сети (VLAN), различие между портами доступа и транковыми (на коммутаторах), технологии DTP и еще очень многое. По большому счету, это сделано сознательно — основной целью было обозначить какие-то общие моменты функционирования компьютерных сетей, понимая которые можно оценивать, в первую очередь, именно прикладные аспекты использования сети Интернет как средства связи с точки зрения обеспечения безопасности и анонимности. А также, при желании, использовать этот базис для уже более углубленного и подробного изучения функционирования компьютерных сетей.

-----------------------------------------------------------------

Свои статьи я публикую также на сайте,

в группе Вконтакте

и Телеграмм-канале - если кому то вдруг будет удобнее подписаться там :-).