Некоторые секреты ip протокола


Содержание

Некоторые секреты ip протокола

ZAlex
SNMP бегает поверх IP/UDP, и для этих целей не подходит никак

Akina
Речь не о ip broadcast, a mac broadcast

8. vinni , 20.11.2009 17:42
Akina
чтобы пингануть бродкаст подсети
Правильно яверт ответил, поиск делается не на сетевом уровне, а на канальном, то есть ищется, например, принтер, у которого вообще ещё не сконфигурирован IP, и ведь находится!
9. Akina , 21.11.2009 10:15
яверт
vinni
А не подскажете готовый МАС pinger? Умеющий послать бродкаст и сгрести в кучку ответы?
PS. тулзы, где пакет формируется «вручную», можно не предлагать, такое имеется.
10. Newcastle , 21.11.2009 23:14
Всем спасибо за ответы!
11. vinni , 23.11.2009 11:39
Akina
Не полностью готовый, но за 2 шага:
C:\>wakearp
Usage: wakearp
Will induce arp resolution for all IP addresses x.y.z.0 — x.y.z.254
This utility lives at: http://www.elifulkerson.com

12. Akina , 23.11.2009 14:37
Это же обычный UDP-пингер.
13. яверт , 23.11.2009 15:08
Akina
На броадкаст запрос обычные компы вам ничего не ответят.
Если вам нужна подобная тулза можно сделайть arp-ping скрипт на базе scapy.
У скапи всё своё начиная с L2, поэтому можно отправлять арп запросы на айпи адреса не из своего сабнета.
14. Akina , 23.11.2009 22:02
Да блин! пойми, для меня просканить диапазон ИПов и выгрести АРП-кэш — не проблема! Да собственно всё ещё проще — пингуем бродкаст подсети и сгребаем ответы. Фигня в том, что для этого надо знать или хотя бы предполагать, что за подсеть рядом.

ТС знает, ему хорошо. он вполне может обойтись вульгарным сканом сети. Меня же заинтересовало иное — найти адрес, не зная подсети или диапазона, просто зная что адрес есть. ИП или МАС — неважно.

Я полагал, что есть какой-то способ безотносительно к ИП получить МАС-и соседей и по ним уже определять наличие ИП и адрес, если ИП есть.

Я не стал высказывать предположение, что на МАС-пинг комп без заточенного под это дело софта отвечать не станет, ибо был не уверен, и попросил фамилию тулзы, чтобы попробовать.
Что ещё можно придумать? на глобальный бродкаст компы не отвечают (да и не очень-то ещё что туда пошлёшь осмысленного. надо будет wakearp попросить, кстати). Попинать определённый сервис по мультикасту? тоже вроде готовых инструментов нет.

15. яверт , 23.11.2009 23:18
Akina
Не ломайте себе голову, все протоколы которые подразумевают безапеляционный ответ на запрос никогда не работают с броадкастовым запросом из-за реальной угрозы DоS атаки.

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

16. Akina , 23.11.2009 23:52
Вот собственно в том и вопрос — как (и можно ли вообще, пусть даже частично) получить сведения о ближайших узлах в сети, разделённой свичами, в разумное время и при этом не положить сегмент и не обидеть свич.

яверт
все протоколы которые подразумевают безапеляционный ответ на запрос никогда не работают с броадкастовым запросом из-за реальной угрозы DоS атаки.
Я предполагаю, что дело всё-таки происходит в рамках LAN. Кстати, на пинг по адресу бродкаста подсети отвечают все узлы этой подсети, если на них разрешён пинг.

17. яверт , 24.11.2009 03:21
Akina
Если свитчи ваши и дружат хоть немного с SNMP то можно слить с них bridging table (dot1dTpFdbTable OID:1.3.6.1.2.1.17.4.3) там нужные вам маки должны быть засвечены.
18. ping_not_dead , 24.11.2009 08:08
Akina:

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

Здесь комп не получил ip-адрес и присвоил из диапазона по умолчанию.

А вот запись о новой станции в сети

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

19. Akina , 24.11.2009 13:51
яверт
ping_not_dead
Ещё раз: меня интересует возможность получения таких сведений в неподконтрольной сети.
Иными словами — представьте, что в стенку уходит кабель, куда он идёт и что там, вам неведомо. А узнать хочется
20. Str@nNik13 , 25.11.2009 15:32
Akina
И как же «вот эта» утилита будет сканить подсеть, не имея неё шлюза и не имея из неё адреса? Она как раз предполагает, что в части маршрутизации в сети всё в порядке.
А кто сказал что маршрутизации нет, лично я исходил из предположения что с маршрутизацией все нормально, а требуется только определить имеющиеся сети и сервисы доступные в этих сетях.
21. Akina , 25.11.2009 17:36
Str@nNik13
Ну вот представь. У тебя адрес. ну скажем 192.168.0.2. Маска /24. Шлюз/ДНС соответственно 0.1. Маршрутизация у тебя нормально работает на любой допустимый адрес.
Ты точно знаешь, что на других портах твоего свича сидят клиенты с IP из другой подсети. И у них тоже с маршрутизацией всё в порядке. Будь у тебя их адреса — ты бы без проблем их пинговал. скажем через общий ваш роутер, у которого на интерфейсе несколько адресов из разных подсетей.
Но адресов/подсетей у тебя нет. Есть только знание, что вы сидите в одном свиче и что на свиче виланов не настроено. К свичу доступа нет. И разрешения переполнить ему ARP-таблицу тоже нет. И SNMP на нём только приватный, и пароля тебе не дали. И роутер не намерен тебе рассказывать, какие у него есть адреса, кроме адреса твоего шлюза.
Можно ли в таких условиях узнать адреса соседей по свичу? А если можно — то как?

цитата: Akina:
Str@nNik13
Но адресов/подсетей у тебя нет. Есть только знание, что вы сидите в одном свиче и что на свиче виланов не настроено. К свичу доступа нет.

Не очень понятно откуда вдруг возьмется знание о настройках vlan на свиче, если к нему никакого доступа нет. Для пользователя это будет абсолютно прозрачно.
Если действительно в одном широковещательном домене находятся несколько подсетей (чего ни один грамотный админ делать никогда не будет), то можно любым сниффером (или Arpwatch тем же) ловить arp-пакеты и делать выводы о том, какие еще сети есть в этом сегменте. Если же в пределах одного широковещательного домена находится только одна подсеть, то о существовании других подсетей «по близости» узнать нельзя.

22. ping_not_dead , 26.11.2009 08:33
23. Akina , 26.11.2009 08:59
ping_not_dead
Не очень понятно откуда вдруг возьмется знание о настройках vlan на свиче, если к нему никакого доступа нет.
Повторю:
Есть только знание, что вы сидите в одном свиче и что на свиче виланов не настроено.

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

жно любым сниффером (или Arpwatch тем же) ловить arp-пакеты и делать выводы о том, какие еще сети есть в этом сегменте.
Вообще-то там свич, а не хаб. Причём не секунду назад включившийся и знающий, какой МАС на каком порту у него сидит. И просто так он тебе транзитные пакеты отправлять не станет.

24. ping_not_dead , 26.11.2009 10:49
Akina:

цитата:
Вообще-то там свич, а не хаб. Причём не секунду назад включившийся и знающий, какой МАС на каком порту у него сидит. И просто так он тебе транзитные пакеты отправлять не станет.

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

25. vinni , 27.11.2009 20:58
Akina
Вообще-то там свич, а не хаб. Причём не секунду назад включившийся и знающий, какой МАС на каком порту у него сидит. И просто так он тебе транзитные пакеты отправлять не станет.
ARP-запросы это броадкаст. А, ну да, ping_not_dead уже сказал об этом.

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

ping_not_dead
Соответственно, по этим ip-адресам можно сказать к какой сети принадлежит хост, пославший пакет.
Точно сказать про сети нельзя, т.к. в ARP-запросе нет масок сетей.

26. Akina , 27.11.2009 23:51
ping_not_dead
ARP-запросы являются широковещательными и будут переданы свичем на все порты. В теле ARP-запроса содержится ip-адрес источника, пославшего пакет и ip-адрес того, чей мак он хочет узнать.
И какой же IP прикажете запрашивать в этом пакете? Если IP, имеющиеся в сегменте, неизвестны?

Добавление от 28.11.2009 00:05:

vinni
остальные уже названы — различные сниферы (в т.ч. arpwatch),
Свич ничего, что может получить снифер, не пропустит — мол, не твоё.

Волшебных средств я не знаю
Я тоже. Но.

Например, пинг любого IP-адреса приведёт к получению ответа от любой станции, для который этот адрес есть бродкаст её подсети.

Запрос определённой структуры на мультикаст 224.0.1.22:427 приведёт к получению ответа от всех станций, на которых установлен нетварёвый клиент.

А есть ли волшебный адрес/порт/протокол/прочее, на который будет получен ответ от любой станции, имеющей IP-протокол? ну при условии что её локальный файрвол не против.

27. ping_not_dead , 30.11.2009 07:00
vinni

цитата: Точно сказать про сети нельзя, т.к. в ARP-запросе нет масок сетей.

цитата: Akina:
ping_not_dead
ARP-запросы являются широковещательными и будут переданы свичем на все порты. В теле ARP-запроса содержится ip-адрес источника, пославшего пакет и ip-адрес того, чей мак он хочет узнать.
И какой же IP прикажете запрашивать в этом пакете? Если IP, имеющиеся в сегменте, неизвестны?

Ничего запрашивать самому не нужно! Нужно слушать сеть и ловить arp-запросы от других хостов (а любой хост обязательно будет их генерить, чтобы сопоставить ip и mac).

цитата: А есть ли волшебный адрес/порт/протокол/прочее, на который будет получен ответ от любой станции, имеющей IP-протокол? ну при условии что её локальный файрвол не против.

Это из под линукса с ключом -b.
Винда на броадкасты не откликается по-моему.

Протоколы TCP/IP простым языком

Протоколы TCP/IP основа работы глобальной сети Интернет. Если быть более точным, то TCP/IP это список или стек протоколов, а по сути, набор правил по которым происходит обмен информации (реализуется модель коммутации пакетов).

В этой статье разберем принципы работы стека протоколов TCP/IP и попробуем понять принципы их работы.

Примечание: Зачастую, аббревиатурой TCP/IP называют всю сеть, работающую на основе этих двух протоколов, TCP и IP.

В модель такой сети кроме основных протоколов TCP (транспортный уровень) и IP (протокол сетевого уровня) входят протоколы прикладного и сетевого уровней (смотри фото). Но вернемся непосредственно к протоколам TCP и IP.

Что такое протоколы TCP/IP

TCP — Transfer Control Protocol. Протокол управления передачей. Он служит для обеспечения и установление надежного соединения между двумя устройствами и надежную передачу данных. При этом протокол TCP контролирует оптимальный размер передаваемого пакета данных, осуществляя новую посылку при сбое передачи.

IP — Internet Protocol. Интернет протокол или адресный протокол — основа всей архитектуры передачи данных. Протокол IP служит для доставки сетевого пакета данных по нужному адресу. При этом информация разбивается на пакеты, которые независимо передвигаются по сети до нужного адресата.

Форматы протоколов TCP/IP

Формат IP протокола

Существуют два формата для IP адресов IP протокола.

Формат IPv4. Это 32-битовое двоичное число. Удобная форма записи IP-адреса (IPv4) это запись в виде четырёх групп десятичных чисел (от 0 до 255), разделённых точками. Например: 193.178.0.1.

Формат IPv6. Это 128-битовое двоичное число. Как правило, адреса формата IPv6 записываются в виде уже восьми групп. В каждой группе по четыре шестнадцатеричные цифры разделенные двоеточием. Пример адреса IPv6 2001:0db8:85a3:08d3:1319:8a2e:0370:7889.

Как работают протоколы TCP/IP

Если удобно представьте передаче пакетов данных в сети, как отправку письма по почте.

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

Протокол IP

Каждый компьютер в сети имеют свой уникальный адрес. В глобальной сети Интернет, компьютер имеет этот адрес, который называется IP-адрес (Internet Protocol Address).

По аналогии с почтой, IP- адрес это номер дома. Но номера дома для получения письма недостаточно.

Передаваемая по сети информация передается не компьютером, как таковым, а приложениями, установленными на него. Такими приложениями являются сервер почты, веб-сервер, FTP и т.п. Для идентификации пакета передаваемой информации, каждое приложение прикрепляется к определенному порту. Например: веб-сервер слушает порт 80, FTP слушает порт 21, почтовый SMTP сервер слушает порт 25, сервер POP3 читает почту почтовых ящиков на порте 110.

Таким образом, в адресном пакете в протоколе TCP/IP, в адресатах появляется еще одна строка: порт. Аналог с почтой — порт это номер квартиры отправителя и адресата.

Source address (Адрес отправителя):

Destination address (Адресполучателя):

Стоит запомнить: IP адрес + номер порта — называется «сокет». В примере выше: с сокета 82.146.47.66:2049 пакет отправляется на сокет 195.34.31.236: 53.

Протокол TCP

