Когда у вас есть подключение с кем-либо где видно MAC адреса, это позволяет, с высокой долей достоверности, узнать производителя оборудования используемого вашим партнёром. А когда это общая коммутационная среда, как на точках обмена трафика, то производителя можно узнать у всех участников разделяющих с вами это подключение, и такой анализ уже был на Habr. Но даже если не быть подключенным к IX, то всё равно информацию о MAC адресах, хотя далеко и не всех участников, можно получить используя Looking glass. Этим мы и займёмся для нескольких крупнейших точек обмена трафиком, а поможет нам в этом Алиса.

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

Год назад я написал статью про "Национальную систему доменных имён", в которой были рассмотрены некоторые технические аспекты её организации, в основном то что касается доступности узлов этой системы, а не аспектов работы DNS. Я не следил, но надеялся встретить за этот год больше информации изнутри, но мне она не попалась. Конференций и каких-то публичных технических мероприятий всё ещё было не очень много, где обычно такая информация появляется, но если кто-то что-то встретил просьба поделиться, я добавлю ссылки сюда и удовлетворю своё любопытство.

Я попробовал поискать в Google доступную информацию, но и там ничего не нашёл, кроме новостей, приказов об основании этой системы и редких ссылок на инструкцию по подключению, вот например на labs.ripe.net в PDF и с подписями. На сайте Роскомнадзора мои усилия тоже закончились ничем. Я подозреваю что какие-то документы есть внутри ЦМУ ССОП, но туда заходить я не стал.

При всём при этом НСДИ остаётся публичной системой, воспользоваться которой может, как минимум, каждый пользователь Интернет в России. Кроме того, за год накопились данные мониторинга с RIPE Atlas на созданных мною измерениях, используя которые мы и посмотрим к чему мы пришли. Мы не выйдем структурно за рамки прошлой статьи и наш взгляд будет всё равно поверхностный, но имея гораздо больший объём данных сможем посмотреть на это чуть пошире.

С начала этого года в России стала эксплуатироваться Национальная Система Доменных Имён - НСДИ, о чём уже можно почитать на Хабр, а провайдерам и владельцем автономных систем РКН рассылает письма с требованиями к ней подключиться. По своей сути это набор из публичных DNS серверов, доступный всем желающим и предлагаемый к использованию как провайдерам так и конечным пользователям Интернет. К своему сожалению, я слабо представляю как конкретно организована и функционирует глобальная система доменных имён, или как организована работа серверов обслуживающих, например, зону RU., и надеюсь это статьёй, в том числе, привлечь внимание к этому вопросу людей которые в этом разбираются или участвуют в этом процессе - это должно быть очень интересно и познавательно, для того чтобы об этом рассказать всем. Поэтому мой первый взгляд будет про адресацию, маршрутизацию, задержки, для чего будет использованы, в том числе, средства RIPE Atlas, и, конечно, про DNS, но ровно настолько насколько я в этом понимаю. Отличительно особенностью именно этой национальной системы является её доступность для исследований, поэтому надеюсь мой первый взгляд, будет продолжен и подхвачен, чтобы рассмотреть этот вопрос со всех сторон.

Модуль «Агент Ревизор» является структурным элементом автоматизированной системы «Ревизор» (АС «Ревизор»). Данная система предназначена для осуществления контроля над выполнением операторами связи требований по ограничению доступа в рамках положений, установленных статьями 15.1-15.4 Федерального закона от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации».

Основной целью создания АС «Ревизор» является обеспечение мониторинга соблюдения операторами связи требований, установленных статьями 15.1-15.4 Федерального закона от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации» в части выявления фактов доступа к запрещенной информации и получения подтверждающих материалов (данных) о нарушениях по ограничению доступа к запрещенной информации.

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

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

Ericsson SmartEdge

notification msg sent (nbr 192.0.2.1, context 0x40030044 32 bytes, repeated 89 times, code 3/4 (update: attribute flags error) - 
0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed 5bdc 3f01

Cisco, то же с другой стороны

NOTIFICATION received from 192.0.2.2 (External AS 64496):
code 3 (Update Message Error) subcode 4 (attribute flags error),
Data: e0 07 08 00 03 02 ed 5b dc 3f 01

Попробуем разобрать это руками как написано в RFC4271. Не будем искать причину — просто разбор заголовков. Будет много цитат и, скорее всего, ничего нового для тех кто уже это умеет делать. Для остальных читаем дальше.

Класс A: 8 бит для номера сети 24 бита для номера хоста
Класс B: 16 бит на сеть и 16 бит на хост
Класс C: 24 бита на сеть 8 бит на хост

IP адрес, десятичное:     10.      10.       0.       1
IP адрес, двоичное: 00001010.00001010.00000000.00000001
Маска, двоичное:    11111111.11111111.11111100.00000000
Маска, десятичное:       255.     255.     252.       0