0 просмотренных постов скрыто
Срочный вопрос
Я спать не смогу, пока не узнаю правду. Вступил в сообщество Тульповодов России, внёс деньги. Думал, сразу узнаю все секреты. И тут выясняется что у сообщества есть враг, по имени Ратифаг. Спрашивал у пацанов- молчат и делают страшные глаза, мол не поминай лихо. Так вот может кто тут слышал- Ратифаг, тульповод. Кто он???? Памагите! Я ведь не усну!
Что такое MTU? Размер Ethernet кадра и IP пакета
Господа, дамы, здравствуйте!
Ниже поговорим о допустимых размерах Ethernet кадров и IP-пакетов, этот пост по факту небольшое отступление от протокола IP, поскольку речь будет в основном про Ethernet, но это отступление, на мой взгляд, необходимо в связи с тем, что далее запланирован пост про фрагментацию пакетов в IP, а там бы не хотелось отвлекаться на размеры пакетов и ограничения с этим связанные.
Что такое MTU и PDU?
Читая или смотря что-то о компьютерных сетях, вы часто можете встретить две аббревиатуры: PDU и MTU. Первая расшифровывается как Protocol Data Unit, проще говоря PDU это обобщенное название фрагмента данных, которым обмениваются устройства по тому или иному протоколу. Например, IP устройства обмениваются пакетами, значит PDU в IP это пакет, у Ethernet это будет кадр или фрейм, а PDU в UDP это дейтаграмма.
MTU расшифровывается как Maximum Transmission Unit или максимальная единица передачи, проще говоря, это максимальный размер пользовательских(полезных) данных, которые можно передать внутри одного PDU тем или иным протоколом без фрагментации. Стоит пояснить, что понимается под полезными данными. Для Ethernet полезными данными может выступать IP-пакет, для IP-пакета полезными данными может быть ICMP сообщение, TCP сегмент или UDP дейтаграмма.
Обычно, когда говорят об MTU, имеют ввиду MTU канального уровня, его еще называют Hardware MTU, но про MTU можно говорить в принципе на любом уровня, начиная с транспортного и ниже. Вот так будет выглядеть MTU протоколов разных уровней, если мы исходим из определения, что MTU это полезные данные, переносимые внутри PDU:
Примеры PDU и MTU(MTU IP-пакет на рисунке показан неверно, ниже пояснение)
Но на самом деле в IP определение MTU отличается от Ethernet или TCP. Для IP MTU это пользовательские данные плюс заголовок пакета, поэтому картинка должна быть такой:
Верный пример PDU и MTU
Но тогда непонятно: в чем разница между канальным и сетевым MTU? Разница будет видна при различного рода туннелях, мне ближе всего MPLS, поэтому вот пример MTU с MPLS:
Пример PDU/MTU с MPLS заголовками
Здесь мы видим, что MPLS заголовки включаются в MTU кадра, но не являются MTU пакета, для MPLS на оборудование можно задавать свой собственный MTU, но это отдельная история. Понятно, что чем больше в PDU выделено места для пользовательских данных по сравнению со служебными, тем для получателя услуги скорость будет выше. Вот здесь есть краткий обзор того, как различные размеры кадров и их MTU влияют на скорость для конечных хостов (правда не на нашем языке).
Примечание
Из выше описанного понятно, что MTU на канальном уровне не включает в себя байты, выделенные под Ethernet заголовок, но есть исключения. Например, оборудование Cisco под управлением ОС IOS XR считает канальный MTU не как размер полезной нагрузки в Ethernet кадре, а как размер полезной нагрузки + Ethernet заголовок. С этим нужно быть внимательным, особенно когда настраиваются протоколы, для которых MTU имеет значение, например, OSPF.
Максимальный размер MTU
Вопрос не такой однозначный и простой. Будем исходить из того, что MTU не может быть бесконечным, на это есть много причин, вот некоторые из них:
Некоторые алгоритмы, которые используются для расчета контрольных сумм, при больших размерах пакетов могут давать сбой.
Когда-то раньше, когда в Ethernet сетях были топологии с общей шиной, а сети строились на хабах и повторителях, большие кадры и пакеты были невыгодны, поскольку в таких сетях пока один из участников канальной среды вел передачу, все остальные его слушали и молчали.
Размер буфера портов у транзитных узлов не бесконечен, чем больше пакет, тем больше места он будет занимать в буфере, а слишком большие буферы делать нерационально, поскольку долго хранящийся в буфере пакет может стать не актуальным для получателя.
Потеря маленького пакета не так критична, как большого, вероятность получить искажение большого пакета выше, чем маленького.
Семейство Ethernet, а также фичи и костыли, которые к Ethernet приделываются, как правило, описываются стандартами IEEE. Самый базовый стандарт Ethernet это IEEE 802.3, он дает следующие верхнее ограничение на размер Ethernet кадра в целом и его MTU в частности:
Размер кадра не должен превышать 1518 байт.
MTU кадра должен быть 1500 байт.
В большинстве случаев можно быть уверенным в том, что кадры с полезной нагрузкой в 1500 байт пролезут через любую сеть.
Примечание
Большинство документов, описывающих IP это RFC (request for comment), изначально идея RFC была в том, что кто-то придумал какую-то фичу или метод, описал как ее реализовать и этот кто-то направляет своим коллегам запрос на комментарии к тому, что он придумал. Сейчас RFC можно считать рекомендациями к реализации той или иной фичи. Ethernet же описывается стандартами, полагаю, разница между словом рекомендация и стандарт особых пояснений не требует.
Минимальный размер MTU
Теперь поговорим о нижем ограничение для MTU. Если коротко, то оно есть и, как правило, это ограничение описывается стандартом протокола. Связаны такие ограничения с физикой нашего мира: дело в том, что сетевые устройства обмениваются физическими сигналами, которые генерируются и распространяются по среде передачи данных не мгновенно(хоть и на скоростях близких к скорости света в вакууме), если говорить про Ethernet, то здесь минимальный размер кадра связан с доменом коллизий (участком сети, где два кадра могут столкнуться друг с другом). Дело в том, что размер кадра должен быть настолько большим, чтобы отправителю кадра в случае возникновения коллизии хватило времени на детектирования коллизии.
Пример коллизий в сетях с Ethernet с общей шиной
Если хотите деталей, то поищите информацию про CSMA/CD. На современном оборудование метод CSMA/CD реализован, но зачастую не используется, в виду того, что домен коллизий ограничен линком между двумя конкретными устройствами, а на линке, как правило, работает full duplex (если вы переводите линк в half, то вопрос обнаружения коллизий на этом линке снова становится актуальным), т.е. для приема своя физика, а для передачи своя, что исключает возможности появления коллизий.
Для Ethernet есть множество стандартов, которые описывают различные физические реализации этого самого Ethernet, у разных стандартов может быть свой минимальный размер кадра, а может быть и так, что стандарты разные, но размер кадра одинаковый.
Для стандартов Ethernet со скоростями 10Mbps и 100Mbps минимальный размер кадра равен 64 байта, для стандартов Ethernet со скоростью 1000Mbps по меди(1000BASE-T) минимальный размер кадра увеличен до 512 байт, а если не ошибаюсь, то для стандарта 1000BASE-X(оптика) минимальный размер кадра 416 байт.
Насколько мне известно, стандарты, описывающие реализацию Ethernet на скоростях 2.5Gbps и выше, не предусматривают возможность работы в режиме half duplex, а это означает, что ограничений, которые накладывал CSMA/CD на размер кадра в этих стандартах нет. Сам не тестировал, но встречал упоминания о том, что для Ethernet кадров из стандартов для скоростей выше 1Gbps наследуется минимальный размер кадра в 512 байт.
Если говорить про связку IP+Ethernet, то здесь минимальные MTU для IP такие:
Для IPv4 минимальный MTU не может быть меньше 68 байт. Иногда можно найти информацию о том, что для IPv4 минимальный MTU равен 576 байт, но это не так, на самом деле 576 байт это гарантированный размер IP-пакета, который должен смочь обработать получатель, то есть хост в IP должен уметь обрабатывать пакеты размером 576 байт, а вот пакеты больших размеров он уже не должен уметь обрабатывать.
Для IPv6 минимальный MTU не может быть меньше 1280 байт.
Почему я не писал явные размеры минимальных MTU станет понятно ниже, когда речь пойдет про размеры Ethernet заголовка.
Размер Ethernet заголовка
Есть группа стандартов под номером IEEE 802, эта группа описывает сети LAN(local area network) и MAN(metropolitan area network). В этой группе есть подгруппа 802.3, в которой собрано всякое разное про Ethernet, плюс есть подгруппа 802.1, которая тоже будет нам интересна в контексте обсуждения Ethernet заголовка.
Группа стандартов IEEE 802
Таблица выше была взята с википедии. Группы 802.3 и 802.1 включают в себя некоторые стандарты, которые увеличивают размер Ethernet кадра за счет добавления или расширения служебных полей, это означает, что зачастую для того, чтобы пропускать такие кадры, оборудование должно поддерживать этот стандарт, эти стандарты как правило не требуют увеличения MTU на линках, но лучше заглянуть в документацию оборудования. Вот примеры таких стандартов.
IEEE 802.1q, 802.1p, 802.3ac
Первым делом стоит сказать про 802.1q, он описывает технологию VLAN, которая реализуется за счет добавления нового поля в заголовок кадра, и есть 802.1p, который описывает методы приоретизации трафика. Стандарт 802.3ac предписывает увеличение Ethernet-кадра на 4 байта, в этих четырех байтах как раз и содержится информация о влане и важности кадра.
Структура Ethernet кадра IEEE 802.1Q
IEEE 802.1ad
Стандарт 802.1ad известен больше как QinQ, он расширяет размер кадра как минимум до 1526 байт, этот стандарт позволяет добавлять в кадр две или более метки VLAN, при этом у каждой может быть свой приоритет. Метки и приоритеты как раз описаны в 802.1q и 802.1p. Как правило используют два влана, хотя, наверное, вы можете встретить сценарии с тремя и более тегами.
Структура Ethernet кадра IEEE 802.1AD
IEEE 802.1ah
Стандарт 802.1ah более известный как PBB или MACinMAC.
Структура Ethernet кадра IEEE 802.1AH
IEEE 802.1ae
Стандарт 802.1ae (технология MAC Security) позволяет генерировать кадры размером 1550 байт, 16 байт выделяется под заголовок MAC Security и 16 байт под поле ICV(контрольная сумма).
Структура Ethernet кадра IEEE 802.1AE
Хороший обзор Ethernet кадров различных стандартов и с различными доп. полями можно почитать здесь. Картинки выше взяты оттуда. А вот сравнение размеров различных Ethernet заголовков:
Сравнение размеров Ethernet кадров различных стандартов
Изображение было взято отсюда. На самом деле размер кадра может больше, чем я описывал ранее. Кадры больше стандартных имеют даже свои названия, например, Baby Giant или Jumbo Frame, названия не официальные.
Baby Giant обычно называются кадры размером от 1519 до 1600 байт. Джамба фреймами обычно называются кадры больше 1518 байт. Не всё оборудование умеет работать с jumbo кадрами, как правило их поддержку нужно включить. Стандартов по обработке jumbo фреймов никаких нет, всё на совести вендора.
Теоретический максимально возможный размер Jumbo Frame ограничивает поле FCS и алгоритм CRC32(Cyclic Redundancy Check), который используется для проверки целостности данных в Ethernet, из-за этих ограничений размер не может превышать11455 байт. Если говорить о реальных реализациях, то современные роутеры позволяют задать канальный MTU немногим более 9000 байт.
И в завершении стоит сказать про стандарт 802.3as. Проблема Ethernet в том, что на ранних стадиях он развивался реактивно: возникала потребность в какой-то фичи, и под эту потребность придумывался новый заголовок, в котором вводились новые поля и этот новый заголовок был больше исходного. В итоге такое развитие привело к созданию стандарта 802.3as, он увеличивает размер кадра до 2000 байт, грубо говоря и не вдаваясь в детали, этот стандарт говорит о том, что кадр размером 2000 байт и MTU не более 1500 байт должен быть обработан любым Ethernet интерфейсом.
Вопросов к данному посту нет, поскольку информация здесь больше справочная, чем на понимание логики работы.
Видео версия
Для тех, кому проще слушать и смотреть
Вроде как всё, спасибо что дочитали!
Показать полностью
11
1
Поле Internet Checksum. Как IP считает контрольную сумму
Господа, дамы, здравствуйте!
Ниже поговорим о контрольной сумме в IP и посмотрим на то, как узлы вычисляют ее. Напомню, что IP не контролирует целостность пользовательских данных, контрольная сумма считается только для заголовка. Поскольку на каждом транзитном узле заголовок пакета изменяется, каждый узел пересчитывает контрольную сумму с учетом внесенных изменений при отправке пакета дальше.
Плюс нужно не забывать: контрольная сумма является одним из полей заголовка, но для расчета контрольной суммы узел обнуляет значение этого поля.
Алгоритм расчета контрольной суммы в IP-заголовке
Сразу хочу обратить внимание, что ниже упрощенная интерпретация алгоритма по расчету контрольной суммы, если вам нужны строгие определения или же примеры реализации на различных языках программирования, вам нужно почитать RFC 1071.
Заголовок разбивается на слова по 16 бит слева направо.
Поле контрольной суммы само равно 16 бит, узел, получивший пакет, для расчета контрольной суммы не должен учитывать значение поля контрольная сумма.
Таким образом если у заголовка нет опций, а само поле контрольной суммы мы отбрасываем, то получается 9 слов по шестнадцать бит, в общем виде одно слово будем обзывать буквой W, таким образом у нас есть слова от W0 до W8.
Чтобы узнать контрольную сумму мы должны сперва сложить все слова: Wsum = W0+W1+W2+W3+W4+W5+W6+W7+W8. Правило о том, что от перестановки мест слагаемых сумма не меняется здесь тоже работает.
Если Wsum получилась размером больше, чем 16 бит, получившееся число разбивается на два слова по 16 бит, которые затем складываются между собой(и так нужно будет повторять до тех пор, пока не получим число 16 бит).
И наконец нужно выполнить операцию "исключающего ИЛИ" между шестнадцатеричным числом FFFF и получившимся Wsum. Это и будет контрольная сумма.
Если честно мне никогда не был понятен алгоритм, описанный словами. Поэтому ниже пример.
Рассчитываем контрольную сумму на калькуляторе
Чтобы проверить свои расчет, проще всего сделать дамп пакета, в котором контрольная сумма уже посчитана.
Дамп IP-пакета для расчета контрольной суммы
Слева в Wireshark мы видим представление пакетов удобное нам, человекам, а справа мы видим байтовой представление пакетов, где каждый байт представлен числом в шестнадцатеричной системе счисления, минимальное значение одного байта 00(ноль в десятичной), максимальное его значение FF(255 в десятичной), но для расчета нас интересуют слова по два байта.
Если слева нажать на строку Internet Protocol Version 4..., то справа нам подсветятся байты, соответствующие IP-заголовку. Байты я разбил на слова зелеными рамками, красная рамка это поле контрольная сумма и его мы отбросим.
Итого у нас получилась вот такая сумма:
Wsum = 4500 + 54 + 413C + 4000 + 3D01 + C0A8 + 010F + C0A8 + 020C = 287FC
Не забудьте переключить калькулятор в режим HEX, чтобы выполнять вычисления в шестнадцатеричном формате:
Складываем слова IP-заголовка
Число 287FC в шестнадцатеричной системе счисления занимает места больше, чем 16 бит, а значит надо разбить его на два числа по 16 бит и сложить их, делается это так:
Wsum = 0002 + 87FC = 87FE
Чтобы записать шестнадцатеричное число 87FE в двоичном виде шестнадцати бит хватит, а значит нам надо сделать FFFF XOR 87FE, здесь XOR это ИСКЛЮЧАЮЩЕЕ ИЛИ, подробнее про операцию можете почитать на вики, мы же сейчас возьмем калькулятор, переведем своё число в двоичный вид и сделаем XOR с двоичным числом 1111111111111111 (в HEX на калькуляторе можно сделать то же самое).
Выполняем операцию исключающее ИЛИ
В результате получилась та же контрольная сумма, что и насчитал роутер (7801 в шестнадцатеричном виде):
Контрольная сумма IP-заголовка посчитана
В общем, ничего сложного нет.
Для самостоятельного расчета
Теперь посмотрим на этот же пакет в дампе, который был сделан на следующем узле по пути его следования, это означает, что у него должен уменьшился TTL на 1 и должна пересчитаться контрольная сумма.
Дамп пакета на следующем узле
Оранжевым выделено поле TTL, его значение изменилось(3c в шестнадцатеричной это 60 в десятичной), красным выделена контрольная сумма, у нее изменился первый байт, все остальные байты заголовка без изменений. Для закрепления алгоритма попробуйте самостоятельно рассчитать контрольную сумму этого заголовка.
Видео версия
Для тех, кому проще смотреть, чем читать.
Показать полностью
6
1
Настройка лабы в EVE-NG к посту о Time to Live
Господа, дамы, здравствуйте!
Предыдущая публикация была о TTL и в ней для демонстрации работы я использовал небольшую лабу, собранную в EVE-NG, этот пост для тех, кто хочет самостоятельно собрать такую же лабу и немного поэксперементировать. Ниже мы разберемся с некоторыми особенностями настроек роутеров и хостов лабы TTL.
Чего не будет в посте
Здесь не будет гайда о том, как установить виртуалку и поднять на ней EVE-NG, т.к. таких гайдов много, плюс есть официальная документация.
Вот на этом ютуб канале есть много гайдов на русском языке по EVE.
Вот раздел документации на официальном сайте. Если вы планируете использовать версию EVE-NG для бедных, то рекомендую начать с раздела Community Cookbook, в интернете есть где-то даже машинный перевод этой документации.
В лабе используются хосты, поднятые на образах Debian 10, но гайдов по работе с Linux здесь тоже не будет, я лишь опишу действия, которые делал, чтобы поднять лабу. Если хотите разобраться со всеми этими линуксами, то рекомендую посты пользователя @doatta. Есть еще два хороших канала на Ютубе: Кирилла Семаева и UNИX, у второго есть еще свой сайт.
В лабе протоколом маршрутизации выбран OSPF, сейчас я лишь покажу как его настроить, чтобы заработало, но детальных пояснений не будет, возможно, когда-нибудь я доберусь до OSPF.
Настройка роутеров
В целом, в настройках роутеров ничего сложно нет, вот основные моменты:
Каждому роутеру был задан Loopback адрес с маской /32, каждый октет адреса равен номеру роутера, сделано это было просто для удобства, например, для R3 это 3.3.3.3/32.
На интерфейсах роутеров были назначены р2р сети, принцип назначения объяснялся в посте про TTL.
Маршрутизация использовалась динамическая, протокол OSPF.
Петля делалась за счет статического маршрута на R4.
Но, наверное, мне нужно было бы начать с напоминания топологии:
Топология сети, которую будем настраивать
IP настройки на интерфейсах
Вот так настраиваются Loopback интерфейсы на роутерах (на примере R5, фактически для этой лабы Lo адреса и не нужны):
R5#conf t
R5(config)#interface lo0
R5(config-if)#description system
R5(config-if)#ip address 5.5.5.5 255.255.255.255
На других роутерах меняется только IP-адрес. IP настройки на интерфейсах роутеров Cisco подробно рассматривались здесь. Но, если что, вот пример настроек на физических интерфейсах R5:
interface FastEthernet0/0
description to_Host_2
ip address 192.168.2.17 255.255.255.0
speed auto
full-duplex
interface FastEthernet0/1
description to_R4
ip address 10.4.5.5 255.255.255.0
speed auto
full-duplex
Настройки OSPF
Детально про настройку OSPF говорить не буду. Но его конфиг я покажу, вот так он выглядит на R5:
R5#conf t
R5(config)#router ospf 100
R5(config-router)#network 5.5.5.5 0.0.0.0 area 0
R5(config-router)#network 10.0.0.0 0.255.255.255 area 0
R5(config-router)#network 192.168.2.0 0.0.0.255 area 0
На R1 строку network 192.168.2.0 0.0.0.255 area 0 нужно будет заменить на network 192.168.1.0 0.0.0.255 area 0. На других роутерах третья команда network не нужна.
Краткое пояснение по командам OSPF
Командной router ospf 100 мы запускаем процесс OSPF на роутере и даем ему номер 100, как понимаете, на роутере может работать несколько разных процессов OSPF, при этом на двух соседних роутерах номера их OSPF процессов могут не совпадать, но обычно их делают одинаковыми для удобства.
Команда network довольно интересная, первое число, похожее на IP-адрес, это номер сети, второе число, похожее на маску сети, на самом деле wildcard mask, на русский язык ее переводят как обратная маска или инверсная маска, но сути ее работы это название не отражает. Когда-нибудь я про не напишу, сейчас отправлю в Яндекс или Гугл.
Можно сказать, что команда network это правило для маршрутизатора, роутер перебирает свои IP-интерфейсы и проверяет: попадают ли они под правило, заданные командой network или нет. Если интерфейс попадает под правило, то на нем включается OSPF процесс, интерфейс включается в регион, который указан после ключевого слова area, а информация о сети, которая настроена на этом интерфейсе, будет рассказана другим маршрутизаторам, с которыми установлено OSPF соседство.
Примечание:
Такая конфигурация OSPF подходит для лабы, но не подходит для реальных сетей. Как минимум, потому, что считается небезопасной, дело в том, что командой network 192.168.2.0 0.0.0.255 area 0 мы включаем OSPF на интерфейсе fa0/0, и роутер будет пытаться найти OSPF соседей за портом fa0/0. Fa0/0 это порт в сторону клиента, за которым на самом деле может оказаться злоумышленник.
Выход из такой ситуации у Cisco называется passive-interface, у Huawei такая же фича называется silent-interface. Вообще, хорошим тоном с точки зрения безопасности сети, является включение OSPF руками на тех сетевых линках, где он вам действительно нужен, а сети с клиентских интерфейсов, если это действительно требуется, вкидывать процессу OSPF через механизм редистрибьюции маршрутов.
Под правило network 5.5.5.5 0.0.0.0 area 0 попадает интерфейс Lo0, на нем включается OSPF процесс, сам интерфейс включается в нулевой регион, его адрес относится к сети 5.5.5.5/32, R5 начинает рассказывать всем своим OSPF соседям о том, что у него есть такая сеть.
Посмотреть OSPF интерфейсы на роутере можно так:
R5#show ip ospf int br
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Fa0/0 100 0 192.168.2.17/24 10 DR 0/0
Fa0/1 100 0 10.4.5.5/24 10 DR 1/1
Lo0 100 0 5.5.5.5/32 1 LOOP 0/0
Если нужна какая-то более детальная информация по интерфейсу:
R5#show ip ospf int fa0/1
FastEthernet0/1 is up, line protocol is up
Internet Address 10.4.5.5/24, Area 0
Process ID 100, Router ID 5.5.5.5, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 5.5.5.5, Interface address 10.4.5.5
Backup Designated router (ID) 4.4.4.4, Interface address 10.4.5.4
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:01
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 2
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 4.4.4.4 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
Для создания петли маршрутизации на роутере R4 прописывался вот такой статический маршрут:
R4#sh run | in ip ro
ip route 192.168.2.12 255.255.255.255 10.3.4.3
R4#
На статиках сейчас останавливаться не буду, скоро будет отдельный пост.
Настройка и подготовка хостов
Теперь о подготовке и настройке хостов. Я не сисадмин Linux, поэтому, возможно, действия, описанные ниже, можно сделать более оптимально и просто, но тут уж как смог.
Для начала разберемся, где взять образы дистрибутивов Linux для EVE-NG, во-первых, на официальном сайте, там же есть гайд: текст + видео. На Ютуб канале, который был обозначен в начале поста есть видео о том, как подготовить свой дистрибутив для эмуляции в EVE-NG.
Настройки EVE-NG для хостов
Теперь о некоторых настройках в EVE-NG, которые я использовал для хостов. При первом запуске образа Linux в EVE-NG для подключения к хосту придется использовать VNC. Мне через VNC с отдельными окнами для каждого хоста работать было неудобно, поэтому я решил проблему так: на эмулируемом образе создал два порта, один из которых был подключен в лабу, второй был подключен в мою домашнюю сеть. На порт, который смотрит в домашнюю сеть, IP-адрес прилетает по DHCP от домашнего роутера, по этому адресу я и подключался к машине в дальнейшем.
Вот первичные настройки виртуальной машины в EVE:
Первичные настройки в EVE-NG для хостов
Чтобы эмулируемые в лабе устройства могли получать адреса от физического роутера, в сетевых настройках VMWare для виртуалки EVE-NG должен быть включен bridge. Настройка производится вот здесь, вот так:
Нужно поставить чекрыжик на Bridged... и галку на Replicate physical...
На топологию лабы нужно добавить интерфейс/устройство, через которое виртуальные хосты, могли бы подключаться к реальной физической сети, надо сделать так: по рабочей области жмем ПКМ, в меню выбираем Network, в появившемся окне в списке Type выбираем как на скрине ниже.
Добавляем устройство для организации связности между виртуальной сетью и физической
Образ Linux одним линком нужно будет подключить к появившемуся облаку, это облако свяжет его с физической сетью.
На официальном сайте EVE образ Debian идут с графическим интерфейсом, но все примеры настроек сделаны в эмуляторе терминала, во-первых, это быстрее, во-вторых, я не знаю как делать сетевые настройки в Linux через графику.
Если вы скачали образ Debian с официального сайта EVE (а я так и сделал), то там уже будет создан пользователь с логином user и паролем Test123.
Настройка sudo на хостах
Мне удобнее работать через sudo, в Debian sudo нужно включить, вот перечень команд для этого:
su
#ввести пароль Test123
apt install sudo
exit
Установка sudo в Debian 10
Для пользователя с логином user правка файла /etc/sudoers не требуется, но если хотите создать нового пользователя и работать из-под него, то не забудьте отредактировать файл sudoers, добавив запись аналогичную той, что сделана для user.
Содержимое файла sudoers
Сетевые настройки хостов
Теперь к сетевым настройкам на хостах. Командой ip a смотрим сетевые интерфейсы, которые сейчас есть.
Список IP-интерфейсов
Интерфейс ens3 соответствует интерфейсу e0 на топологии EVE-NG, интерфейс ens4 это e1, этот мануал я пишу уже после того, как собрал изначальную схему и записал видео, т.е. ниже буду рассказать как добавить третий образ на схему (для исходных двух хостов отличаться будут только настраиваемые IP-адреса и прописываемые статики), физически я его подключил так:
Настраиваем узел с именем Linux
Перед тем как продолжать докладываю, этих ваших команд в Linux вагон и маленькая тележка, список команд можно увеличивать за счет установки новых программ и утилит, но базовые команды по работе с сетью и интерфейсами можно найти в этой шпаргалке на сайте Red Hat.
Я хочу чтобы на ens3 мне приходили настройки из моей реальной сети по DHCP, давайте это организуем, пишем команду:
sudo nano /etc/network/interfaces
В данном файле можно делать различные сетевые настройки, VIM не использую, потому что не хочу писать гайд о том, как из него выйти. В этом файле пишем настройки для интерфейса ens3, пишем их так:
# to_local_network
allow-hotplug ens3
iface ens3 inet dhcp
Строка с решеткой это просто комментарий, вторая строка говорит том, что ens3 надо включать сразу как включится образ, третья строка заставляет машину начинать слать DHCP запросы через ens3, чтобы получить свои сетевые настройки. В файле это выглядит так:
Настройка получения IP-адресов по DHCP в Debian 10
Далее нажимаем Ctrl+O чтобы сохранить, Ctrl+X закрыть файл. Если вы после редактирования напишите ip a, то увидите, что сетевые настройки на ens3 по DHCP не прилетают, на самом деле они и не запрашиваются, значит нужно передернуть, передергивать интерфейс будем такой командой:
sudo ifup ens3
Смотрим настройки сетевых интерфейсов после передергивания
После этого мы видим, что адрес был выдан и это 192.168.0.130. Всё, по этому адресу мы можем подключаться при помощи SSH клиента, который установлен на основной операционной системе, плюс образ Linux теперь имеет доступ к интернету.
Настройки SSH на клиенте, через который мы будем подключаться к Debian, стандартные, в SecureCRT они находятся здесь:
Настройки SSH на клиенте
Для того чтобы была возможность подключаться по SSH на виртуальной машине должен быть запущен SSH сервер, который должен слушать 22 порт на предмет входящих подключений, сам порт должен быть открыть, включен ли сервер и какой порт он слушает можно проверить так:
user@debian:~$ sudo systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Sat ... CDT; 39min ago
Docs: man:sshd(8)
man:sshd_config(5)
Process: 471 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 491 (sshd)
Tasks: 1 (limit: 4689)
Memory: 5.7M
CGroup: /system.slice/ssh.service
└─491 /usr/sbin/sshd -D
debian systemd[1]: Starting OpenBSD Secure Shell server...
debian sshd[491]: Server listening on 0.0.0.0 port 22.
debian sshd[491]: Server listening on :: port 22.
Строка Active: active (running) означаете, что сервер включен, по портам, полагаю, не нужно пояснять. Посмотреть открытые tcp/udp порты можно еще и так:
ss -lnput #UDP+TCP
ss -lu #только UDP
ss -tl #только TCP
Если не установлен ssh сервер его надо установить, в Debian и ему подобных дистрибутивах это делается так:
sudo apt update
sudo apt install openssh-server
Если 22 порт закрыт, его надо открыть, вариантов почему порт закрыт, может быть много, например, у вас установлен фаервол ufw и он не разрешает подключение к 22 порту, открыть порт можно будет так:
sudo ufw allow ssh
С вопросом подключения по SSH мы разобрались, нам надо теперь разобраться с интеграцией образа Linux в лабу, для этого на ens4 нужно назначить IP-адрес:
sudo nano /etc/network/interfaces
# to_lan_network
allow-hotplug ens4
iface ens4 inet static
address 192.168.3.25/24
# gateway 192.168.3.1
up ip route add 192.168.1.0/24 via 192.168.3.1 #первый статик
up ip route add 192.168.2.0/24 via 192.168.3.1 #второй статик
up ip route add 10.0.0.0/8 via 192.168.3.1 #третий статик
Строка iface ens3 inet static говорит о том, что адрес на интерфейс надо назначить руками, строка address 192.168.3.25/24 сообщает операционной системе какой IP-адрес и маску мы хотим использовать на этом интерфейсе. Строка # gateway 192.168.3.1 закомментирована, если убрать решетку, то машина будет считать, что за портом ens4 находится шлюз по умолчанию. Эту строку я закомментировал, потому что мой домашний роутер по DHCP сообщил, что именно он является шлюзом по умолчанию для данного хоста(а через домашний роутер осуществляется выход в интернет, а обычным домашним компьютерам и роутерам живется проще, когда они дорогу в интрнет знают не как full view, а как маршрут по умолчанию).
В связи с тем, что домашний роутер является шлюзом по умолчанию, но третий хост все-таки должен знать как добраться до других устройств лабы, пришлось писать и три статических маршрута: первый нужен чтобы был доступен узел Host_1, второй нужен чтобы был доступен Host_2, третий нужен чтобы были доступны p2p сети, настроенные между роутерами между роутерами. Если нужно чтобы были доступны Loopback интерфейсы роутеров, статики до них нужно тоже прописать.
Посмотрим применились ли настройки на ens4:
user@debian:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:00:00:08:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.130/24 brd 192.168.0.255 scope global dynamic ens3
valid_lft 4963sec preferred_lft 4963sec
3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:00:00:08:01 brd ff:ff:ff:ff:ff:ff
inet6 fe80::250:ff:fe00:801/64 scope link noprefixroute
valid_lft forever preferred_lft forever
user@debian:~$
Наших настроек на ens4 не видим, статических маршрутов, которые мы добавили, тоже не увидим:
user@debian:~$ ip route show
default via 192.168.0.1 dev ens3
192.168.0.0/24 dev ens3 proto kernel scope link src 192.168.0.130
user@debian:~$
Надо передернуть, скажете вы:
user@debian:~$ sudo ifup ens4
user@debian:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:00:00:08:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.130/24 brd 192.168.0.255 scope global dynamic ens3
valid_lft 4476sec preferred_lft 4476sec
3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:00:00:08:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.3.25/24 brd 192.168.3.255 scope global ens4
valid_lft forever preferred_lft forever
user@debian:~$
И будете правы, получилось! Сразу после этого в таблице маршрутизации должны будут появиться маршруты, которые мы задавали статикой:
user@debian:~$ ip route show
default via 192.168.0.1 dev ens3
10.0.0.0/8 via 192.168.3.1 dev ens4
192.168.0.0/24 dev ens3 proto kernel scope link src 192.168.0.130
192.168.1.0/24 via 192.168.3.1 dev ens4
192.168.2.0/24 via 192.168.3.1 dev ens4
192.168.3.0/24 dev ens4 proto kernel scope link src 192.168.3.25
user@debian:~$
Если не появились, надо будет напечатать в эмуляторе терминала три команды из файла interfaces, но уже без ключевого слова up, вот так:
ip route add 192.168.1.0/24 via 192.168.3.1
ip route add 192.168.2.0/24 via 192.168.3.1
ip route add 10.0.0.0/8 via 192.168.3.1
Чтобы новый хост получил связность с другими узлами сети, нужно не забыть выполнить настройки на R3(донастроить OSPF + настроить интерфейс в сторону хоста), показывать я это уже не буду.
Для просмотра базовой информации о сетевых и канальных параметрах есть четыре команды:
ПОСМОТРЕТЬ СЕТЕВЫЕ НАСТРОЙКИ:
user@debian:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:00:00:08:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.130/24 brd 192.168.0.255 scope global dynamic ens3
valid_lft 4166sec preferred_lft 4166sec
3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:00:00:08:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.3.25/24 brd 192.168.3.255 scope global ens4
valid_lft forever preferred_lft forever
ПОСМОТРЕТЬ КАНАЛЬНЫЕ ПАРАМЕТРЫ:
user@debian:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:50:00:00:08:00 brd ff:ff:ff:ff:ff:ff
3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:50:00:00:08:01 brd ff:ff:ff:ff:ff:ff
ARP ТАБЛИЦА:
user@debian:~$ ip neigh show
192.168.0.101 dev ens3 lladdr 8c:55:4a:a9:b9:dd REACHABLE
192.168.0.1 dev ens3 lladdr b#:#0:24:#0:#f:#0 STALE
ТАБЛИЦА МАРШРУТИЗАЦИИ:
user@debian:~$ ip route show
default via 192.168.0.1 dev ens3
10.0.0.0/8 via 192.168.3.1 dev ens4
192.168.0.0/24 dev ens3 proto kernel scope link src 192.168.0.130
192.168.1.0/24 via 192.168.3.1 dev ens4
192.168.2.0/24 via 192.168.3.1 dev ens4
192.168.3.0/24 dev ens4 proto kernel scope link src 192.168.3.25
user@debian:~$
Давайте проверим доступность R3:
user@debian:~$ ping 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=255 time=9.88 ms
64 bytes from 192.168.3.1: icmp_seq=2 ttl=255 time=11.1 ms
64 bytes from 192.168.3.1: icmp_seq=3 ttl=255 time=2.07 ms
^C
--- 192.168.3.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 2.074/7.673/11.067/3.988 ms
user@debian:~$
Успех, а теперь попингуем Host_1 и Host_2:
PING 192.168.1.15 (192.168.1.15) 56(84) bytes of data.
^C
--- 192.168.1.15 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 75ms
user@debian:~$
user@debian:~$ ping 192.168.2.12
PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data.
^C
--- 192.168.2.12 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 68ms
user@debian:~$
А вот хосты не доступны. Вопрос: почему? На роутерах настройки корректные. Что надо сделать, чтобы эти узлы стали доступны?
Напоследок дам еще некотрые пояснения. Сетевые настройки мы выполняли в файле /etc/network/interfaces для того, чтобы после перезагрузки виртуальной машины они сохранились. Но адреса можно настраивать временно без сохранения в настроек в файл.
В примере ниже адрес 192.168.3.44/24 добавляется на интерфейс ens4 как secondary, поскольку основной адрес у нас уже задан, а add означает добавить. Вторичный адрес будет активен до перезагрузки.
user@debian:~$ sudo ip address add 192.168.3.44/24 dev ens4
user@debian:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:00:00:08:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.130/24 brd 192.168.0.255 scope global dynamic ens3
valid_lft 6906sec preferred_lft 6906sec
3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:00:00:08:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.3.25/24 brd 192.168.3.255 scope global ens4
valid_lft forever preferred_lft forever
inet 192.168.3.44/24 scope global secondary ens4
valid_lft forever preferred_lft forever
user@debian:~$
На этом, собственно, всё. Видео к данном посту нет и не планировалось.
Показать полностью
11
#003 Про IP-адреса и их свойства. Часть 1: номер сети и номер хоста
Господа, дамы, здравствуйте!
Мы разобрались с видами устройств в IP, теперь нужно научиться как-то отличать один узел сети от другого, а для этого надо разобраться с IP-адресами, какими они обладают свойствами, как их записывать и другими вопросами. Вопросов много, разбираться будем по порядку.
Тему IP-адресов я разбил на три логические части: сперва идет немного теории, потом мы разбираемся с формами записи IP-адресов, пингуя всё на свете, кроме шила и гвоздя, а в третьей части мы соберем небольшую лабу в EVE-NG, чтобы разобраться как настраиваются основные и вторичные IP-адреса на интерфейсах роутеров.
Я не нашел как на Пикабу создать оглавление для поста в его начале(если кто-то что-то подскажет по этому поводу буду благодарен), а все три части вместе получились довольно объемными, поэтому тема будет разбита на два поста, ниже теория + пинги, отдельным постом поделаем настройки.
Задачи IP-адресов
Давайте сперва поймем какие задачи решает IP-адрес, для себя я выделяю их две. Первая заключается в том, чтобы нумеровать узлы компьютерной сети(на самом деле не только узлы, но и сети, к которым узел относится), то есть IP-адрес выступает уникальным идентификатором узла в сети, вернее даже не узла, а его интерфейса. Вторая немаловажная задача IP-адресации заключается в том, что с помощью адресов мы можем построить маршрут из одной точки сети в другую, но об этом мы поговорим, когда речь пойдет о маршрутизации.
Идентифицировать устройства в небольших сетях проще было бы по названию, например, у вас дома есть компьютер, ноутбук, несколько мобильных телефонов, планшет и умный чайник, в такой ситуации проще дать имя каждому узлу и обращаться к нему по имени, а вот рассказать это имя всем остальным узлам в мире выглядит проблемой, да и гарантировать, что это имя не пересечется с другим тоже сложно. Поэтому узлы для сетевого взаимодействия мы нумеруем при помощи IP-адресов, да еще и не просто так, а по определенным правилам.
Свойства IP-адресов
IP-адрес обладает большим количеством свойств, выделю пять основных (на мой взгляд):
Размер IP-адреса 32 бита или 4 байта, если хотите можно говорить октета. Это означает, что у нас примерно имеется 4 млрд адресов, более точно можете узнать, если возведете два в тридцать вторую степень (у нас для хранения IP-адреса выделено 32 бита, каждый бит может принимать значение либо ноль, либо единица).
IP-адрес назначается на канальный интерфейс устройства.
IP-адрес для нормальной работы сети должен быть уникальным в пределах всей сети, если на устройстве А и Б будут одинаковые адреса, то для одной части узлов сети будет доступно устройство А, а для другой части сети устройство Б, этим можно пользоваться для реализации anycast взаимодействия, так как штатно в IPv4 этот вид взаимодействия не реализован.
IP-адрес состоит из двух частей:
первая часть адреса является идентификатором канальной среды или номером сети (Network ID), номер сети будет одинаковым для всех узлов внутри одной канальной среды и разным у узлов из разных канальных сред;
вторая часть IP-адреса – это номер узла или идентификатор хоста (Host ID), номер узла должен быть разным для всех узлов внутри одной сети, но может повторяться, если узлы находятся в разных канальных средах.
На текущий момент границу между номером сети и номером узла проводит маска подсети. Если вы не знаете маску подсети, то не сможете сказать: где у IP-адреса номер хоста, а где номер сети.
IP-адрес на устройство назначается не его производителем, а человеком, который это устройство использует, скорее всего, сетевым администратором. При этом способ назначения не важен: адреса можно выдавать динамически при помощи DHCP, или же статически: своими собственными руками назначать каждому интерфейсу.
Номер сети и номер хоста
IP-адрес нумерует сразу две сущности: сам узел и сеть, в которой этот узел находится. Таким образом получается, что узлы, находящиеся в одной подсети, имеют одинаковый номер сети, но у них разные номера хостов. Если два или более узла находятся в одной подсети, то не будет ошибкой говорить, что они находятся в одной канальной среде.
Если два узла находятся в разных подсетях, то их номера узлов могут повторяться, а их номера сети будут разными. Узлы, находящиеся в одной канальной среде, могут обратиться к узлам другой подсети через маршрутизатор, основная задача роутера как раз и заключается в том, чтобы перекладывать кадры из одной канальной среды в другую.
Все вышесказанное продемонстрировано на этой картинке.
На ней изображено три сети: зеленая, оранжевая и синяя, номера сетей я указал римскими цифрами, номера узлов подписаны арабскими. Все три сети соединены одним роутером, для того чтобы этот роутер мог связать узлы этих трех сетей друг с другом, его интерфейсы должны находиться во всех трех сетях, то есть если мы хотим, чтобы зеленый узел мог пинговать оранжевый узел, то хотя бы один интерфейс роутера должен быть в зеленой сети и хотя бы один интерфейс роутера должен быть в оранжевой сети.
Сколько IP-адресов может быть на устройстве?
Операционные системы, а вернее прошивки некоторых простых устройств позволяют задать только один адрес, в некоторых случаях несколько IP-адресов, но спецификация IP нас не ограничивает в количестве адресов, которые можно присвоить одному узлу.
Если вспомним самое начало, то там речь была о том, что IP-адрес назначается на канальный интерфейс узла и тут можно подумать, что если у узла три канальных интерфейса, то ему можно назначить три адреса из разных подсетей, но это не так.
Если у узла три канальных интерфейса, то ему на каждый канальный интерфейс можно назначить один основной IP-адрес и сколько угодно вторичных. Важно чтобы на разных канальных интерфейсах были адреса из разных подсетей, при этом основной и вторичные IP-адреса на одном интерфейсе могут быть из одной подсети.
Как записать IP-адрес
Разбираться будем с формами записи в десятичной системе счисления. Если вы выходите в интернет, то, наверное, видели IP-адреса, например, 192.168.0.1. Читатель может заметить и спросить, ну и чего тут рассказывать, вон на экране написано 192.168.0.1, это и есть форма записи IP-адреса, которая всем понятна и удобна. Я бы мог в свою очередь сказать, что это стандартная форма записи, но, насколько мне известно, в спецификации IP стандартная форма записи никак не описана.
В общем так, если вам достаточно что IP-адрес, это число размером 32 бита и записывается он как четыре числа по восемь бит разделенных точками, то дальше можно и не читать если этого недостаточно, то давайте начнем по порядку.
Для начала запишем форму записи для 192.168.0.1 в общем виде:
8bit.8bit.8bit.8bit
А теперь давайте запишем в этом виде самый маленький и самый большой адреса:
0.0.0.0
255.255.255.255
Переведем их в двоичный вид:
00000000|00000000|00000000|00000000
11111111|11111111|11111111|11111111
В двоичном виде вместо точки я использовал пайп. Самый маленький адрес в двоичном виде представляет собой тридцать два нуля, самый большой тридцать две единицы, комбинции нулей и единиц между двумя представленными выше крайностями это все остальные IP-адреса. Фактически IP-адрес это число 32 бита, оно же может быть и десятичным. Вопрос в том, как нам записать адрес в десятичном виде одним числом и можно ли это вообще делать?
Для примера давайте пропингуем Яндекс:
PS C:\> ping ya.ru
Обмен пакетами с ya.ru [5.255.255.242] с 32 байтами данных:
Ответ от 5.255.255.242: число байт=32 время=46мс TTL=54
Ответ от 5.255.255.242: число байт=32 время=46мс TTL=54
Ответ от 5.255.255.242: число байт=32 время=47мс TTL=54
Ответ от 5.255.255.242: число байт=32 время=46мс TTL=54
Статистика Ping для 5.255.255.242:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 46мсек, Максимальное = 47 мсек, Среднее = 46 мсек
PS C:\>
Яндекс доступен по адресу: 5.255.255.242. Давайте переведем адрес в двоичный вид, каждый октет по отдельности:
00000101|11111111|11111111|11110010
Про переводы чисел из одной системы счисления в другую я рассказывать не планирую, если не умеете переводить, пользуйтесь калькулятором в режиме "Программист", в десятичном режиме пишите свое число, в соответствующей строке видите его двоичное представление.
Перевод чисел из десятичной системы счисления в двоичную
Хотел бы обратить внимание на число 5. Калькулятор представляет его как четыре бита: 0101, а под одно число IP-адреса у нас выделено восемь бит. В таком случае мы должны вместо недостающих старших бит написать нули (чем старше бит, тем левее он стоит, аналогично и для байтов), так как они в данном случае ничего не значат и само восьми битное число никак не изменится (чего не скажешь о числе размером 32 бита, если октет будет в середине, а не как у нас крайним слева).
Но вернемся к IP-адресу. Чтобы представить его в виде обычного числа, нам нужно из двоичной формы убрать разделители:
00000101111111111111111111110010
Роутер или компьютер работают с адресами без разделителей для них это просто биты. Затем получившуюся битовую последовательность переводим в десятичную систему счисления.
Переводим число из двоичной системы в десятичную
Получилось число 100 663 282. Давайте его пропингуем.
Пингуем десятичное число, получаем IP-адрес
Видим, что винда привела этот номер в привычный нам вид, всё успешно пропинговалось. Здесь может возникнуть справедливый вопрос: почему это мы вместо того чтобы использовать простые и понятные числа, переводим их в двоичный вид, разрезаем одно большое число на четыре куска по восемь бит, потом преобразуем эти восьмибитные двоичные числа обратно в десятичные и только потом записываем IP-адреса? Если коротко, то в таком виде удобнее разрезать сети на подсети или же наоборот (человекам, а не комплюхтерам): объединять маленькие сеточки в одну большую, если более детально, то будет отдельная тема о масках подсети.
Две не очень популярные формы записи
Я знаю еще две формы записи, которые, как я слышал, пришли из систем BSD. В общем виде их можно записать так:
8bit.8bit.16bit
8bit.24bit
Я ни разу не видел, чтобы их кто-то использовал в каких-то рабочих целях, но вдруг вы столкнетесь. Винда понимает эти формы, вот для примера пинг 8.8.8.8.
PS C:\Windows\system32> ping 8.8.2056
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 54ms, Maximum = 54ms, Average = 54ms
PS C:\Windows\system32> ping 8.526344
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 54ms, Maximum = 54ms, Average = 54ms
PS C:\Windows\system32>
Итого у нас имеется четыре формы записи IP-адреса:
8bit.8bit.8bit.8bit
8bit.8bit.16bit
8bit.24bit
32bit
Переводить из одной формы записи в другую удобнее всего в двоичном виде, в двоичном виде вы просто отсчитываете нужное количество бит и ставите точку, получившуюся последовательность переводите в десятичную систему.
Если байты IP-адреса нулевые и не крайние, то некоторые операционные системы разрешают их не указывать, пользоваться этой фичей не рекомендую, особенно, если вы настраиваете адрес на оборудование, а не пингуете его, ниже примеры пинга адреса 1.0.0.1.
C:\Users\user>ping 1.0.0.1
Pinging 1.0.0.1 with 32 bytes of data:
Reply from 1.0.0.1: bytes=32 time=39ms TTL=59
Reply from 1.0.0.1: bytes=32 time=46ms TTL=59
Reply from 1.0.0.1: bytes=32 time=40ms TTL=59
Reply from 1.0.0.1: bytes=32 time=39ms TTL=59
Ping statistics for 1.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 46ms, Average = 41ms
C:\Users\user>ping 1.0.1
Pinging 1.0.0.1 with 32 bytes of data:
Reply from 1.0.0.1: bytes=32 time=39ms TTL=59
Reply from 1.0.0.1: bytes=32 time=39ms TTL=59
Reply from 1.0.0.1: bytes=32 time=40ms TTL=59
Reply from 1.0.0.1: bytes=32 time=40ms TTL=59
Ping statistics for 1.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 40ms, Average = 39ms
C:\Users\user>ping 1.1
Pinging 1.0.0.1 with 32 bytes of data:
Reply from 1.0.0.1: bytes=32 time=39ms TTL=59
Request timed out.
Reply from 1.0.0.1: bytes=32 time=47ms TTL=59
Reply from 1.0.0.1: bytes=32 time=39ms TTL=59
Ping statistics for 1.0.0.1:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 47ms, Average = 41ms
А на этом всё, здесь появится ссылка на вторую часть после ее публикации.
Вопросы для ваших ответов
Оставлю комментарий для ответов, если захотите отвечать на вопросы, то лучше делать под этим комментарием, чтобы не спойлерить другим.
Какое число больше 8.234.255.12 или 9.0.0.0?
Зачем IP-адресу точки?
Почему если средние октеты адреса нулевые их допускается не печатать, а крайние октеты мы печатать должны?
Какой байт пропущен для адреса 1.1.1 (слева от центральной единицы или справа)?
У нас есть локальная сеть(не интернет), в сети есть узлы, кто этим узлам выдает IP-адреса?
Нужен ли роутер для взаимодействия между узлами одной подсети?
Схема: к Wi-Fi роутеру подключено два ноутбука по Wi-Fi, все три устройства в одной подсети, пингуем с первого ноутбука второй. Вопрос: как физически будут передаваться данные, напрямую между двумя ноутбуками или через роутер и почему?
Видео версия
Тем, кому лучше смотреть, чем читать.
Теоретическая теория здесь
Про формы записи адресов и пинги тут:
Показать полностью
4
2
Виды устройств в IP (хосты и роутеры). Часть 2
Господа, дамы, здравствуйте!
Продолжение поста о видах устройств в 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, а какой-то другой протокол?
Показать полностью
9
1
#002 Виды устройств в IP (хосты и роутеры). Часть 1
Господа, дамы, здравствуйте!
Важно понимать, что 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.
Поверхностно разобрались с тем, как связаны канальный и сетевой уровни.
И убедились, что функции отправителя и получателя может выполнять одно и то же устройство.
Теперь можно перейти к рассмотрению работы транзитных узлов, поэтому отправляю вас ко второй части.
Видео версия
Вот здесь теоретическая часть:
Вот здесь про прямое взаимодействие хостов:
p.s. Вопросы на подумать к данной теме смотрите в конце поста со второй частью.
Показать полностью
19
2