Всем привет! Современные роутеры, продающиеся в сетях (Asus/D-Link/Tp-Link/Keenetic (они же ЗУХЕЛЬ)) не предполагают слежения за трафиком. Максимум можно ограничить трафик по разным критериям. Так же есть различные Microtik/Tenda, которые имеют более широкие возможности.
А есть ли роутеры с записью посещенных сайтов? Или есть ли устойчиво работающие сервисы, которые можно было бы прикрутить к роутеру таким образом, что бы знать, какие были запросы с конкретного устройства из подключенных к сети?
Продолжение поста о видах устройств в IP, если вы не смотрели первую часть, то рекомендую сперва перейти туда, а затем уже читать здесь. Вопросы, замечания, дополнения и уточнения только приветствуются.
В этой части мы посмотрим на то, как отправители и получатели будут взаимодействовать друг с другом в том случае, когда между ними стоят роутеры, т.е. в тех случаях, когда узлы находятся в разных канальных средах или другими словами в разных подсетях.
Взаимодействие отправителя и получателя через роутеры
Далее мы будем работать с верхней частью схемы.
Пинг c PC0 к PC1 в режиме реального времени
Не будем рассматривать детально, что делают отправители и получатели, а также не будем рассматривать, что делают все транзитные узлы, кроме RO2, на нем и остановимся детально. Плюс, как видите, я изначально в режиме реального времени выполнил пинг, сделано это было, чтобы не смотреть на работу протокола ARP, который в данном случае должен отработать между каждым линком каждого устройства, представленного на схеме.
Сделаю небольшое пояснение, на рисунке выше показано, что я планирую пинговать с узла PC0 узел PC1, но по факту я пинговал адрес 10.2.2.1, который настроен на роутере RO3 на интерфейсе в сторону PC1, надеюсь, никто за это не осудит.
Понятно, что сперва отправитель PC0 должен будет сформировать IP-пакет в сторону получателя, здесь мы также сильно не мудрим и используем команду ping. Вся разница с первым случаем в том, что PC0 направит пакет не сразу к получателю (по факту это RO3), а в сторону транзитного узла RO1, т.е. PC0 должен будет изучить мак-адрес RO1 и выбрать тот интерфейс, который ведет к RO1, различия сетевого уровня у отправителя при отправке пакета сразу получателю и для случая, когда пакет посылается транзитному узлу представлены ниже.
Сетевой уровень узла отправителя для случая, когда получатель в другой подсети
Запускается процесс Ping.
Создается сообщение ICMP Echo Request и отправляется нижележащему процессу.
При пинге не была задан явно IP-адрес источника, поэтому узел выбрал наиболее оптимальный адрес с его точки зрения.
И вот здесь начинается разница. Узел видит, что адрес, который надо пинговать, находится в другой подсети, а это означает, что надо прибегнуть к помощи роутера.
Благо, что адрес роутера, который может помочь доставить пакет в пункт назначения, по мнение узла PC0, задан в качестве шлюза по умолчанию(defalut gateway или DG).
Маршрут по умолчанию, шлюз по умолчанию, DG. Пока по-простому... Это инструкция для узла: если у тебя нет точной информации куда направить пакет, направляй его узлу, который у тебя задан шлюзом по умолчанию.
Описание происходящего на канальном и физическом уровнях узла PC0 мы пропускаем, как и полностью пропускаем действия RO1. В итоге нам важно, что RO1 получил пакет от PC0 и передал его RO2.
На маршрутизаторе RO2 физические порта подключены так:
FastEthernet8/0 к RO1
FastEthernet7/0 к RO3
FastEthernet9/0 к коммутатору
На физическом уровне RO2 просто принимает битовую последовательность в порт Fa8/0 и формирует из нее кадр, который передается на L2.
Что делает RO2 на канальном уровне при приеме пакета
RO2 убеждается, что мак-адрес назначения в кадре принадлежит ему.
А это значит, что кадр можно вскрыть, посмотреть что внутри и как-то эти внутренности обработать.
После вскрытия на канальном уровне внутри обнаруживается IP-пакет и в дело вступает сетевой.
Что делает RO2 на сетевом уровне при приеме пакета
В CPT описание скромное, немного дополню: транзитный роутер не снимает IP-заголовок пакета, в данном случае он лишь смотрит на поле, в котором хранится IP-адрес назначения, запоминает адрес назначение и начинает проверять: а есть ли этот адрес в его таблице маршрутизации. В ходе этой проверки может возникнуть разные ситуации, например:
Этот адрес настроен на его интерфейсе, тогда заголовок будет снят для дальнейшего анализа.
Этот адрес будет принадлежать соседу, который подключен к одному из интерфейсов роутера, тогда роутер пошлет пакет непосредственно ему.
Этот адрес будет доступен через другой транзитный узел, тогда адрес будет послан непосредственно ему.
У роутера может не быть никакой информации о сети, в которой находится данный адрес, такой пакет будет уничтожен.
Подумайте: какой из пунктов описывает данную ситуацию?
В итоге RO2 понял, что IP-адрес ему не принадлежит и нужно понять, куда отправлять пакет, для этого он смотрит в таблицу маршрутизации. Нам сейчас не важно как роутер это делает, важно только то, что из таблицы маршрутизации роутер может достать информации об интерфейсе, в который надо направить пакет, либо IP-адрес соседа по канальной среде, в сторону которого пакет нужно направить.
Что делает RO2 на сетевом уровне при отправке пакета следующему узлу
Здесь нам поясняется:
RO2 нашел по таблице маршрутизации какой маршрут соответствует IP-адресу назначения, а также был установлен IP-адрес соседа, в сторону которого следует направить пакет.
И изменил значения поля TTL (TTL это число, которое задает узел отправитель, RO2 отнял от него единицу).
Пакет был передан канальному уровню.
Что делает RO2 на канальном уровне при отправке пакета следующему узлу
На канальном уровне:
Роутер начинает понимать, что IP-адрес соседа (next-hop IP), которому нужно направить пакет, является юникастовый, а значит надо запустить ARP (next-hop IP это не IP-адрес назначения, а именно адрес соседа, которому пакет будет передан).
Протокол ARP в своей таблице нашел соответствие между IP-адресом и мак-адресом соседа.
Пакет запаковался в Ethernet кадр.
Кадр спускается на физический уровень. Здесь определяется интерфейс (Fa7/0), через который пакет будет послан следующему транзитному узлу, а кадр превращается в последовательность нулей и единиц.
Как помните, я совершил ошибку и начал пинговать узел RO3. На самом деле это даже неплохо, так как появилось несколько моментов, которые я бы обязательно упустил.
RO2 при передачи пакета в сторону RO3 считает, RO3 следующим транзитным узлом, а не конечным получателем. Вопрос: почему он так считает? На самостоятельный разбор.
RO3 является конечным получателем, но пакет к нему приходит на один интерфейс (который направлен на RO2), а PC0 пингует интерфейс RO3, которым RO3 соединяется с PC1. Давайте посмотрим, что происходит на RO3.
У RO3 интерфейсы распределены так:
Fa6/0 в сторону RO2
Fa7/0 в сторону компьютера
Канальный и физический уровни RO3 смотреть смысла нет, там ничего нового, смотрим сразу в сетевой:
Сетевой уровень при приеме пакета на RO3
Роутер понимает, что IP-адрес назначения, указанный в принятом пакете, настроен на одном из его интерфейсов, поэтому надо вскрыть пакет, понять какому процессу его передать и сделать это (в смысле передать).
Вскрытие показало ICMP вложение, значит данные надо передать процессу ICMP.
Процесс ICMP понимает, что это сообщение Echo Request.
А значит надо понять чего и как отвечать, смотрим сетевой Out Layers.
Сетевой уровень RO3 при ответе на запрос
Процесс ICMP понимает, что отвечать надо сообщением Echo Reply.
ICMP процесс его и генерирует.
IP подхватывает данный Reply и накрывает своим заголовком.
В пакете есть IP-адрес назначения, это адрес узла PC0, роутеру надо по таблице маршрутизации найти маршрут для этого адреса, чтобы понять куда слать пакет.
Когда маршрут найден, пакет передается канальному уровню, также канальному уровню передается информация о IP-адресе соседа транзитного узла, которому пакет нужно направить.
Все дальнейшие действия были описаны уже не раз. Посмотрим лишь на результат: когда пакет дошел до PC0.
PC0 получил ICMP ответ
Ниже представлены результаты первого пинга, который был сделан в режиме реального времени и второго пинга, который мы рассматривали в симуляции.
C:\>ping 10.2.2.1
Pinging 10.2.2.1 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 10.2.2.1: bytes=32 time=4ms TTL=253
Reply from 10.2.2.1: bytes=32 time<1ms TTL=253
Ping statistics for 10.2.2.1:
Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 4ms, Average = 2ms
C:\>ping 10.2.2.1
Pinging 10.2.2.1 with 32 bytes of data:
Reply from 10.2.2.1: bytes=32 time=6ms TTL=253
Reply from 10.2.2.1: bytes=32 time=3ms TTL=253
Reply from 10.2.2.1: bytes=32 time<1ms TTL=253
Reply from 10.2.2.1: bytes=32 time<1ms TTL=253
Ping statistics for 10.2.2.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 6ms, Average = 2ms
C:\>
Вопросы
Если решите по отвечать на представленные ниже вопросы, предлагаю давать их под комментарием, который я оставлю под этим постом для ответа на вопросы.
Как мак-адрес РС2 оказался в ARP таблице PC3, если PC3 не делал ARP запрос чтобы узнать мак-адрес РС2 (вопрос по первой части)?
Куда потерялись пакеты при первом пинге от PC0 до RO3.
Как узлы в примерах понимают, что из полученных битов нужно слепить Ethernet кадры а не кадры какого-то другого протокола?
Какой порт слушает узел получатель для приема ICMP?
За счет чего ARP запрос получают все соседи по канальной среде?
Нужен ли будет ARP, если на канальном уровне будет не Ethernet, а какой-то другой протокол?
Важно понимать, что IP это не только пакет и адрес, но и устройства, на которые эти самые адреса назначаются, чтобы затем генерировать, пересылать или же принимать пакеты, о устройствах и поговорим далее. На Пикабу есть ограничение: пост не может иметь больше 25 картинок, в ходе его подготовки это ограничение было немножечко превышено мной, поэтому он разделен на две части.
Первая часть содержит в себе теорию, плюс здесь мы посмотрим на взаимодействие двух оконечных IP узлов в тех случаях, когда им для этого взаимодействия роутер не требуется.
Для общего представления о работе IP теории будет достаточно, для того чтобы проникнуться лучше самостоятельно собрать и повторить лабу в Cisco Packet Tracert(далее для краткости CPT), внимательно посмотреть где и какие адреса меняются, подумать(с гуглом или яндексом) почему это происходит. Вопросы, замечания, дополнения и уточнения только приветствуются.
Виды устройств в IP
Устройства в IP делятся на два вида:
Конечные или терминальные узлы, для краткости я их буду называть хосты, они могут отправлять и получать пакеты, в некоторых случаях устройство может либо только получать, либо только отправлять пакеты. Хосты описаны в RFC1122.
Транзитные узлы или роутеры, как правило, к таким узлам мы не обращаемся напрямую, их задача направлять пакеты в ту или иную сторону.
Протокол IP – это протокол сетевого уровня, любые сетевые устройства должны быть соединены каналами, канальная среда может быть любой, но чаще всего на канальном уровне мы работаем с Ethernet.
Задачи узла отправителя
Начнем с хостов и с их возможности генерировать пакеты и направить их в сеть, вот что делает устройство для отправки пакета:
Пакет нужно сформировать, следует сказать, что IP-пакет состоит из двух частей: заголовка, в котором находится вся необходимая информация для обработки пакета узлами компьютерной сети и поля данных. Сам IP никаких данных не генерируют, процесс IP получает данные от вышестоящего процесса, если вышестоящим процессом является транспортный уровень, то обычно это такие протоколы как UDP, TCP, SCTP, но вышестоящим процессом может быть и протокол сетевого уровня, например, протокол ICMP, который используется когда мы хотим чего-нибудь попинговать. Кто бы ни был вышестоящим процессом его данные помещаются в соответствующее поле данных в пакете, а затем накрываются заголовком.
Вторым шагом отправитель должен решить какому соседу по канальной среде нужно передать пакет, чтобы он дошел до получателя. Если получатель в одной канальной среде с отправителем, то пакет будет передан непосредственно ему. Если же получатель находится в другой подсети, то пакет будут передан транзитному узлу, который дальше будет принимать решение о том что делать с пакетом.
Отправитель может иметь один или несколько интерфейсов, которыми он подключен к сети, поэтому ему нужно выбрать интерфейс, в который пакет будет направлен, выбор будет зависеть от результатов второго шага, а затем нужно определить канальный адрес соседа, которому пакет будет отправлен. Если получатель в одной канальной среде с отправителем, то определяется канальный адрес получателя, если получатель и отправитель в разных подсетях, то отправитель определяет канальный адрес транзитного узла, которому пакет будет передан. Если на канальном уровне Ethernet, то определяется мак-адрес, за узнавание мак-адресов соседей отвечает протокол ARP.
И наконец IP-пакет запаковывается в кадр канального протокола, далее кадр превращается в битовую последовательность, которая направляется в сеть через выбранный интерфейс.
Вроде бы никаких хитрых действий отправитель не совершает.
Задачи узла получателя
Задачи получателя несколько более простые:
Пакет нужно получить и убедиться в двух вещах:
Получатель должен убедиться, что именно он является получателем.
А также проверить корректность полученных данных.
Далее данные передаются вышестоящему процессу, который уже решит что с ними делать.
Если получатель сочтет нужным, то он в дальнейшем может послать ответ отправителю.
Задачи маршрутизатора (транзитного узла)
Роутеры самые сложные устройства с точки зрения IP, выполняющее самый большой объем работы. В их задачи входит:
Получить пакет (пакет может прийти как от непосредственно отправителя, так и от другого роутера, маршрутизатору это не важно, т.к. зачастую судьба пакета определяется только IP-адресом получателя, указанным в заголовке). Роутер должен убедиться в корректности полученных данных, а также в том, что он не является конечным получателем.
Далее требуется определить какому из соседей по канальной среде следует передавать пакет. Если роутер в одной канальной среде с получателем, то пакет будет передан непосредственно ему, если же нет, то следующему транзитному узлу.
Как и в случае с узлом отправителем, роутер определяет свой интерфейс, в который будет послан пакет, а также канальный адрес соседа.
Если требуется модификация пакета, то пакет модифицируется, а затем отправляется в выбранный интерфейс.
Для проверки корректности заголовка у пакета есть контрольная сумма, а чтобы понять, что ты не являешься конечным получателем достаточно сравнить IP-адрес назначения в пакете со своими IP-адресами и если они не совпадают, то направить пакет дальше.
Важно понимать, что описанные роли никак не ограничивают устройства, одно и то же устройство может быть: отправителем, получателем и транзитным узлом. Для примера возьмем ваш домашний роутер: когда вы выходите в интернет, это транзитный узел, когда вы подключаетесь к роутеру, чтобы его настроить, он становится хостом, который отправляет и принимает пакеты.
Обратное утверждение тоже справедливо: устройство не обязано реализовывать сразу все три функции, например, различного рода дешевые датчики мониторинга могут только посылать пакеты.
Топология и подготовка лабы
С теорией всё, давайте соберем простенькую лабу и посмотрим на IP устройства в эмуляторе. Для практики по данной теме буду использовать CPT. Пока мы ничего не будем настраивать, просто посмотрим, что эмулятор будет нам рассказывать о действиях узлов.
В целом я бы не рекомендовал для обучения использовать CPT, в данном случае я его использую для наглядности. Если производительность вашего ПК позволяет, присмотритесь к GNS3 или EVE-NG, второй эмулятор более предпочтительный. Есть еще pnetlab, говорят он даже по-лучше EVE-NG будет. Если нужен онлайн эмулятор, можно попробовать онлайн сервис СПбГУ: https://miminet.ru/
Схема, на которой будем тренироваться выглядит так:
Топология лабы. Если будете настраивать самостоятельно, то не забудьте отключить на роутерах CEF+настроить маршрутизацию.
Пояснения к схеме:
Оранжевым обведены хосты.
Зеленым роутеры.
Синим коммутатор, в данном случае мы его не рассматриваем как IP-устройство, сейчас можно представить, что это не коммутатор, а связка проводов, которая соединяет PC2, PC3 и RO2 вместе.
На топологии, обведенной фиолетовым, мы посмотрим как два хоста взаимодействуют напрямую, а на участке, обведенном серым, мы посмотрим на взаимодействие хостов через транзитные узлы. Начнем с прямого взаимодействия.
У CPT есть два режима работы: режим реального времени и режим симуляции, в котором можно отследить каждое действие и отследить каждый пакет. Заглянуть внутрь пакетов и получить описания действий узлов можно в режиме симуляции.
Лабу нужно перевести в режим симуляции, а затем настроить фильтр пакетов, которые мы хотим видеть, всё это можно сделать кнопками в правом нижнем углу программы.
Кнопка Simulation для перевода в режим симуляции, кнопка "Edit Filters" чтобы отключить лишние для нас пакеты. Оставляем только ICMP и ARP.
Кнопка Edit Filters отвечает за появление окна на скрине выше, на вкладках IPv6 и Misc тоже нужно отключить отображение всех прочих пакетов.
Я сознательно не останавливался на детальном описание интерфейса CPT, сам он нам не интересен, да и гайдов по его использованию в этих ваших интернетах тьма темная.
Взаимодействие отправителя и получателя
Начнем с более простого, то есть с той ситуации, когда отправитель и получатель находятся в одной канальной среде. На схеме между PC2 и PC3 есть коммутатор, но для IP он полностью прозрачный, можно считать что этих два устройства с точки зрения IP соединены напрямую проводом.
Выполним пинг с PC2 на PC3, нужно открыть командную строку PC2 сделать это можно так:
В топологии кликаем на иконку PC2.
Появится окно, в котором нужно будет выбрать вкладку Desktop.
На вкладке Desktop выбираем иконку Command Prompt.
Интерфейс компьютера в CPT
После этого у нас появится командная строка, в ней мы пишем: ping 192.168.0.1. В данном случае мы смотрим на прямое взаимодействие отправителя и получателя, они находятся в одной подсети, а значит и в одной канальной среде, а это всё означает, что таким узлам не нужны посредники в виде роутеров.
PC2 сформировал пакеты
После того, как мы ввели команду и нажали Enter, PC2 сформировал два пакета:
Синий, это как раз тот пакет, который нас интересует, то есть ICMP.
Зеленый, это кадр с ARP запросом, он нам не интересен, сейчас нам лишь важно понимать, что протокол ARP поможет PC2 узнать канальный адрес узла PC3, в данном случае это мак-адрес.
Посмотрим содержимое синего пакета, клацнув в него.
Содержимое ICMP пакет и описание того как его обрабатывает отправитель на сетевом уровне.
Появившееся окно имеет две вкладки: OSI Model и Outbound PDU Details. Нам интересна первая, вторую даже смотреть не будем, на ней представлена детальная информация о структуре кадров и пакетов, она нам сейчас не интересна.
На вкладке OSI можно по шагам посмотреть что делает тот или иной узел при приеме или отправке пакета. За прием отвечает In Layers, за передачу отвечает Out Layers. Как видите, каждая половина разбита на семь уровней, это семь уровней модели OSI, если шрифт уровня тускло серого цвета, значит на нем ничего не происходит, если шрифт черный, значит на этом уровне что-то происходит и он кликабельный, переключаться между уровнями можно еще и кнопками Previous Layer/Next Layer.
Сетевым инженерам обычно интересны уровни с транспортного и ниже, то есть Layer 1 - Layer 4, если мы смотрим на окно CPT. Ниже я приведу синонимы каждого Layer, которые обычно используются:
Layer 1 = L1 = Физический уровень
Layer 2 = L2 = Канальный уровень
Layer 3 = L3 = Сетевой уровень
Layer 4 = L4 = Транспортный уровень
На рисунке выше CPT нам показывает, что делает узел отправитель(PC2) на сетевом уровне :
PC2 запустил процесс Ping сразу после того, как мы выполнили команду ping.
Процесс Ping создает сообщение ICMP Echo Request и отправляет его нижележащему процессу. Здесь следует пояснить, что ICMP и IP это протоколы сетевого уровня, но для ICMP процесс IP это нижележащий процесс.
Отправитель должен подставлять в пакет свой IP-адрес, чтобы обратная сторона могла ответить, если она сочтет это нужным. При выполнении команды ping не был задан IP-адрес, поэтому устройство выбрало адрес само (оптимальный на взгляд устройства, хотя по факту он там настроен один).
PC2 установил, что IP-адрес узла получателя находится с ним в одной подсети, а также в пакет был добавлен IP-адрес узла получателя.
А вот что CPT нам может рассказать о канальном уровне.
Что происходит на канальном уровне
Важный момент: в примере на канальном уровне у нас работает Ethernet, за связку сетевого и канального уровня в случае IP/Ethernet используется протокол ARP.
На канальном уровне:
Узел PC2 определил, что IP адрес получателя юникастовый, а это значит, что узел должен знать или определить мак-адрес получателя. Чтобы определить канальный адрес соседа узел запустил процесс ARP.
Первым делом ARP проверил свою таблицу, чтобы найти: какой мак-адрес соответствует IP-адресу, который мы пингуем (192.168.0.1), но такого соответствия он не обнаружил, поэтому PC2 сформировал ARP-запрос и сохранил ICMP пакет в свой буфер(то есть на текущем шаге синий пакет отправлен никуда не будет).
На физическом уровне пока ничего не происходит, нам нужно перевести симуляцию на следующий шаг. Сделать это можно в правом нижнем углу экрана на соответствующей панели.
Управление симуляцией
Кнопка Play запустить симуляцию в автоматическом режиме, левая кнопка это шаг назад, правая кнопка шаг вперед. Автоматический режим нам не интересен, перейдем на следующий шаг. Следующих несколько шагов покажут нам как по сети гуляет ARP, сейчас мы не будем детально разбираться с тем, как работает ARP, для этого будет отдельная тема, сейчас нам важно понимать две вещи:
ARP-запрос PC2 использует, чтобы изучить канальный адрес соседа, в сторону которого должен быть отправлен пакет с ICMP.
ARP-запрос получат все соседи PC2 по канальной среде, но ответ даст только тот сосед, чей IP-адрес будет указан в ARP-запросе, все остальные проигнорируют этот ARP-запрос. И тут два момента: если соседей с таким IP нет, то никто и не ответит; если сосед с таким адресом есть, то он ответит, в ответе будет содержаться его мак-адрес.
Вот что по этому поводу нам показывает CPT:
Соседние узлы получили ARP-запрос
Узел RO2 получил запрос и проигнорировал его, это видно по красному крестику, а вот узел PC3 готов ответить на запрос. Что делает PC3 для отправки ARP мы пропустим, но в итоге мы приходим к той ситуации, что узел PC2 получил ARP ответ и изучил мак-адрес соседа, в сторону которого надо отправить пакет.
Зеленый пакет ниже это и есть ARP-ответ PC3, а синий пакет, это тот ICMP, который ранее был спрятан в буфер.
Узел PC2 получил ARP-ответ от узла PC3, тем самым изучил его канальный адрес
Давайте рассмотрим дальнейшие действия PC2, уже после того, как он изучил мак-адрес нужного соседа.
Узел PC2 изучил мак-адрес соседа и отправляет пакет
Напомню, что остановились на том, что у канального уровня не было мак-адреса соседа, в сторону которого надо было посылать пакет, теперь мы этот адрес знаем, поэтому:
ICMP пакет был извлечен из буфера для дальнейшей обработки.
PC2 инкапсулирует(помещает/запаковывает) IP пакет, внутри которого ICMP, внутрь Ethernet кадра.
И тут мы видим что физический уровень стал кликабельным.
Что происходит на физическом уровне
А на L1 мы видим, что отправитель выбрал свой интерфейс, через который он будет готов послать сообщение в сеть, на физическом уровне Ethernet кадр превращается в последовательность бит.
Пакет пройдет коммутатор и на нем мы не будем останавливаться, для нас там ничего интересного нет. Посмотрим на пакет, пришедший к получателю.
Пакет пришел к получателю
Здесь мы видим изменения:
1. На вкладке OSI появилось описание того, что происходит на приеме, т.е. теперь у нас информация по In Layers и Out Layers.
2. Вкладок PDU Details тоже стало две.
Сейчас мы не будем заходить на вкладку из пункта два. Что касается первого пункта: PC3 должен сперва принять пакет, т.е. выполнить действия получателя, они описаны под заголовком In Layers, а затем он должен будет дать ответ, т.е. PC3 становится отправителем, что он делает для ответа описано под заголовком Out Layers.
Также вы могли заметить что прием выполняется снизу вверх, а передача наоборот, сверху вниз. PC3 на физическом уровне получает битовую последовательность по порту FastEthernet0 и превращает ее в кадр Ethernet. Переходим на канальный уровень.
Действия узла на канальном уровне при приеме пакета
Здесь узел PC3 убеждается:
Что мак-адрес это мак-адрес, который присвоен одному из интерфейсов PC3, либо это широковещательный мак-адрес, любо это мак-адрес многоадресной рассылки, на который должен отвечать PC3. По факту в данном случае мак-адрес юникастовый и он принадлежит PC3.
Ввиду того, что мак-адрес назначения, указанный в кадре, принадлежит PC3, можно снять Ethernet заголовок и заглянуть и обнаружить под ним IP-пакет.
Переходим на сетевой уровень.
Сетевой уровень при приеме пакета
Здесь происходит следующее:
PC3 убеждается, что пакет направлен именно ему, а не кому-то другому, поскольку он видит что адрес назначения в пакете совпадает с тем, что настроен на его интерфейсе, либо широковещательный, либо из диапазона многоадресной рассылки в которой данный узел заинтересован. В нашем случае адрес назначения в пакете настроен непосредственно на PC3, а это значит, что можно снять заголовок IP и посмотреть что в пакете.
Внутри пакет обнаружилось ICMP вложение, которое надо передать процессу ICMP.
ICMP процесс установил что тип полученного сообщения это ICMP Echo Request, на который нужно дать ответ.
И вот мы на границе, когда один и тот же узел превращается из отправителя в получателя. Посмотрим, что делает PC3 для отправки ответа, ответ начинает формироваться на сетевом уровне и спускается вниз к физическому.
Узел PC3 готовит ICMP Reply, сетевой уровень
Действия узла такие:
ICMP процесс решает что на данный Request следует ответить сообщением типа ICMP Echo Reply.
Сообщение Echo Reply отправляется процессу IP.
Узел видит, что IP-адрес назначения находится в одной подсети с ним, а значит пакет можно отправлять непосредственно получателю.
ICMP вложение накрывается IP заголовком и передается на канальный уровень.
Действия PC3 на канальном уровне
PC3 установил что IP-адрес назначения юникастовый, а значит надо запустить ARP процесс для того, чтобы узнать канальный адрес соседа.
Мак-адрес соседа находится в ARP-таблице, поэтому в дальнейшем в Ethernet-кадр в поле мак-адрес назначения будет подставлен мак-адрес, соответствующий IP-адресу 192.168.0.2, взятый из ARP-таблицы.
IP-пакет накрывается Ethernet-заголовком, тем самым формируется Ethernet кадр.
На физическом уровне ничего интересного нет, PC3 для отправки выбрал интерфейс Fa0, превратил кадр в битовую последовательность, которая и была направлена в сеть. В итоге ответ PC3 дойдет до PC2 и когда PC2 получит этот ответ, произойдет изменение в командной строке, появится диагностическая информация о том, что узел PC3 доступен.
ICMP пришел на PC2
Исходный отправитель превратился в получателя. Получение пакета на канальном и физическом уровнях для PC2 ничем не будут отличаться от действий на PC3, поэтому оставляю этот момент без комментариев. Вот что происходит на сетевом уровне уровне:
Действия PC2 на сетевом уровне при получении пакета
Первым шагом PC3 видит, что пакет принадлежит ему, а значит, надо снять IP заголовок.
Под заголовком обнаруживается ICMP вложение, оно предается ICMP процессу.
ICMP процесс видит, что это Reply на Request, посланный ранее.
Процесс Ping получает от ICMP сообщение Echo Reply, в этом сообщение содержится диагностическая информация, которая затем отображается на экране командной строки.
По умолчанию в CPT хосты отсылают четыре пакета, чтобы не ждать симуляцию, я перевел лабораторную работу в режим реального времени и дождался когда команда завершит свою работу.
Пинг завершен
По итогу:
Мы более детально рассмотрели, как взаимодействуют отправители и получатели пакетов без участия транзитных узлов в случае, когда на канальном уровне работает Ethernet.
Поверхностно разобрались с тем, как связаны канальный и сетевой уровни.
И убедились, что функции отправителя и получателя может выполнять одно и то же устройство.
Их есть у нас! Красивая карта, целых три уровня и много жителей, которых надо осчастливить быстрым интернетом. Для этого придется немножко подумать, но оно того стоит: ведь тем, кто дойдет до конца, выдадим красивую награду в профиль!
Для ЛЛ: Тут о роутерах Keenetic, Python и ChatGPT.
Как полноценно пользоваться VPN разделяя при помощи роутера трафик на тот, что должен идти напрямую и тот, что должен ходить через VPN туннель на основании доменного имени, т.е. адресе сайта, без необходимости постоянно лазить в админку и что-то там шаманить?
Можно воспользоваться готовыми решениями типа KVAS, xKeen, ADGh и т.п. или каким-нибудь облачным «Hosted Router». Но что если железо домашнего роутера подкачало, а открыв админку облачного роутера становится понятно, что ничего не понятно?
Так со мной и случилось. В моем распоряжении скромный роутер Keenetic Air, он хорош для своих задач, но у него на борту мало памяти и нет USB порта, из-за чего невозможно использование необходимых мне готовых решений на основе OPKG пакетов.
Но делать, что-то надо и мелькнула мысль - а почему бы не попробовать найти какое-то более-менее подходящее решение и подстроить его под себя?
Однако, с попыткой разобраться в исходном коде программ других людей пришло понимание, что это просто безнадежно и проще будет сделать что-то самостоятельно, постепенно вникая в процесс и принципы работы всего этого сетевого добра.
Никогда не считал себя программистом, у меня есть лишь базовый опыт работы с командной строкой в Win и Unix системах, разве что когда-то давно я владел ZX Spectrum c его вариацией Basic... С этим, безусловно «солидным» багажом я и решил попробовать.
Не обладая опытом программирования, пришлось обратиться за помощью к ChatGPT. Это был довольно занятный процесс, при всей мощи искусственного интеллекта, какой промт ему не напиши, он не выдаст результат на 100% соответствующий твоим ожиданиям и уж тем более готовое и полностью функционирующее решение, но тем не менее он помогает облегчить задачу тысячекратно.
Результатом такого совместного труда стал DNSmasq сервер на Python который выступая промежуточным звеном между конечным устройством (роутером или ПК) и публичным DNS сервером закидывает в роутер статические маршруты к указанным пользователем доменам, для перенаправления к ним траффика через VPN подключение.
Видео с демонстрацией:
Во избежание случайного возбуждения товарища майора для демонстрации выбран закрытый для российских IP-адресов ChatGPT, но какие домены добавлять в фильтр дело каждого ;)
Из основных проблем это низкая производительность и странная стабильность – может работать сутками, а может замереть через пару минут после запуска.
Скрипт скорее является «proof of concept» т.е. демонстрацией жизнеспособности задумки, работает на Windows и Unix в т.ч. на VPS.
Подытоживая. Думаю, что для непрограммиста получилось вполне неплохо ;)
Пост запилил скорее себе на память, но, если кто чего подскажет в плане какого-то готового решения аналогичного функционала или изменений в коде - тоже будет хорошо, а если кому-то окажется полезным так и вообще - восторг.
Для ЛЛ, скорость 550-600 мегабит стабильно без ограничений на трафик и торренты.
Небольшой обзор замены основного домашнего проводного интернета на мобильный 5G. Да, тот самый 5G, не pre-5G и прочей чуши.
Не первый год сидел на классическом Ethernet с тарифом до 100 мегабит, давно хотел переключиться на тариф от 100, но увы, в моём доме нет технической возможности. В целом, мне и скорость 80-90 мегабит вполне устраивала, если не частые разрывы со стороны провайдера. Очень много нервов сжирает отвал VPN, а работа удалённая. Сначала грешил на роутер, поменял на другой и прошил на OpenWRT, отвалы продолжились.
В один прекрасный день психанул, открыл карту покрытия 5G, убедился что вхожу в зону покрытия. В обеденный перервыв сбегал в салон связи и приобрёл 5G роутер для дома. Комплекте шла сим карта со спец тарифом (по стоимости немного дешевле проводного). Оператор сообщил, что нет никаких ограничений по трафику, скорости, полный безлимит. На данный момент выкачал более 1 терабайта, основном торренты, оператор скорость не режет, вечером в час пик скорость ниже 500 мегабит не падает.
Роутер разместил рядом с окном.
На борту Wi-Fi6, 5G, слот для симки, 8 антенн и кулер для охлаждения.
Скорость на ноутбуке:
Спидтест до Москвы:
Спидтест до США:
Замер с Andoid телефона:
С iPhone:
Потреблённый трафик:
Торрент без фокусов:
Я никогда не понимал зачем нужен 5G, когда хватает 4G. А теперь я не понимаю, как он работает и что за магия. Почему нет просадок по вечерам и потолок - 600 мегабит. Подключил бесперебойник, теперь не страшны отключения электроэнергии во время работы и умный дом всегда на связи.
Не могу подключится к домашней сети через vpn-сервер. Пробовал и IKE v2 и v1 и pptp. Результат один и тот же. Оператор домашнего интернета билайн. Сотовые операторы билайн и мегафон. Роутер kinetic lite прошивка 4.1.3. Кто-нибудь сталкивался с таким?
Есть viva kn-1910 на 4.1.2 на линии 300 мбит. На wifi висят два компа, три ноута (все под Windows 10), кучка телефонов и планшетов (Android) (все вместе никогда не работают) - большинство на 5 Ггц. Гостевая сеть выключена. Для незарегистрированных ограничений нет.
Уже несколько месяцев странная ситуация: с телефонов (5 ГГц) по спидтесту скорость 250+. С компов и ноутов - хаотично от нуля до 180. Чаще всего примерно 35-50.
Пример: Комп показывает по спидтесту ~35 мбит. Если подключить комп через лежащий рядом телефон (Poco умеют в режим бриджа - одновременно и вайфай, и раздача интернета), то на компе/ноуте скорость под 100+, без провалов. При этом на самом телефоне в этот же момент под 300.
Ситуация одинакова на разных ноутах и компах, то есть сетевые разные. Но! Все они под Win10 home (если это важно).
Вот только что: зашел в свойства точки на компе (wifi 5 802.11ac) - Скорость линии 117/97. Закрыл окошко, зашел еще раз - 780/780 Mbps. Закрыл-открыл - 29/90. Еще раз - 117/117. Причем на ближайших каналах нет других сетей на 5 ггц.