Протокол TCP это протокол следующего после протокола IP уровня. Предназначен этот протокол для контроля передачи информации и ее целостности.

Например, Передаваемая информация разбивается на отдельные пакеты. Пакеты доставят получателю независимо. В процессе передачи один из пакетов не передался. Протокол TCP обеспечивает повторные передачи, до получения этого пакета получателем.

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

Некоторые секреты ip протокола

Напомним, что IP относится к группе протоколов TCP/IP. Протокол TCP реализует транспортные функции модели OSI ( Open Systems Interconnection), ее четвертого уровня. Его основная обязанность — обеспечение надежной связи между начальной и конечной точками пересылки данных. IP располагается в OSI на сетевом, или третьем, уровне; он должен поддерживать передачу маршрутизаторам адресов отправителя и получателя каждого пакета на всем пути его следования.

Маршрутизаторы и коммутаторы третьего уровня считывают записанную в пакетах по правилам IP и других протоколов третьего уровня информацию и используют ее совместно с таблицами маршрутизации и некоторыми другими интеллектуальными средствами поддержки работы сети, пересылая данные по сетям TCP/IP любого масштаба — от «комнатной» до глобальной, охватывающей всю планету.

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

Кроме того, в заголовке пакета записан IP-адрес его места назначения. Если отправляющая станция определяет, что адрес доставки не локальный, пакет направляется маршрутизатору первого сетевого сегмента. Этот маршрутизатор определяет IP-адрес пакета и проверяет по своей таблице, не расположена ли станция получателя в локальной физически подключенной к нему сети, которая называется IP-подсетью (обычно она назначается для всех сетевых интерфейсов маршрутизатора). Если же выясняется, что IP-адрес получателя локальный, маршрутизатор начинает искать внутреннее хранилище IP- и MAC-адресов локальных устройств — ARP-кэш (Adress Resolution Protocol), позволяющий сопоставлять IP- и MAC-адреса.

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

Процесс построения и обновления таблиц маршрутизации практически непрерывен. Он осуществляется средствами, использующими интеллектуальные протоколы обнаружения, например RIP или OSPF. В таблице каждого маршрутизатора указан оптимальный маршрут до адреса назначения или до маршрутизатора следующего сегмента (если адрес не принадлежит локальной подсети). Последовательно просматривая собственные таблицы маршрутизации, соответствующие устройства передают пакет «по этапу», запрашивая, при необходимости, MAC-адрес конечной станции. Этот процесс продолжается до тех пор, пока пакет не доберется до пункта назначения.

Однако при пересылке пакета через множество сетевых сегментов существует опасность образования «петель»: неправильно сконфигурированный маршрутизатор постоянно возвращает пакет тому маршрутизатору, через который данный пакет уже проходил. Во избежание этого в IP предусмотрена TTL-функция (time-to-live), позволяющая задать предел времени путешествия пакета по сети. Значение TTL устанавливается заранее и уменьшается на единицу при каждом прохождении любого сегмента. Если величина TTL становится равной нулю, пакет удаляется, а маршрутизатор отсылает отправителю сообщение ICMP.

Механизм IP- маршрутизации

1. Маршрутизатор проверяет IP-адрес входящего пакета и просматривает т аблицу, определяя, не является ли пунктом назначения локальная сеть.

2. Если IP-адрес назначения локальный, то маршрутизатор находит во внутреннем хранилище IP- и MAC-адресов локальных устройств MAC-адрес места назначения, помещает его в заголовок пакета и направляет пакет получателю.

3. Если MAC-адрес получателя не обнаруживается, маршрутизатор должен послать запрос о нем по IP-адресу получателя. Если после просмотра таблицы выясняется, что пакет не предназначен для локальной сети, маршрутизатор переправляет его маршрутизатору следующего сетевого сегмента, используя MAC-адрес последнего.

Зачем вообще нужно IP упаковывать в Ethernet, почему не сделали один протокол?

08.04.2013, 21:26

Зачем упаковывать структуры и объекты в интерфейсы?
Объясните пожалуйста кто-нибудь человеческим языком зачем упаковывать структуры и объекты в.

Зачем нужно вообще Моделирование в целом?
Здравствуйте всем! хотел бы поинтересоваться зачем нужна вообще Моделирование? я знаю что по.

Нужно узнать зачем здесь эдит и что делать вообще
Нужно узнать.зачем здесь эдит и что делать вообще

Зачем вообще нужно слово NULL если можно просто написать 0?
Для чего нужны все эти слова как например NULL, EOF? Вместо них можно просто цифры написать.

Зачем сделали const_cast?
Вот в C# я могу например же символу не константе присвоить значение символа константы без всякого.

09.04.2013, 07:28 2
09.04.2013, 21:26 [ТС] 3

Ethernet делится на
LLC — Logical link control
и MAC — Media Access Control

а TCP-IP вообще стек протоколов(типа OSI только менее эталонный и более практичный)
Так-что odip, давай дальше размышлять над вопросом

10.04.2013, 09:43 4

Ethernet делится на
LLC — Logical link control
и MAC — Media Access Control

а TCP-IP вообще стек протоколов(типа OSI только менее эталонный и более практичный)

Мне кажется что причина в том что Ethernet и IP работают на разных уровнях
На каждом уровне адресация своя собственная
Адресацию на физическом уровне передачи делают более удобной для этой самой передачи
Специально под IP они не затачиваются

Кроме этого Ethernet и TCP-IP развивались отдельно друг от друга
Раньше поверх Ethernet использовались другие протоколы — IPX, NetBIOS
Доминирование TCP-IP появилось намного позже

Разумеется никому не пришло в голову выкинуть весь Ethernet и сделать новый Ethernet2,
который заточен специально на передачу TCP-IP

И кроме этого IP передается поверх и других протоколов — ADSL, VDSL, поверх оптики
Ты предлагаешь все выкинуть, переделать все эти протоколы под IP ?

И кроме этого IP бывает IPv4, IPv6
Под какой IP будешь затачивать протоколы — под IPv4 или под IPv6 ?

Добавлено через 1 минуту
Оптика — это не один протокол, а целое семейство с разными скоростями

Добавлено через 6 минут
Ну и самое главное — TCP/IP делался так чтобы разные уровни были независимы друг от друга
Это дает большие преимущества — например можно гонять IP поверх самых разных физических каналов
Не зря ведь TCP/IP так распространился

Ты предлагаешь сэкономить немного байтов и лишиться этого преимущества
А ведь все конкуренты которые так делали фактически сдохли

10.04.2013, 09:43
10.04.2013, 14:31 [ТС] 5

Начнем с того что Ethernet — это часть TCP IP (по крайней мере везде так написано, это конешно все условность), и что-то типа Ethernet II уже давно существует (кадры например Ethernet Type II, протоколы приоритезации, вланов,аутентификации, и т.д.), а также именно по этому создана куча фишек на канальном уровне, которые на сетевом решать глупо — т.к. нарушится принцип инкапсуляции.

Но речь не об этом — речь о том, зачем дублировать функционал адресации на 2 и 3 уровнях.

А вот это уже здравое звено, для размышлений.

Я пришел к тому, что канальный уровень, существует отдельно:
1. Потому что так сложилось
2. Видимо есть какая-то взаимосвязь с принципами коммутации пакетов и каналов, и чтобы на верхних уровнях непариться об особенностях передачи по тому или иному виду каналу, такой протокол существует отдельно.
3. Но при всем при этом, функционал адресации, TTL вполне могли бы быть в одном протоколе, просто тогда он станет чуть менее универсальный, прийдется Ethernet уже инкапсулировать в другие протоколы, хотя не так уж и часто дело обстоит иначе.

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

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

10.04.2013, 19:27 6

Надо же
Это и есть независимость уровней

И насколько я понимаю TCP-IP — это пакетная передача
Никакой коммутации каналов в нем НЕТ !

TTL — это тот TTL который в IP-пакетах ?
Так он и есть в одном протоколе — в IP-пакете
В Ethernet что-то я никакого TTL не помню

Добавлено через 1 минуту

10.04.2013, 21:38 7

подругому даже не ответишь.

11.04.2013, 01:15 [ТС] 8

Дорогой это отлично что вы читаете википедию, давайте без флуда, OSI мне известна уже лет 10. Тут обсуждение рациональности отдельных технологий. Целесообразность данного обсуждения не зависит от эталоности какой либо модели. Если сомневаетесь, ознакомьтесь с понятиями «Эталонная, Идеальный и Модель» — в реальном мире нет места таким вещам (эталон он 1, остальные от него отличаются), только в мире идеальном И в догонку — обсуждается стек протоколов TCP/IP который в принципе имеет сами знаете сколько расхождений с эталоном.
Дальнейший подобный флуд — будет проигнорирован.

Что бред? Стек протоколов TCP/IP включает в Себя протокол Ethernet. (Когда говорят о TCP IP, подразумевают это обычно. Стек протоколов — это набор протоколов работающих поверх друг друга — потому и назван стеком, вы не знали?) Это новость для Вас?

11.04.2013, 07:11 9

1) По-моему фраза «Стек протоколов TCP/IP включает в Себя протокол Ethernet.» обозначает что спецификация TCP-IP включает в себя спецификацию Ethernet, что бред и есть

11.04.2013, 07:42 10
11.04.2013, 09:44 [ТС] 11

Речь шла о целесообразности дублирования функционала адресации в IP/Ethernet. Не кажется ли вам, что наличие двух разных адресов на канальном уровне и сетевом — нарушает принцип инкапсуляции?

odip, вот Вы , Эксперт C++, когда напишете класс «Дом» наследник от «Здание», будете добавлять новое поле «Координаты»?, или будете использовать такое же поле, которое уже есть в классе «Здание»?(при том, что вы Архи-Архитектор, которому подвластна стандартизация системы координат — таковыми являются ребята которые открытые протоколы внедряют)

11.04.2013, 17:35 12

А ты не путай программирование и реальные физические технологии
Считаю эту аналогию весьма хромой — например программу я могу и переписать и раздать всем новую версию
Тогда выкинуть все Ethernet-адаптеры я уже не очень могу

Добавлено через 4 минуты

А не кажется тебе что адреса немного разные по структуре ?
MAC-адрес фактически планарный
IP-адрес структурирован
Кроме этого чего ты прицепился к Ethernet — есть и другие технологии где адрес канального уровня черт знает как выглядит

Кстати если посмотреть на IPv6-адрес — то там можно сказать что при определенной автоматической конфигурации часть IPv6-адреса состоит из MAC-адреса сетевой карты Ethernet

11.04.2013, 18:20 [ТС] 13

Какая разница какой адрес, он для одной цели служит.

А дело не в программировании, принципы программирования не просто так придуманы (и вообще это больше принцип проектирования ИС чем программирования), благодаря им меньше дырок, и лучше «понятность» технологий что ли.
А в результате этой фигни с адресацией появляется избыточность требующая лишних телодвижений типа ARP RARP, следом за этим появляются дыры и становится возможным что-нибудь типа ARP-Spoofing.

Выкинуть Ethernet адаптеры не получится, а вот внедрить новую технологию — с поддержкой старой, за счет постепенного перехода, более чем возможно.
Если ты помнишь в Ethernet так уже поступали: в Fast-Ethernet, Gigabit-Ethernet, и незнаю че там дальше — ни кто так и неубрал CSMA/CD — то есть подключай себе по топологии Шина свои девайсы (кстати неразу не пробывал, но — что будет работать описано в дюжине источников), когда все уже давно на свичах.

11.04.2013, 21:06 14

И что ?
Кто мешает тебе использовать подмену IP-адреса ?

И RARP кстати вовсе не для лишних телодвижений используется

Добавлено через 1 минуту

Очень странное утверждение

Добавлено через 1 минуту

11.04.2013, 21:24 [ТС] 15

И сейчас никто не мешает, но если ты отправляешь сообщение с подменой своего адреса — с этим еще легко бороться.

А вот если, устройство — которое решает кому отправить сообщение, думает что ты тот — кем ты не являешься, это уже совершенно другая проблема.

12.04.2013, 07:31 16
12.04.2013, 08:03 17

PCK, odip, Вы о чем спорите?
Ethernet это вообще НЕ ПРОТОКОЛ! Это сборник стандартов в которые входит и модель OSI

«Стандарты Ethernet определяют проводные соединения и электрические сигналы на физическом уровне, формат кадров и протоколы управления доступом к среде — на канальном уровне модели OSI. Ethernet в основном описывается стандартами IEEE группы 802.3. «

odip, TCP это не пакетный протокол, а потоковый, так для справки )

Добавлено через 3 минуты
PCK, Приведу пример. Вот ты например ездишь на работу или учебу на транспорте, до остановки или стоянки машины ходишь на своих ногах. Так вот, то о чем ты говоришь в этой теме равносильно «А давай отрежем ему ноги, ведь на автобусе он и без ног ездить сможет. «

Добавлено через 20 минут
PCK, Теперь что касается «дублирования» адресации. Я отправляю данные по TCP хрен знает куда, в другую точку планеты и хочу, что бы туда они дошли именно в таком виде в каком я их отправил. Через какие сети эти данные пройдут и с какими архитектурами построения сетей, по каким кабелям и т.д. меня не должно волновать, мне не нужно это знать, я просто хочу что бы данные дошли. Железка, когда получает данные, ей пофиг кто их отправил, она просто должна знать какой железке передать их дальше, конечная цель маршрута ее не волнует и ни о чем ей не говорит. Вот именно для этого придумана многоуровневая модель и все эти стандарты, каждый из которых имеет свою важную роль! Эти стандарты и протоколы разрабатывала специальная комиссия из специалистов высокого уровня, так что все придумано совсем не просто так.

Сетевые протоколы. Межсетевой протолок IP. Протокол управления передачей TCP.

Сетевые протоколы.

IP-ФРАГМЕНТАЦИЯ

В данном документе мы рассмотрим, что такое IP фрагментация, как она происходит и почему является нежелательным явлением в сетях, а также рассмотрим пару сценариев как ее предотвратить.

ПРОТОКОЛ GRE

GRE (Generic Routing Encapsulation) — протокол туннелирования сетевых пакетов, разработанный фирмой Cisco. Протокол GRE обеспечивает механизм инкапсуляции произвольных пакетов в произвольный транспортный протокол. В наиболее общем случае система имеет пакеты, которые нужно инкапсулировать и маршрутизировать (информационные пакеты). Информация (payload) сначала инкапсулируется в пакет GRE, который может также содержать маршрут.

КОНФИГУРИРОВАНИЕ GRE ТУННЕЛЕЙ В TCP/IP

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

ЗАЩИТА СТЕКА TCP/IP ОТ SYN АТАК

Большинство людей знает, насколько может быть проблематична защита от SYN-атак. Обычно используются несколько более или менее эффективных методов. Почти в каждом случае, основным решением является правильная фильтрация пакетов. В дополнение к созданию пакетных фильтров, администратором может быть выполнена модификация TCP/IP стека данной операционной системы. Данный метод — настройка TCP/IP стека в различных операционных системах, и будет описан ниже.

ПРОТОКОЛ SSTP

SSTP (Secure Socket Tunneling Protocol – протокол безопасного туннелирования сокетов) и его возможности для VPN в будущем.

ПРОТОКОЛ SNMP

С расширением компьютерных сетей возникла необходимость управлять ими. Это просто непрактично постоянно переходить c рабочей станции на сервер и назад на рабочую станцию, чтобы убедиться, что все в порядке. Вот здесь в игру вступает Протокол управления простыми сетями (SNMP).

ПРОТОКОЛ TFTP

В настоящей жизни у всех нас есть родственники, близкие и не очень. Если провести параллель с сетевым миром, то картина выглядит похожей. В данной статье мы рассмотрим двоюродного брата протокола FTP протокол TFTP (Trivial File Transfer Protocol – Протокол передачи обычных файлов). Они обладают одинаковыми свойствами, но в то же самое время у них есть и некоторые существенные различия.

ПРОТОКОЛ UDP

Передача информации из интернет происходит при помощи транспортных протоколов. Существует два транспортных протокола — TCP и UDP. В этой статье мы рассмотрим User Datagram Protocol или UDP.

ПРОТОКОЛ FTP

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

ПРОТОКОЛ NNTP

Все знают о таких программах для работы в одноранговой сети, как Napster, Kazaa и т.д. Однако сколько человек знают о новостных группах в двоичном формате? Держу пари, что немногие. Подобные группы основаны на протоколе NNTP, который и является основной целью написания настоящей статьи. Итак, читайте, чтобы узнать больше о NNTP!

УСТРАНЕНИЕ НЕИСПРАВНОСТЕЙ TCP/IP: СТРУКТУРНЫЙ ПОДХОД

О чем вы думаете, когда слышите фразу «устранение неисправностей с TCP/IP»? Люди, которые обладают хорошим воображением могут сразу представить блок-схему. Люди более прямолинейного склада ума могут увидеть последовательность определенных шагов. А все остальные почувствуют себя потерянно и неадекватно. Устранение неисправностей, связанных с TCP/IP, должно быть просто, верно? Ведь кроме всего, это всего лишь протокол—серия определенных действий по передачи битов по сети. Но что это за протокол – четыре уровня, и несколько протоколов на каждом из уровней.

НЕКОТОРЫЕ СЕКРЕТЫ IP-ПРОТОКОЛА

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

IP АДРЕС: ОПРЕДЕЛЕНИЕ И СОКРЫТИЕ

Как известно, Internet основана на семействе протоколов tcp/ip, определяющих, каким образом осуществляется взаимодействие между подключенными к сети компьютерами. Идентификация этих компьютеров осуществляется с помощью так называемых IP-адресов, каждый из которых представляет собой уникальный 32-битный идентификатор, обычно записываемый в виде четырех десятичных чисел, напрмер, 192.168.0.1. И с точки зрения адресации сервер, обрабатывающий ежесекундно тысячи запросов практически ничем не отличается от вашего компьютера, подключаемого к сети по dial-up. Единственная разница — домашний пользователь, как правило, получает так называемый динамический ip-адрес, меняющийся от подключения к подключению.

1 Межсетевой протокол IP

Модуль IP является базовым элементом технологии internet, а центральной частью IP является его таблица маршрутов. Протокол IP использует эту таблицу при принятии всех решений о маршрутизации IP-пакетов. Содержание таблицы маршрутов определяется администратором сети. Ошибки при установке маршрутов могут заблокировать передачи.

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

На рисунке показана небольшая IP-сеть, состоящая из 3 машин: A, B и C. Каждая машина имеет такой же стек протоколов TCP/IP как на рис.1. Каждый сетевой адаптер этих машин имеет свой Ethernet-адрес. Менеджер сети должен присвоить машинам уникальные IP-адреса.

Рис.6. Простая IP-сеть

Когда A посылает IP-пакет B, то заголовок IP-пакета содержит в поле отправителя IP-адрес узла A, а заголовок Ethernet-кадра содержит в поле отправителя Ethernet-адрес A. Кроме этого, IP-заголовок содержит в поле получателя IP-адрес узла B, а Ethernet-заголовок содержит в поле получателя Ethernet-адрес B.

адрес

отправитель

получатель

Табл.5. Адреса в Ethernet-кадре, передающем IP-пакет от A к B.

В этом простом примере протокол IP является излишеством, которое мало что добавляет к услугам, предоставляемым сетью Ethernet. Однако протокол IP требует дополнительных расходов на создание, передачу и обработку IP-заголовка. Когда в машине B модуль IP получает IP-пакет от машины A, он сопоставляет IP-адрес места назначения со своим и, если адреса совпадают, то передает датаграмму протоколу верхнего уровня.

В данном случае при взаимодействии A с B используется прямая маршрутизация.

На рисунке представлена более реалистичная картина сети internet. В данном случае сеть internet состоит из трех сетей Ethernet, на базе которых работают три IP-сети, объединенные шлюзом D. Каждая IP-сеть включает четыре машины; каждая машина имеет свои собственные IP- и Ethernet адреса.

Рис.7. Сеть internet, состоящая из трех IP-сетей

За исключением D все машины имеют стек протоколов, аналогичный показанному на рисунке. Шлюз D соединяет все три сети и, следовательно, имеет три IP-адреса и три Ethernet-адреса. Машина D имеет стек протоколов TCP/IP, похожий на тот, что показан на рис.3, но вместо двух модулей ARP и двух драйверов, он содержит три модуля ARP и три драйвера Ethernet. Обратим внимание на то, что машина D имеет только один модуль IP.

Менеджер сети присваивает каждой сети Ethernet уникальный номер, называемый IP-номером сети. Нарис.7 IP-номера не показаны, вместо них используются имена сетей.

Когда машина A посылает IP-пакет машине B, то процесс передачи идет в пределах одной сети. При всех взаимодействиях между машинами, подключенными к одной IP-сети, используется прямая маршрутизация, обсуждавшаяся в предыдущем примере.

Когда машина D взаимодействует с машиной A, то это прямое взаимодействие. Когда машина D взаимодействует с машиной E, то это прямое взаимодействие. Когда машина D взаимодействует с машиной H, то это прямое взаимодействие. Это так, поскольку каждая пара этих машин принадлежит одной IP-сети.

Однако, когда машина A взаимодействует с машинами, включенными в другую IP-сеть, то взаимодействие уже не будет прямым. Машина A должна использовать шлюз D для ретрансляции IP-пакетов в другую IP-сеть. Такое взаимодействие называется «косвенным».

Маршрутизация IP-пакетов выполняется модулями IP и является прозрачной для модулей TCP, UDP и прикладных процессов.

Если машина A посылает машине E IP-пакет, то IP-адрес и Ethernet-адрес отправителя соответствуют адресам A. IP-адрес места назначения является адресом E, но поскольку модуль IP в A посылает IP-пакет через D, Ethernet-адрес места назначения является адресом D.

адрес

отправитель

получатель

Табл.6. Адреса в Ethernet-кадре, содержащем IP-пакет от A к E (до шлюза D).

Модуль IP в машине D получает IP-пакет и проверяет IP-адрес места назначения. Определив, что это не его IP-адрес, шлюз D посылает этот IP-пакет прямо к E.

адрес

отправитель

получатель

Табл.7. Адреса в Ethernet-кадре, содержащем IP-пакет от A к E (после шлюз D)

Итак, при прямой маршрутизации IP- и Ethernet-адреса отправителя соответствуют адресам того узла, который послал IP-пакет, а IP- и Ethernet-адреса места назначения соответствуют адресам получателя. При косвенной маршрутизации IP- и Ethernet-адреса не образуют таких пар.

В данном примере сеть internet является очень простой. Реальные сети могут быть гораздо сложнее, так как могут содержать несколько шлюзов и несколько типов физических сред передачи. В приведенном примере несколько сетей Ethernet объединяются шлюзом для того, чтобы локализовать широковещательный трафик в каждой сети.

Правила маршрутизации в модуле IP

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

Для отправляемых IP-пакетов, поступающих от модулей верхнего уровня, модуль IP должен определить способ доставки — прямой или косвенный — и выбрать сетевой интерфейс. Этот выбор делается на основании результатов поиска в таблице маршрутов.

Для принимаемых IP-пакетов, поступающих от сетевых драйверов, модуль IP должен решить, нужно ли ретранслировать IP-пакет по другой сети или передать его на верхний уровень. Если модуль IP решит, что IP-пакет должен быть ретранслирован, то дальнейшая работа с ним осуществляется также, как с отправляемыми IP-пакетами.

Входящий IP-пакет никогда не ретранслируется через тот же сетевой интерфейс, через который он был принят.

Решение о маршрутизации принимается до того, как IP-пакет передается сетевому драйверу, и до того, как происходит обращение к ARP-таблице.

Менеджер сети присваивает IP-адреса машинам в соответствии с тем, к каким IP-сетям они подключены. Старшие биты 4-х байтного IP-адреса определяют номер IP-сети. Оставшаяся часть IP-адреса — номер узла (хостномер). Для машины из табл.1 с IP-адресом 223.1.2.1 сетевой номер равен 223.1.2, а хост-номер — 1. Напомним, что IP-адрес узла идентифицирует точку доступа модуля IP к сетевому интерфейсу, а не всю машину.

Существуют 5 классов IP-адресов, отличающиеся количеством бит в сетевом номере и хост-номере. Класс адреса определяется значением его первого октета.

В табл.8 приведено соответствие классов адресов значениям первого октета и указано количество возможных IP-адресов каждого класса.

Рис.8. Структура IP-адресов

Класс

Диапазон значений первого октета

Возможное кол-во сетей

Возможное кол-во узлов

Табл.8. Характеристики классов адресов

Адреса класса A предназначены для использования в больших сетях общего пользования. Они допускают большое количество номеров узлов. Адреса класса B используются в сетях среднего размера, например, сетях университетов и крупных компаний. Адреса класса C используются в сетях с небольшим числом компьютеров. Адреса класса D используются при обращениях к группам машин, а адреса класса E зарезервированы на будущее.

Некоторые IP-адреса являются выделенными и трактуются по-особому.

Рис.9. Выделенные IP-адреса

Как показано на рис.9, в выделенных IP-адресах все нули соответствуют либо данному узлу, либо данной IP-сети, а IP-адреса, состоящие из всех единиц, используются при широковещательных передачах. Для ссылок на всю IP-сеть в целом используется IP-адрес с нулевым номером узла. Особый смысл имеет IP-адрес, первый октет которого равен 127. Он используется для тестирования программ и взаимодействия процессов в пределах одной машины. Когда программа посылает данные по IP-адресу 127.0.0.1, то образуется как бы «петля». Данные не передаются по сети, а возвращаются модулям верхнего уровня, как только что принятые. Поэтому в IP-сети запрещается присваивать машинам IP-адреса, начинающиеся со 127.

Прежде чем вы начнете использовать сеть с TCP/IP, вы должны получить один или несколько официальных сетевых номеров. Выделением номеров (как и многими другими вопросами) занимается DDN Network Information Center (NIC)

SRI International, Room EJ210, 333 Ravenswood Avenue, Menlo Park, California 94025, USA. Тел. 1-800-235-3155. E-mail: NIC@NIC.DDN.MIL

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

Одно из важнейших решений, которое необходимо принять при установке сети, заключается в выборе способа присвоения IP-адресов вашим машинам. Этот выбор должен учитывать перспективу роста сети. Иначе в дальнейшем вам придется менять адреса. Когда к сети подключено несколько сотен машин, изменение адресов становится почти невозможным.

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

Адресное пространство сети internet может быть разделено на непересекающиеся подпространства — «подсети», с каждой из которых можно работать как с обычной сетью TCP/IP. Таким образом единая IP-сеть организации может строиться как объединение подсетей. Как правило, подсеть соответствует одной физической сети, например, одной сети Ethernet.

Конечно, использование подсетей необязательно. Можно просто назначить для каждой физической сети свой сетевой номер, например, номер класса C. Однако такое решение имеет два недостатка. Первый, и менее существенный, заключается в пустой трате сетевых номеров. Более серьезный недостаток состоит в том, что если ваша организация имеет несколько сетевых номеров, то машины вне ее должны поддерживать записи о маршрутах доступа к каждой из этих IP-сетей. Таким образом, структура IP-сети организации становится видимой для всего мира. При каких-либо изменениях в IP-сети информация о них должна быть учтена в каждой из машин, поддерживающих маршруты доступа к данной IP-сети.

Подсети позволяют избежать этих недостатков. Ваша организация должна получить один сетевой номер, например, номер класса B. Стандарты TCP/IP определяют структуру IP-адресов. Для IP-адресов класса B первые два октета являются номером сети. Оставшаяся часть IP-адреса может использоваться как угодно. Например, вы можете решить, что третий октет будет определять номер подсети, а четвертый октет — номер узла в ней. Вы должны описать конфигурацию подсетей в файлах, определяющих маршрутизацию IP-пакетов. Это описание является локальным для вашей организации и не видно вне ее. Все машины вне вашей организации видят одну большую IPсеть. Следовательно, они должны поддерживать только маршруты доступа к шлюзам, соединяющим вашу IP-сеть с остальным миром. Изменения, происходящие в IP-сети организации, не видны вне ее. Вы легко можете добавить новую подсеть, новый шлюз и т.п.

Как назначать номера сетей и подсетей

После того, как решено использовать подсети или множество IP-сетей, вы должны решить, как назначать им номера. Обычно это довольно просто. Каждой физической сети, например, Ethernet или Token Ring, назначается отдельный номер подсети или номер сети. В некоторых случаях имеет смысл назначать одной физической сети несколько подсетевых номеров. Например, предположим, что имеется сеть Ethernet, охватывающая три здания. Ясно, что при увеличении числа машин, подключенных к этой сети, придется ее разделить на несколько отдельных сетей Ethernet. Для того, чтобы избежать необходимости менять IP-адреса, когда это произойдет, можно заранее выделить для этой сети три подсетевых номера — по одному на здание. (Это полезно и в том случае, когда не планируется физическое деление сети. Просто такая адресация позволяет сразу определить, где находится та или иная машина.) Однако прежде, чем выделять три различных подсетевых номера одной физической сети, тщательно проверьте, что все ваши программы способны работать в такой среде.

Вы также должны выбрать «маску подсети». Она используется сетевым программным обеспечением для выделения номера подсети из IP-адресов. Биты IP-адреса, определяющие номер IP-сети, в маске подсети должны быть равны 1, а биты, определяющие номер узла, в маске подсети должны быть равны 0. Как уже отмечалось, стандарты TCP/IP определяют количество октетов, задающих номер сети. Часто в IP-адресах класса B третий октет используется для задания номера подсети. Это позволяет иметь 256 подсетей, в каждой из которых может быть до 254 узлов. Маска подсети в такой системе равна 255.255.255.0. Но, если в вашей сети должно быть больше подсетей, а в каждой подсети не будет при этом более 60 узлов, то можно использовать маску 255.255.255.192. Это позволяет иметь 1024 подсети и до 62 узлов в каждой. (Напомним, что номера узлов 0 и «все единицы» используются особым образом.)

Обычно маска подсети указывается в файле стартовой конфигурации сетевого программного обеспечения. Протоколы TCP/IP позволяют также запрашивать эту информацию по сети.

Людям удобнее называть машины по именам, а не числами. Например, у машины по имени alpha может быть IP-адрес 223.1.2.1. В маленьких сетях информация о соответствии имен IP-адресам хранится в файлах «hosts» на каждом узле. Конечно, название файла зависит от конкретной реализации. В больших сетях эта информация хранится на сервере и доступна по сети. Несколько строк из файла «hosts» могут выглядеть примерно так:

В первом столбце — IP-адрес, во втором — название машины.

В большинстве случаев файлы «hosts» могут быть одинаковы на всех узлах. Заметим, что о узле delta в этом файле есть всего одна запись, хотя он имеет три IP-адреса (рис.11). Узел delta доступен по любому из этих IP-адресов. Какой из них используется, не имеет значения. Когда узел delta получает IP-пакет и проверяет IP-адрес места назначения, то он опознает любой из трех своих IP-адресов.

IP-сети также могут иметь имена. Если у вас есть три IP-сети, то файл «networks» может выглядеть примерно так:

В первой колонке — сетевой номер, во второй — имя сети.

В данном примере alpha является узлом номер 1 в сети development, beta является узлом номер 2 в сети development и т.д.

Показанный выше файл hosts удовлетворяет потребности пользователей, но для управления сетью internet удобнее иметь названия всех сетевых интерфейсов. Менеджер сети, возможно, заменит строку, относящуюся к delta:

223.1.2.4 devnetrouter delta

Эти три строки файла hosts задают каждому IP-адресу узла delta символьные имена. Фактически, первый IP-адрес имеет два имени: «devnetrouter» и «delta», которые являются синонимами. На практике имя «delta» используется как общеупотребительное имя машины, а остальные три имени — для администрирования сети.

Файлы hosts и networks используются командами администрирования и прикладными программами. Они не нужны собственно для работы сети internet, но облегчают ее использование.

Как модуль IP узнает, какой именно сетевой интерфейс нужно использовать для отправления IP-пакета? Модуль IP осуществляет поиск в таблице маршрутов. Ключом поиска служит номер IP-сети, выделенный из IP-адреса места назначения IP-пакета.

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

В большинстве систем таблица маршрутов может быть изменена с помощью команды «route». Содержание таблицы маршрутов определяется менеджером сети, поскольку менеджер сети присваивает машинам IP-адреса.

Подробности прямой маршрутизации

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

Рис.10. Одна физическая сеть

Таблица маршрутов в узле alpha выглядит так:

флаг вида маршрутизации

Табл.9. Пример таблицы маршрутов

В данном простом примере все узлы сети имеют одинаковые таблицы маршрутов.

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

флаг вида маршрутизации

Табл.10. Пример таблицы маршрутов с номерами сетей.

Порядок прямой маршрутизации

Узел alpha посылает IP-пакет узлу beta. Этот пакет находится в модуле IP узла alpha, и IP-адрес места назначения равен IP-адресу beta (223.1.2.2). Модуль IP с помощью маски подсети выделяет номер сети из IP-адреса и ищет соответствующую ему строку в таблице маршрутов. В данном случае подходит первая строка.


Остальная информация в найденной строке указывает на то, что машины этой сети доступны напрямую через интерфейс номер 1. С помощью ARP-таблицы выполняется преобразование IP-адреса в соответствующий Ethernet-адрес, и через интерфейс 1 Ethernet-кадр посылается узлу beta.

Если прикладная программа пытается послать данные по IP-адресу, который не принадлежит сети development, то модуль IP не сможет найти соответствующую запись в таблице маршрутов. В этом случае модуль IP отбрасывает IP-пакет. Некоторые реализации протокола возвращают сообщение об ошибке «Сеть не доступна».

Подробности косвенной маршрутизации

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

Таблица маршрутов в узле alpha выглядит так:

Курс по основам компьютерных сетей на базе оборудования Cisco. Этот курс поможет вам подготовиться к экзаменам CCENT/CCNA, так как за его основу взят курс Cisco ICND1.

4.1 Протокол IP (IPv4) и его назначение

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей, начнем разбираться с протоколом IP и особенностями его работы. На данный момент каких-то серьезных альтернатив у протокола IP на сетевом уровне нет, поэтому бок о бок работают две версии этого протокола: IPv4 и IPv6. IPv4 преобладает просто потому, что появился значительно раньше, а версия IPv6 более продумана и лишена многих недостатков IPv4, но она по-прежнему является протоколом IP и в ее основе лежат всё те же принципы работы. Четвертая часть у нас будет про IPv4, новую версию мы трогать пока не будем, поскольку в самом конце нашего курса будет тема про IPv6.

Если тема компьютерных сетей вам интересна, то можете ознакомиться с другими записями курса.

4.1.1 Введение

Этой темой мы открываем четвертую часть нашего курса на основе Cisco ICND1, в которой мы будем знакомиться с протоколом IP, а конкретно с его версией IPv4. Насколько глубоко мы будем рассмотрим протокол IPv4? Настолько, чтобы хватило спокойно настраивать и устранять проблемы в компьютерных сетях. То есть мы разберем все самые важные и основные вещи, связанные с IPv4, необходимые администратору компьютерной сети, но не будем вдаваться в неважные тонкости, которые больше интересны и важны разработчикам сетевого оборудования и его программного обеспечения.

Мы не будем разбираться с историей появления протокола IPv4 и его предшественниками, так как жалко тратить время на информацию, которая никому не пригодится. В первой теме мы познакомимся с протоколом IP и посмотрим на него в общих чертах, то есть первая наша тема — это коротко обо всем, что будет в этой части.

4.1.2 Роль и назначение протокола IP в модели TCP/IP

Internet Protocol или IP— маршрутизируемый протокол сетевого уровня модели стека протоколов TCP/IP. Благодаря протоколу IP существует нынешняя сеть Интернет, поскольку именно этот протокол стал связующей нитью между разрозненными компьютерными сетями во всем мире. На данный момент нам нужно выделить два ключевых понятия в протоколе IP: минимально единицей измерения данных здесь является IP-пакет (о единицах измерения в компьютерных сетях), который чаще всего инкапсулируется в Ethernet кадр, а также каждый узел на сетевом уровне в модели TCP/IP должен иметь IP-адрес.

Мы уже не раз говорили, что протокол IP относится к сетевому уровню модели TCP/IP, это также справедливо и для эталонной модели OSI 7. Также мы уже не раз применяли этот протокол на практике, а значит косвенно касались вопроса о значении протокола IP в компьютерных сетях или сетях передачи данных. Если говорить коротко, то протокол IP нужен для логической адресации устройств в компьютерной сети или сети передачи данных.

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

А, например, в моей домашней сети есть четыре устройства, которые подключатся к роутеру, то есть моя домашняя сеть состоит из пяти железяк, для этих пяти железяк на роутере выделена сеть 192.168.1.0/24, это означает, что чисто теоретически в этой сети может работать сразу 254 устройства включая роутер, так как IP-адрес 192.168.1.0 – это номер сети, а адрес 192.168.1.255 – это адрес широковещательной рассылки (эти адреса нельзя задавать узлам сети), пропинговав который можно опросить все узлы данной сети. Но главное здесь то, что у каждого устройства должен быть уникальный IP-адрес из выделенной подсети, например, у роутера будет адрес 192.168.1.1, у настольного ПК будет адрес 192.168.1.2, а у ноутбука 192.168.1.3, а если я захочу подключиться к роутеру мобильным телефоном, то на нем нужно будет настроить любой адрес от 192.168.1.4 до 192.168.1.254, чтобы этот телефон смог взаимодействовать с другими устройствами моей локальной сети.

Какие выводы мы делаем? Правильно, первая функция протокола IP заключается в том, чтобы дать уникальные имена узлам в компьютерной сети. Чтобы было более наглядно обратите внимание на Рисунок 4.1.1, на нем показана схема, описанная словами выше.

Рисунок 4.1.1 Пример использования IP-адресов в локальной сети

Стоит обратить внимание на то, что сейчас для нас неважно как узлы получают IP-адреса: назначаются они руками, или их выдает DHCP-сервер, также мы сейчас даже не затрагиваем вопрос: как частные IP-адреса превращаются в публичные при выходе в сеть Интернет, забегая вперед отмечу, что делается это при помощи протокола NAT.

Вторая функция протокола IP заключает в том, чтобы предоставить услугу вышестоящему уровню, то есть транспортному уровню. Тут нужно заметить, что модель TCP/IP не предполагает взаимодействие с установлением соединения на сетевом уровне, вид взаимодействия определяется транспортным уровнем (при помощи выбора одного из двух протоколов: TCP или UDP), следовательно сам протокол IP работает без установления соединения и как бы это странно не прозвучала, но услугой протокола IP для транспортного уровня является передача данных между сетями или же транспортировка. То есть протоколы TCP и UDP рассматривают IP как рабочую лошадку, которая таскает пакеты из точки А в точку Б, минуя множество различных подсетей, если мы говорим о сети Интернет.

Как мы знаем, протокол IP связан с канальным уровнем при помощи протокола ARP, который можно отнести к метафорическому уровню 2.5, так как он работает между канальным и сетевым уровнем. Сейчас мы этот факт просто для себя отмечаем и запоминаем, в дальнейшем пригодится. Также на сетевом уровне работают протоколы динамической маршрутизации, такие как OSPF, IS-IS, RIP, EIGRP, в английской литературе эти протоколы объединены общим словом Routing, то есть те, кто маршрутизирует, сам же IP именуется Routed, то есть тот, кого маршрутизируют. Internet Control Message Protocol или просто ICMP также относится к сетевому уровню. Просто чтобы напомнить приведу здесь рисунок, на котором показана модель TCP/IP.

Рисунок 4.1.2 Модель стека протоколов TCP/IP

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

Протоколу IP не важно какими характеристиками обладает компьютерная сеть, какая топология у сети передачи данных, протоколу IP даже не важно поверх какого протокола канального уровня работать, протокол IP будет точно будет работать, если между устройствами будет один из следующих каналов: Ethernet (например, IP поверх Ethernet II есть RFC 894), ATM (RFC 1932), линки типа точка-точка (например, протоколы PPP или HDLC), есть даже документ, описывающий работу протокола IP поверх голубей (RFC 1149), и это далеко не полный список. Протоколу IP не важен даже размер компьютерной сети, его можно использовать как в сетях BAN, так и в сетях WAN.

4.1.2 Типы адресов в модели TCP/IP

Теперь стоит поговорить не конкретно о видах IP-адресов, а о видах адресов в сети, построенной по архитектуре TCP/IP, тут для нас будут важны четыре вида адресов:

  • локальные адреса, для нас это будут MAC-адреса;
  • сетевые адреса, естественно, в нашем случае это IP-адреса;
  • адреса транспортного уровня;
  • символьные адреса или доменные имена.

Начнем двигаться снизу-вверх по иерархии модели TCP/IP.

4.1.2.1 Локальные адреса или мак-адреса

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

Рисунок 4.1.3 Схема, в которой четыре узла и две подсети

Здесь мы видим четыре узла, для них подписаны IP-адреса и маски подсети в префиксной записи, где /24 означает, что в маски подсети двадцать четыре единицы, из подписей можно сделать вывод, что стационарные ПК находятся в одной канальной среде или в одной подсети, а ноутбуки находятся в другой подсети. В данном случае взаимодействие между этими подсетями невозможно, то есть ноутбук не сможет достучаться до компьютера и наоборот, поскольку узлы соединены коммутатором, а как вы помните, обычный L2 коммутатор ничего не знает про IP-адреса (хорошо еще, что здесь мы не использовали хаб/сетевой концентратор, который работает на физическом уровне), он оперирует MAC-адресами (про разницу между хабами, коммутаторами и роутерами можно почитать здесь).

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

Как же тогда сделать так, чтобы компьютер смог общаться с ноутбуком? Тут у нас два варианта: первый заключается в том, чтобы «поместить» ноутбуки в одну подсеть с компьютерами, изменив их сетевые настройки, ну например: Laptop1 задать адрес и маску 192.168.2.3/24, а второму 192.168.2.4/24. Второй вариант заключается в использование роутера, тогда один интерфейс роутера будет смотреть в сеть с ноутбуками и на этом интерфейсе будет задан адрес из этой подсети, например, IP-адрес 192.168.1.3/24, а второй интерфейс роутера будет смотреть в сеть стационарных ПК и на нем будет задан адрес из этой подсети: 192.168.2.25/24.

Но это еще не все, для устройств из подсети «компьютеры» нам нужно будет прописать основной шлюз: 192.168.2.25, таким образом компьютеры будут знать: на какое устройство слать пакеты, если IP-адрес не из их локальной сети, ну а устройствам из сети «ноутбуки» нужно задать шлюз по умолчанию 192.168.1.3, для этих же целей. Что делает с Ethernet кадрами и IP-пакетами роутер, когда пересылает данные из одной сети в другую, мы смотрели, когда говорили про назначение роутеров и более обстоятельно эта тема раскрыта в теме разница между хабами коммутаторами и роутерами, сейчас на этом не останавливаемся, но для наглядности приведу схему.

Рисунок 4.1.4 Схема, в которой четыре узла, две подсети и роутер

Наша схема преобразилась и теперь в ней есть роутер, обратите внимание: в данном случае один физический порт роутера смотрит в сеть «компьютеры», а второй физический порт роутера смотрит в сеть «ноутбуки», граница между этими канальными средами проходит по роутеру, а у каждого порта роутера свой мак-адрес, дело все в том, что устройства из подсети будут обращаться к своему порту роутера при помощи мак-адреса. Собственно, по этой причине мак-адреса называют локальными, так как они нужны для взаимодействия в пределах одной подсети. Если вы не понимаете обозначения на схеме, то рекомендую ознакомится с темой «Условные обозначения Cisco и стандартные физические компоненты компьютерной сети».

Все схемы собраны в программе Cisco Packet Tracer, вот инструкция по установке Cisco Packet Tracer в Windows, а вот мануал по установке Packet Tracer на Linux дистрибутив Ubuntu. Чтобы быстро разобраться с интерфейсом Cisco Packet Tracer, вы можете ознакомиться с публикацией простая схема сетевого взаимодействия.

4.1.2.2 Сетевые адреса или IP-адреса

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

В нашем случае, описанном выше, номер сети «ноутбуки» выглядит так: 192.168.1.0, в этой сети у нас три узла, у каждого из этих узлов есть номер: у первого ноутбука это 1, у второго 2, а у порта роутера 3. По аналогии можно понять, что творится в подсети «компьютеры». Определять где заканчивается номер сети и начинается номер узла в IP-адресе мы научимся позже, сейчас просто обозначаем. Нам важно сделать вывод о том, что в Интернете все сети имеют уникальные номера, но и это еще не все, все узлы в этих сетях также имеют уникальные номера. То же самое справедливо и для локальной сети, если она разбита на подсети, например, как наша, у нас есть две сети с уникальными номерами: 192.168.1.0 и 192.168.2.0, а внутри этих сетей есть узлы, у которых тоже номера уникальны.

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

4.1.2.3 Адреса транспортного уровня

На транспортном уровне тоже есть свои адреса, эти адреса называются сокетами, которые представляют собой пару IP-адрес + номер TCP/UDP порта. Так, например, чтобы попасть на сайт по протоколу HTTP, наш компьютер будет посылать запрос удаленному серверу на 80-ый TCP порт, выглядеть это будет примерно так 192.168.1.1:80. Но это еще не все, дело в том, что серверу надо как-то ответить своему клиенту, для этого он тоже будет использовать TCP. А это означает, что клиент должен заранее позаботиться о том, чтобы сервер знал – на какой TCP порт нужно отвечать, поэтому в TCP-сегменте (так называются сообщения в протоколе TCP) указывается два порта: порт источника, чаще всего это случайно сгенерированное число и порт назначения (чаще всего этот порт относится к хорошо известным и закреплен за каким-нибудь протоколом), в нашем случае порт является хорошо известным (80 порт закреплен за HTTP).

Для примера, у нас есть компьютер с IP-адресом 10.10.10.25 и где-то в нашей сети есть веб-сервер, доступ к которому осуществляется по HTTPs, пусть у этого сервера будет IP-адрес 192.168.1.67. Тогда наш клиент сформирует TCP сообщение, в котором будет два сокета, сокет источника 10.10.10.25:45678 (в данном случае число 45678 является случайно сгенерированным), этим сокетом воспользуется сервер, чтобы ответить клиенту; а также у нас будет сокет назначения: 192.168.1.67:443, в данном случае число 443 означает, что мы обращаемся к серверу по протоколу HTTPs, TCP порт 443 является хорошо известным. Разобраться со схемой взаимодействия клиент-сервер, вам поможет эта публикация.

Какие выводы можно сделать? Да все очень просто! Адресация на транспортном уровне нужна и важна для конечных устройств. Именно благодаря ей конечные узлы понимают: для какого приложения приходят данные. Здесь мы поговорили очень сжато и скомкано, поскольку у нас будет отдельная тема по транспортному уровню, где мы все расставим по своим местам.

4.1.3 Версии протокола IP: IPv4 и IPv6

Из запланированного нам осталось коротко поговорить о версиях протокола IP, коих на данный момент две: IPv4 и IPv6. С версией IPv4 мы разберемся в данной теме, а вот версии IPv6 мы уделим свое внимание в отдельной теме ближе к концу. Сделаем поверхностный разбор каждой из представленных версий протокола IP.

Начнем с IPv4, цифра четыре здесь не означает четыре октета в IP-адресе, просто так случайно вышло. Больше всего нас интересует IP-адрес, под него в IPv4 выделено четыре байта или октета, как известно, в байте 8 бит, то есть восемь двоичных значений (0 или 1), следовательно, максимально возможное десятичное число равно 255, минимально допустимое 0. Думаю, приводить примеры IP-адресов для IPv4 не нужно, вам они уже знакомы. Более детальное описание у нас будет в отдельной теме.

Обмен информацией в IPv4 происходит при помощи IP-пакетов, у данной версии протокола этот пакет делится на два больших поля: поле данных, в котором переносится полезная информация и заголовок, в котором заложен весь функционал протокола, заголовок пакета IPv4 содержит 14 полей, тринадцать из которых обязательные и одно опциональное. Вообще, протокол IPv4 дает нам в распоряжение 2 в 32 степени IP-адресов или же 4 294 967 296. Но этих адресов уже начинает не хватать, дело все в том, что этот протокол был разработан 1980-ом году, тогда это число выглядело ужасающе большим, сейчас во времена интернет-чайников и тостеров со встроенным Wi-Fi этого пространства начинает не хватать.

Осознание того, что 4.2 млрд адресов не хватит начало приходить в 90-ых годах, а в 1996 году появился протокол IPv6, который должен когда-нибудь заменить IPv4. Дело всё в том, что под IP-адрес в IPv6 выделено 128 бит или 16 байт, а это уже совсем другая история. Теперь давайте попытаемся немного по сравнивать IPv4 и IPv6. Во-первых, IPv6 делает такую технологию, как NAT в текущих условиях бесполезной (для кого-то это плюс, а для кого-то это минус, поскольку NAT не только позволяет «перебивать» много частных IP-адресов в один публичный, но является первой линией защиты вашей компьютерной сети).

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

4.1.4 Выводы

Итак, что нам нужно вынести из этой темы? Да всё очень просто. Нам нужно запомнить, что IP-адрес состоит из двух частей: номер сети и номер узла, благодаря чему можно однозначно идентифицировать узел в сети Интернет. А также нам нужно помнить: сетевой уровень находится между транспортным и канальным, с канальным уровнем протокол IP в нашем случае взаимодействует при помощи протокола ARP, а для транспортного он является рабочей лошадкой, которая должна обеспечить транспорт между точкой А и точкой Б, и неважно что точка А где-нибудь в Японии, а Б в Египте.

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

Урок 5. Сетевой уровень. Описание протокола IP

К протоколам сетевого уровня относят 2 протокола: IP и ICMP. В этом уроке мы рассмотрим протокол IPv4.

IP (Internet Protocol) используется в качестве маршрутизируемого протокола, который перенаправляет пакеты от одного узла к другому, используя IP адреса. IP адрес представляет собой уникальный идентификатор сетевого устройства. С помощью данного идентификатора пакеты доставляются конечным узлам.

В отличие от протоколов верхних уровней IP протокол не устанавливает и не управляет соединениями, не контролирует передачу данных и не исправляет ошибки. Все эти функции возложены на протоколы транспортного и прикладного уровней.
При поступлении сегмента с транспортного уровня добавляется 20-ти байтный заголовок, хотя в некоторых случаях его длина может достигать и 60

Версия — версия протокола, для IPv4 равен 4.

IHL (Internet Header Length) — длина заголовка IP. Длина заголовка может иметь размеры от 20 до 60 байт. Поэтому данное поле указывает принимающему узлу где заканчивается заголовок и начинаются данные. Длина указывается в единицах по 4 байта, то есть 1 единица = 4 байта, 5 единиц = 20 байт, то есть значение 5 указывает на минимальную длину заголовка.

Длина пакета (Total Length) — длина пакета в байтах, включая сам заголовок и данные.

Тип обслуживания (Type Of Service, ToS) — определяет приоритетность в обслуживании пакетов. То есть пакет с высшим приоритетом будет обслужен в первую очередь.

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

Флаги — используются для фрагментации. Первый бит всегда равен 0. Второй бит DF (don’t fragment) разрешает или запрещает фрагментацию. Третий бит MF (more fragments) указывает на то, последний ли это фрагмент или имеются еще.

Смещение фрагмента (Fragment Offset) — определяет позицию фрагмента в потоке. Иными словами указывает на номер фрагмента.

Время жизни (Time To Live, TTL) — количество маршрутизаторов, через которое проходит пакет. После прохождения пакета через маршрутизатор значение TTL уменьшается на 1. Если TTL окажется равным 0, то пакет уничтожается, а отправителю посылается сообщение Time Exceeded по протоколу ICMP.

Для чего нужен TTL?

Для предотвращения зацикливания при маршрутизации. При неправильной конфигурации пакет может блуждать по сети бесконечно, поэтому и ввели такой параметр. Максимальное значение равно 255, то есть пакет может пройти максимум через 255 маршрутизаторов.

Протокол (Protocol) — указывает на протокол верхнего уровня (TCP, UDP, ICMP).

Контрольная сумма заголовка (Checksum) — вычисляется для проверки на наличие ошибок.

Опции (Options) — дополнительные параметры. Именно за счет этих параметров длина заголовка может увеличиваться.

Выравнивание (Padding) — заполняющие нули для выравнивания длины заголовка.

Рассмотрим упрощенную схему работы протокола.

На передаче:

На приеме:

Протокол IP при необходимости может дробить большие пакеты на более мелкие. Обычно такая необходимость возникает на стыковке сетей с различными технологиями канального уровня, например, Ethernet, ATM, FDDI, Token Ring и так далее. Кадры данных технологий имеют различную длину, которая называется MTU (Maximum Transmission Unit) — максимальный объем данных, который может уместиться в одном кадре.

Например, в Ethernet MTU равен 1500, в FDDI — 4096.
Кадр FDDI не сможет поместиться в кадре Ethernet, поэтому на этот случай и предусмотрен механизм фрагментации пакетов на сетевом уровне.

Порядок фрагментации следующий:

1) Проверяется флаг DF. Если он равен 1, то фрагментация не происходит ни при каких обстоятельствах и пакет уничтожается. Отправителю пакета посылается сообщение Fragmentation needed.

2) Если DF = 0, то исходный пакет делится на равные части. Последний фрагмент обычно меньше остальных.

3) Заголовок исходного пакета копируется в заголовки фрагментов, то есть все заголовки одинаковы.

4) В поле Identification всех фрагментов записывается уникальное и одинаковое число.

5) Во всех фрагментах, кроме последнего, флагу MF присваивается 1. В последнем фрагменте флаг MF равен 0.

6) В поле Fragment offset записывается положение фрагмента в общем потоке. В первом фрагменте это значение всегда равно 0.

Рассмотрим фрагментацию на простом примере. Необходимо фрагментировать пакет длиной в 300 байт на 3 части длиной по 100 байт.
Вот как выглядит заголовок исходного пакета

А вот как выглядят фрагменты после деления:

На приеме для сборки пакетов сравниваются следующие параметры:

1) IP адрес отправителя — у всех должны совпадать

2) IP адрес получателя — у всех должны совпадать

3) Identification — у всех должны совпадать

4) MF — у всех, кроме последнего должна быть 1

5) Fragment Offset — у всех разная

Если первые 3 параметра совпадают, то фрагменты собираются.

Некоторые секреты ip протокола

2.1. Классовая модель 2.2. Бесклассовая модель(CIDR) 2.3. Запись адресов в бесклассовой модели

1. Функции протокола IP

Протокол IP находится на межсетевом уровне стека протоколов TCP/IP. Функции протокола IP определены в стандарте RFC-791 следующим образом: “Протокол IP обеспечивает передачу блоков данных, называемых дейтаграммами, от отправителя к получателям, где отправители и получатели являются компьютерами, идентифицируемыми адресами фиксированной длины (IP-адресами). Протокол IP обеспечивает при необходимости также фрагментацию и сборку дейтаграмм для передачи данных через сети с малым размером пакетов”.

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

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

Одна из основных задач, решаемых протоколом IP, — маршрутизация дейтаграмм, т.е. определение пути следования дейтаграммы от одного узла сети к другому на основании адреса получателя.

Общий сценарий работы модуля IP на каком-либо узле сети, принимающего дейтаграмму из сети, таков:

  • с одного из интерфейсов уровня доступа к среде передачи (например, с Ethernet-интерфейса) в модуль IP поступает дейтаграмма;
  • модуль IP анализирует заголовок дейтаграммы;
  • если пунктом назначения дейтаграммы является данный компьютер:
    • если дейтаграмма является фрагментом большей дейтаграммы, ожидаются остальные фрагменты, после чего из них собирается исходная большая дейтаграмма;
    • из дейтаграммы извлекаются данные и направляются на обработку одному из протоколов вышележащего уровня (какому именно — указывается в заголовке дейтаграммы);
  • если дейтаграмма не направлена ни на один из IP-адресов данного узла, то дальнейшие действия зависят от того, разрешена или запрещена ретрансляция (forwarding) “чужих” дейтаграмм;
  • если ретрансляция разрешена, то определяются следующий узел сети, на который должна быть переправлена дейтаграмма для доставки ее по назначению, и интерфейс нижнего уровня, после чего дейтаграмма передается на нижний уровень этому интерфейсу для отправки; при необходимости может быть произведена фрагментация дейтаграммы;
  • если же дейтаграмма ошибочна или по каким-либо причинам не может быть доставлена, она уничтожается; при этом, как правило, отправителю дейтаграммы отсылается ICMP-сообщение об ошибке.

При получении данных от вышестоящего уровня для отправки их по сети IP-модуль формирует дейтаграмму с этими данными, в заголовок которой заносятся адреса отправителя и получателя (также полученные от транспортного уровня) и другая информация; после чего выполняются следующие шаги:

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

Здесь и далее узлом сети называется компьютер, подключенный к сети и поддерживающий протокол IP. Узел сети может иметь один и более IP-интерфейсов, подключенных к одной или разным сетям, каждый такой интерфейс идентифицируется уникальным IP-адресом.

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

Маршрутизатором, или шлюзом, называется узел сети с несколькими IP-интерфейсами, подключенными к разным IP-сетям, осуществляющий на основе решения задачи маршрутизации перенаправление дейтаграмм из одной сети в другую для доставки от отправителя к получателю.

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

Маршрутизаторы представляют собой либо специализированные вычислительные машины, либо компьютеры с несколькими IP-интерфейсами, работа которых управляется специальным программным обеспечением. Компьютеры конечных пользователей, различные серверы Интернет и т.п. вне зависимости от своей вычислительной мощности являются хостами.

Неотъемлемой частью IP-модуля является протокол ICMP (Internet Control Message Protocol), отправляющий диагностические сообщения при невозможности доставки дейтаграммы и в других случаях. Совместно с протоколом IP работает также протокол ARP (Address Resolution Protocol), выполняющий преобразования IP-адресов в MAC-адреса (например, адреса Ethernet).

2. IP-адреса

IP-адрес является уникальным 32-битным идентификатором IP-интерфейса в Интернет. Часто говорят, что IP-адрес присваивается узлу сети (например, хосту); это верно в случае, если узел является хостом с одним IP-интерфейсом, иначе следует уточнить, об адресе какого именно интерфейса данного узла идет речь. Далее для краткости там, где это не вызовет неверного толкования, вместо адреса IP-интерфейса узла сети говорится об IP-адресе хоста.

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

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

2.1. Классовая модель

В классовой модели IP-адрес может принадлежать к одному из четырех классов сетей. Каждый класс характеризуется определенным размером сетевой части адреса, кратным восьми; таким образом, граница между сетевой и хостовой частями IP-адреса в классовой модели всегда проходит по границе октета. Принадлежность к тому или иному классу определяется по старшим битам адреса.

Класс А. Старший бит адреса равен нулю. Размер сетевой части равен 8 битам. Таким образом, может существовать всего примерно 2 7 сетей класса А, но каждая сеть обладает адресным пространством на 2 24 хостов. Так как старший бит адреса нулевой, то все IP-адреса этого класса имеют значение старшего октета в диапазоне 0 — 127, который является также и номером сети.

Класс В. Два старших бита адреса равны 10. Размер сетевой части равен 16 битам. Таким образом, может существовать всего примерно 2 14 сетей класса В, каждая сеть обладает адресным пространством на 2 16 хостов. Значения старшего октета IP-адреса лежат в диапазоне 128 — 191, при этом номером сети являются два старших октета.

Класс С. Три старших бита адреса равны 110. Размер сетевой части равен 24 битам. Количество сетей класса С примерно 2 21 , адресное пространство каждой сети рассчитано на 254 хоста. Значения старшего октета IP-адреса лежат в диапазоне 192 — 223, а номером сети являются три старших октета.

Класс D. Сети со значениями старшего октета IP-адреса 224 и выше. Зарезервированы для специальных целей. Некоторые адреса используются для мультикастинга — передачи дейтаграмм группе узлов сети, например:

224.0.0.1 — всем хостам данной сети;

224.0.0.2 — всем маршрутизаторам данной сети;

224.0.0.5 — всем OSPF-маршрутизаторам;

224.0.0.6 — всем выделенным (designated) OSPF-маршрутизаторам;

В классе А выделены две особые сети, их номера 0 и 127. Сеть 0 используется при маршрутизации как указание на маршрут по умолчанию и в других особых случаях.

IP-интерфейс с адресом в сети 127 используется для адресации узлом себя самого (loopback, интерфейс обратной связи). Интерфейс обратной связи не обязательно имеет адрес в сети 127 (особенно у маршрутизаторов), но если узел имеет IP-интерфейс с адресом 127.0.0.1, то это — интерфейс обратной связи. Обращение по адресу loopback-интерфейса означает связь с самим собой (без выхода пакетов данных на уровень доступа к среде передачи); для протоколов на уровнях транспортном и выше такое соединение неотличимо от соединения с удаленным узлом, что удобно использовать, например, для тестирования сетевого программного обеспечения.

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

Например, 194.124.84.0 — сеть класса С, номер хоста в ней определяется последним октетом. При отправлении широковещательного сообщения оно отправляется по адресу 194.84.124.255. Номера, разрешенные для присваивания хостам: от 1 до 254 (194.84.124.1 — 194.84.124.254), всего 254 возможных адреса.

Другой пример: в сети 135.198.0.0 (класс В, номер хоста занимает два октета) широковещательный адрес 135.198.255.255, диапазон номеров хостов: 0.1 — 255.254 (135.198.0.1 — 135.198.255.254).

2.2. Бесклассовая модель (CIDR)

Предположим, в локальной сети, подключаемой к Интернет, находится 2000 компьютеров. Каждому из них требуется выдать IP-адрес. Для получения необходимого адресного пространства нужны либо 8 сетей класса C, либо одна сеть класса В. Сеть класса В вмещает 65534 адреса, что много больше требуемого количества. При общем дефиците IP-адресов такое использование сетей класса В расточительно. Однако если мы будем использовать 8 сетей класса С, возникнет следующая проблема: каждая такая IP-сеть должна быть представлена отдельной строкой в таблицах маршрутов на маршрутизаторах, потому что с точки зрения маршрутизаторов — это 8 абсолютно никак не связанных между собой сетей, маршрутизация дейтаграмм в которые осуществляется независимо, хотя фактически эти IP-сети и расположены в одной физической локальной сети и маршруты к ним идентичны. Таким образом, экономя адресное пространство, мы многократно увеличиваем служебный трафик в сети и затраты по поддержанию и обработке маршрутных таблиц.

С другой стороны, нет никаких формальных причин проводить границу сеть-хост в IP-адресе именно по границе октета. Это было сделано исключительно для удобства представления IP-адресов и разбиения их на классы. Если выбрать длину сетевой части в 21 бит, а на номер хоста отвести, соответственно, 11 бит, мы получим сеть, адресное пространство которой содержит 2046 IP-адресов, что максимально точно соответствует поставленному требованию. Это будет одна сеть, определяемая своим уникальным 21-битным номером, следовательно, для ее обслуживания потребуется только одна запись в таблице маршрутов.

Единственная проблема, которую осталось решить: как определить, что на сетевую часть отведен 21 бит? В случае классовой модели старшие биты IP-адреса определяли принадлежность этого адреса к тому или иному классу и, следовательно, количество бит, отведенных на номер сети.

В случае адресации вне классов, с произвольным положением границы сеть-хост внутри IP-адреса, к IP-адресу прилагается 32-битовая маска, которую называют маской сети (netmask) или маской подсети (subnet mask). Сетевая маска конструируется по следующему правилу:

  • на позициях, соответствующих номеру сети, биты установлены;
  • на позициях, соответствующих номеру хоста, биты сброшены.

Описанная выше модель адресации называется бесклассовой (CIDR — Classless Internet Direct Routing, прямая бесклассовая маршрутизация в Интернет). В настоящее время классовая модель считается устаревшей и маршрутизация и (большей частью) выдача блоков IP-адресов осуществляются по модели CIDR, хотя классы сетей еще прочно удерживаются в терминологии.

2.3. Запись адресов в бесклассовой модели

Для удобства записи IP-адрес в модели CIDR часто представляется в виде a.b.c.d / n, где a.b.c.d — IP адрес, n — количество бит в сетевой части.

Маска сети для этого адреса: 17 единиц (сетевая часть), за ними 15 нулей (хостовая часть), что в октетном представлении равно

Представив IP-адрес в двоичном виде и побитно умножив его на маску сети, мы получим номер сети (все нули в хостовой части). Номер хоста в этой сети мы можем получить, побитно умножив IP-адрес на инвертированную маску сети.

Пример: IP = 205.37.193.134/26 или, что то же,

IP = 205.37.193.134 netmask = 255.255.255.192.

Распишем в двоичном виде:

Умножив побитно, получаем номер сети (в хостовой части — нули):

или, в октетном представлении, 205.37.193.128/26, или, что то же, 205.37.193.128 netmask 255.255.255.192.

Хостовая часть рассматриваемого IP адреса равна 000110, или 6. Таким образом, 205.37.193.134/26 адресует хост номер 6 в сети 205.37.193.128/26. В классовой модели адрес 205.37.193.134 определял бы хост 134 в сети класса С 205.37.193.0, однако указание маски сети (или количества бит в сетевой части) однозначно определяет принадлежность адреса к бесклассовой модели.

Упражнение. Покажите, что адрес 132.90.132.5 netmask 255.255.240.0 определяет хост 4.5 в сети 132.90.128.0/20 (в классовой модели это был бы хост 132.5 в сети класса В 132.90.0.0). Найдите адрес broadcast для этой сети.

Очевидно, что сети классов А, В, С в бесклассовой модели представляются при помощи масок, соответственно, 255.0.0.0 (или /8), 255.255.0.0 (или /16) и 255.255.255.0 (или /24).

3. Маршрутизация

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

Маршрутизация дейтаграмм осуществляется на уровне протокола IP.

Маршрутизация выполняется на основе данных, содержащихся в таблице маршрутов. Строка в таблице маршрутов состоит из следующих полей:

  • адрес сети назначения;
  • адрес следующегомаршрутизатора (то есть узла, который знает, куда дальше отправить дейтаграмму, адресованную в сеть назначения);
  • вспомогательные поля.

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

Принцип работы протокола IP

Алгоритм работы протокола IP на каком-либо узле сети принимающего дейтаграмму из сети показан на рисунке 4.2.

Помимо вопросов адресации протокол IP также осуществляет, в случае необходимости, фрагментацию и сборку отправляемых пакетов.

На пути пакета от отправителя к получателю могут встречаться локальные и глобальные сети разных типов с разными допустимыми размерами полей данных кадров канального уровня (MaximumTransfer Unit, MTU). Так, сети Ethernet могут передавать кадры, несущие до 1500 байт данных, для сетей X.25 характерен размер поля данных кадра в 128 байт, сети FDDI могут передавать кадры размером в 4500 байт, в других сетях действуют свои ограничения. Протокол IP умеет передавать дейтаграммы, длина которых больше MTU промежуточной сети, за счет фрагментирования – разбиения большого пакета на некоторое количество частей (фрагментов), размер каждой из которых удовлетворяет промежуточную сеть. После того, как все фрагменты будут переданы через промежуточную сеть, они будут собраны на узле-получателе модулем протокола IP обратно в большой пакет. Отметим, что сборку пакета из фрагментов осуществляет только получатель, а не какой-либо промежуточный маршрутизатор. Маршрутизаторы могут только фрагментировать пакеты, но не собирать их. Это связано с тем, что разные фрагменты одного пакета не обязательно будут проходить через одни и те же маршрутизаторы.

Для того чтобы не перепутать фрагменты разных пакетов, используется поле Идентификации, значение которого должно быть одинаковым для всех фрагментов одного пакета и не повторяться для разных пакетов, пока у обоих пакетов не истекло время жизни. При делении данных пакета, размер всех фрагментов, кроме последнего, должен быть кратен 8 байтам. Это позволяет отвести меньше места в заголовке под поле Смещение фрагмента.

Если второй бит поля Флаги (More fragments) равен единице, значит данный фрагмент – не последний в пакете. Если пакет отправляется без фрагментации, флаг “More fragments” устанавливается в 0, а поле Смещение фрагмента – заполняется нулевыми битами.

Если первый бит поля Флаги (Don’t fragment) равен единице, то фрагментация пакета запрещена. Если этот пакет должен быть передан через сеть с недостаточным MTU, то маршрутизатор вынужден будет его отбросить. Этот флаг используется в случаях, когда отправителю известно, что у получателя недостаточно ресурсов по восстановлению пакетов из фрагментов.

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

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

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

Протокол ICMP

Протокол ICMP (Internet Control Message Protocol – протокол межсетевых управляющих сообщений) является вспомогательным сетевым протоколом, включенным в стек протоколов TCP/IP. Данный протокол используется для отправки сообщений об ошибках при передаче или ситуациях, когда маршрутизатор или узел не отвечает или требуемая услуга недоступна. По сути, протокол ICMP не может запросить послать потерянный пакет повторно, а просто оповещает о проблемах в работе сети. Также на ICMP возлагаются некоторые сервисные функции.

Когда протокол IP определяет, что дальнейшая передача пакета невозможна, перед тем как уничтожить пакет, он должен отослать узлу-источнику диагностическое ICMP-сообщение. Если при передаче самого ICMP-сообщения возникла ситуация препятствующая его передаче, то протокол ICMP не будет отправлять об этом диагностическое сообщения для избегания «штормов» в сетях.

При передаче по сети, сообщения ICMP инкапсулируются в поле данных IP-пакетов. Формат заголовка ICMP-пакета изображён на рисунке 4.3.

Заголовок ICMP-сообщения состоит из 8 байт:

  • Тип(1 байт)– числовой идентификатор типа сообщения: 0 или 8, где 0 – ICMP-reply (ответ), 8 – ICMP-request (запрос);
  • Код(1 байт) – числовой идентификатор, более точно определяющий тип ошибки;
  • Контрольная сумма(2 байта) – вычисляется для всего ICMP-сообщения;
  • Оставшиеся четыре байта и Поле данных зависят от значений полей типа и кода.

ICMP сообщения используются при отправке эхо-запроса (echo request) с помощью команды ping. Такой запрос обычно выполняется с целью проверки доступности узла в сети. На рисунке 4.4показаны отправленные и принятые пакеты при отправке эхо-запроса с узла 10.114.7.5 на узел 10.114.7.2.

Протокол ARP

В сетях Ethernet для идентификации узла используются IP и MAC адреса. Информация, передаваемая по сетям, содержит в себе оба этих адреса. Поскольку сами по себе эти адреса никак не связаны, такую связь обеспечивает протокол ARP (Address Resolution Protocol – Протокол определения адресов). Связь между IP адресом и MAC адресом осуществляется с помощью так называемых ARP-таблиц (рисунок 4.5), где в каждой строке указывается соответствие IP адреса MAC адресу. Просмотреть содержимое ARP-таблиц можно с помощью специальной команды arp.

Протокол RARP (Reverse Address Resolution Protocol – Обратный протокол определения адресов) выполняет обратное отображение адресов, то есть преобразует аппаратный адрес в IP-адрес.

Структура заголовка ARP изображена на рисунке 4.6:

  • Hardware type (HTYPE) Каждый канальный протокол передачи данных имеет свой номер, который хранится в этом поле. Например, Ethernet имеет номер 0x0001
  • Protocol type (PTYPE) Код сетевого протокола. Например, для IPv4 будет записано 0x0800
  • Hardware length (HLEN) Длина физического адреса в байтах. Адреса Ethernet имеют длину 6 байт.
  • Protocol length (PLEN) Длина логического адреса в байтах. IPv4 адреса имеют длину 4 байта.
  • Operation Код операции отправителя: 1 в случае запроса и 2 в случае ответа.
  • Sender hardware address (SHA) Физический адрес отправителя.
  • Sender protocol address (SPA) Логический адрес отправителя.
  • Target hardware address (THA) Физический адрес получателя. Поле пусто при запросе.
  • Target protocol address (TPA) Логический адрес получателя.

На рисунках 4.7 и 4.8 показаны ARP-запрос и ARP-ответ. ARP-запрос является широковещательным (MAC-адрес назначения: ff:ff:ff:ff:ff:ff). При получении сообщения узлом 10.114.7.1, тот формирует ARP-ответ, отправляя его только отправителю ARP-запроса.

Способы назначения IP-адресов. DHCP

IP-адрес может быть задан вручную администратором или автоматически соответствующей службой (DHCP). В первом случае на каждом компьютере в сети указывается IP-адрес, маска подсети, адрес шлюза и DNS-сервера(ов). В случае динамической выдачи адресов все параметры настраиваются один раз на сервере, а узлы получают их автоматически при подключении к сети. Нельзя сказать, что, например, динамическая настройка является лучшей по сравнению с ручной и выполняется чаще. У обоих вариантов есть свои плюсы и минусы, и администратор сети сам решает, что для данной конкретной сети подходит лучше.

Протокол DHCP (Dynamic Host Configuration Protocol – протокол динамической настройки узла) предназначен для автоматической выдачи узлу таких параметров, как адрес сети, маска подсети, шлюз по умолчанию, адрес DNS-сервера и др. В ходе работы протокола между клиентом (узлом, желающим получить настройки) и сервером (узлом, выдающим эти настройки) происходит обмен сообщениями. Поля, присутствующие в этих сообщениях, описаны в таблице 4.2.

Процесс получения адреса состоит из следующих шагов:

  1. Когда клиент (узел) подключается к сети, он отправляет сообщение DHCPDISCOVER о поиске DHCP-сервера в сеть. При этом в качестве адреса отправителя указывается адрес 0.0.0.0 (т.к. у клиента пока нет своего адреса), а в качестве получателя – 255.255.255.255 (т.к. адрес сервера также неизвестен).
  2. При получении сообщения DHCPDISCOVER сервер формирует сообщение DHCPOFFER, в котором содержатся предлагаемый сервером адрес (yiaddr) и все остальные необходимые клиенту настройки. В качестве адреса-приёмника в сообщении указывается MAC-адрес клиента.

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

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

  1. В ответ на DHCPOFFER клиент формирует широковещательное сообщение DHCPREQUEST, указав, что он принимает полученные параметры конфигурации. При наличии нескольких серверов DCHP клиент получит также несколько сообщений DHCPOFFER. Сообщение DHCPREQUEST является широковещательным, и клиент указывает идентификатор (xid) выбранного им сервера. Сообщение DHCPREQUEST по-прежнему будет содержать адрес источника 0.0.0.0, если клиенту все еще нельзя использовать IP-адрес, полученный в сообщении DHCPOFFER.

Не исключено, что клиента не устроит ни одно из серверных предложений. Тогда вместо DHCPREQUEST он снова выдаст в сеть запрос DHCPDISCOVER, а серверы так и не узнают, что их предложения отклонены. Именно по этой причине сервер не обязан резервировать помещенный в DHCPOFFER адрес.

  1. Как только сервер получает DHCPREQUEST от клиента, он посылает DHCPACK сообщение о том, что теперь клиент может использовать IP-адрес, назначенный к нему. Клиент окончательно подключается к сети с настроенными параметрами.

Если к моменту поступления сообщения DHCPREQUEST предложенный адрес уже был присвоен другому клиенту (например, от первой станции слишком долго шёл ответ на поступившее предложение), сервер ответит сообщением DHCPNAK.

  1. Получив сообщение DHCPACK, клиент обязан убедиться в уникальности IP-адреса (с помощью ARP) и зафиксировать суммарный срок его аренды. Последний рассчитывается как время, прошедшее между отправкой сообщения DHCPREQUEST и приемом ответного сообщения DHCPACK, плюс срок аренды, указанный в DHCPACK.

Обнаружив, что адрес уже используется, клиент обязан отправить серверу сообщение DHCPDECLINE и не ранее чем через 10 секунд начать всю процедуру снова.

  1. Для досрочного прекращения аренды адреса клиент отправляет серверу сообщение DHCPRELEASE.

Также необходимо знать, что IP-адрес сдаётся DHCP-сервером в аренду (lease). После истечения срока сервер может свободно присвоить этот адрес другому узлу. По истечении половины срока аренды клиент обычно пытается автоматически продлить её срок путем отправки DHCPREQUEST, указав в качестве адреса источника уже выданный адрес (а не 0.0.0.0, как это было при первичном получении). Получив DHCPACK, клиент будет знать, что срок аренды продлён.

Стоит отметить, что если клиент и сервер DHCP находятся в локальной подсети, сообщения в процессе работы протокола будут передаваться без посредников. Однако если сервер находится в другой подсети, то сообщения будут проходить через так называемый агент ретрансляции (DHCP Relay). При получении сообщения от клиента агент меняет адрес отправителя (0.0.0.0) на свой, адрес получателя (255.255.255.255) и пересылает пакет серверу.

Исчерпание адресного пространства

Стандарт IP-адреса версии 4 (IPv4) был принят в сентябре 1981 года. Адресное пространство его составляет 2 32 = 4 294 967 296 различных адресов. Выдача адресов регулируется американской некоммерческой организацией IANA (Internet Assigned Numbers Authority). Она выдавала большие блоки адресов пяти региональным регистраторам (RIR), которые в свою очередь раздают более мелкие диапазоны между Интернет-провайдерами (ISP). Провайдеры раздают адреса штучно или небольшими блоками конечным пользователям и организациям.

Во время утверждения стандарта казалось, что адресное пространство достаточно велико, чтобы удовлетворить потребности растущего Интернета на десятилетия вперёд. Однако в период бурного роста и популяризации сети Интернет, а также развития вычислительной техники в целом, уже в 90-х стало ясно, что такого количества адресов хватит ненадолго, что адресное пространство рано или поздно (а по темпу роста – скорее рано) исчерпается. Выделяют следующие факторы исчерпания адресов IPv4:

Неэффективное использование адресов. В 80-х годах, когда ещё не предвиделось такого бурного развития сети Интернет, адреса раздавались более «щедро» целыми блоками класса. Некоторые крупные компании или университеты могли получить в то время блок адресов класса A (16 миллионов адресов), если количество узлов их сети превышало 65 тысяч, и блока адресов класса B было недостаточно.

Теоретически IANA может получить обратно эти блоки адресов, после чего распределить их более рационально. Некоторые организации, среди которых Стэнфордский университет и Министерство обороны США, уже вернули блоки адресов. Однако смена адресов в большой сети может оказаться дорогой по стоимости и времени, и организации, обладающие «лишними» адресами, просто откажутся их возвращать (у Стэнфордского университета ушло два года на перенастройку 56 тысяч единиц оборудования).

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

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

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

Постоянное соединение с сетью Интернет. В 90-х – начале 2000-х основным способом подключения к сети Интернет был коммутируемый удалённый доступ при помощи телефонного модема. Применялась почасовая оплата за пользование доступом, поэтому подключение устанавливалось, как правило, на некоторый короткий промежуток времени. С середины 2000-х начал преобладать широкополосный доступ. Оплата за интернет сначала стала исчисляться по объёму трафика, а затем многие провайдеры перешли на безлимитный (по времени и трафику) способ за абонентскую плату. Поскольку для рядового пользователя отпала необходимость экономить на проведенном в Интернете времени и полученном трафике, отпала и необходимость в постоянном подключении/отключении к Интернету. Т.е. подключение к Интернету осуществлено всегда, когда включен компьютер.

Ситуация усугубилась, когда начали появляться в продаже недорогие домашние маршрутизаторы, «раздающие» Интернет между несколькими устройствами фактически одного абонента. Поскольку эти маршрутизаторы потребляют небольшое количество энергии и работают достаточно тихо, никто не отключает их, например, на ночь, или в когда никого нет дома. Следовательно, абонент подключен к сети Интернет 24/7, что практически полностью исключает возможность перераспределения освободившихся публичных адресов между абонентами.

К решению проблемы подошли с другой стороны. Поскольку подавляющему большинству домашних Интернет-пользователей вовсе не обязательно наличие «белого» адреса в собственном распоряжении, провайдеры выдают абонентом не публичные, а частные адреса. Таким образом, у провайдера формируется небольшая локальная сеть (в пределах одного дома, или района), которая использует для выхода в Интернет один публичный адрес. Это реализуется с помощью технологииNAT (Network Address Translation), а точнее её разновидности – PAT (Port Address Translation).

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

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

В приведенных факторах все решения по более эффективному использованию адресного пространства позволяют лишь несколько отсрочить дату исчерпания адресов, но не решат проблему. Для полноценного решения требуется переход на новый формат адресов. Следующий стандарт IPv6был разработан ещё в 1996 году, однако по ряду причин переход на новый стандарт адресов затянулся.

Некоторые секреты ip протокола

ZAlex
SNMP бегает поверх IP/UDP, и для этих целей не подходит никак

Akina
Речь не о ip broadcast, a mac broadcast

8. vinni , 20.11.2009 17:42
Akina
чтобы пингануть бродкаст подсети
Правильно яверт ответил, поиск делается не на сетевом уровне, а на канальном, то есть ищется, например, принтер, у которого вообще ещё не сконфигурирован IP, и ведь находится!
9. Akina , 21.11.2009 10:15
яверт
vinni
А не подскажете готовый МАС pinger? Умеющий послать бродкаст и сгрести в кучку ответы?
PS. тулзы, где пакет формируется «вручную», можно не предлагать, такое имеется.
10. Newcastle , 21.11.2009 23:14
Всем спасибо за ответы!
11. vinni , 23.11.2009 11:39
Akina
Не полностью готовый, но за 2 шага:
C:\>wakearp
Usage: wakearp
Will induce arp resolution for all IP addresses x.y.z.0 — x.y.z.254
This utility lives at: http://www.elifulkerson.com

12. Akina , 23.11.2009 14:37
Это же обычный UDP-пингер.
13. яверт , 23.11.2009 15:08
Akina
На броадкаст запрос обычные компы вам ничего не ответят.
Если вам нужна подобная тулза можно сделайть arp-ping скрипт на базе scapy.
У скапи всё своё начиная с L2, поэтому можно отправлять арп запросы на айпи адреса не из своего сабнета.
14. Akina , 23.11.2009 22:02
Да блин! пойми, для меня просканить диапазон ИПов и выгрести АРП-кэш — не проблема! Да собственно всё ещё проще — пингуем бродкаст подсети и сгребаем ответы. Фигня в том, что для этого надо знать или хотя бы предполагать, что за подсеть рядом.

ТС знает, ему хорошо. он вполне может обойтись вульгарным сканом сети. Меня же заинтересовало иное — найти адрес, не зная подсети или диапазона, просто зная что адрес есть. ИП или МАС — неважно.

Я полагал, что есть какой-то способ безотносительно к ИП получить МАС-и соседей и по ним уже определять наличие ИП и адрес, если ИП есть.

Я не стал высказывать предположение, что на МАС-пинг комп без заточенного под это дело софта отвечать не станет, ибо был не уверен, и попросил фамилию тулзы, чтобы попробовать.
Что ещё можно придумать? на глобальный бродкаст компы не отвечают (да и не очень-то ещё что туда пошлёшь осмысленного. надо будет wakearp попросить, кстати). Попинать определённый сервис по мультикасту? тоже вроде готовых инструментов нет.

15. яверт , 23.11.2009 23:18
Akina
Не ломайте себе голову, все протоколы которые подразумевают безапеляционный ответ на запрос никогда не работают с броадкастовым запросом из-за реальной угрозы DоS атаки.

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

16. Akina , 23.11.2009 23:52
Вот собственно в том и вопрос — как (и можно ли вообще, пусть даже частично) получить сведения о ближайших узлах в сети, разделённой свичами, в разумное время и при этом не положить сегмент и не обидеть свич.

яверт
все протоколы которые подразумевают безапеляционный ответ на запрос никогда не работают с броадкастовым запросом из-за реальной угрозы DоS атаки.
Я предполагаю, что дело всё-таки происходит в рамках LAN. Кстати, на пинг по адресу бродкаста подсети отвечают все узлы этой подсети, если на них разрешён пинг.

17. яверт , 24.11.2009 03:21
Akina
Если свитчи ваши и дружат хоть немного с SNMP то можно слить с них bridging table (dot1dTpFdbTable OID:1.3.6.1.2.1.17.4.3) там нужные вам маки должны быть засвечены.
18. ping_not_dead , 24.11.2009 08:08
Akina:

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

Здесь комп не получил ip-адрес и присвоил из диапазона по умолчанию.

А вот запись о новой станции в сети

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

19. Akina , 24.11.2009 13:51
яверт
ping_not_dead
Ещё раз: меня интересует возможность получения таких сведений в неподконтрольной сети.
Иными словами — представьте, что в стенку уходит кабель, куда он идёт и что там, вам неведомо. А узнать хочется
20. Str@nNik13 , 25.11.2009 15:32
Akina
И как же «вот эта» утилита будет сканить подсеть, не имея неё шлюза и не имея из неё адреса? Она как раз предполагает, что в части маршрутизации в сети всё в порядке.
А кто сказал что маршрутизации нет, лично я исходил из предположения что с маршрутизацией все нормально, а требуется только определить имеющиеся сети и сервисы доступные в этих сетях.
21. Akina , 25.11.2009 17:36
Str@nNik13
Ну вот представь. У тебя адрес. ну скажем 192.168.0.2. Маска /24. Шлюз/ДНС соответственно 0.1. Маршрутизация у тебя нормально работает на любой допустимый адрес.
Ты точно знаешь, что на других портах твоего свича сидят клиенты с IP из другой подсети. И у них тоже с маршрутизацией всё в порядке. Будь у тебя их адреса — ты бы без проблем их пинговал. скажем через общий ваш роутер, у которого на интерфейсе несколько адресов из разных подсетей.
Но адресов/подсетей у тебя нет. Есть только знание, что вы сидите в одном свиче и что на свиче виланов не настроено. К свичу доступа нет. И разрешения переполнить ему ARP-таблицу тоже нет. И SNMP на нём только приватный, и пароля тебе не дали. И роутер не намерен тебе рассказывать, какие у него есть адреса, кроме адреса твоего шлюза.
Можно ли в таких условиях узнать адреса соседей по свичу? А если можно — то как?

цитата: Akina:
Str@nNik13
Но адресов/подсетей у тебя нет. Есть только знание, что вы сидите в одном свиче и что на свиче виланов не настроено. К свичу доступа нет.

Не очень понятно откуда вдруг возьмется знание о настройках vlan на свиче, если к нему никакого доступа нет. Для пользователя это будет абсолютно прозрачно.
Если действительно в одном широковещательном домене находятся несколько подсетей (чего ни один грамотный админ делать никогда не будет), то можно любым сниффером (или Arpwatch тем же) ловить arp-пакеты и делать выводы о том, какие еще сети есть в этом сегменте. Если же в пределах одного широковещательного домена находится только одна подсеть, то о существовании других подсетей «по близости» узнать нельзя.

22. ping_not_dead , 26.11.2009 08:33
23. Akina , 26.11.2009 08:59
ping_not_dead
Не очень понятно откуда вдруг возьмется знание о настройках vlan на свиче, если к нему никакого доступа нет.
Повторю:
Есть только знание, что вы сидите в одном свиче и что на свиче виланов не настроено.

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

жно любым сниффером (или Arpwatch тем же) ловить arp-пакеты и делать выводы о том, какие еще сети есть в этом сегменте.
Вообще-то там свич, а не хаб. Причём не секунду назад включившийся и знающий, какой МАС на каком порту у него сидит. И просто так он тебе транзитные пакеты отправлять не станет.

24. ping_not_dead , 26.11.2009 10:49
Akina:

цитата:
Вообще-то там свич, а не хаб. Причём не секунду назад включившийся и знающий, какой МАС на каком порту у него сидит. И просто так он тебе транзитные пакеты отправлять не станет.

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

25. vinni , 27.11.2009 20:58
Akina
Вообще-то там свич, а не хаб. Причём не секунду назад включившийся и знающий, какой МАС на каком порту у него сидит. И просто так он тебе транзитные пакеты отправлять не станет.
ARP-запросы это броадкаст. А, ну да, ping_not_dead уже сказал об этом.

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

ping_not_dead
Соответственно, по этим ip-адресам можно сказать к какой сети принадлежит хост, пославший пакет.
Точно сказать про сети нельзя, т.к. в ARP-запросе нет масок сетей.

26. Akina , 27.11.2009 23:51
ping_not_dead
ARP-запросы являются широковещательными и будут переданы свичем на все порты. В теле ARP-запроса содержится ip-адрес источника, пославшего пакет и ip-адрес того, чей мак он хочет узнать.
И какой же IP прикажете запрашивать в этом пакете? Если IP, имеющиеся в сегменте, неизвестны?

Добавление от 28.11.2009 00:05:

vinni
остальные уже названы — различные сниферы (в т.ч. arpwatch),
Свич ничего, что может получить снифер, не пропустит — мол, не твоё.

Волшебных средств я не знаю
Я тоже. Но.

Например, пинг любого IP-адреса приведёт к получению ответа от любой станции, для который этот адрес есть бродкаст её подсети.

Запрос определённой структуры на мультикаст 224.0.1.22:427 приведёт к получению ответа от всех станций, на которых установлен нетварёвый клиент.

А есть ли волшебный адрес/порт/протокол/прочее, на который будет получен ответ от любой станции, имеющей IP-протокол? ну при условии что её локальный файрвол не против.

27. ping_not_dead , 30.11.2009 07:00
vinni

цитата: Точно сказать про сети нельзя, т.к. в ARP-запросе нет масок сетей.

цитата: Akina:
ping_not_dead
ARP-запросы являются широковещательными и будут переданы свичем на все порты. В теле ARP-запроса содержится ip-адрес источника, пославшего пакет и ip-адрес того, чей мак он хочет узнать.
И какой же IP прикажете запрашивать в этом пакете? Если IP, имеющиеся в сегменте, неизвестны?

Ничего запрашивать самому не нужно! Нужно слушать сеть и ловить arp-запросы от других хостов (а любой хост обязательно будет их генерить, чтобы сопоставить ip и mac).

цитата: А есть ли волшебный адрес/порт/протокол/прочее, на который будет получен ответ от любой станции, имеющей IP-протокол? ну при условии что её локальный файрвол не против.

Это из под линукса с ключом -b.
Винда на броадкасты не откликается по-моему.

Илон Маск рекомендует:  Что такое код loadmodule
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL