Русский
Русский
English
Статистика
Реклама

Сетевые технологии

L2TP amp IPsec with pre shared key vs MITM

31.05.2021 12:16:05 | Автор: admin

В статье рассмотрены основные vpn протоколы, которые на текущий момент применимы в бизнес процессах, а также углубленно освещен вопрос использования L2TP в связке с IPsec в режиме pre shared key. На практике разобраны подходы к организации виртуальных сетей на оборудовании MikroTik и выполнен практический аудит безопасности передачи данных с позиции анализа третьими лицами исходящего трафика при возможности MITM атаки.

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

Для начала разберем, в каких случаях бизнесу нужен vpn:
при подключении удаленных сотрудников к сетевым ресурсам компании (site-to-client vpn) и
при объединении территориально разнесенных сетевых элементов (site-to-site vpn). Самих протоколов vpn сейчас много: GRE , PPTP, SSTP, OVPN, L2TP, Wireguard и т.д.

Здесь важно не путать протоколы с сервисами vpn, которых еще больше: ExpressVPN, CyberGhost, NordVPN и т.д. Вторые по сути являются провайдерами услуг, обеспечивая доступ клиентов к собственным ресурсам с целью обхода блокировок со стороны ISP, а также анонимности серфинга в интернете. Про них сейчас речь не идет.

С вариацией протоколов определились, какой же выбрать?
Во-первых, в зависимости от того, что строим site-to-client или site-to-site, потому что GRE для первого случая не подойдет.

Во-вторых, Wireguard хоть молодой, простой и очень перспективный, но на офисном маршрутизаторе Cisco или MikroTik его не поднять, вендоры даже не планируют внедрять. PPTP очень легок в настройке, однако будет либо не шифрованным, либо шифрованным протоколом MPPE, который не имеет аппаратной разгрузки, в следствие чего, многопользовательскую сеть замедлит в работе. SSTP отличный протокол, работает по TLS в UDP на 443 порту, пролезет через любой Firewall, а может даже и IDS. У некоторых вендоров, например, MikroTik, может работать по pre shared key вместо сертификата, запускается на Windows клиентах из коробки.
Из минусов: определенные танцы с бубном при настройке Linux клиентов (протокол все-таки от Microsoft) и отсутствие поддержки со стороны вендоров в аппаратной разгрузке. OpenVPN всем хорош, особенно высокой гибкостью. Можно туннелировать на L2, можно на L3, всего не перечислить. Не даром он open soft. Роутер MikroTik скоро научится работать с ним по UDP (ожидается в следующем поколении RouterOS), так как смысла в TCP нет, ведь соединение все равно проверяется во вложенном туннеле. Однако, скорее всего ваша офисная Cisco не умеет с ним работать, поэтому vpn сервер из нее не организовать.

Фактически, стандартом де-факто в корпоративной среде является протокол L2TP. Он работает на UDP, порт по умолчанию 1701. С шифрованием все хорошо, особенно наличие возможности аппаратной разгрузки IPsec. Есть вероятность, что ваш корпоративный MikroTik (несмотря на то, что он софтовый маршрутизатор) умеет шифровать IPsec на железе (смотри таблицу Hardware acceleration на сайте производителя ). У Cisco в этом вопросе дела обстоят еще лучше. Даже если ваш офисный роутер не умеет шифровать железом, никто кроме вас это знать не должен не будет.

Итак, подведем промежуточный итог: vpn технологии бизнесу нужны, использовать лучше всего L2TP. Закончив с затянувшейся вводной частью, перейдем непосредственно к теме статьи. Рассмотрим на примере оборудования MikroTik безопасность передачи данных в туннеле при возможности MITM атаки со стороны третьих лиц. Этот вопрос возникает в следствие того, что почти всегда в корпоративной среде используют L2TP в связке с IPsec в туннельном режиме и общим ключем для всей сети, вместо создания PKI и задействования сертификатов. Это удобно, сеть быстро разворачивается и легко обслуживается. Безопасно ли это в условиях компрометации pre shared key? Разберем на практике.

Начнем с того, что L2TP может быть не шифрованным:

/ppp profile name=test use-encryption=no


с интегрированным в протокол шифрованием MPPE:

/ppp profile name=test use-encryption=yes (или require, при этом IPsec отключен)



с качественным внешним шифрованием от IPsec, вроде AES:

/ppp profile name=test use-encryption=yes (или require, при этом IPsec включен)



Настройка L2TP сервера осуществляется достаточно просто, активируем его и указываем тип аутентификации:

/interface l2tp-server server set authentication=mschap2 default-profile=test enabled=yes


Здесь же появляется возможность сразу активировать IPsec и настроить pre shared key. Если это сделать, то общий ключ будет закреплен за всей vpn сетью и передан всем ее участникам в качестве настроечной информации. Один и тот же на всех. На самом деле, если активировать IPsec таким образом, то RouterOS автоматически создает необходимые настройки в соответствующем разделе /ip ipsec сразу после установления L2TP соединения.

Конкретно речь идет:

  • IPsec Policy с указанными протоколом UDP и портом подключения 1701;
  • IPsec Peer c IP адресами сервера и клиента;
  • IPsec Identity с указанным ранее pre shared key.

Автоматически созданные настройки IPsec

Очень удобно. Особенно, когда IP адреса динамические и вообще натированные. Клиентам не нужно выполнять лишние процедуры по отслеживанию их текущих значений. В RouterOS в разделе L2TP есть дополнительная настройка, определяющая общий секрет при конфигурировании в сетях Virtual Private DialUp Network протяженных соединений точка-точка между удаленным сервером PPPOE и L2TP сетью, но это к теме статьи не относиться, поэтому просто ее упомянем всуе:

/ppp l2tp-secret add address=0.0.0.0/0 secret=

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

/ip ipsec peer add address=IP local-address=IP name=peer1/ip ipsec identity add peer=peer1 auth-method=digital-signature certificate=u01.crt_0/ip ipsec policy add dst-address=IP dst-port=1701 peer=peer1 protocol=udp src-address=IP src-port=1701

Здесь нас поджидает кропотливая работа, ведь, скорее всего, адреса у клиентов меняются (и достаточно часто), кроме этого клиенты сидят за провайдорским NAT. Все это можно накрутить кастомными скриптами на RouterOS, и все будет отлично работать. Нужно ли это? Cмоделируем ситуацию, когда общий для всех pre shared key стал известен злоумышленнику, который целенаправленно хочет нам навредить. Или клиент vpn нам больше не клиент. Сразу баним его учетную запись, и теперь аутентификацию mschap2 (или какая у вас там выбрана) он не пройдет и доступ не получит:

/ppp secret disable bad_user

Если каким-то чудом у него есть возможность MITM, то есть пропускать трафик через себя, то толку в этом ровно никакого нет. Весь трафик зашифрован. Выдать себя за vpn сервер другим участникам корпоративной сети тоже не удастся. В подобном нереальном сценарии аутентификацию mschap2 клиенты не пройдут, ведь их секрет известен только им и вам, разумеется:

/ppp secret add name=good_user password=12345 service=l2tp

Шифрованный трафик L2TP туннеля

Исследовательский интерес нас ведет дальше. Может все-таки что-то можно сделать с трафиком? И в результате извлечь передаваемую информацию? Попробуем дешифровать трафик в лабораторных условиях. MikroTik позволяет нам выполнить debug соединения и увидеть подробную информацию об установленной IPsec сессии:

/ip ipsec installed-sa print

Как видно, сессия установилась на 30 минут, имеются разные ключи аутентификации и шифрования. Применим их в Wireshark, после приведения шестнадцатеричных значений к корректному формату: SPI 0x0ada181b, вместо MikroTik-овского 0xADA181B, ключи начинаются со значения 0x. Если все сделано правильно, тогда трафик откроется.

Ввод данных сессии для дешифрования IPsec

Дешифрованный IPsec

Подведем результаты

Насколько безопасно использовать L2TP c общим секретом? Абсолютно безоапасно. По сути IPsec с помощью pre shared key выполняет функцию аутентификации, но в нашем случае процедура аутентификации выполняется ранее при установлении L2TP соединения. Нет практической необходимости выполнять аутентификацию повторно. По сути MikroTik, введя возможность настройки IPsec в разделе создания L2TP сервера, автоматизирует рутинные задачи по настройке шифрованного туннеля в ручном режиме (история про танцы с бубном). Это еще один плюс в сторону использования не дорогостоящего, но качественного оборудования MikroTik. Конечно, в ручном режиме гораздо больше вариаций на тему шифрования, но по умолчанию задаются, по авторскому мнению, идеальные значения: aes256 и sha1.


Как рекомендации для бизнеса, смело можно использовать L2TP с IPsec pre shared key. При планировании политик информационной безопасности, нет необходимости в задании сложных значений для pre shared key. Важно выставить не угадываемые и не словарно подбираемые значения для аутентификации L2TP (/ppp secret). Удобно, безопасно и качественно, админ доволен, клиенты не замучены.


Подробнее..

Транспортный протокол QUIC приняли в качестве стандарта RFC 9000

01.06.2021 02:22:59 | Автор: admin


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

Уже много рассказывалось о преимуществах транспорта QUIC, который взят за основу будущего стандарта HTTP/3. В HTTP следующего поколения транспорт TCP меняется на QUIC, что означает автоматическое ускорение соединений и зашифровку всего интернет-трафика, который раньше шёл в открытом виде по TCP. Нешифрованный QUIC не предусмотрен вообще.

В мае 2021 года состоялось знаменательное событие: протокол QUIC принят в качестве официального стандарта RFC9000. Это великолепные новости для всей интернет-экосистемы.

Утверждением таких стандартов занимается Инженерный совет Интернета (IETF). Ранее были оформлены вспомогательные стандарты RFC 9001, RFC 9002 и RFC 8999.

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

В последние годы QUIC был одним из главных приоритетов IETF. Появившись как эксперимент Google, вскоре разработка QUIC вышла на международный уровень. Она велась почти пять лет. Зафиксировано 26 очных собраний, 1749 задач в трекере и многие тысячи писем в почтовой рассылке.

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

Окостенение означает, что система с каждым годом становится всё менее гибкой, менее подвижной. QUIC принесёт в транспортный уровень множество инноваций, включая обязательное шифрование, версионность, гораздо более богатый и более производительный набор сервисов, поверх которых будут строиться новые технологии. Предполагается, что QUIC приведёт к появлению нового поколения интернет-инноваций. Это уже начало происходит с расширениями, такими как ненадёжные датаграммы (Unreliable Datagram Extension). Ненадёжные датаграммы открывают двери перед новым классом медиа в реальном времени и другими приложениями, которым нужен более функциональный транспорт, чем обязательная доставка пакетов с обрывом канала при потере нескольких пикселей. Мы уже видим многообещающие технологии, такие как MASQUE и WebTransport.

HTTP/3


Стандарт HTTP/3 (это HTTP поверх QUIC) идёт с небольшим опозданием за QUIC и тоже будет официально принят в самое ближайшее время.


34-й (!) драфт HTTP/3

С момента принятия HTTP/2 прошло шесть лет: спецификация RFC 7540 опубликована в мае 2015-го, но пока не используется повсеместно. Протокол реализован во всех браузерах ещё с конца 2015 года, а спустя три года только 45,4% из 10 млн самых популярных интернет-сайтов поддерживают HTTP/2. Два с половиной года назад таких было 31,2%. Севсем недавно на HTTP/2 перешли сайты Amazon, Paypal, Telegram.org.

Cейчас практически готова третья версия HTTP/3, осталось совсем немного подождать.

QUIC представляет собой замену TCP, которая работает поверх UDP. Изначально эта технология была создана инженерами Google, как и предыдущий протокол SPDY, который стал основой HTTP/2. В первое время QUIC именовали HTTP/2-encrypted-over-UDP.

Затем разработку QUIC передали в IETF для стандартизации. Здесь он разделилcя на две части: транспорт и HTTP. Идея в том, что транспортный протокол можно использовать также для передачи других данных, а не только эксклюзивно для HTTP или HTTP-подобных протоколов. Однако название осталось таким же: QUIC. Разработкой транспортного протокола занимается рабочая группа QUIC Working Group в IETF.

Долгое время версия IETF называлась iQUIC, в то время как Google и другие продолжили работу над собственной реализацией gQUIC, но 7 ноября 2018 года один из ведущих разработчиков протокола Дмитрий Тихонов объявил, что стороны достигли совместимости протоколов, и теперь разработка продолжится в общем русле. QUIC в Chrome включается в настройках chrome://flags. Есть ещё расширение-индикатор, которое показывает, какие сайты поддерживают QUIC.



Встроенная безопасность и производительность


В чём преимущества транспортного протокола QUIC перед TCP? Преимуществ очень много. По словам руководителя рабочей группы Марка Ноттингема, переход от устаревшего TCP на новые протоколы просто неизбежен, поскольку сейчас очевидно, что TCP страдает от проблем неэффективности.

Поскольку TCP протокол доставки пакетов по порядку, то потеря одного пакета может помешать доставке приложению последующих пакетов из буфера. В мультиплексированном протоколе это может привести к большой потере производительности, объясняет Марк Ноттингем. QUIC пытается решить эту проблему с помощью эффективной перестройки семантики TCP (вместе с некоторыми аспектами потоковой модели HTTP/2) поверх UDP.

Кроме перехода значительного объёма трафика с TCP на UDP, протокол QUIC требует обязательного шифрования: нешифрованного QUIC не существует вообще. QUIC использует TLS 1.3 для установки ключей сессии, а затем шифрования каждого пакета. Но поскольку он основан на UDP, значительная часть информации о сессии и метаданных, открытых в TCP, шифруется в QUIC.



В статье Будущее интернет-протоколов Марк Ноттингем говорит о значительных улучшениях в безопасности с переходом на QUIC:

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

Кроме того, становится невозможна пассивная оценка RTT и потерь пакетов путём простого наблюдения за соединением; там недостаточно информации для этого.

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

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

Возможно, принятие стандарта QUIC произошло бы и раньше, если бы компания Google не поспешила внедрить свою реализацию в браузер Chrome, так что случилось раздвоение стандарта.

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



См. также:





Отмечайте юбилей GlobalSign и получайте скидки!


Подробнее..

Построение карты сети

01.06.2021 16:23:51 | Автор: admin

Построение карты сети это длительный процесс. Исследование происходит за счет отслеживания откликов операционных систем на испорченные данные в заголовках сетевых протоколов. Этот подход обычно дает ~ 80% точности. И довольно сложно найти информацию о том, как точно каждая ОС отзывается на подобные воздействия. А что, если будет технология или функция операционной системы, которая на 100% точно будет говорить о состоянии сетевой подсистемы и сообщать дополнительную информацию? Статья расскажет о таких функциях ОС Windows.

Старые как мир технологии

Чтобы получить полную картину того, как ОС Windows представляет свои функции в сети, нужно вспомнить о таких механизмах, как DCOM и RPC.

Remote Procedure Call механизм межпроцессного взаимодействия (IPC). Механизм позволяет обмениваться информацией и вызывать функции в разных процессах в рамках ОС, локальной сети или через Интернет.

Distributed Component Object Model спецификация COM объектов, которая регламентирует правила взаимодействия в сети между объектами. В документации можно встретить формулировку DCOM Remote Protocol.

Два механизма соотносятся по следующей схеме:

Схема взята отсюда

Как это работает? Общая схема работы протокола представлена ниже.

Схема взята отсюда

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

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

Что интересного для карты сети

DCOM для Offensive уже изучался на BlackHat 2004. В выступлении было очень много информации, которая может быть использована для версий Windows вплоть до Windows Server 2003. Вот список некоторых действий, которые можно выполнять:

  • Сбор информации о конфигурации ОС (не требует авторизации);

  • Перебор паролей для учетных данных пользователей;

  • Отправка запроса на создание задач ScheduledTask, а так же удаление, просмотр;

  • Просмотр состояния сервисов (авторизация требуется).

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

Практика

Для эксперимента будем использовать 3 виртуальные машины:

  • Windows 10

  • Windows 7

  • Windows 8

Каждая виртуальная машина будет подключена как минимум к двум сетям, которые будут включать в себя разные сегменты. Тестовой виртуальной машиной станет Kali Linux. Попробуем собрать скрипты и приложения для сбора информации о системе посредством RPC. Список инструментов представлен ниже:

  • nmap script rpcinfo.nse - собирает порты rpc и пишет, по возможности имя сервиса, который их использует;

  • impacket rpcdump.py - получает информацию из rcp сервисов;

  • impacket rpcmap.py - собирает endpoint порты, которые ожидают коннекта;

  • Metasploit module auxiliary/scanner/dcerpc/endpoint_mapper - поиск endpoint;

  • Metasploit module auxiliary/scanner/dcerpc/hidden - поиск скрытого сервиса;

  • Metasploit module auxiliary/scanner/dcerpc/management - получение данный из RMI DCERPC;

  • Metasploit module auxiliary/scanner/dcerpc/tcp_dcerpc_auditor - поиск названий сервисов, которые используют DCERPC;

  • IOXIDResolver.py - скрипт для получения данных о конфигурации сетевой подсистемы;

Попробуем работоспособность инструментов на виртуальных машинах:

Windows 7

Результаты nmap:

Результаты Metasploit:

На картинке представлена часть endpoint сервисов.На картинке представлена часть endpoint сервисов.

Hidden services

Management

TCP Auditpr

Результаты IOXIDResolver:

Windows 8

Результаты nmap:

Результаты Metasploit:

endpoint_mapper

На картинке представлена часть endpoint сервисов. На картинке представлена часть endpoint сервисов.

Hidden services

Management

TCP auditor

Результаты IOXIDResolver:

Windows 10

Результаты nmap:

Результаты Metasploit:

На картинке представлена часть endpoint сервисов. На картинке представлена часть endpoint сервисов.

Hidden services

Management

TCP auditor

Результаты IOXIDResolver:

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


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

Подробнее..

Наша анонимность утрачена?

04.06.2021 22:07:07 | Автор: admin

IT-технологии развиваются с каждым годом. Многие корпорации полным ходом развивают технологические подходы в области сбора и обработки полученной информации. Одним из таких подходов является использование баз данных цифровых отпечатков пользователей сети Интернет.

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

1. Ip-адрес. Провайдеры годами хранят статистику на каком ip-адресе работал их пользователь. Зная ip-адрес можно легко вычислить расположение пользователя.

2. DNS-запросы. Каждый раз, когда Ваш браузер хочет получить доступ к определенной службе, например Google, обратившись к www.google.com, Ваш браузер запросит службу DNS, чтобы найти IP-адреса веб-серверов Google. Таким образом, интернет-провайдер DNS-записей сможет рассказать обо всем, что Вы делали в сети, просто просмотрев те журналы, которые, в свою очередь, могут быть предоставлены злоумышленнику.

3. NFC-платежи через устройства. Данная технология используется для выполнения бесконтактных платежей. По сути это радиочастотная идентификация. Вы заходите в магазин и на рамке происходит сканирование любых RFID-чипов, которые есть у вас: бесконтактные карты, транспортные карты, рабочие карты доступа, ключи от машины. Эти данные можно собирать и использовать для поиска людей.

4. Устройства Wi-Fi и Bluetooth вокруг Вас. Производители смартфонов заложили функции поиска Вашего местонахождения без использования GPS-функций. Достаточно сканировать Wi-Fi сети вокруг устройства. Данные о Вашем местоположении отправляются на сервера третьих компаний.

5. Использование Wi-Fi на смартфоне. Чтобы получить Ваши данные хакеры могут использовать специальные устройства, которые будут мешать работе wi-fi точек доступа и вынуждать Ваш смартфон подключиться к их устройству вместо публичной wi-fi точки доступа. В этом случае все Ваши данные становятся доступными для злоумышленника. В данном случае используются технологии MITM (Man-In-The-Middle) или человек посередине.

6. Использование Tor/VPN. За прошедшие годы было разработано и изучено множество передовых методов деанонимизации зашифрованного трафика Tor. Атака по корреляционным отпечаткам пальцев: эта атака будет отпечатывать ваш зашифрованный трафик (например, веб-сайты, которые вы посещали) только на основе анализа вашего зашифрованного трафика (без его расшифровки). Он может сделать это с колоссальным успехом в 96%. Такие отпечатки пальцев могут использоваться злоумышленником, имеющим доступ к вашей исходной сети (например, Ваш интернет-провайдер), для выяснения некоторых ваших зашифрованных действий (например, какие веб-сайты вы посещали).

7. Современные смартфоны на Android, IOS.
После выключения такого устройства оно будет продолжать передавать идентификационную информацию на близлежащие устройства даже в автономном режиме с использованием Bluetooth Low-Energy. Это дает способ найти Вас даже если Ваш телефон выключен, но имеет подключенный аккумулятор.

8. IMEI идентификатор Вашего оборудования. IMEI привязан непосредственно к телефону, который вы используете. Этот номер известен и отслеживается операторами мобильной связи, а также известен производителями. Каждый раз, когда ваш телефон подключается к мобильной сети, он регистрирует IMEI в сети. Он также используется многими приложениями (например, банковскими приложениями, злоупотребляющими разрешением телефона на Android) и операционными системами смартфонов (Android/IOS) для идентификации устройства. Сегодня предоставление вашего реального номера телефона в основном то же самое или лучше, чем предоставление вашего паспорта. Журналы антенн оператора мобильной связи также хранят некоторые данные о подключении. Они знают и регистрируют, например, что телефон с IMEI, подключен к набору мобильных антенн, и насколько мощный сигнал каждой из этих антенн. Это позволяет легко выполнять триангуляцию/геолокацию сигнала. Они также знают, какие другие телефоны (например, ваш настоящий) подключены в одно и то же время к тем же антеннам с тем же сигналом, что позволит точно знать, что этот телефон всегда был подключен в том же месте и в то же время, что и этот другой телефон, который появляется каждый раз, когда используется записывающий телефон. Эта информация может использоваться различными третьими сторонами для точного определения вашего местоположения/отслеживания.

9. Ваш браузер. При посещении любых сайтов ваш браузер получает уникальные cookie-данные с каждого сайта. Ваши данные в браузере становятся уникальными, а это значит, что веб-порталы знают кто зашел через браузер. На смену cookies приходят supercookies и Ваша анонимность сводится практически к нулю.

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

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

12. Использование антивируса. Антивирус кроме основных своих целей по поиску и обезвреживанию вирусов анализирует вашу сетевую активность, данные браузеров. Эти данные могут быть переданы третьим лицам.

При повышении количества собранных данных формируется цифровой профиль человека, которые содержат в себе:

  • пол;

  • возраст;

  • семейное положение;

  • политические, религиозные взгляды;

  • финансовое состояние;

  • интересы;

  • привычки;

  • и многие другие.

Согласно результатам исследования EFF (Electronic Frontier Foundation), уникальность отпечатка браузера очень высока и он содержит в себе ниже описанные данные:

  • User-agent (включая не только браузер, но и версию ОС, тип устройства, языковые настройки, панели инструментов и т.п.);

  • Часовой пояс;

  • Разрешение экрана и глубину цвета;

  • Supercookies;

  • Настройки куки;

  • Системные шрифты;

  • Плагины к браузеру и их версии;

  • Журнал посещений;

  • И другие данные.

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

Согласно исследованию Browser Fingerprinting via OS and Hardware Level Features, точность идентификации пользователя при помощи отпечатка браузера составляет 99,24%.

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

Статья написана в соавторстве:
1. Меньшиков Ярослав
2. Беляев Дмитрий

Подробнее..

4 часа и ни минутой больше тактика и стратегия Uptime

11.06.2021 12:20:14 | Автор: admin

Привет, я Владислав Алмазов, директор по сопровождению информационных технологий (IT Operations) в Lamoda. Одно из направлений, за которое я отвечаю uptime. Это количественный показатель непрерывной работы нашей платформы.


Дать возможность клиенту найти товар в каталоге, положить его в корзину, выбрать способ доставки, рассчитать скидки и оплатить все это значит оформить заказ. Одноименная кнопка доступна на сайте 99,95% времени в году. Оставшиеся 0,05% это 4 часа в год, которые клиенты не замечают. Эта метрика отражает основное бизнес-требование к непрерывности самых критичных IT-систем. Час простоя для Lamoda это потери десятков миллионов рублей.


По итогам прошлого года мы превысили план и наш uptime составил 99,96%. Дальше я расскажу, за счет чего это удалось.



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


Еще три направления занимаются инфраструктурой:


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

Рецепт uptime


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


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


Обычно дежурят команда Devops, сетевики, безопасники, а также разработчики, так как часто для решения инцидента необходим hotfix. Мы умеем делать hotfix за считаные минуты и выкатывать его на прод, соблюдая все необходимые процедуры и сохраняя возможность сделать rollback. Это помогает нам сохранять высокие показатели uptime.


У нас много расписаний дежурств. Первая линия поддержки работает круглосуточно и первая же реагирует на любые инциденты. Вторая линия сопровождает бизнес-системы, доставку и офис.


У Devops две команды дежурных: одна отвечает за uptime всех платформ онлайн-магазина, которые работают на Linux, а вторая занимается Windows-платформами, например, Active Directory. Дежурные ИБ (SecOps), отвечают за сегментацию сети и инциденты информационной безопасности, а также за управление доступами (IAM). Дежурные сетевые инженеры за сеть в ЦОД и распределенные сети. Дежурные разработчики отвечают за наборы микросервисов, в которых они обладают техническим лидерством.


Мы соблюдаем стандарты информационной безопасности NIST-800 и PCI DSS. Основные компоненты платформы изолированы друг от друга: нет открытой связности между 170 микросервисами онлайн-магазина, а также между другими системами, например ERP и платформой данных и аналитики. Следование таким стандартам позволяет нам снижать риски влияния угроз ИБ на наш uptime.


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


Если говорить о технических мерах, которые помогают нам пассивно бороться с инцидентами, то это, конечно, физическое резервирование. Датацентр отвечает за все, связанное с электропитанием, охлаждением и физической безопасностью. Все системы продублированы и это подтверждено сертификатом TIER III. Как-то раз в разных частях нашего датацентра на расстоянии 30 метров в течение часа были повреждены два ввода питания, и мы фактически полтора дня работали на дизельном электрогенераторе. На работу это никак не повлияло, и все оборудование функционировало в штатном режиме.


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


Вообще, мы очень любим темное волокно это относительно недорого и надежно. Например, у нас два канала волокна по 10 gbps до центрального офиса, фотостудии, сервиса защиты от DDoS, распределительного центра и других объектов. Также у нас есть своя автономная система (AS) и два блока провайдеронезависимых адресов, что позволяет подключаться к интернету у разных провайдеров и иметь пиринг на площадке MSK-IX со скоростью 10 gbps. Тут у нас стопроцентный uptime.


Что нужно, чтобы все работало


Достигать высоких показателей нам помогает резервирование сетевого оборудования: кластер ядра сети, кластеры фаерволов, по два top-of-rack коммутатора, четыре пограничных маршрутизатора. Также у нас есть протоколы отказоустойчивости, например, LACP и протоколы динамической маршрутизации EIGRP и BGP.


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


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


На следующем уровне работы наших приложений, которые относятся к онлайн-магазину, все крутится в Docker и управляется Kubernetes, у которого высокий уровень отказоустойчивости. Тут могут быть лишь секундные потери, если ноды выйдут из строя. В качестве сетевого решения, а также для обеспечения сегментации микросервисов, мы используем Calico. У всех подов есть маршрутизируемые адреса, которые анонсируются по протоколу BGP (Border Gateway Protocol) в корпоративную сеть. Все микросервисы для обмена между собой работают по правилу deny-any-any, поэтому у нас тысячи строк yaml-конфигураций фаервольных правил, а каждый новый микросервис проходит строгую проверку ИБ.


Часто именно базы данных (DB) становятся точкой отказа и могут повлиять на uptime. Наша платформа построена так, что в определенный момент времени есть только одна Master DB, с которой работает конкретное приложение. Но также есть еще от одной до шести Slave DB, у которых есть полная копия Master, но они работают только на чтение. В результате помимо распределения нагрузки, у нас присутствует избыточность данных, в том числе в целях реализации плана непрерывности бизнеса (BCP/DRP).


Для автоматического переключения в случае отказа Master DB мы используем решение Patroni, которое все делает автоматически. Это позволяет снизить downtime до минимальных значений. Был случай, когда до внедрения системы резервирования, сервер, на котором крутилась одна из критических баз данных, вышел из строя. Это случилось в полночь и нам потребовалось всего 9 минут на решение этой проблемы. Три минуты ушли на реакцию инцидент-менеджера, системы мониторинга и подъем дежурного инженера DevOps. Шесть минут ушло на подключение к сети, оперативный анализ ситуации на основе уже имеющихся данных мониторинга и переключение на Master DB.


Не наступать второй раз на одни и те же грабли помогает глубокий post mortem анализ. Мы детально разбираем каждый случай: определяем масштаб проблемы, хронологию событий и системы, которые были вовлечены, затем проводим анализ действий и вводим превентивные меры.


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


4 часа тишины


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


Еще четверть инцидентов или один час последствия bad release, когда некачественно протестированный код попадает в прод. У нас выстроен серьезный процесс разработки, который проходит code review, unit- и интеграционные тестирования в автоматическом и ручном режиме. Перед релизом мы отправляем все на препрод: софт полностью обкатывается на продуктовых данных и только потом попадает в прод. Релизов может быть несколько штук в день, и в таком потоке случаются неожиданные неприятности.


И еще один час downtime это человеческий фактор. Был случай, когда наш новый инженер по информационной безопасности, выполняя достаточно рутинную операцию, внес в конфигурацию файервола ядра некорректное правило фильтрации. Это привело к остановке всего трафика в датацентре. Благодаря системе оперативного мониторинга изменений, мы выяснили причину и пофиксили это за 25 минут, а инженер даже не понял, что по его вине произошел инцидент, так как он случился с задержкой во времени. После этого появилось правило 4eyes-review. То есть все подобные изменения катятся не в одни руки, а только двумя инженерами совместно, как и во многих других процессах.


Чтобы избежать downtime, все инфраструктурные изменения проводятся через так называемый RFC (Request for change). Этот набор правил касается выкатки на прод: чтобы внести изменения в инфраструктуре, инициатор описывает план действий, получает подтверждение другого инженера, и обозначает downtime в минутах. Для таких изменений мы выделяем определенное временное окно. Если нужно обновить софт на ядре и это приведет к downtime в 10 минут, то я согласую время с 4 до 6 утра. В это время происходит минимальное количество заказов, соответственно, импакт для бизнеса будет меньше.


RFC проводится несколько раз в неделю, чтобы минимизировать downtime. Тут у нас строгая дисциплинa: если все же downtime возможен, то он по факту он не должен оказаться выше, чем планировалось. Это учит грамотно оценивать уровень риска и не занижать его, даже если его вероятность 0,01%. От того, насколько мы уложились в прогноз, зависит и наш KPI.




Напоследок скажу, что работа над uptime это непрерывный процесс, требующий внимания, с учетом того, что любая онлайн-платформа растет и развивается очень быстро. В основном, управление инфраструктурой и рисками, кроме влияния на time-to-market, не зарабатывает деньги для бизнеса, но позволяет контролировать его расходы, снижая издержки и предотвращая резкие влияния серьезных инцидентов на финансовые показатели компании.

Подробнее..

Интеграция SAML в Zimbra OSE

16.06.2021 14:10:53 | Автор: admin
Технология единого входа обладает массой преимуществ по сравнению с классическими методами аутентификации, главное из которых заключается в том, что именно SSO обеспечивает наилучший баланс между удобством пользователя и информационной безопасностью предприятия. Ранее мы уже рассказывали о том, как реализовать SSO в Zimbra OSE при использовании аутентификации в Active Directory с помощью Kerberos. На этот раз мы расскажем о том, как внедрить Zimbra OSE другую технологию единого входа SAML на примере провайдера Okta.

image

Единый вход с помощью SAML в Zimbra OSE доступен только для пользователей Zextras Suite Pro.

Подготовка к интеграции

В первую очередь для включения интеграции в SAML, необходимо пропатчить NGINX. Для этого в папке /opt/zimbra/conf/nginx/templates/ отредактируйте поочередно файлы:

  • nginx.conf.web.http.default.template
  • nginx.conf.web.http.template
  • nginx.conf.web.https.default.template
  • nginx.conf.web.https.template

Во всех файлах в разделе location ^~ /zx/ замените содержимое на

location ^~ /zx/

{

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header Host $http_host;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header X-Forwarded-Port $server_port;

proxy_pass ${web.upstream.zx};

}


Эти изменения нужны для того, чтобы составлять полноценные URL-запросы Protocol X и X-Port.

Также необходимо активировать движок аутентификации от Zextras на уровне домена. Сделать это может администратор сервера, введя в командной строке команду zmprov modifyDomain example.ru zimbraAuthMech custom:zx.

Создание приложения в Okta

В том случае, если вы ранее не использовали SAML для доступа к ресурсам компании, вам придется создать собственное приложение для аутентификации пользователей. Для того, чтобы создать такое приложение в Okta:

1. Зарегистрируйтесь в качестве разработчика на сайте okta.com

2. В личном кабинете нажмите на кнопку Create App Integration



3. В открывшемся списке выберите SAML 2.0 и нажмите Next



4. В следующем окне укажите название своего приложения, выберите иконку и настройте его видимость и нажмите кнопку Next, когда всё будет готово



5. В следующем окне:

  1. В качестве SSO URL укажите адрес вашего сервера с аппендиксом /zx/auth/saml
  2. В качестве Audiend URI укажите адрес вашего сервера с аппендиксом /zx/auth/samlMetadata
  3. В качестве Name ID Format укажите EmailAddress
  4. Нажмите кнопку Next



6. В мини-опросе выберите первый вариант ответа и нажмите кнопку Finish



7. Скачайте метаданные своего приложения SAML



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

Экспорт учетных записей из домена Zimbra OSE

Приложение SAML поддерживает как создание новых учетных записей, так и импортирование уже существующих из Zimbra. Для того, чтобы импортировать учетные записи, необходимо сперва экспортировать их из Zimbra в формате .csv.

Для экспорта учетных записей перейдите в консоль администратора Zimbra, перейдите во вкладку Поиск и осуществите поиск по пользователям с названием домена в поисковом запросе. Результатом поиска будет полный список пользователей домена, который можно выгрузить в формате CSV, нажав на иконку Дополнительные настройки в правом верхнем углу и выбрав раздел Загрузить



Импортируйте полученный CSV в приложение SAML с помощью соответствующего инструмента в личном кабинете разработчика.

Интеграция приложения в Zimbra OSE

Чтобы интегрировать приложение SAML в Zimbra OSE, вам потребуются данные из скачанного ранее файла с метаданными приложения.

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

Для того, чтобы выполнить интеграцию в автоматическом режиме, введите команду zxsuite auth saml import example.ru url dev-3299935.okta.com/app/exkvjcggn7C7jrhc75d6/sso/saml/metadata. Если вы используете собственный сервер SAML с самоподписанными сертификатами, используйте параметр allow_insecure true для пропуска проверки подлинности SSL-сертификата.

Чтобы провести интеграцию в ручном режиме, экспортируйте настройки SAML по умолчанию при помощью команды zxsuite auth saml get example.ru export_to /tmp/saml.json. Откройте полученный файл /tmp/saml.json в любом редакторе и добавьте в него следующие данные, заменяя строки отмеченные знаками >> << данными из файла с метаданными. В нашем случае добавленные строки будут выглядеть следующим образом:

sp.nameidformat:urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress ,
sp.entityid: >>example.ru/zx/auth/samlMetadata?domain=example.ru<<,
sp.assertion_consumer_service.url: >>example.ru/zx/auth/saml<<,
idp.single_sign_on_service.url: >>dev-3299935.okta.com/app/dev-3299935_zextrassamlintegration_1/exkvjcggn7C7jrhc75d6/sso/saml<<,
idp.entityid: >>www.okta.com/exkvjcggn7C7jrhc75d6<<,
idp.x509cert: >>MIIDpjCCAo6gAwIBAgIGAXmC9e8bMA0GCSqGSIb3DQEBCwUAMIGTMQswCQYDVQQGEwJVUzETMBEG A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzENMAsGA1UECgwET2t0YTEU MBIGA1UECwwLU1NPUHJvdmlkZXIxFDASBgNVBAMMC2Rldi0zMjk5OTM1MRwwGgYJKoZIhvcNAQkB Fg1pbmZvQG9rdGEuY29tMB4XDTIxMDUxOTA0NDkyNloXDTMxMDUxOTA0NTAyNlowgZMxCzAJBgNV BAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1TYW4gRnJhbmNpc2NvMQ0wCwYD VQQKDARPa3RhMRQwEgYDVQQLDAtTU09Qcm92aWRlcjEUMBIGA1UEAwwLZGV2LTMyOTk5MzUxHDAa BgkqhkiG9w0BCQEWDWluZm9Ab2t0YS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCOJA7bhf/LO89VpuGTHur77RbwKlJg3Eni/P4JKowSVrQD6PghwprCdzThyTsKWcHwESZoYwEL WdrZ6CVzDZWAegWJnaJivfiFlFjsEZ15UHOGizMBM3VI0ePWjaWJ6O2DM9BID2mGULnXUDbQXbf6 rE1EHxzlxzCKIBWmT8ut/JsA/lmBm0YNi4BKfP06KXCLianxoH+fEETNd/NH2mXwgHdxMV1BS/mm TAHSJtkDfWxTM+dTGngrjMANKvmChGjSO1ZXFs/pm+vx0o6ffYcoeXnfgodBX3FZ7aTFBTk0s5Se Wms1utjfa8qhHbrolErqqIc1PPBngEFvzcLjFAfRAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAByU jjdAc5tdH+QFAHS0CJNYa9VNaapxuEFrlR3ZdAztIaczKUqYfHqHdXuDHYCjdHXhLFHwntBsnphk M2sk8D2zG0wpoYsEA3IrvbXoTwwqDzACpLF37S7Pfn0RjE5IvvJ9WP4DoZa9ikM/p0N+H7fpqkU2 xavoiNGOMqot9xpWrytM0P+luXereriOOzVaBS1+DuhA4INhze5luyc52X18T4HrJ3iGivfXR2os L8/PI4gZwR956Ju8tDEcmFVCelLN4FlN3ITogPK+SyKHhlTBuSGHidrGKQJBRmkLhk6lhKWTHjWP mI88ECqrA63+QvxU4KRUl1zzRgKVwrgzos4=<<

Сохраните внесенные в файл изменения и импортируйте его в Zimbra OSE с помощью команды zxsuite auth saml import example.ru /tmp/saml.json



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

По всем вопросам, связанными c Zextras Suite Pro и Team Pro вы можете обратиться к Представителю компании Zextras Technology Екатерине Триандафилиди по электронной почте ekaterina.triandafilidi@zextras.com
Подробнее..

USB over IP удалённое администрирование

21.06.2021 16:11:25 | Автор: admin

Большую часть своей жизни я жил и работал в Москве. Занимался тем, что менял здоровье на деньги. Правда, на очень хорошие, поэтому под занавес пятого десятка купил квартиру в тихом приморском городке, далеко от столичной суеты и ежедневной нервотрёпки.

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

Работа в тихом городке

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

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

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

Иногда приходилось выезжать на место, но не часто. Большинство задач вполне решалось дистанционно либо через TeamViewer, либо по телефону. Меня это устраивало, клиентов тоже.

Токены головная боль

Например, надо срочно отправить счёт. Сотрудник вводит пароль, входит в Диадок, загружает документ Но подписать его не может его коллега вчера сунул ключ себе в карман, а сегодня не пришёл на работу, поскольку с утра поехал утрясать какие-то вопросы с партнёром. Приходится отгружать товар без оплаты. Это означает, что деньги придут с большой задержкой как известно, уже оказанная услуга услугой не считается.

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

Всё действительно сложно

Сначала задача показалась мне простой. Технология USB over IP существует достаточно давно все токены подключены к одному устройству, а сотрудники работают с ними, как с локальными. Ничего не теряется, поскольку не покидает пределов офиса.

Осталось полчасика погуглить, найти решение подешевле и предложить заказчикам. Но ни тут-то было. Поразмыслив, я пришёл к выводу, что такой проект значительно сложнее, чем казался.

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

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

Поскольку айтишников на фултайме ни в одной конторе не было, самодельные и софтовые решения исключались. Делать, настраивать и чинить некому.

По масштабированию прекрасно подходят облака. Но цены у них откровенно кусаются. Например, сервис FlexiHub обойдётся заказчику более 10 тыс. рублей в месяц за 5 ключей, не считая стоимости хаба. И это без гарантий совместимости.

Но самое главное сервисы требуют регулярной своевременной оплаты. У небольшой компании с этим могут быть проблемы. У неё не всегда есть возможность даже зарплаты сотрудникам заплатить вовремя. Задержка в неделю-другую дело обыкновенное.

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

Если ориентироваться на мировые бренды, то надо брать Digi AnywhereUSB. За 2 USB-порта больше 20 тыс. рублей, за 14 портов в районе 150 тыс. рублей. Для небольших компаний это явно дорого.

Конечная остановка USB over IP концентратор

Перебирая варианты я пришёл к отечественному аппаратно-программному решению DistKontrolUSB. На нём и остановился. Причин этому несколько.

Прежде всего цена. За концентратор на 4 порта мой мелкий клиент заплатит 26 тыс. рублей с хвостиком, а более крупным придётся выложить около 69 тыс. рублей, но за 16 портов. Дешевле западного аналога в два раза.

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

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

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

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

Третье достоинство удобное удалённое управление концентратором через веб-интерфейс. Это особенно важно для более крупных организаций, которым подойдёт концентратор на 16 портов. Сотрудников там больше и без каких-то элементов ИБ не обойтись.

Допустим, по соображением безопасности требуется ограничить доступ к порту по IP-адресу, а к ключу по логину и паролю. Через панель управления это делается мгновенно, причём в одном модуле. Надо всего два раза сдвинуть соответствующие ползунки и нажать на кнопу Сохранить. Изменения сразу вступят в силу.

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

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

В настройках USB over IP концентратора было сформировано автоматическое задание, по которому устройство отключается в заданное время. А чтобы директор не волновался и спал спокойно он получает уведомление о выполнении на электронную почту.

Итоги

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

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

Например, дневная задержка в оплате счёта на один миллион стоит от 100 до 1000 рублей в зависимости от договора. С отчётностью ещё хуже 5% от суммы налога. А это уже несколько тысяч даже для небольшой фирмочки. Причём, только прямого ущерба о каких-то сорвавшихся сделках я даже не говорю.

Сумму убытков из-за подобных задержек владелец компании знает. Стоимость USB over IP концентратора тоже. Срок окупаемости вычисляется без всякой высшей математики.

Насколько я могу судить, первопроходцы уже ушли в плюс. Даже те, кто приобрёл устройство на 16 портов.

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

Впрочем, вру. Мои клиенты уже начали рекомендовать меня своим знакомым. Я думаю, что по уровню заработка я тут потихоньку достигну своего бывшего московского уровня. Жалею, что не уехал из Москвы раньше.

Подробнее..

Перевод Локальный TCP Anycast это действительно сложно

17.06.2021 18:06:38 | Автор: admin

Pete Lumbis и Network Ninja в своих комментариях к моим записям, посвященным UCMP, упомянули интересный случай использования UCMP в центре обработки данных: а именно серверы anycast.

Вот типичный сценарий, который они упомянули: группа серверов, случайно подключенных к нескольким leaf-коммутаторам, предоставляет услугу на одном и том же IP-адресе (отсюда и происходит anycast).

Прежде чем вдаваться в подробности, давайте зададим себе простой вопрос: Работает ли это за пределами PowerPoint? Безусловно. Это идеальная конструкция для масштабируемой UDP-службы, такой как DNS, и крупные фермы DNS-серверов обычно строятся именно таким образом.


Сложности TCP Anycast

Действительно интересный вопрос: Работает ли это для сервисов TCP? Теперь мы подходим к действительно сложной части - поскольку spine и leaf-коммутаторы выполняют ECMP или UCMP в отношении anycast IP-адреса. Кто-то должен следить за назначениями сессий серверам, иначе весь хаос выйдет из-под контроля.

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

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

Потеря соединения и узла

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

Хеш-бакеты для действительных next-hops не трогаются.

Недействительные хэш-бакеты (из-за недействительного next-hop) переназначаются на действительные next-hops.

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

Добавление новых серверов

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

И, наконец, ICMP: ICMP-ответы включают оригинальные номера портов TCP/UDP, но ни один аппаратный коммутатор не в состоянии копаться в пакете так глубоко, поэтому ICMP-ответ обычно отправляется на какой-то случайный сервер, который понятия не имеет, что с ним делать. Добро пожаловать в хаос PMTUD.

Обеспечить работу Локальный TCP Anycast

Значит ли это, что невозможно выполнить локальную балансировку нагрузки TCP anycast? Конечно, нет - каждый гипермасштабируемый центр обработки данных использует этот трюк для реализации масштабируемой балансировки нагрузки в сети. Инженеры Microsoft писали о своем решении в 2013 году, Fastly задокументировал свое решение в 2016 году, у Google есть Maglev, Facebook открыла Katran, мы знаем, что у AWS есть Hyperplane, но все, что мы получили из видеороликов re:Invent, - это потрясающая магия. На конференции Networking @Scale 2018 они рассказали еще несколько подробностей, но это все еще было на уровне Karman.

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

Существует, по крайней мере, несколько программных решений с открытым исходным кодом, которые можно использовать для создания крупномасштабных служб anycast TCP. Если вы не чувствуете себя комфортно при использовании таких "горячих" новинок, как XDP, есть BalanceD от Demonware, использующий Linux IPVS.

С более академической стороны, есть Cheetah... и в радужном будущем мы, возможно, получим довольно оптимальное решение, напоминающее сеансовый уровень с Multipath TCP v1.

Для изучения


Прямо сейчас мы в OTUS запускаем специализацию Network Engineer. В связи с этим приглашаем всех желающих на демоурок по теме: "Технологии прошлого. RIP". В рамках урока рассмотрим протокол динамической маршрутизации RIP. Плюсы и минусы технологии. Разберем, почему не используется в продакшн, но где еще нужен, а также какие протоколы пришли ему на замену. Протокол RIP в своей простоте настроек и работы наглядно продемонстрирует логику работы протоколов динамической маршрутизации. Даст понимание о возможностях и необходимости использования такой маршрутизации.

Подробнее..

Промышленные VS офисные сети построение, защита, подвохи, и как надежно отделить первые от вторых

07.06.2021 18:08:54 | Автор: admin
Привет, Хабр! Этим постом я хотел бы начать серию публикаций по промышленным решениям, которые мы сейчас активно тестируем в нашей КРОК-лаборатории. Для начала попробую разобрать основные вопросы проводных промышленных сетей и показать, чем их построение отличается от классических офисных. В качестве подопытного кролика возьму наиболее востребованное на рынке оборудование и софт от Cisco и разберу их особенности.



Как организовать Ethernet-подключения в промышленных зонах?


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

Здесь возникает первая сложность и первое же отличие промышленных сетей от офисных: большая часть коммутаторов устанавливается не в серверные, а в монтажные шкафы, разбросанные по цехам или по территории объекта. Тянуть от каждого монтажного шкафа по две оптические линии по разным путям дорого и сложно, из-за этого становится сложнее организовать привычную и надёжную звездообразную топологию. Приходится использовать кольца. Каждый, кто погружался в построение Ethernet-сетей, помнит, что кольца из коммутаторов зло. В случае со Spanning-Tree это действительно так. Этот протокол в кольцевой топологии может отрабатывать до 30 секунд, что часто неприемлемо для сетей, обслуживающих производственные процессы. Хуже того, скорость сходимости STP падает с увеличением количества хопов от корневого коммутатора до крайних коммутаторов, и как правило, рекомендуется не превышать расстояние в 7 хопов. Это значит, в кольце должно быть не больше 14 коммутаторов.

Что с этим можно сделать? В случае с коммутаторами Cisco, самое простое решение использовать вместо STP Resilient Ethernet Protocol REP и его модификацию REP Fast. Данный протокол специально предназначен для кольцевых топологий и обеспечивает сходимость сети максимум за 50-100мс при любых типах неисправностей и размерах колец до 50 коммутаторов. Причём 50 коммутаторов в кольце это не предел для такого протокола. Время сходимости при росте кольца конечно будет увеличиваться, но тот же Spanning-Tree на кольцах такого размера не сойдётся вообще никогда. REP поддерживается не только в промышленных коммутаторах, но и в офисных, в частности в серии Catalyst 9000, которые могут служить в качестве коммутаторов агрегации.

Протокол очень прост в настройке, вот пример:



Для более сложных случаев доступны протоколы PRP и HSR. Они предполагают полную дупликацию трафика по двум путям в сети. При отказе одного из путей потерь в передаче данных не возникает вообще. Однако и стоимость реализации такой устойчивости выше протокол поддерживается только в старших моделях и только промышленных Ethernet-коммутаторов (IE3400, IE4000, IE4010, IE5000). Впрочем, требования к надёжности и сходимости промышленной сети, как правило жёстко определяются характером производственного процесса, который эта сеть будет обслуживать. Один простой даже в 50 миллисекунд порой может стоить дороже, чем хорошее сетевое оборудование.

Как обеспечить требуемую надёжность работы?


Как правило требования по надёжности и отказоустойчивости к промышленному сегменту сети выше, чем к офисному. Промышленное сетевое оборудование делается и тестируется так, чтобы отвечать этим требованиям. В случае с коммутаторами Cisco, промышленное исполнение означает:

монтаж в компактные шкафы на DIN-рейку, питание от постоянного тока;
защита микросхем и портов от электростатических разрядов до 4000 кВ;
отсутствие вентиляторов высокоэффективное охлаждение конвекцией, несмотря на малый размер устройств;
способность выдерживать скачки напряжения электропитания согласно требованиям сертификаций IEC 61000-4-11, IEC 61850 коммутаторы Cisco продолжают работать при пропадании электропитания на промежуток времени до 50 мс, а при отключении отправляют сигнал Dying Gasp;
высокоточные внутренние часы;
возможность быстро заменить неисправный коммутатор, просто переставив SD-карту в новый (при этом новый коммутатор поднимется не только с тем же конфигом, что и старый, но и с тем же образом IOS);
быстрая загрузка (в пределах 80 секунд);
тщательное тестирование на соответствие промышленным сертификациям.


Рисунок 1. Симуляция процесса охлаждения коммутатора конвекцией


Рисунок 2. Тестирование коммутатора на устойчивость к электромагнитным воздействиям


Рисунок 3. Тесты с воздействием водой на коммутатор с уровнем защиты IP67

Часто так бывает, что промышленные коммутаторы подключаются к обычным офисным, как к коммутаторам агрегации и при отказе последних промышленный сегмент перестаёт работать. Чтобы такого не допустить, необходимо обеспечивать агрегацию промышленных коммутаторов, расположенных в цехах или по территории промышленного предприятия, на специальных промышленных коммутаторах агрегации. Cisco для этой цели предлагает коммутаторы серии Cisco IE5000:



Они монтируются в 19-дюймовый шкаф, могут питаться и от постоянного и от переменного тока, обеспечивают высокую плотность портов, высокую производительность, но при этом промышленную надёжность и поддержку промышленных протоколов, например PTP, PRP, HSR, PROFINET MRP. Как и другие коммутаторы промышленной линейки, Cisco IE5000 умеют принимать сигналы тревоги от устройств автоматики, например, устройств контроля климата или датчика открытия двери в помещение, и отдавать их например для включения сирены и светового оповещения, помимо, конечно же, SNMP и Syslog-сообщений о состоянии коммутатора, отсылаемых в системы мониторинга. Кроме того, эти коммутаторы поддерживают стекирование через 10G-порты. Вот пример построения сети с использованием REP-колец и коммутаторов IE5000 в качестве агрегирующих:



Поддержка промышленных протоколов


В промышленных Ethernet-сетях используются Ethernet-версии различных промышленных протоколов: PROFINET, CCLINK, CIP и т.п. При этом, как правило, от сетевого оборудования требуется поддержка таких протоколов в том или ином виде. К примеру, при использовании PROFINET, требуется управлять с помощью этого протокола не только контроллерами, сенсорами или исполнительными устройствами, но и самими коммутаторами, образующими сеть. Для этого в моделях промышленных коммутаторов Cisco начиная с IE3000 реализована поддержка работы по PROFINET в качестве устройства ввода-вывода. Кроме того, некоторыми моделями коммутаторов Cisco можно управлять с помощью портала Siemens TIA.

Ещё один пример промышленного стандарта, поддержка которого часто требуется Time-Sensitive Networking (TSN). Это набор стандартов Ethernet, позволяющий обеспечить доставку Ethernet-фреймов с предсказуемой и не меняющейся во времени задержкой. Привычный Ethernet, напомню, работает асинхронно и фреймы в нём доходят до адресата настолько быстро, насколько получается. Функционал TSN протокол поддерживается в коммутаторах Cisco IE3400, IE4000, IE4010 и IE5000.

Как защитить промышленную сеть?


Многие стандарты и рекомендации построения промышленных сетей предусматривают реализацию демилитаризованной зоны ДМЗ между офисной и промышленной сетями. В этой зоне могут располагаться рабочие станции для удалённого доступа к промышленным компонентам. Есть целый ряд рекомендаций по построению такой ДМЗ, например:

трафик не должен проходить между офисной и промышленной сетями насквозь;
любой протокол, разрешённый между ДМЗ и промышленным сегментом должен быть в явном виде запрещён между ДМЗ и офисным сегментом;
в промышленный сегмент сети не должно быть доступа из интернета, даже через межсетевой экран;
И конечно никаких Any в полях для IP-адресов, портов и протоколов в политиках межсетевого экрана.

В идеале ДМЗ должна быть устроена так что если её физически отключить от сети, промышленный сегмент продолжит работать.

Промышленный, офисный и ДМЗ-сегменты отделяются друг от друга межсетевыми экранами. Здесь у Cisco явное преимущество на её продуктах можно построить защищённую сеть от и до.
Межсетевые экраны Cisco умеют распознавать не только промышленные сетевые протоколы:







но и промышленные устройства, подключённые к сети:



А также обнаруживать, разрешать или запрещать конкретные действия в рамках данных протоколов:



Это позволяет выстраивать политики межсетевого экранирования не только на базе IP-адресов и TCP/UDP-портов, но и на базе наименований конкретных моделей устройств и протоколов взаимодействия между ними. Для большинства ситуаций в межсетевом экране есть преднастроенные правила, которые можно использовать с собственными параметрами. Такими правилами можно защищаться не только от преднамеренных атак, но и от дурака ошибочно подаваемых на промышленные устройства команд.

Межсетевые экраны обеспечивают так называемую макросегментацию сети разделение на крупные участки, трафик между которыми либо запрещён, либо фильтруется через правила межсетевого экранирования. Таким образом отделяются друг от друга не только ДМЗ, промышленный и офисный сегменты сети, но и, например, разные цеха и производственные линии в промышленном сегменте. Для последней задачи может пригодиться межсетевой экран Cisco Industrial Security Appliance (ISA) полноценный фаерволл в промышленном исполнении.



Как правильно обеспечить удалённый доступ?


Как правило, в промышленных сетях требуется обеспечивать удалённый доступ для организаций, обслуживающих оборудование АСУТП. При этом, важно хорошо контролировать кому и куда такой доступ предоставляется и защититься от доступа несанкционированного. Удалённый доступ осуществляется через описанную выше ДМЗ.

Здесь, помимо межсетевых экранов Cisco Firepower, огромную помощь может оказать решение Cisco Identity Services Engine. Межсетевые экраны обеспечивают подключение с помощью AnyConnect VPN или проксирование трафика удалённого рабочего стола, а ISE позволяет максимально чётко идентифицировать и человека, получающего доступ и объект в сети, к которому этот доступ предоставляется, а также определить политики такого доступа в виде своего рода матрицы:



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





Как выполнить требования регуляторов?


Стандарты международных организаций и дизайн-документы Cisco Validated Design только дают рекомендации как лучше. Но кроме рекомендаций есть ещё и требования регулирующих органов, которые необходимо выполнять при построении промышленных сетей. В России к таким относится приказ 239 ФСТЭК Об утверждении требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации. Он содержит перечень архитектурных решений функционала, которые должны быть реализованы.

Часть требований приказа, такие как наличие межсетевого экрана и обновляемого IPS на периметре промышленного сегмента, сегментация сети, организация ДМЗ закрываются межсетевыми экранами Cisco Firepower, описанными выше. Требования по аутентификации и авторизации Cisco ISE. Далее, целый набор требований, связанных с мониторингом промышленной сети закрывается решением Cisco CyberVision.

Решение Cisco CyberVision может собрать данные с промышленной сети в виде SPAN-трафика или со специальных сенсоров в сетевых устройствах и представить картинку происходящего администратору, а также отправить необходимую информацию в системы управления конфигурациями и SIEM. Администратор сети может получить полный список устройств, подключённых к промышленному сегменту сети (не только Ethernet-коммутаторов, но и устройств промышленной автоматики), проверить их на известные уязвимости и отследить их поведение.


Рисунок 4. Пример отображения известных уязвимостей для промышленных устройств

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

Всё о проекте Спутниковый интернет Starlink. Часть 31. Описание антенны Ка-диапазона

09.06.2021 00:09:23 | Автор: admin
Предлагаю ознакомиться с ранее размещенными материалами по проекту Starlink (SL):
Часть 25. EPFD или административно-физическая гиря на ногах SpaceX Часть 26. Первые итоги. Часть первая позитивная Часть 27. Первые итоги. Часть вторая проблемная Часть 28. Использование StarLink на движущихся объектах Часть 29. Страны, где сервис начнет предоставляться в первую очередь Часть 30. Сравнение сервиса StarLink с сервисами других операторов ШПД

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


Приведенный ниже документ Starlink Gateway V3 Technical Information 08-07-20 является актуальным и используется в США и за его пределами подрядчиками SpaceX при строительстве Гейтвеев. В документе указаны основные технические параметры антенны и приемопередатчика Гейтвея.


Contents

  • Gateway V3 Summary
  • System Specifications
  • RF Overview
  • Mechanical Overview
  • Gateway V3 Block Diagram
  • Gateway V3 Wiring Diagram
  • Gateway Grounding Diagram
  • Harmonized Shipping Codes (TBD)
  • Photographs

Gateway V3 Summary

  • The Starlink V3 Gateway is a fully integrated Ka antenna and motion platform, assembled into a weather resistant

enclosure ( radome ).

  • Gateways are custom steerable parabolic dishes that provide the high bandwidth data backhaul to our satellites.

Unlike the user terminals, the gateways are not placed at customers houses they are located behind fences at

telecom sites

  • The gateway is powered using 240VAC, 3 phase power and communicates to an external network switch through a fiber optic cable. An umbilical Ethernet connection is available for testing purposes, but will not be used in the field.

Inside the radome are heaters and a blower to control internal temperature (and humidity to some extent). Below is a simplified assembly level block diagram


System Specifications



RF Overview



  • The radiation pattern of the gateway is designed to be compliant with the

following specifications:

FCC 25.209

ITU S.580

  • The spectral mask of the gateway is designed to be compliant with the

following specifications:

ITU SM.1541

ITU SM.329

FCC 25.202

Mechanical Overview




Gateway V3 Block Diagram




Gateway V3 Wiring Diagram







Gateway Grounding Diagram




Photographs




Partial 1x9 Site Example




Partial 3x3 Site Example



Revision History

  • 07/08/2020: Added RF overview slides.
Подробнее..

Свой лунапарк TFTP с блэкджеком и С17

02.06.2021 12:04:43 | Автор: admin

image


Преамбула


Я работаю в команде разработки встраиваемого ПО на базе GNU Linux для телекоммуникационного оборудования. В ходе разработки у нашей команды появляется огромное количество прошивок для нашего оборудования: релизные версии, предрелизные версии, тестовые отладочные сборки, сборки для разных веток из трекера задач и все это для разных аппаратных платформ.


Прошивка, в данном случае, это ...

набор бинарных файлов, размером до 70Мб, представляющих собой:


  • доработанный Das u-boot;
  • доработанное ядро GNU Linux;
  • файловая система, в которой содержится множество скомпилированных исполняемых файлов, конфигураций и пр., например, корневая файловая система GNU Linux;
  • кортеж комбинаций всего перечисленного;

Для идентификации файлов прошивки в системе документооборота и трекере используются MD5 хеши в файлах *.md5. В итоге имеем несколько деревьев в файловой системе для хранения прошивок.


Обновление ПО, а именно передача прошивки в изделие, происходит через протокол TFTP.


Постановка задачи


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


Результат


В результате, получился проект TFTP Firmware Server или просто server-fw.


Поддержка рекомендаций:


  • RFC1350 "THE TFTP PROTOCOL (REVISION 2)"
  • RFC2347 "TFTP Option Extension"
  • RFC2348 "TFTP Blocksize Option"
  • RFC7440 "TFTP Windowsize Option" (экспериментально)

Текущая версия сервера v0.2.0


Список опций сервера
$ bin/server-fw -hSimple tftp firmware server 'server-fw' v0.2 licensed GPL-3.0(c) 2019-2021 Vitaliy.V.Shirinkin, e-mail: vitaliy.shirinkin@gmail.comSome features:  - Recursive search requested files by md5 sum in search directory  - Use Firebird SQL server as file storage (optional requirement)Usage: bin/server-fw [<option1> [<option1 argument>]] [<option2> [<option2 argument>]] ... Possible options:  {-h|-H|-?|--help} Show help message  {-l|-L|--ip|--listen} {<IPv4>|[<IPv6>]}[:port] Listening address and port    (default 0.0.0.0:69)    Sample IPv4: 192.168.0.1:69    Sample IPv6: [::1]:69  {-s|-S|--syslog} <0...7> SYSLOG level flooding (default 6)  --lib-dir <directory> System library directory  --lib-name <name> Firebird library filename (default libfbclient.so)  --root-dir <directory> Server root directory  --search <directory> Directory for recursive search by md5 sum (may be much)  --fb-db <database> Firebird access database name  --fb-user <username> Firebird access user name  --fb-pass <password> Firebird access password  --fb-role <role> Firebird access role  --fb-dialect <1...3> Firebird server dialect (default 3)  --daemon Run as daemon  --retransmit <N> Maximum retransmit count if fail  --file-chuser <user name> Set user owner for created files (default root)  --file-chgrp <group name> Set group owner for created files (default root)    Warning: if user/group not exist then use root  --file-chmod <permissions> Set permissions for created files (default 0664)    Warning: can set only r/w bits - maximum 0666; can't set x-bits and superbits

Сервер позволяет настроить один основной каталог (опция --root-dir) и любое количество каталогов для поиска (опция --search). Каталоги для поиска работают только для GET запросов.
Для принимаемых файлов сервер позволяет настроить права (опция --file-chmod) и владение (опция --file-chuser и опция --file-chgrp).


Для запуска в качестве демона настройки располагаются в файле /etc/default/server-fw.


Соответствие настроек файла конфигурации и аргументов командной строки сервера
Настройки демона в файле /etc/default/server-fw Аргументы командной строки
IP --listen
SYSLOG --syslog
ROOT_DIR --root-dir
SERACH --search
FILE_CHUSER --file-chuser
FILE_CHGRP --file-chgrp
FILE_CHMOD --file-chmod

Обработка запросов GET осуществляется в следующем порядке:


  • если сервер распознает имя как md5-хеш, то ищет по хешу:
    в основном каталоге сервера
    в дополнительных каталогах поиска в порядке их задания в опциях
  • сервер ищет по имени файла:
    в основном каталоге сервера
    в дополнительных каталогах поиска в порядке их задания в опциях

При обработке запросов PUT, сервер складывает файл в основной каталог.


Пакет для установки для OC Ubuntu 18.04 (другие не проверялись) лежит здесь


Для самостоятельной сборки (GNU Linux):


$ mkdir server-fw$ git clone https://github.com/shvit/server-fw.git server-fw...$ cd server-fw$ make deb...$

Рефлексия


Сервер не поддерживает режим mail и netascii, вернее он должен их обрабатывать аналогично режиму octet (интересно узнать, а кто-то их испрользует? см. опрос).


Проверить опцию "windowsize" пока не получилось, но вроде должно работать.


Послесловие


Задачи на будущее:
  • использовать для хранения файлов реляционную СУБД
  • расширить поиск файлов по дополнительным метаданным
Подробнее..

BGPexplorer машина времени для IPMPLS сетей

10.06.2021 18:12:02 | Автор: admin
Предисловие

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

Современные сети, основанные на маршрутизации IP-пакетов, а точнее сервисы, которые они предоставляют, по факту управляются протоколом BGP. Этот протокол был спроектирован в конце 80-хх на трех салфетках. Да, с тех пор в этот протокол добавили массу возможностей, в том числе обмен маршрутной информацией VPN, правилами фильтрации трафика и всяким прочим полезным, но основа там осталась все той же, описанной на трех салфетках. И в этом есть свой плюс, потому что этот протокол в своей сути очень прост.

Но я хотел поговорить не о его простоте, а о "махании кулаками после драки", с которой частенько приходится сталкивать любой службе эксплуатации сети, или NOC - network operation centre (а может быть и center).

Поступает жалоба "а у меня вот сайт не открывается", или "вот час тому назад плохо работал сайт такой-то, а 5 минут тому назад он починился". Инженер идет на маршрутизатор и смотрит что маршрут к адресу рекомого сайта изменился 5 минут тому назад. И что с этим можно сделать? Чаще всего мало чего. Маршрутизатор знает, что вот такой маршрут "прилетел" 5 минут тому назад, а вот что было раньше? Может быть ничего существенного и не произошло, у маршрута обновились какие-нибудь информационные параметры, а пакеты как летели, так и летят в том же направлении. А может быть наоборот - маршрут изменился существенно и пакеты летят совсем в другом направлении. И узнать историю без дополнительного инструментария (или машины времени) нет возможности. И опять же - хорошо бы узнать, что же именно менялось. Да, есть глобальный инструмент bgplay. Но он рассчитан на использование в Интернете и запоминает изменения при перестроении маршрута между разными провайдерами. А вот изменения внутри сети одного провайдера он не ловит, да и не должен, так как не все то что происходит внутри автономной системы, должно быть видно снаружи.

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

А вот дальше я подзавис. Самая лучшая библиотека, даже я бы сказал целый фреймворк, для обработки BGP - это пакет exabgp. Всем хорош и удобен. Один, на мой взгляд, существенный минус - он на python. Не то чтобы я был питононенавистником, отнюдь. Но каждый инструмент хорош, когда применяется по назначению. А python имеет всем известные особенности (интерпретатор, GIL), которые препятствуют эффективной обработке данных, если алгоритмы реализовывать именно на нем. И в данном случае мне хотелось бы иметь реализацию инструмента на компилируемом (как минимум) языке, с управляемыми политиками блокировок. А также иметь возможность выделить обработку протокола BGP в виде библиотеки и желательно чтобы применяемый язык мог позволить библиотеке жить без своего неотделимого и неотъемлемого рантайма (привет, golang!). Для чего? Ну, например, для того чтобы в перспективе применять эту библиотеку для других bgp-шных приложений. Ну и для скорости. Далеко не для всех видов запросов для поиска маршрутной информации возможно построить эффективный индекс.

Решил я попробовать в качестве основного языка по этой теме Rust и в общем все что хотел получилось. Работу с протоколом BGP выделил в библиотеку. В отличие от exabgp реализовывать логику работы BGP FSM в библиотеке я не стал, по той простой причине что в Rust для сети используется не одно API, std там строго синхронное, а в реальных задачах лучше иметь возможность применять по желанию и потребности асинхронные библиотеки. Библиотеку разумеется назвал zettabgp, а приложение bgpexplorer.

Принцип работы прост. Bgpexplorer может как выступать в роли bgp-спикера, то есть роутер (лучше всего route reflector) устанавливает с сервером bgp-соседство, и отдает в сторону сервера всю маршрутную информацию. Приложение накапливает в своей RIB (Routing Information Database) как актуальную маршрутную информацию, так и историческую. Для просмотра и поисковых запросов доступен веб-интерфейс. Сейчас все хранится в оперативной памяти и ее нужно достаточно много - в зависимости разумеется от того, какого объема таблицу маршрутизации нужно отслеживать.


Если интересно попробовать - то это просто. Нужна сеть, которую нужно мониторить и комп (сервер) с достаточно большим объемом ОЗУ чтобы маршрутная информация туда поместилась.

На сервере нужно взять исходники с гитхаба, предполагается что уже есть git и rust.

$ git clone https://github.com/wladwm/bgpexplorer...$ cd bgpexplorer$ cargo build...

Приложение собрано. Теперь на роутере настроим соседство с сервером.

Если это Cisco, то:

! Номер автономки тут 65535 разумеется для примера, как и адресаrouter bgp 65535 ! указываем адрес сервера с той же автономкой, чтобы сессия была IBGP neighbor 10.1.1.1 remote-as 65535 ! указываем с какого адреса соединяться neighbor 10.1.1.1 update-source Loopback0 ! будем ждать попыток соединения с сервера neighbor 10.1.1.1 transport connection-mode passive address-family ipv4 ! для паблик инета активируем  neighbor 10.1.1.1 activate ! отправляем на сервер вообще все что есть  neighbor 10.1.1.1 route-reflector-client ! Активируем если нужно ipv4 labeled-unicast  neighbor 10.1.1.1 send-label address-family vpnv4 ! включаем VPNv4  neighbor 10.1.1.1 activate  neighbor 10.1.1.1 send-community extended

Возвращаемся на сервер и подготовим конфигурационный файл для приложения

$ cat > bgpexplorer.ini <<EOF[main]httplisten=0.0.0.0:8080httproot=contribsession=s0whoisjsonconfig=whois.json[s0]mode=bmpactivebgppeer=10.0.0.1peeras=65535EOF

В секции main указываем:

  • httplisten на каком адресе и порту будет работать протокол http

  • httproot где лежит корень файлового сервиса. Там лежит index.html и все такое прочее.

  • Whoisjsonconfig указывает на файл конфигурации сервиса whois

  • Session это имя секции, описывающей режим работы bgp, в данном примере s0

В секции сессии (s0 в данном примере) указано:

  • bgppeer адрес роутера BGP для активного режима

  • Peeras номер автономной системы

  • protolisten адрес:порт, где ожидать входящего соединения по протоколу BGP или BMP

  • Mode варианты работы протокола

В mode можно указать:

  • bgppassive ждать входящего подключения от роутера

  • bgpactive инициировать подключение к роутеру

  • bmpactive инициировать подключение к роутеру по протоколу BMP

  • bmppassive ждать входящего подключения от роутера по протоколу BMP

После написания ini-файла можно запустить bgpexplorer, например, командой

cargo run

После чего можно открыть браузер и направить его на адрес сервера с указанием порта.

На самом верху будет выбор RIB для просмотра - IPv4, IPv6, VPN разные всякие и т.п.

Далее строка для фильтра, а уже после нее - пейджинг и собственно маршрутная информация.

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

В фильтре можно задавать кроме собственно подсетей фильтрацию по community, aspath, nexthop, route-target, route-distinguisher.

При наведении курсора на ASn, адреса роутеров будет выполняться запрос к whois или DNS, и полученная информация будет отображаться в попапе. Иногда это долго, но бывает полезно.


Буду рад, если этот инструмент пригодится еще кому-нибудь. Найденные проблемы, пожелания, идеи, конструктивная критика приветствуется.

Подробнее..

Что почитать об инфраструктуре интернет-провайдеров, протоколах и разработке систем связи

19.06.2021 22:22:36 | Автор: admin

Продолжаем делиться материалами [раз, два] о работе операторов связи, их инструментарии и вопросах, с которыми они периодически сталкиваются. В этой подборке посты о причинах дефицита сетевого оборудования и HDD, альтернативах VPN/IPoE-сервера ACCEL-PPP и прокладке новых широкополосных линий связи в развитых странах.

Unsplash / Lars KienleUnsplash / Lars Kienle

Мировые практики и регулирование

ЖКХ и телеком зачем и почему им работать вместе. Разбираемся, насколько эффективен вид сотрудничества, когда застройщик и телеком-оператор внедряют в новостройке элементы умного дома. Обсуждаем опыт зарубежных стран Тайвани, Испании, Великобритании и объясняем, можно ли эффективно адаптировать его для российских реалий.

Как идет строительство новых широкополосных линий связи в развитых странах. Пост из нашего хабраблога об инициативах регуляторов в Великобритании, Германии и Швеции. Первые тянут оптоволокно в каждый дом, вторые закрепляют право на быстрый доступ в сеть, а третьи планируют обеспечить граждан гигабитным интернетом уже к 2025 году. Еще мы подготовили отдельный материал о том, как обстоят дела с broadband-подключениями в США там хотят пересмотреть сложную систему тарификации услуг интернет-связи.

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

Что мешает работе провайдеров

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

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

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

Сети и протоколы

На что пересесть после ACCEL-PPP. Это открытый VPN/IPoE-сервер для Linux. Он позволяет настроить доступ абонентов к интернету и отлично подходит для небольших провайдеров. Но с ростом клиентской базы его возможностей начинает не хватать. Приводим плюсы и минусы ряда альтернативных решений, которые можно найти на рынке.

CG-NAT зачем нужен и как начать пользоваться. Статья, где мы разбираем несколько решений для работы с CG-NAT, в том числе A10 Networks Thunder, F5 BIG-IP и Cisco ASR 9000. Также приводим небольшую инструкцию, как самостоятельно настроить NAT и управлять им.

Unsplash / Nathan DumlaoUnsplash / Nathan Dumlao

Почему шифрование DNS не всегда эффективно обсуждаем экспертные мнения. Обзорный материал о том, почему DoH и DoT не оказывают положительного влияния на защищенность подключений и даже могут вредить ей. В этом хабрапосте мы обсуждаем уязвимые места протоколов Server Name Indication (SNI) и ответы Online Certificate Status Protocol (OCSP) а также новые кибератаки, использующие DNS-over-HTTPS.

Как масштабировать BRAS ключевые требования. Рассказываем, как расширить возможности сетевой инфраструктуры в частности, говорим о вертикальном и горизонтальном масштабировании для схем L3 и L2 BRAS. В первом случае система взаимодействует с абонентами через промежуточные маршрутизаторы, а во втором напрямую. Кейсы разбираем с примерами на базе серверов Intel и AMD и схемами подключения.


Дополнительное чтение у нас в блоге и на Хабре:


Подробнее..

Перевод Сеть в bitly Linux tc для минимизации издержек и забавы ради

02.06.2021 20:09:34 | Автор: admin

Представьте, что вы, например, bitly то есть очень большой сервис сокращения ссылок. И вот, вы хотите скопировать свои 150 ТБ сжатых данных с одного физического кластера на другой, новый. Чтобы сделать это, вы запускаете distcp из набора инструментов hadoop и рады тому, насколько быстро он работает. Но, несколько позже, вы уже совсем не радуетесь жалобам обычных пользователей веб-сайта и API-клиентов случаются ошибки, задерживаются ответы, а данные их дата-центра только запутывают. К старту курса о DevOps мы перевели материал о том, что делать, если вы, как и bitly, оказались в подобной ситуации.


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

Важной частью инфраструктуры bitly и основным инструментом команды Data Science и рабочей группы обслуживания операций и инфраструктуры (Ops/Infra) в течение довольно долгого времени был физический кластер hadoop набор утилит, библиотек и фреймворк для разработки и выполнения распределённых программ, работающих на кластерах из сотен и тысяч узлов. Мы уже давно вынашивали идею подключения нового кластера, копирования и объединения данных старого кластера с данными нового.

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

  • bitly работает с огромными объёмами данных: на момент миграции кластер hadoop занимал более 150 ТБ дискового пространства сжатых потоковых данных, то есть данных, полученных в результате работы наших различных приложений. Объёмы таких данных продолжали увеличиваться в результате дополнительной обработки другими приложениями;

  • физически инфраструктура bitly располагается в центре обработки данных нашего партнёра. Она состоит из трёх физических видов шасси (приложения, хранилище и база данных), расположенных в ряд в смежных стойках. На момент написания этой статьи каждое шасси имело три физических гигабитных Ethernet-канала (каждый логически изолирован посредством организации сети VLAN) прямой канал, обратный канал и схему удалённого управления (для внеполосного управления серверными шасси). Каждое соединение после прохождения через ряд патч-панелей и коммутаторов подключается к нашим главным коммутаторам через стеклянное оптоволокно 10 Gb по звездообразной схеме сети;

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

Вернёмся к нашей истории.

Для быстрого копирования данных с одного кластера на другой мы воспользовались инструментом distcp, поставляемом в комплекте с кластером hadoop. Говоря просто, инструмент distcp выдаёт задание программному фреймворку mapreduce (используемому для параллельных вычислений над очень большими наборами данных в компьютерных кластерах) на перемещение данных из одного кластера hdfs в другой при копировании узлов в режиме "многие ко многим". Инструмент distcp сработал быстро, и это нас порадовало.

Но тут сломался сервис bitly, и это не привело в восторг команду Ops/Infra.

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

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

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

В новом кластере было больше узлов, значит, по идее, hadoop должен был работать быстрее.

Мы, кажется, осчастливили команду Data Science.

Но, к сожалению, поскольку кластер hadoop стал крупнее и быстрее, во время работы mapreduce на большее количество узлов стало передаваться большее количество данных, и это привело к непредвиденному эффекту:

Сервис bitly опять сломался, на этот раз очень серьёзно. Команда Ops/Infra была от этого не в восторге.

Первым импульсивным действием было вообще отрубить hadoop.

Но такое решение очень не понравилось команде Data Science.

Отключение кластера hadoop самое плохое из возможных решений (по последствиям может сравниться разве что с поломкой bitly), поэтому мы вернули кластер в состояние 1995 года, заставив все сетевые карты перейти на 100 Мбит/с (с 1 Гбит/с) с помощью команды ethtool -s eth1 speed 100 duplex full autoneg on. Теперь можно было спокойно подключить hadoop, но какой же медленной стала его работа!

Команда Data Science по-прежнему не выказывала признаков восторга.

И действительно, работа кластера была настолько "тормозной", что при вводе данных, выполнении запланированных заданий ETL (извлечения, преобразования и загрузки) и выдаче отчётов стали часто возникать сбои, постоянно срабатывали аварийные сигналы, будившие среди ночи членов команды Ops/Infra.

Надо ли говорить, как это не нравилось команде Ops/Infra!

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

Сделаем ещё одно небольшое отступление:

Что нам было доступно в bitly?

  • roles.json : список серверов (app01, app02, userdb01, hadoop01 и т. д.), ролей (userdb, app, web, monitoring, hadoop_node и т.д.), а также сведения об отображении серверов на роли (app01,02 -> app, hadoop01,02 -> hadoop_node и т. д.);

  • $datacenter/jsons/* : каталог, содержащий json-файл для каждого логического сервера с атрибутами, описывающими сервер, IP-адресами, именами, информацией конфигурирования и, что наиболее важно в нашей истории, расположением стоек.;

  • Linux : Linux.

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

Но команда Ops/Infra не проявляла признаков радости.

Её не устраивал синтаксис системы контроля сетевого трафика (Traffic Control, tc) в Linux, не говоря уже о совершенно неудобочитаемой документации. После напряжённого периода работы (с многочисленными проклятиями и разбиванием о стену клавиатур) мы смогли, наконец, создать не вызывающие отторжения работающие сценарии в tc. Были открыты ветви, написаны скрипты, выполнены развёртывания, проведены эталонные тестирования, и в результате было создано несколько тестовых узлов с таким кодом:

$ tc class show dev eth1class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b    cburst 1561bclass htb 1:10 root prio 0 rate 819200Kbit ceil 819200Kbit burst 1433b     cburst 1433bclass htb 1:20 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b     cburst 1561b$ tc filter show dev eth1filter parent 1: protocol ip pref 49128 u32 filter parent 1: protocol ip pref 49128 u32 fh 818: ht divisor 1 filter parent 1: protocol ip pref 49128 u32 fh 818::800 order 2048 key     ht 818 bkt 0 flowid 1:20     match 7f000001/ffffffff at 16filter parent 1: protocol ip pref 49129 u32 filter parent 1: protocol ip pref 49129 u32 fh 817: ht divisor 1 filter parent 1: protocol ip pref 49129 u32 fh 817::800 order 2048 key     ht 817 bkt 0 flowid 1:10     match 7f000002/ffffffff at 16filter parent 1: protocol ip pref 49130 u32 filter parent 1: protocol ip pref 49130 u32 fh 816: ht divisor 1 filter parent 1: protocol ip pref 49130 u32 fh 816::800 order 2048 key     ht 816 bkt 0 flowid 1:20     match 7f000003/ffffffff at 16<snipped>$ tc qdisc showqdisc mq 0: dev eth2 root qdisc mq 0: dev eth0 root qdisc htb 1: dev eth1 root refcnt 9 r2q 10 default 100     direct_packets_stat 24

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

class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b cburst 1561b

Каждый класс это потолок пропускной способности исходящего трафика, агрегированного по всем подписанным на этот класс фильтрам.

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

filter parent 1: protocol ip pref 49128 u32 filter parent 1: protocol ip pref 49128 u32 fh 818: ht divisor 1 filter parent 1: protocol ip pref 49128 u32 fh 818::800 order 2048 key     ht 818 bkt 0 flowid 1:20     match 7f000001/ffffffff at 16

можно интерпретировать как "subscribe hadoop14 to the class 1:20", где "7f000001" можно интерпретировать как IP для hadoop14, а "flowid 1:20" класс для подписки. Затем запускаем команду qdisc, формирующую более или менее активную очередь для устройства eth1. Данная очередь по умолчанию помещает любой хост, не определённый в фильтре класса, в класс 1:100:

qdisc htb 1: dev eth1 root refcnt 9 r2q 10 default 100 direct_packets_stat 24

В такой конфигурации любой хост (hadoop или другой), находящийся в одной стойке с конфигурируемым хостом, получает фильтр, назначенный классу "1:10", разрешающий скорость передачи до ~800 Мбит/с для класса в целом. Аналогичным образом для предопределённого списка ролей, считающихся "ролями приоритетных узлов", создаётся фильтр по тому же правилу "1:100". Такие узлы выполняют довольно важные задачи, например запускают сервисы hadoop namenode или jobtracker, а также наши узлы мониторинга. Любой другой хост hadoop, не находящийся в той же стойке, подключается к классу "1:20", ограниченному более консервативным классом ~200 Мбит/с.

Как было сказано выше, любой хост, не определённый в фильтре, попадает в класс по умолчанию для eth1 qdisc, то есть в класс "1:100". Как это выглядит на практике? Вот хост, подпадающий под действие правила "1:100":

[root@hadoop27 ~]# iperf -t 30 -c NONHADOOPHOST------------------------------------------------------------Client connecting to NONHADOOPHOST, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 35897 connected with NONHADOOPHOST port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.1 sec   735 MBytes   205 Mbits/sec

Теперь при подключении к другому хосту, расположенному в той же стойке или подпадающему под правило "1:10":

[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER------------------------------------------------------------Client connecting to CABINETPEER, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 39016 connected with CABINETPEER port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  2.86 GBytes   820 Mbits/sec

Что произойдёт при подключении к двум серверам, подпадающим под правило "1:10"?

[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER1------------------------------------------------------------Client connecting to CABINETPEER1, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 39648 connected with CABINETPEER1 port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  1.47 GBytes   421 Mbits/sec[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER2------------------------------------------------------------Client connecting to 10.241.28.160, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 38218 connected with CABINETPEER2 port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  1.43 GBytes   408 Mbits/sec

Трафик уменьшится вдвое? Похоже на правду. Даже лучше стало относительно проще отслеживать тренды данных, анализируя статистические данные, выводимые на наши сервисы трендов:

$ /sbin/tc -s class show dev eth1 classid 1:100class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit     burst 1561b cburst 1561b Sent 5876292240 bytes 41184081 pkt (dropped 0, overlimits 0 requeues 0) rate 3456bit 2pps backlog 0b 0p requeues 0 lended: 40130273 borrowed: 0 giants: 0tokens: 906 ctokens: 906

После тестирования мы проверили хосты hadoop, подняв их скорости до первоначальных 1Gb после применения ролей traffic control. После всех описанных действий кластер hadoop вновь обрёл достаточно высокую производительность.

Мы осчастливили команду Data Science.

Команда Ops/Infra смогла приступить к устранению неполадок и поиску решений, при этом спокойно спать по ночам, зная, что сервис bitly будет вести себя нормально.

Мы осчастливили и команду Ops/Infra.

Выводы:

  • Попав в трудное положение, помните: ваш набор инструментов для управления средой так же важен, как и сама среда. Поскольку у нас уже имелся набор инструментов для комплексного контроля среды, мы сумели выбраться из ямы почти так же быстро, как попали в неё.

  • Не загоняйте себя в трудные ситуации: изучите все нюансы среды, в которой будете работать. В данном случае нам следовало лучше понять и оценить масштабы миграции hadoop и её возможные последствия.

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

  • Linux: Linux

И последнее

Эта история хорошая иллюстрация "закона Мерфи для девопсов":

Закон Мёрфи для девопсов: "Если что-то может пойти не так, значит, что-то уже идёт не так, просто Nagios ещё не предупредил".

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Intel 5G Solution 5000 5G M.2 модем для ноутбуков

31.05.2021 14:10:41 | Автор: admin


На проходящей в эти дни выставке Computex 2021 компания Intel представила 5G Solution 5000 первый в ее истории 5G модем в форм-факторе М.2. Новый продукт стал результатом сотрудничества трех компаний: Intel разработчика ПО для хост-системы, MediaTek, ответственной за модем и Fibocom, соединившей все компоненты в готовое устройство FM350-GL.

Напомним, что в 2017-18 годах Intel активно развивала мобильное направление и выпустила несколько моделей 5G контроллеров, таких как XMM 8060 (первый модем компании) и XMM 8160, однако далее она отказалась от роли самостоятельного игрока на этом рынке, продав в июле 2019 уже имеющиеся наработки компании Apple. Ставка была сделана на стратегическое сотрудничество с третьими компаниями, и уже в конце 2019 был оформлен альянс с одним из крупнейших мировых чипмейкеров тайваньской компанией MediaTek.

Модем представляет собой PCIe устройство в форм-факторе М.2. Обращает на себя внимание нестандартный для М.2 размер карточки 30x52 мм, что потребует специального дизайна отсека. Intel 5G Solution 5000 планируется устанавливать в ноутбуки на базе процессоров Intel Tiger Lake и Alder Lake, основные его характеристики приведены в таблице.
Стандарты связи 5G NR/ 4G LTE/ 3G WCDMA
Форм-фактор M2, 30x52 односторонний
Диапазон частот Sub 6GHz
Скорость (DL/UL) 4.7 Гбит/c / 1.25 Гбит/c в режиме 5G
SIM Встроенная eSIM
Поддержка ОС Windows, Chrome, Linux
Подробнее..

Wi-Fi высокой плотности не существует

02.06.2021 14:09:29 | Автор: admin

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

Я люблю элементарные вопросы, потому что они (прямо как элементарные частицы) на пути в собственные глубины приводят к бесконечности. Когда мы встречаем фразу Wi-Fi высокой плотности, то так и хочется задать дополнительный вопрос про какую плотность идёт речь? Плотность чего высока? Ответ, как всегда, не так однозначен, как может показаться.

Вот, например, несколько определений, которые я сравнительно легко нагуглил.

Под сетями Wi-Fi высокой плотности (далее СВП) понимается беспроводная среда с высокой концентрацией пользователей, где пользователи подключены к беспроводной сети и интенсивно работают с сетевыми сервисами (источник)

В предыдущей статье мы вывели одно из главных правил Wi-Fi: Пока говорит один остальные слушают. Возникает логичный вопрос раз в каждый момент времени передаёт только одно устройство, есть ли принципиальная разница между, грубо говоря, ста клиентами по 1 Мбит/с или одним клиентом по 100 Мбит/с, если все данные всё равно будут переданы по очереди? О какой плотности идёт речь о плотности передачи данных в эфире?

Следующее определение:

Когда на одно клиентское устройство приходится менее 1 кв.м площади, можно считать, что на Вашем объекте высокая плотность подключений к Wi-Fi (источник)

Как между собой связано расстояние между клиентами и особенности проектирования сети Wi-Fi? Опять же: буду ли я проектировать сеть иначе, если между клиентами будет в 10 раз больше расстояния, но передавать они будут в 100 раз больше данных?

Ещё одно определение:

High-density Wi-Fi is a design strategy for large deployments to provide pervasive connectivity to clients when a high number of clients are expected to connect to Access Points within a small space. A location can be classified as high density if more than 30 clients are connecting to an AP

Или по-русски:

Wi-Fi высокой плотности это стратегия планирования сети для крупных внедрений для предоставления всеобъемлющего сервиса для клиентских устройств, когда большое количество клиентов должны будут подключаться к точке доступа в малом пространстве. Сеть может быть определена как высокоплотная, если к ТД подключено больше 30 клиентов

(источник)

А если 31? Если площадь большая, но клиенты сосредоточены вокруг точек очень плотно это всё ещё высокоплотный Wi-Fi или уже нет?

Да полным-полно всяких формулировок. В 2017 году на конференции БЕСЕДА-2017 Виктор Платов из Cisco определил Wi-Fi высокой плотности как любой, когда в каждой точке покрытия сети видно три или больше точки доступа (это очень хорошее определение, мне оно понравилось своей ёмкостью и красотой). Самое смешное что все они верны. И самое смешное что всё, что приводит к попыткам такого определения, относится к каждой сети Wi-Fi.

Упростим нашу ситуацию по максимуму: в мире осталась одна точка доступа и одно клиентское устройство. Призовём цветные столбики и внимательно посмотрим, как, например, пользовательские данные с точки попадут на клиента.

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

На картинке зелёным показаны симпатичные и, безусловно, очень важные 300 байт пользовательских данных (включая заголовок IP), которые пролетели через сеть Wi-Fi, работающую на максимуме возможностей стандарта 802.11n в канале шириной 20 МГц. Если бы пользователь открыл свойства своего подключения к беспроводной сети, то он бы увидел скромное число 72,2 Мбит/с. Весь процесс этого перелёта занял (в нашем эталонном примере) 407 мкс, из которых чуть больше четверти времени (а именно 115 мкс) в эфире была абсолютная тишина (по мнению устройств Wi-Fi). Если бы её не было, то вся игра началась бы с самого начала, и стало бы ещё хуже.

Возведём ситуацию в абсолют. Представим, что эта картинка повторяется, что называется, спина к спине: ни единой микросекунды не расходуется впустую всегда данные летят, таймеры считаются, никаких тебе переповторов и помех, всё чётко и прекрасно. Нетрудно сделать следующий вывод: больше четверти всего времени в эфире была тишина! Значит, какая бы то ни было мощность на приёмниках, слушавших всё происходящее, была всего лишь в 72% всего времени. А знаете, что самое смешное? Лучше особо и не будет.

Этот процент от времени (какую часть всего времени среда занята передачей хоть какой-то информации) называется утилизацией канала и, собственно, он и показывает потолок всей пропускной способности каждой точки доступа, каждого канала и сети в целом. На этой картинке много переменных: частичка под названием CW меняется в огромных пределах; в зелёную часть можно впихнуть больше данных за то же самое время; синенькая часть в Wi-Fi 6 стала чуть подлинее но в целом потолок определён достаточно явно: если мы хотим, чтобы Wi-Fi работал, 25% времени мы будем слушать тишину.

Неэффективно? Возможно. Зато ультранадёжно!

Утилизация это следующий после сырых мегабит и больших децибеллов параметр, по которому постепенно погружающийся в пучину Wi-Fi инженер начинает использовать в качестве мерила нормальности работы беспроводной сети. После того, как он научился не проверять работоспособность Wi-Fi с помощью Speedtest и понял, что мощный сигнал и пробитые стены не гарантируют хорошей пропускной способности, он поднимается на канальный уровень 802.11 и обнаруживает, что те самые 72,2 Мбит/с, которые рисуются системой в свойствах устройства, недостижимы в принципе протокол устроен так, что скорость передачи данных никогда не превысит 75% от канальной скорости.

Именно утилизация показывает, насколько занят тот или иной канал (считай, точка доступа) и сколько возможностей для передачи может появиться для нового клиента в этой сети. По большому счёту, других параметров для этого и нет. Децибеллы причина утилизации (высокой или низкой как спланируете сеть), мегабиты в спидтесте следствие использования свободной утилизации (а много её свободно или мало опять же, как спланируете сеть). Хорошо спланированная (с помощью высоких децибеллов) сеть при высокой утилизации выдаёт высокие значения Мбит/с. Всё просто!

Что же значат определения Wi-Fi высокой плотности в переводе на простой инженерный? Высокая концентрация пользователей, где пользователи подключены к беспроводной сети и интенсивно работают с сетевыми сервисами это всего лишь высокая утилизация каналов, на которых работает наша сеть. Высокая плотность подключений к Wi-Fi и Большое количество клиентов должны будут подключаться к точке доступа в малом пространстве означает, что на доступное эфирное время точки доступа будет претендовать много клиентских устройств. Утилизация везде и всюду. Но ведь она и в обычной сети, самой что ни на есть домашней, внезапно может уйти в потолок!

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

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

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

<h2>Лозунг первый: Передаём быстрее!</h2>

Ускоряем зелёную часть так, как только можем.

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

  • Никакого Rate limiting в воздухе, потому что он растянет зелёную часть (клиент может передать свои 300 байт на скорости 72,2 Мбит/с, но сеть ему говорит Ну уж нет, не больше шести!. В сколько раз дольше он будет занимать эфир?). Шейпите где-нибудь дальше!

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

  • Выберите точки, которые могут передавать данные на скорости самых быстрых клиентов (если бюджет вам этого не запретит). MIMO 3x3:3 хватит для почти любого клиента Wi-Fi, кроме одной PCI-E карты ASUS, которая 4x4:4, про которую все говорят и никто ни разу в руках не держал;

  • Уменьшите количество неудачных передач (retry rate тут мы начинаем погружаться в дебри траблшутинга Wi-Fi, я постараюсь держаться поближе к поверхности) к примеру, уберите точки подальше от металла и прочих подстилающих поверхностей.

Всё? Не только ведь мы можем ускорить и оранжевую часть! Смотрите: по умолчанию в 5 ГГц это 6 Мбит/с (в 2,4 всего 1 Мбит/с, ха-ха-ха!). Если я хорошо спланирую свою сеть и тщательно всё настрою, то смогу разогнать оранжевую часть (это называется Tx management rate) до 24 Мбит/с и при прочих равных сэкономлю на передаче всё того же фрейма в 300 полезных байт целых 76 мкс! Да это 20% доступного времени (и пропускной способности) просто на халяву!

Конечно, эти самые 24 Мбит/с наложат определённые требования на качество сигнала клиентов, подключенных к ТД. Но без хорошей физики в любом случае не будет хорошей логики (и тем более передачи данных)!

На этом с ускорением передачи покончено, по большому счёту. Но у нас в запасе есть

<h2>Лозунг второй: Передаём меньше!</h2>

  • Всё, что можно не передавать в эфир в топку. Меньше сетей (SSID), созданных на сети (собственно, железо): каждый SSID это десять фреймов Beacon в секунду! Хорошо, если они быстро пролетят через сеть а если они передаются на 1 Мбит/с? Да вы бы ещё мегабит десять данных выжали бы с точки за это время!

  • Если можем просто подключить клиента к сети подключаем, а не тратим время на то, что клиент будет тыкаться в сеть с паролем, неправильно его вводя (привет, гостевые открытые сети!). Домой это, конечно, особо не применимо вспомните про этот пункт, когда займётесь офисной сетью;

  • Если можем не отвечать на тупые вопросы проходящих мимо клиентов о возможностях нашей сети (broadcast Probe Request) не отвечаем;

  • Если начали отвечать не ждём, пока клиент соизволит ответить (он мог сто раз уйти на другой канал, зачем его ждать?);

И так далее, и тому подобное. Для уровней выше тоже верно: не мониторим абонентов бесконечными пингами всех выданных адресов на DHCP-сервере (встречались и такие случаи), режем лишний broadcast Короче, если можем что-то не передать в эфир не передаём!

Ну, и как основное и главное правило

<h2>Лозунг третий: Планируем сеть!</h2>

Каждый канал это доступные 70% времени передачи. Занимаете четыре канала, объединяя их в один на 80 МГц это становится теми же самыми 70% доступного времени, хотя вы могли бы выжать вчетверо больше!

Добавим цветных столбиков?

Сверху наша затюненная сеть на 802.11n в 20 МГц, быстро разбирающаяся с пользовательскими данными по 300 байт в пакете. Снизу сеть на 802.11ac в 80 МГц, с которой больше никаких действий не сделано. В итоге получается, что старый стандарт быстрее передаёт пользовательские данные и к тому же в том же куске эфира их можно уместить четыре одновременно! Жаль, конечно, что это не даст выгоды, например, одному жирному клиенту, который хочет штурмовать выданные провайдером 300-500 Мбит/с через приснопамятный Speedtest что ж, возможно, стоит дать ему широкий канал в 80 МГц, но пожалуйста, не забывайте про то, что клиент будет слышать передачу в таком широченном канале в ДВЕНАДЦАТЬ раз хуже, чем в узком двадцатимегагерцовом!

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

Ну, и последнее определение Wi-Fi высокой плотности, которое хотелось бы обсудить это высокая плотность установки точек доступа. Спустя несколько лет мы все обнаружили, что в наших квартирах зачастую виден десяток разных сетей от всех соседей. Даже в густых лесах уже попадаются микротики с шириной канала 40 МГц в 2,4 ГГц:

А в обычной квартире всё чаще всего существенно хуже:

И лучше, пожалуй, уже не будет. Как минимум, до 6E но это уже, как говорит Каневский, совсем другая история. А пока ваш домашний вайфай имеет такую же плотность, как и офисный, просто пока об этом не знает. Знать нужно вам самим и лучше заранее!

Подробнее..

Рыцарь в доспехах, а BPDU слова его любви

04.06.2021 10:04:57 | Автор: admin

Тоннель EOIP (обычно применяемый одним известным брендом) не пропускает BDPU по умолчанию. А это значит, что если протащить VLAN через EOIP, закольцуя его в целях резервирования, то не стоит надеяться, что STP его отработает. Случится петля. Коммуникации в этом VLAN не произойдет - каждый из коммутаторов возомнит себя королем и voil - ваша сеть стоит на коленях! Если вы знаете как настроить EOIP на пропуск BPDU, то, пожалуйста, напишите об этом в комментарии! Эта информация будет полезна.

Топология Spanning Tree возникает благодаря BPDU (Bridge Protocol Data Unit). Это то, что делает возможным свободную от петель коммуникацию на сети с избыточными линками. И наверное, первое, что нужно сделать перед созданием избыточного линка, будь он логическим или физическим, - это проверить есть ли обмен BPDU между коммутаторами.

Можно подумать о BPDU как о языке любви, возникающий между железками и на основе которого расцветает и распускается дерево Spanning Tree. Они как слова, которыми влюбленные обмениваются друг с другом. И любовь их питается этими словами. А если нет слов, то нет и любви.

Каждое это слово любви содержит информацию об отправителе. Этой информацией они делятся - так они узнают друг о друге и решают, кто будет главным в семье: кто альфа, а кто омега. И главное, на что коммутаторы смотрят - это идентификатор Bridge ID (Bridge Identifier). Каждый из коммутаторов, который имеет включенный Spanning Tree Protocol, несет этот идентификатор. И есть три элемента, которые являются частью этого идентификатора и делают его уникальным для каждого коммутатора. Первый из них - это приоритет (Priority). Его значение по умолчанию равно 32768. (Сколько бит будет задействовано, чтобы получить такое значение?). А если так, то все коммутаторы, настроенные по умолчанию, будут иметь равные шансы стать альфой в семье, так? Нет! Тут вступает в роль второй элемент. Это номер VLANa. Коммутатор приплюсует номер VLANa к приоритету. Например, если номер VLANa - 7, то Bridge ID будет равен 32768 + 7 = 32775. Но и это не сделает коммутатор королем, даже если оба коммутатора имеют VLAN 7. Поэтому знакомьтесь с третьми элементом - MAC address, совершенно уникальным идентификатором.

Однако тут стоит оговориться. Второй элемент не найти на коммутаторах Huawei по умолчанию он часть проприетарного протокола PVST другого известного вендора. Значение номера VLANa не играет никакой роли в STP на Huawei сети второго уровня, пока мы не скажем ему делать это. IOSv устанавливает rapid-pvst протоколом по умолчанию. Huawei mstp. В этом разница. И это может пролить немного света почему вендоры не рекомендуют совмещать свои продукты с продуктами других компаний, если даже, казалось бы, они выполняют одну задачу и работают с одной и той же логикой.

Как же сделать балансировку между разными VLANs? Как же назначить королем один коммутатор для одного VLAN, а для другого VLAN сделать королем другой коммутатор? Балансировка нагрузки возможна: Huawei сделал для этого собственный протокол - VBST (VLAN BASES SPANNING TREE). Он позволяет, используя приоритеты VLANs, манипулировать деревом для каждого VLAN.

Команда display stp к вашим услугам, чтобы посмотреть Bridge ID :

CIST - это аббревиатура (Common and Internal Spanning Tree). Как уже было сказано, Huawei сделал MSTP режимом по умолчанию, поэтому мы видим здесь терминологию "регионов". В данном случае CIST Root/ERPC показывает локальный Bridge ID коммутатора LSW4. Причем Bridge ID это не только значение приоритета, это вся строчка с приоритетом и мак-адресом.

При этом все меняется, если применить пару команд: включить vbst, активировать его на конкретном VLAN, например, на VLAN 7.

[LSW4]stp mode vbst

[LSW4]stp vlan 7 enable

Говоря теперь о втором элементе, то, во-первых, он назван Root ID, что является локальным значение дерева VLAN 7 на этом коммутаторе, и во-вторых, он калькулируется как сумма дефолтного значения и номера VLAN: 32768 + 7.

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

Подробнее..

Перевод Эксклюзив США по словам чиновника, взломы с помощью программ-вымогателей надо приравнять к терроризму

04.06.2021 16:20:58 | Автор: admin
image

Вашингтон (Рейтер) Министерство юстиции США считает расследования атак с использованием программ-вымогателей таким же важным, как и терроризм. После взлома Colonial Pipeline и увеличения ущерба, нанесенного киберпреступниками, сообщил Reuters высокопоставленный чиновник ведомства.

Внутреннее руководство, направленное в четверг в офисы прокуратуры США по всей стране, гласит, что информация о расследованиях программ-вымогателей на местах должна централизованно координироваться с недавно созданной целевой группой в Вашингтоне.

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

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

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

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

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

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

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

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

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

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

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

Хакеры создают, покупают и сдают в аренду бот-сети для совершения киберпреступлений, начиная от рекламного мошенничества и заканчивая крупными кибератаками.

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

Марк Калифано, бывший прокурор США и эксперт по киберпреступности, сказал, что усиление отчетности может позволить Министерству юстиции более эффективно использовать ресурсы и выявлять распространенные эксплойты, используемые киберпреступниками.
Подробнее..

Перевод Azure Active Directory Gateway теперь на .NET Core 3.1

08.06.2021 18:13:14 | Автор: admin

*Gateway шлюз

Azure Active Directory Gateway это обратный прокси-сервер, который работает с сотнями служб, входящих в Azure Active Directory (Azure AD). Если вы пользовались такими службами, как office.com, outlook.com, azure.com или xbox.live.com, то вы использовали шлюз Azure AD. Шлюз присутствует в более чем 53 центрах обработки данных Azure по всему миру и обслуживает ~115 миллиардов запросов ежедневно. До недавнего времени шлюз Azure AD работал на платформе .NET Framework 4.6.2. С сентября 2020 года он работает на .NET Core 3.1.

Мотивация для перехода на .NET Core

Масштаб результатов шлюза приводит к значительному потреблению вычислительных ресурсов, что, в свою очередь, стоит денег. Поиск путей снижения стоимости работы сервиса был ключевой целью для команды, стоящей за ней. Шумиха вокруг производительности .NET Core привлекла наше внимание, тем более что TechEmpower назвал ASP.NET Core одним из самых быстрых веб-фреймворков на планете. Мы провели собственные тесты прототипов шлюза на .NET Core, и результаты позволили нам принять очень простое решение: мы должны перенести наш сервис на .NET Core.

Обеспечивает ли .NET Core реальную экономию средств?

Безусловно, обеспечивает. Благодаря шлюзу Azure AD мы смогли сократить затраты на CPU (ЦП) на 50%.

Раньше шлюз работал на IIS с .NET Framework 4.6.2. Сегодня он работает на IIS с .NET Core 3.1. На изображении ниже показано, что использование ЦП сократилось вдвое на .NET Core 3.1 по сравнению с .NET Framework 4.6.2 (фактически удвоив пропускную способность).

В результате увеличения пропускной способности мы смогли уменьшить размер нашего сервера с ~40 тыс. до ~20 тыс. ядер (сокращение на 50%).

Как произошел переход к .NET Core?

Он происходил в 3 этапа.

Этап 1: Выбор пограничного сервера

Когда мы начали работу по переходу, первый вопрос, который мы должны были задать себе, был: какой из трех серверов в .NET Core мы выберем?

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

Kestrel:

Когда мы инициировали наш переход (ноябрь 2019 года), Kestrel не поддерживал ни согласование клиентских сертификатов, ни их аннулирование для каждого имени хоста. В .NET 5.0 поддержка этих функций была добавлена.

Как и в .NET 5.0, Kestrel (благодаря использованию SslStream) не поддерживает CTL-хранилища для каждого имени хоста. Поддержка ожидается в .NET 6.0.

HTTP.sys:

Сервер HTTP.sys столкнулся с несоответствием между конфигурацией TLS на Http.Sys и имплементацией .NET: Даже если привязка настроена так, чтобы не согласовывать клиентские сертификаты, обращение к свойству Client certificate в .NET Core вызывает нежелательное повторное согласование TLS.

Например, выполнение простого null check в C# приводит к повторному согласованию TLS handshake (рукопожатия TLS):

if (HttpContext.Connection.ClientCertificate != null)

Это показано в https://github.com/dotnet/aspnetcore/issues/14806 в ASP.NET Core 3.1. В то время, когда мы делали переход в ноябре 2019 года, мы были на ASP.NET Core 2.2 и поэтому не выбрали этот сервер.

IIS:

IIS отвечал всем нашим требованиям к TLS, поэтому мы выбрали именно этот сервер.

Этап 2: Миграция приложения и зависимостей

Как и многие крупные службы и приложения, шлюз Azure AD имеет множество зависимостей. Некоторые из них были написаны специально для этой службы, а некоторые другими специалистами внутри и вне Microsoft. В некоторых случаях эти библиотеки уже были нацелены на .NET Standard 2.0. В других случаях мы обновили их для поддержки .NET Standard 2.0 или нашли альтернативные имплементации, например, удалили нашу устаревшую библиотеку Dependency Injection и вместо нее использовали встроенную в .NET Core поддержку для внедрения зависимостей. На этом этапе большую помощь оказал .NET Portability Analyzer.

Для самого приложения:

  • Шлюз Azure AD имел зависимость от IHttpModule и IHttpHandler из классического ASP.NET, которой нет в ASP.NET Core. Поэтому мы переработали приложение, используя конструкции промежуточного ПО в ASP.NET Core.

  • Одной из вещей, которая действительно помогла в процессе миграции, является Azure Profiler (служба, которая собирает трассировки производительности на виртуальных машинах Azure). Мы развертывали наши ночные сборки на тестовых площадках, использовали wrk2 в качестве агента нагрузки для тестирования сценариев под нагрузкой и собирали трассы Azure Profiler. Эти трассировки затем информировали нас о следующей настройке, необходимой для получения пиковой производительности нашего приложения.

Этап 3: Постепенное развертывание

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

  • Мы развернули наши первоначальные версии в тестовом, интеграционном и DogFood средах. Это привело к раннему обнаружению ошибок и помогло исправить их до того, как они попали в работу.

  • После завершения кода мы развернули сборку .NET Core на одной производственной системе в единице масштабирования. Единица масштабирования это пул виртуальных машин с балансировкой нагрузки.

  • В единице масштабирования ~100 машин, где на 99 машинах все еще работала наша существующая сборка .NET Framework и только на 1 машине была установлена новая сборка .NET Core.

  • Все ~100 машин в этом масштабном блоке получают точный тип и количество трафика. Затем мы сравнили коды состояния, количество ошибок, функциональные сценарии и производительность одной машины с остальными 99 машинами, чтобы обнаружить аномалии.

  • Мы хотели, чтобы эта единственная машина вела себя функционально так же, как и остальные 99 машин, но имела гораздо более высокую производительность/пропускную способность, что мы и наблюдали.

  • Мы также "перенаправили" трафик с действующих производственных устройств (работающих с .NET Framework build) на устройства с .NET Core, чтобы сравнить и сопоставить их, как указано выше.

  • Как только мы достигли функциональной эквивалентности, мы начали увеличивать количество единиц масштаба, работающих на .NET Core, и постепенно расширили их до целого центра данных.

  • После миграции всего центра обработки данных последним шагом было постепенное распространение по всему миру на все центры обработки данных Azure, где присутствует служба шлюза Azure AD. Миграция завершена!

Полученные знания

  • ASP.NET Core внимателен к RFC. Это очень хорошая особенность, так как она способствует распространению передовой практики. Однако классические ASP.NET и .NET Framework были более снисходительны, что вызывает некоторые проблемы с обратной совместимостью:

  • Веб-сервер по умолчанию разрешает только значения ASCII в заголовках HTTP. По нашей просьбе поддержка Latin1 была добавлена в IISHttpServer: https://github.com/dotnet/aspnetcore/pull/22798

  • HttpClient на .NET Core раньше поддерживал только значения ASCII в HTTP-заголовках.

  • Формы и cookies, не соответствующие RFC, приводят к исключениям при проверке. Поэтому мы создали "запасные" парсеры, используя классический исходный код ASP.NET, чтобы сохранить обратную совместимость для клиентов.

  • В методе FileBufferingReadStreams CopyToAsync() наблюдалось снижение производительности из-за нескольких 1-байтовых копий n-байтового потока. Эта проблема решена в .NET 5.0 путем выбора размера буфера по умолчанию в 4K: https://github.com/dotnet/aspnetcore/issues/24032.

  • Помните о классических причудах ASP.NET:

    • Автоматически тримятся (auto-trimmed) символы пробелов:

foo.com/oauth ?client=abc тримятся до foo.com/oauth?client=abc в классическом ASP.NET.

  • С течением времени клиенты/даунстрим сервисы стали зависеть от этих тримов, а ASP.NET Core не выполняет автоматическтий триминг.

Поэтому нам пришлось убрать пробельные символы (auto-trim), чтобы имитировать классическое поведение ASP.NET.

  • Заголовок Content-Type автоматически генерируется, если отсутствует тому:

Когда размер ответа больше нуля байт, но заголовок Content-Type отсутствует, классический ASP.NET генерирует стандартный заголовок Content-Type:text/html. ASP.NET Core не генерирует заголовок Content-Type по умолчанию принудительно, и клиенты, которые полагают, что заголовок Content-Type всегда появляется в ответе, начинают испытывать проблемы. Мы имитировали классическое поведение ASP.NET, добавив Content-Type по умолчанию, когда он отсутствует в нижестоящих службах.

Будущее

Переход на .NET Core привел к удвоению пропускной способности нашего сервиса, и это было отличное решение. Наше путешествие по .NET Core не закончится после перехода. В будущем мы рассматриваем следующие варианты:

  • Обновление до .NET 5.0 для повышения производительности.

  • Переход на Kestrel, чтобы мы могли перехватывать соединения на уровне TLS для повышения отказоустойчивости.

  • Использовать компоненты/лучшие практики YARP (https://microsoft.github.io/reverse-proxy/) в нашем собственном обратном прокси и также внести свой вклад.


Перевод материала подготовлен в рамках специализации "Network Engineer". Эта учебная программа подойдет тем, кто планирует снуля освоить профессию сетевого инженера и подготовиться к прохождению промышленной сертификации CCNA.

Подробнее..

Национальная система доменных имён первый взгляд

15.06.2021 10:13:02 | Автор: admin

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

Из уже упомянутой выше статьи по ссылкам можно найти оригинальное письмо РКН, из которого мы знаем что существуют:

  • 194.85.254.37 - корневой DNS сервер позволяющий, помимо прочего, выполнять запрос AXFR, то есть получать корневую зону "как есть", но для этого надо попасть в список доверенных серверов и такой возможности у меня нет

  • a.auth-nsdi.ru, b.auth-nsdi.ru - тоже корневые DNS, позволяющие не рекурсивно запрашивать записи из корневой зоны

  • a.res-nsdi.ru, b.res-nsdi.ru - рекурсивные резолверы, позволяющие запрашивать любую запись

Сразу обращу ваше внимание на то, что система находится в очень подвижном состоянии, как и положено любой системе на начальном этапе эксплуатации, да и вообще системе в Интернет. И дотошный читатель наверняка уже нашёл, что существуют, например, c.auth-nsdi.ru и d.auth-nsdi.ru, пока не отвечающие на запросы. Но это значит, что через пару месяцев или недель ситуация, как она описывается в этой статье, может поменяться кардинально. Помните об этом.

Корневые серверы

194.85.254.37 принадлежит блоку 194.85.254.0/24, который появился отдельной строчкой в RIR и тогда же стал анонсироваться в глобальную таблицу Интернет маршрутизации меньше года назад - в августе 2020 года, источником анонсов является AS62135. Отвечает на CHAOS TXT запросы:

  • version.bind - "PowerDNS Authoritative Server 4.4.0-alpha3.125.master.g6835270cd (built Nov 16 2020 18:13:24 by root@b6b5979d40d3)"

  • id.server - mu.cmu.msk-ix.ru

Есть поддержка NSID - "mu.cmu.msk-ix.ru", и насколько можно судить по данным RIPE Atlas этот сервер представлен в единственной точке присутствия в центральной европейской части России.

Расположение

NSID

Время ответа (мс)

Калининград

mu.cmu.msk-ix.ru

39,5

Санкт-Петербург

mu.cmu.msk-ix.ru

10,7

Ростов-на-Дону

mu.cmu.msk-ix.ru

19,1

Волжский

mu.cmu.msk-ix.ru

24,1

Самара

mu.cmu.msk-ix.ru

3,2

Казань

mu.cmu.msk-ix.ru

14,0

Пермь

mu.cmu.msk-ix.ru

20,4

Екатеринбург

mu.cmu.msk-ix.ru

25,4

Челябинск

mu.cmu.msk-ix.ru

32,2

Омск

mu.cmu.msk-ix.ru

44,3

Новосибирск

mu.cmu.msk-ix.ru

50,3

Чита

mu.cmu.msk-ix.ru

81,4

Хабаровск

mu.cmu.msk-ix.ru

101,9

На временные интервалы, здесь и дальше, следует ориентироваться с большой долей условности, из-за высокой динамичности. Для расчёта были отброшены четверть значений сверху, четверть снизу из оставшегося посчитано среднее.

a.auth-nsdi.ru и b.auth-nsdi.ru представлены в IPv4 и IPv6 и входят в блоки 195.208.6.0/24, 2a0c:a9c7:a::/48,195.208.7.0/24 и 2a0c:a9c7:b::/48, которые появились отдельными строчками в RIR и начали анонсироваться в конце осени, начале зимы 2020. Все от имени AS41740 c as-name NDNS. Всего с той же AS анонсируется 12 префиксов, которые мы ещё встретим дальше:

193.232.147.0/24, 193.232.253.0/24, 195.208.5.0/24, 195.208.4.0/24, 195.208.6.0/24, 195.208.7.0/24, 2a0c:a9c7:a::/48, 2a0c:a9c7:253::/48, 2a0c:a9c7:147::/48, 2a0c:a9c7:b::/48, 2a0c:a9c7:9::/48, 2a0c:a9c7:8::/48

Также поддерживается NSID и запрос CHAOS TXT id.version. На основе которых по отчётам RIPE Atlas (30376498, 30376499, 30376500, 30376501) можно сделать выводы что задействовано несколько точек присутствия и механизмы распределения трафика между ними.

Расположение

a.auth-nsdi.ru

b.auth-nsdi.ru

NSID

Время ответа (мс)

NSID

Время ответа (мс)

Калининград

IPv4/IPv6

auth1-spb.ix.ru, auth2-spb.ix.ru

28.3

auth1-khouse.ix.ru, auth2-khouse.ix.ru

36,6

auth1-khouse.ix.ru, auth2-khouse.ix.ru

40,0

auth1-rnd.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-spb.ix.ru

41,3

Санкт-Петербург

IPv4/IPv6

auth1-spb.ix.ru, auth2-spb.ix.ru

1,4

auth2-spb.ix.ru, auth1-spb.ix.ru

1,3

auth2-kzn.ix.ru, auth1-kzn.ix.ru

76.4

auth1-nsk.ix.ru, auth2-rnd.ix.ru, auth2-nsk.ix.ru, auth2-vlv.ix.ru

229,0

Ростов-на-Дону

IPv4/IPv6

auth2-rnd.ix.ru, auth2-khouse.ix.ru, auth1-rnd.ix.ru, auth1-khouse.ix.ru

0,8

auth1-rnd.ix.ru, auth2-rnd.ix.ru, auth2-khouse.ix.ru

0,8

auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-rnd.ix.ru, auth1-rnd.ix.ru

0,7

auth1-rnd.ix.ru, auth1-khouse.ix.ru, auth2-rnd.ix.ru

0,7

Волжский

IPv4/IPv6

auth2-khouse.ix.ru, auth1-khouse.ix.ru

23,5

auth1-khouse.ix.ru, auth2-khouse.ix.ru

23,5

auth1-khouse.ix.ru, auth2-khouse.ix.ru

21,3

auth1-rnd.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-spb.ix.ru

21,4

Самара

IPv4/IPv6

auth1-kzn.ix.ru, auth2-kzn.ix.ru

17,1

auth1-khouse.ix.ru, auth2-khouse.ix.ru

2,6

auth2-kzn.ix.ru, auth1-kzn.ix.ru

16,9

auth1-spb.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-spb.ix.ru

5,4

Казань

IPv4/IPv6

auth2-khouse.ix.ru, auth1-khouse.ix.ru

13,6

auth1-khouse.ix.ru, auth2-khouse.ix.ru

13,6

auth2-kzn.ix.ru, auth1-kzn.ix.ru

91,8

auth1-nsk.ix.ru, auth2-rnd.ix.ru, auth2-nsk.ix.ru, auth2-vlv.ix.ru

244,4

Пермь

IPv4/IPv6

auth2-khouse.ix.ru, auth1-khouse.ix.ru

21,8

auth1-khouse.ix.ru, auth2-khouse.ix.ru

21,1

auth1-khouse.ix.ru, auth2-khouse.ix.ru

19,2

auth1-nsk.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-rnd.ix.ru, auth2-nsk.ix.ru

27,9

Екатеринбург

IPv4/IPv6

auth1-ekt.ix.ru, auth2-ekt.ix.ru

2,1

auth1-ekt.ix.ru, auth2-ekt.ix.ru

2,1

auth2-ekt.ix.ru, auth1-ekt.ix.ru

1,8

auth1-ekt.ix.ru, auth2-spb.ix.ru, auth2-ekt.ix.ru

1,8

Челябинск

IPv4/IPv6

auth1-ekt.ix.ru, auth2-ekt.ix.ru

4,0

auth1-khouse.ix.ru, auth2-khouse.ix.ru

30,3

auth2-kzn.ix.ru, auth1-kzn.ix.ru

58,1

auth1-nsk.ix.ru, auth2-khouse.ix.ru, auth2-nsk.ix.ru, auth2-vlv.ix.ru

116,2

Омск

IPv4/IPv6

auth2-khouse.ix.ru, auth1-khouse.ix.ru

43,8

auth1-khouse.ix.ru, auth2-khouse.ix.ru

43,7

auth1-khouse.ix.ru, auth2-khouse.ix.ru

38,5

auth1-nsk.ix.ru, auth1-rnd.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-nsk.ix.ru

35,4

Новосибирск

IPv4/IPv6

auth1-nsk.ix.ru, auth2-nsk.ix.ru, auth2-khouse.ix.ru

6,5

auth2-nsk.ix.ru, auth1-nsk.ix.ru, auth1-khouse.ix.ru

6,5

auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth1-nsk.ix.ru

6,6

auth1-nsk.ix.ru, auth2-rnd.ix.ru, auth2-nsk.ix.ru

6,6

Чита

IPv4/IPv6

auth1-nsk.ix.ru, auth2-nsk.ix.ru, auth2-khouse.ix.ru, auth1-khouse.ix.ru

36,1

auth1-nsk.ix.ru, auth2-nsk.ix.ru, auth2-khouse.ix.ru

36,0

auth1-khouse.ix.ru, auth2-khouse.ix.ru

80,4

auth1-rnd.ix.ru, auth2-vlv.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-spb.ix.ru

81,0

Хабаровск

IPv4/IPv6

auth2-khouse.ix.ru, auth2-ekt.ix.ru, auth1-ekt.ix.ru, auth1-nsk.ix.ru, auth2-vlv.ix.ru, auth1-khouse.ix.ru, auth1-vlv.ix.ru, auth2-nsk.ix.ru

34,5

auth2-vlv.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru

100,8

auth1-khouse.ix.ru, auth2-vlv.ix.ru, auth2-nsk.ix.ru, auth1-spb.ix.ru, auth1-vlv.ix.ru, auth2-khouse.ix.ru

39.0

auth1-nsk.ix.ru, auth2-vlv.ix.ru, auth1-vlv.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-spb.ix.ru

100.9

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

auth1-ekt.ix.ru, auth1-khouse.ix.ru, auth1-kzn.ix.ru, auth1-nsk.ix.ru, auth1-rnd.ix.ru, auth1-spb.ix.ru, auth1-vlv.ix.ru, auth2-ekt.ix.ru, auth2-khouse.ix.ru, auth2-kzn.ix.ru, auth2-nsk.ix.ru, auth2-rnd.ix.ru, auth2-spb.ix.ru, auth2-vlv.ix.ru

Несмотря на то, что у меня нет возможности сделать AXFR запрос и сравнить корневые зоны на идентичность Root Zone File, можно сделать обычные запросы по каждой из записей в корневой зоне и сравнить результаты. Несколько однострочников в Bash, чтобы убедиться что корневая зона отдаваемая серверами НСДИ идентична эталонной. В этом мне помогла одна особенность на которую я обратил внимание, возможно, присущую конкретной версии используемых серверов и которая касается DNSSEC и записей NSEC. Не все корневые серверы, возвращают эту запись по прямому запросу, а только в случае NXDOMAIN,корневые НСДИ серверы - возвращают. Таким образом задача решается одним запросом dig +dnssec для каждой строчки из Root Zone File с последующим сравнением. Совсем чуть-чуть придётся поработать с представлением отдаваемых данных, например, привести адреса IPv6 к одному формату, в эталонном файле они приводятся без применения правил сокращения, запретить dig форматировать base64 строчки +nosplit и ещё не забыть про IDN - +noidnout. Результат, насколько я могу судить, не отличается от эталонного. Конечно, интересно было бы следить за этим постоянно, измерять, например, задержки между публикациями зоны и распределением её по серверам НСДИ, но оставим это для следующих авторов.

Рекурсивные резолверы

a.res-nsdi.ru и b.res-nsdi.ru - тоже представлены в IPv4 и IPv6: 195.208.4.0/24, 2a0c:a9c7:8::/48,195.208.5.0/24 и 2a0c:a9c7:9::/48 уже знакомой нам AS41740. В анонсах появились также в конце 2020. Поддерживается только CHAOS TXT id.version, NSID - нет. Но так как это рекурсивные серверы то можно воспользоваться сервисом предоставляемым PowerDNS, чтобы определить с какого реального адреса был отправлен запрос. Это даёт нам технически более строгий способ, так как мы выявляем адреса непосредственно участвующие в запросах со стороны НСДИ, а не идентификаторы, которые можно менять без каких-либо последствий. Опять смотрим на RIPE Atlas (30376488, 30376489, 30376490, 30376491, 30376492, 30376493, 30376494, 30376495).

Расположение

a.auth-nsdi.ru

b.auth-nsdi.ru

Адрес запроса

Время ответа (мс)

Адрес запроса

Время ответа (мс)

Калининград

IPv4/IPv6

res1-spb-lb.ix.ru, res2-spb-lb.ix.ru

26,8

res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res1-khouse-lb.ix.ru

39,1

res2-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-khouse-lb.ix.ru, res2-khouse-lb.ix.ru

38,1

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-spb-lb.ix.ru

39,7

Санкт-Петербург

IPv4/IPv6

193.232.139.82, res1-rnd-lb.ix.ru, res1-spb-lb.ix.ru, res2-spb-lb.ix.ru

1,3

res1-khouse-lb.ix.ru ,res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-spb-lb.ix.ru

7,0

res1-khouse-lb.ix.ru, res1-kzn-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-kzn-lb.ix.ru, res2-nsk-lb.ix.ru

81,5

193.232.139.82, res1-nsk-lb.ix.ru, res1-vlv-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru, res2-vlv-lb.ix.ru

172,0

Ростов-на-Дону

IPv4/IPv6

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-rnd-lb.ix.ru

17,2

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-rnd-lb.ix.ru

1,3

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-rnd-lb.ix.ru

18,5

193.232.139.82, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-rnd-lb.ix.ru

1,3

Волжский

IPv4/IPv6

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

23,3

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

23,4

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

21,3

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-rnd-lb.ix.ru, res2-spb-lb.ix.ru

21,5

Самара

IPv4/IPv6

res1-kzn-lb.ix.ru, res1-spb-lb.ix.ru, res2-kzn-lb.ix.ru, res2-spb-lb.ix.ru

16,0

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

2,6

res1-khouse-lb.ix.ru, res1-kzn-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-kzn-lb.ix.ru

12,1

res1-spb-lb.ix.ru, res2-khouse-lb.ix.ru, res2-spb-lb.ix.ru

12,9

Казань

IPv4/IPv6

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru

30,1

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

13,7

res1-khouse-lb.ix.ru, res1-kzn-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-kzn-lb.ix.ru, res2-nsk-lb.ix.ru

97,6

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-vlv-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru, res2-vlv-lb.ix.ru

187,4

Пермь

IPv4/IPv6

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru

27,6

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

20,9

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-rnd-lb.ix.ru

30,2

res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru

30,4

Екатеринбург

IPv4/IPv6

193.232.231.82, res1-ekt-lb.ix.ru, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-ekt-lb.ix.ru, res2-nsk-lb.ix.ru

9,1

193.232.231.82, res1-ekt-lb.ix.ru, res2-ekt-lb.ix.ru

2,0

193.232.231.82, res1-ekt-lb.ix.ru, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-ekt-lb.ix.ru, res2-khouse-lb.ix.ru

10,5

193.232.231.82, res1-ekt-lb.ix.ru, res2-ekt-lb.ix.ru, res2-spb-lb.ix.ru

1,8

Челябинск

IPv4/IPv6

193.232.231.82, res1-ekt-lb.ix.ru, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-ekt-lb.ix.ru

13,5

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

31,1

res1-kzn-lb.ix.ru, res1-spb-lb.ix.ru, res2-kzn-lb.ix.ru, res2-nsk-lb.ix.ru, res2-spb-lb.ix.ru

82,6

res1-nsk-lb.ix.ru, res1-vlv-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-vlv-lb.ix.ru

86,2

Омск

IPv4/IPv6

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru

37,9

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-rnd-lb.ix.ru

44,6

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru

34,7

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru

25,4

Новосибирск

IPv4/IPv6

193.232.139.82, 193.232.231.82, res1-ekt-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res1-spb-lb.ix.ru, res2-ekt-lb.ix.ru, res2-nsk-lb.ix.ru, res2-spb-lb.ix.ru

6,5

res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru

6,5

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru

9,2

res1-nsk-lb.ix.ru, res2-nsk-lb.ix.ru

6,6

Чита

IPv4/IPv6

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-spb-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-spb-lb.ix.ru

66,0

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res2-nsk-lb.ix.ru, res2-vlv-lb.ix.ru

36,4

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-spb-lb.ix.ru, res2-khouse-lb.ix.ru, res2-spb-lb.ix.ru

81,4

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res1-vlv-lb.ix.ru, res2-khouse-lb.ix.ru, res2-spb-lb.ix.ru, res2-vlv-lb.ix.ru

82,8

Хабаровск

IPv4/IPv6

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res1-vlv-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru, res2-vlv-lb.ix.ru

95,9

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-vlv-lb.ix.ru

101,9

res1-khouse-lb.ix.ru, res1-kzn-lb.ix.ru, res1-msk-lb.ix.ru, res1-spb-lb.ix.ru, res1-vlv-lb.ix.ru, res2-kzn-lb.ix.ru, res2-nsk-lb.ix.ru, res2-spb-lb.ix.ru, res2-vlv-lb.ix.ru

100,3

res1-nsk-lb.ix.ru, res1-vlv-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-spb-lb.ix.ru, res2-vlv-lb.ix.ru

61,4

Отметим ещё один момент.AAAA запросы используют IPv6 в качестве адреса источника, даже если обращения было сделано на клиентский публичный IPv4 адрес сервера. Для A запросов на IPv6 адрес это тоже верно. В таблице приведены уже преобразованные к доменным именам адреса, там где они были в PTR, каждый из них имеет и A и AAAA запись. Всего получилось 17 уникальных адресов доменных имён у каждого в наличии IPv4 и IPv6. Для двух адресов видимо забыли завести записи в обратную зону, хотя в прямой они есть (я их привёл в скобках).

193.232.139.82(res2-rnd-lb.ix.ru), 193.232.231.82(res2-ekt-lb.ix.ru), res1-ekt-lb.ix.ru, res1-khouse-lb.ix.ru, res1-kzn-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res1-smr-lb.ix.ru, res1-spb-lb.ix.ru, res1-vlv-lb.ix.ru, res2-ekt-lb.ix.ru, res2-khouse-lb.ix.ru, res2-kzn-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru, res2-smr-lb.ix.ru, res2-spb-lb.ix.ru, res2-vlv-lb.ix.ru

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

Для этих серверов уже действует ограничение на выдачу ресурсов присутствующих в списке запрещённых - NXDOMAIN в ответ.

На этом - всё. Как я уже сказал в самом начале, цель этой статьи начать техническое обсуждение построенной системы. Можно свободно использовать те измерения которые я реализовал в RIPE Atlas и ссылки на которые есть в статье, они останутся настолько долго, насколько не потеряют актуальность. Совсем незатронутым остался вопрос DNSSEC, также как и возможные пересечения с существующей системой поддержки национальных TLD. Можно порассуждать про обратные зоны в ARPA., которые не менее важны чем прямые, но они не реализованы в НСДИ, в отличие от прямой корневой зоны. Вопрос устойчивости и работы под нагрузкой, вопрос безопасности... Другими словами больше осталось за кадром, чем в статье - много интересной работы и вопросов, надеюсь, что кого-то я этим заинтересовал.

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru