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

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

Перевод SSH, пользовательский режим, TCPIP и WireGuard

16.04.2021 16:20:16 | Автор: admin
Тому, кто хостит приложение у провайдера наподобие Fly.io (далее просто Fly), вполне может понадобиться подключиться к серверу, на котором работает это приложение, по SSH.

Но Fly это вроде как белая ворона среди других подобных платформ. Наше железо работает в дата-центрах, разбросанных по всему миру. Наши серверы подключены к интернету через Anycast-сеть, а друг с другом они связаны с помощью WireGuard-сети. Мы берём у пользователей Docker-контейнеры и превращаем их в микровиртуальные машины Firecracker. И, когда мы только начали работать, мы поступали именно так для того чтобы дать нашим клиентам возможность запускать пограничные приложения. Такие приложения обычно представляют собой сравнительно небольшие, самодостаточные фрагменты кода, которые весьма чувствительны к качеству работы сетей. Эти фрагменты кода, в результате, нужно запускать на серверах, расположенных как можно ближе к пользователям. В такой среде возможность подключения к серверу по SSH не так уж и важна.



Но теперь не все наши клиенты пользуются Fly по такой схеме. В наши дни в среде Fly можно без труда выполнять весь код, имеющий отношение к некоему приложению. Мы упростили процедуру запуска ансамбля сервисов в кластерной среде. Такие сервисы могут, используя защищённые каналы связи, взаимодействовать друг с другом, могут хранить данные на постоянной основе, могут, по WireGuard-сети, связываться со своими операторами. Если я продолжу рассказ о нашей системе в том же духе, то мне придётся дать ссылки на все материалы, которые мы написали за последние пару месяцев.

Но, в любом случае, нормальной поддержки SSH у нас не было.

Ясно, конечно, что можно было просто собрать контейнер со службой SSH, к которой можно подключиться по SSH. Платформа Fly поддерживает работу с обычными TCP-портами (и с UDP-портами тоже). Если клиент, пользуясь файлом fly.toml, расскажет нашей Anycast-сети о своём странном SSH-порте, система организует маршрутизацию его SSH-подключений, после чего всё будет работать как надо.

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

Часть 1: 6PN и Hallpass


Я много написал о том, как во Fly устроены частные сети. Если рассказать об этом в двух словах, то окажется, что то, что есть у нас, можно сравнить с упрощённой IPv6-версией виртуальных частных облаков GCP или AWS. Мы называем эту систему 6PN. Когда во Fly запускается экземпляр приложения (микровиртуальная машина Firecracker), мы назначаем этому экземпляру особый IPv6-префикс. В префиксе закодировано несколько идентификаторов: идентификатор приложения, организации, которой принадлежит приложение, и аппаратных ресурсов, на которых приложение работает. Мы используем немного eBPF-кода для организации статической маршрутизации подобных IPv6-пакетов в нашей внутренней WireGuard-сети и для обеспечения того, чтобы клиенты не могли бы подключаться к системам организаций, к которым они не имеют отношения.

Кроме того, можно, используя WireGuard, посредством мостов, соединять создаваемые нами частные IPv6-сети с другими сетями. Наш API умеет создавать WireGuard-конфигурации, которые можно, например, применять на EC2-хостах для проксирования RDS Postgres. Или, если надо, можно пользоваться WireGuard-клиентами (в Windows, Linux или macOS) для подключения компьютера, на котором ведётся разработка, к собственной частной сети.

Вероятно, вы уже поняли, к чему я клоню.

Мы написали очень маленький и очень простой SSH-сервер на Go, который назвали Hallpass. Его можно сравнить с Hello, World!, созданным с использованием Go-библиотеки x/crypto/ssh. (Если бы я снова это делал, я, вероятно, просто использовал бы пакет Glider Labs, предназначенный для создания SSH-серверов. С использованием этого пакета наш сервер, в буквальном смысле, был бы программой уровня Hello, World!.) При инициализации всех экземпляров микровиртуальных машин Firecracker выполняется и запуск Hallpass с привязкой к их 6PN-адресам.

Если вы способны работать в 6PN-сети своей организации (предположим, через WireGuard-соединение), это значит, что вы можете войти в экземпляр микровиртуальной машины с помощью Hallpass.

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

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

Возможно, у вас есть вопросы по поводу этого решения. Поэтому я раскрою ещё некоторые подробности о нём.

Во-первых поговорим о сертификатах. Десятилетия безумства X.509, возможно, привели к тому, что слово сертификат вызывает у вас неприятное послевкусие. И я вас за это не виню. Но сертификаты стоит использовать при организации SSH-соединений, так как подобные сертификаты в данном случае это хорошее решение. При этом SSH-сертификаты это не X.509-сертификаты. Тут используется собственный формат OpenSSH, и, в общем-то, об этих сертификатах нельзя рассказать больше ничего особенного. У них, как и у всех остальных сертификатов, есть срок годности, что позволяет создавать короткоживущие ключи (а это, почти всегда, именно то, что нужно). И, конечно, они позволяют назначить один публичный ключ целой группе серверов, который может авторизовывать произвольное количество приватных ключей. При этом нет необходимости постоянно обновлять соответствующие серверы.

Далее наш API и подписание сертификатов. Ну что ж! Мы очень осторожны, но эти сертификаты, в целом, так же безопасны, как токены доступа к Fly. В настоящий момент сертификаты не могут быть защищены лучше, чем токены, так как токен позволяет развёртывать новые версии контейнеров приложений. Работа с Web PKI X.509 CA предусматривает массу формальностей. Мы обходимся без них.

И наконец наша DNS. Она, соглашусь, выглядит как полная ерунда. Но она, на самом деле, не так уж и плоха. На каждом хосте, на котором выполняются экземпляры микровиртуальных машин Firecracker, работает и локальная версия нашего частного DNS-сервера (маленькая программа, написанная на Rust). eBPF-код обеспечивает то, что Firecracker-машины могут взаимодействовать только с этим DNS-сервером, обращаясь к нему с 6PN-адреса своего сервера. (С технической точки зрения пользователь может выполнять запросы только к приватному API DNS этого сервера, а запросы всех остальных пользователей будут обрабатываться в рекурсивном режиме.) DNS-сервер может (знаю выглядит это необычно) надёжно идентифицировать организацию, анализируя IP-адреса источников запросов. В общем-то именно так мы и работаем.

Всё это происходит в недрах нашей системы, пользователям всего этого не видно. Пользователи видели лишь команду flyctl ssh issue -a, которая запрашивала новый сертификат у нашего API, а потом передавала его локальному SSH-агенту, после чего SSH-подключения, в общем-то, оказывались работоспособными. Всё это было устроено достаточно аккуратно. Но любое дело всегда можно сделать аккуратнее, чем прежде.

Часть 2: работа в WireGuard-сети из пользовательского режима с применением TCP/IP


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

Правда, и такие пользователи нуждаются в работе со своими системами по SSH.

На первый взгляд то, что у кого-то не установлен WireGuard, может показаться непреодолимой помехой. Ведь как работает WireGuard? На компьютере пользователя создаётся новый сетевой интерфейс. Это либо WireGuard-интерфейс уровня ядра (в Linux), либо туннель с прикреплённым к нему WireGuard-сервисом пользовательского режима (во всех остальных ОС). Без этого сетевого интерфейса работать с WireGuard-сетью нельзя.

Но, если взглянуть на WireGuard под правильным углом, то можно увидеть, что, с технической точки зрения, это не так. А именно, для настройки нового сетевого интерфейса нужны привилегии уровня операционной системы. А вот для отправки пакетов на 51820/udp никаких привилегий не нужно. Всё, что нужно для обеспечения работы протокола WireGuard, можно запустить в виде непривилегированного процесса, функционирующего в пользовательском режиме. Именно так работает пакет wireguard-go.

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

Сложно ли будет написать небольшой фрагмент кода, обеспечивающий работу протокола TCP в пользовательском режиме, рассчитанный исключительно на то, чтобы поддерживать обмен данными по WireGuard-сети, опять же, в пользовательском режиме? Такой код позволил бы пользователям Fly подключаться к своим системам по SSH и при этом не устанавливать у себя того, что обеспечивает работу WireGuard.

Я поступил опрометчиво, рассуждая обо всём этом в Slack-канале, в котором присутствовал Джейсон Доненфельд. А именно, я, поразмышляв вслух, отправился спать. Когда я проснулся, Джейсон уже всё это реализовал, используя gVisor, и включил в состав библиотеки WireGuard.

Самое интересное тут это gVisor. Мы уже о нём писали. Если кто не знает gVisor это, в сущности, ОС Linux, работающая в пользовательском пространстве, Linux, реализованная на Golang, используемая в качестве замены runc для выполнения контейнеров. Это, на самом деле, совершенно безумный проект. И если вы им воспользуетесь, то, полагаю, вы можете с гордостью рассказать об этом окружающим, потому что это ну просто шикарная штука. В его недрах имеется полная реализация TCP/IP, написанная на Go, которая оперирует входными и выходными данными, представленными в виде обычных буферов []byte.

Тогда было твитнуто несколько твитов, а потом, через пару часов, мне пришло очень приятное электронное письмо от Бена Баркерта. Бен уже занимался разными задачами, связанными с сетевой подсистемой gVisor, его заинтересовало то, над чем мы работали, он желал узнать, хотим ли мы с ним скооперироваться. Нам понравилась его идея по совместной работе над этим проектом. И теперь, если не вдаваться в подробности, у нас имеется реализация SSH, основанная на сертификатах, которая работает через gVisor-реализацию TCP/IP пользовательского режима. Всё это взаимодействует с WireGuard-сетью посредством пакета пользовательского режима wireguard-go. И, наконец, эта штука встроена во flyctl.

Для того чтобы воспользоваться SSH с помощью flyctl достаточно ввести команду такого вида:

flyctl ssh shell personal dogmatic-potato-342.internal

А теперь, чтобы вы могли осознать всю невероятность происходящего, немного расскажу об этой команде. Так dogmatic-potato-342.internal это внутреннее DNS-имя, разрешающееся только силами приватного DNS-сервера в сети 6PN. Всё это работоспособно из-за того, что в режиме ssh shell утилита flyctl использует TCP/IP-стек gVisor пользовательского режима. Но в gVisor нет кода для выполнения DNS-поиска. Это всего лишь стандартная Go-библиотека, которую мы обдурили, подсунув ей наш особенный TCP/IP-интерфейс.

Flyctl, между прочим, это опенсорсный проект (он и должен таким быть, так как клиентам нужно пользоваться им на собственных компьютерах, на которых они занимаются разработкой). Поэтому, если интересно, можете просто почитать его код. Бен написал хороший код, находящийся в папке pkg. А весь остальной код, кошмарный, написал я. В Go обеспечение обмена данными по протоколу IP в сети WireGuard выглядит на удивление просто. Если вы когда-нибудь занимались низкоуровневым TCP/IP-программированием, то вам, возможно, эта простота покажется невероятной. Объекты из TCP-стека gVisor подключаются прямо к сетевому коду стандартной библиотеки.

Взгляните на этот код:

tunDev, gNet, err := netstack.CreateNetTUN(localIPs, []net.IP{dnsIP}, mtu)if err != nil {return nil, err}// ...wgDev := device.NewDevice(tunDev, device.NewLogger(cfg.LogLevel, "(fly-ssh) "))

CreateNetTUN это часть wireguard-go. Тут используются возможности gVisor. В нашем распоряжении оказывается, во-первых, синтетическое туннельное устройство, которое можно использовать для чтения и записи обычных пакетов, обеспечивающих работу WireGuard. Во-вторых у нас имеется функция net.Dialer, обёртка для gVisor, которую можно использовать в Go-коде и через неё взаимодействовать с соответствующей WireGuard-сетью.

Это всё? В общем-то да. Вот, например, как мы используем эти механизмы для работы с DNS:

resolv: &net.Resolver{PreferGo: true,Dial: func(ctx context.Context, network, address string) (net.Conn, error) {return gNet.DialContext(ctx, network, net.JoinHostPort(dnsIP.String(), "53"))},},

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

Очевидно, все должны поступать именно так


Благодаря парам сотен строк кода (это если не считать код реализации Linux для пользовательского режима, которая достаётся нам от gVisor; но что делать от зависимостей никуда не деться) можно получить в своё распоряжение новую сеть с криптографической аутентификацией. Сеть, которая доступна в любое время и практически из любой программы.

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

В любом случае, то, о чём я рассказал, решило огромную нашу проблему. Эта система ведь подходит не только для организации работы SSH. Мы, кроме того, хостим базы данных Postgres. Очень удобно, когда есть возможность, выполнив простую команду, буквально откуда угодно открыть оболочку psql, независимо от того, можно ли, именно в нужный момент, установить WireGuard для macOS.

Пользуетесь ли вы WireGuard?

Подробнее..

Администратор узла сети I2P. Полный курс

31.03.2021 22:18:24 | Автор: admin

I2P (Invisible Internet Project, Проект невидимого интернета) одноранговая сеть с открытым исходным кодом, где анонимность участников главная повестка всех архитектурных решений.

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

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

Установка

I2Pd (Invisible Internet Protocol Daemon) роутер от преимущественно русскоговорящего сообщества PurpleI2P. Разрабатывается с 2013 года. Реализован на языке программирования C++, использует библиотеки OpenSSL и Boost. I2Pd является кроссплатформенным, готовые бинарники распространяются для платформ Windows, Linux, MacOS и Android. Очевидна возможность ручной компиляции, в том числе под операционные системы, не перечисленные выше. I2Pd имеется в стандартных репозиториях некоторых дистрибутивов Linux, однако для использования актуальной версии рекомендуется репозиторий сообщества. Основным местом распространения исходных кодов и бинарных файлов является репозиторий GitHub.

К счастью, администрирование I2P-роутера на всех платформах фактически идентично: веб-консоль на локальном адресе главный источник информации о текущей активности роутера. Адрес веб-консоли по умолчанию: http://127.0.0.1:7070.

Webconsole: Main page

Разберем всё по порядку:

Uptime Показывает прошедшее время с момента запуска.

Network status Сообщает сетевой статус роутера. В версиях выше 2.37.0 присутствует Network status 6 для отдельного отображения состояния сети на интерфейсах IPv6. Принимает значения:

  • Testing: Тестирование сетевых возможностей роутера.

  • OK: Всё в норме. Означает, что роутер работает в штатном режиме и доступен для соединений извне по протоколу TCP и UDP. Как правило, статус ОК появляется, когда порт I2Pd в операционной системе открыт, а IP-адрес доступен глобально, т.е. является выделенным, или белым (либо через NAT прокинут порт для I2Pd).

  • Firewalled: Является индикатором недоступности порта TCP извне. Может быть сигналом о блокировке рабочего порта I2Pd файерволом операционной системы. В большинстве случаев статус Firewalled видят пользователи за NAT-сервером, не имеющие выделенного IP-адреса: главным образом пользователи сотовых операторов.

  • Proxy: Работа роутера через прокси. Подразумевает работу только по протоколу NTCP2 (криптоаналог TCP), так как SSU (криптоаналог UDP) через прокси не ходит. Настраивается вручную через конфиг.

  • Mesh: Работа роутера в меш-сети. На момент написания статьи поддерживается работа в Yggdrasil Network. Статус Mesh подразумевает работу роутера исключительно через меш-сеть, минуя обычный интернет. В случае использования режима Mesh вместе с прокси, или непосредственной работой через интернет, статус Mesh не выводится.

  • Unknown: Отсутствует трафик SSU, при этом конфигурация роутера не соответствует индикаторам Proxy или Mesh.

Tunnel creation success rate Процент успешно построенных туннелей, т.е. процент успешно созданных туннелей от числа инициированных роутером. В среднем варьируется от 20 до 50%.

Received и Sent Объем полученной и отправленной информации с момента запуска роутера. В скобках указывается скорость передачи в настоящий момент.

Transit Объем транзитного трафика и актуальная скорость его потока.

Data path Рабочая директория роутера, где хранятся ключи и локальная база сети.

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

Hidden content. Press on text to see Спойлер с чувствительной информацией о роутере. По умолчанию скрыт. Здесь отображаются IP-адреса с указанием протокола: SSU, SSUv6, NTCP2 и NTCP2v6 (приставка v6 обозначает работу по IPv6), а также криптографическое имя роутера (Router Ident), образуемое от публичного ключа router.keys. Этим ключом шифруется информация, адресуемая нашему роутеру.

В секции Our external address отображаются внешние IP-адреса роутера с указанием рабочего порта, на который роутер принимает внешние обращения. Случайный порт генерируется при первом запуске и сохраняется в файле router.info. Также есть возможность указать случайный рабочий порт вручную при запуске или в конфигурационном файле. Если в веб-консоли вы видите локальный адрес или нули, это сигнал о том, что рабочий порт роутера закрыт файерволом, либо ваш IP-адрес недоступен извне (т.е. не является выделенным). В случае протокола SSU при работе за NAT-сервером (например, через USB-модем), в списке внешних адресов роутера появится адрес NAT-сервера провайдера и порт, который в настоящее время закреплен за вами (Hole punch).

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

  • f: Floodfill роутер является флудфилом.

  • H: Hidden роутер не публикует свои IP-адреса.

  • K: Канал для транзитного трафика до 12КБ/сек.

  • L: Канал для транзитного трафика до 48 КБ/сек (по умолчанию).

  • M: Канал для транзитного трафика до 64 КБ/сек.

  • N: Канал для транзитного трафика до 128 КБ/сек.

  • O: Канал для транзитного трафика до 256 КБ/сек.

  • P: Канал для транзитного трафика до 2000 КБ/сек.

  • X: Канал для транзитного трафика 2000 КБ/сек и выше (значение по умолчанию для флудфила).

  • R: Reachable роутер доступен для обращений извне, имеет выделенный адрес и открытый порт.

  • U: Unreachable роутер недоступен для внешних обращений.

Флаги роутера R и U в I2Pd указываются для корректной работы морально устаревшего Java-роутера. I2Pd эти флаги игнорирует и использует аналогичные флаги из Router Info (RI). Логично, что для каждого адреса флаги доступности могут различаться (например, для IPv4 за NAT и выделенного IPv6). В RI флаги указываются для каждого IP-адреса отдельно.

Router Info информация, публикуемая роутером о себе, которая включает ключи, флаги и IP-адреса. Файл router.info генерируется после каждого изменения состояния роутера и находится в рабочей директории Data path.

Помимо перечисленных флагов R и U, к адресам в Router Info опционально добавляются следующие:

  • 4: Скрытый адрес IPv4.

  • 6: Скрытый адрес IPv6.

  • B: Означает, что SSU-адрес обрабатывает пиртесты, т.е. может быть привлечен для проверки доступности роутера извне.

  • С: Означает, что адрес может быть интродьюсером (introducer) сущностью, выступающей в роли связующего звена для обращения к узлу со скрытым IP-адресом. Информация об использовании конечным узлом IPv4 или IPv6 необходима для совместимости на уровне транспорта после ответа связующего звена (флаги 4 и 6). Интродьюсер весьма емкая тема, которая будет подробно рассмотрена в отдельной статье.

Routers Отображает актуальное количество известных роутеров сети в локальной базе.

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

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

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

Transit Tunnels Количество транзитных туннелей, частью которых является роутер в настоящий момент времени.

В нижней части страницы, под заголовком Services обозначено состояние служб (активна или нет):

  • HTTP Proxy HTTP-прокси пользователя для выхода в скрытую сеть. По умолчанию доступен на адресе 127.0.0.1:4444.

  • SOCKS Proxy Пользовательский SOCKS-прокси для выхода в скрытую сеть. По умолчанию доступен на адресе 127.0.0.1:4447.

  • BOB (Basic Open Bridge) Является интерфейсом для прикладных программ, работающих через I2P. Основная задача заключается в создании динамических туннелей. В Java-роутере считается устаревшим из-за подписи DSA, ненадежной из-за успешной практики взлома хеша SHA1, используемого в этой подписи. В I2Pd BOB активно поддерживается, использует актуальные алгоритмы подписи, а также имеет расширения протокола, вовсе отсутствующие в Java-роутере. В общем, является актуальным инструментом.

  • SAM (Simple Anonymous Messaging) Является интерфейсом для прикладных программ, работающих через I2P. Основная задача также заключается в создании динамических туннелей. В I2Pd SAM является равноценной альтернативой BOB, а в Java-роутере единственным протоколом в своем роде.

    Сходство BOB и SAM обусловлено изначальной разработкой разными людьми со схожими целями: BOB для торрент-клиента Robert, SAM для iMule. В итоге и Robert и iMule ушли на задний план, а протоколы взаимодействия приложений с I2P-роутером остались.

  • I2CP (I2P Control Protocol) протокол взаимодействия внешних программ с роутером, строго разделяющий I2P-роутер с программой, обращающейся в скрытую сеть. Концепция заключается в том, что работой с данными должно заниматься некое внешнее по отношению к маршрутизатору приложение. На практике это означает, что внешнее приложение должно содержать ~2/3 кода I2P-роутера, чтобы делать что-то осмысленное. В Java-роутере абсолютно весь трафик проходит через протокол I2CP, что сильно влияет на падение гибкости: стримы (сессии TCP фактически вся активность пользователя) не могут контролировать доступ к туннелям и лизсетам.

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

    В I2Pd протокол I2CP существует, как инструмент совместимости с приложениями, написанными в парадигме Java-роутера. Из рабочей логики I2Pd этот протокол убран, а все клиентские данные обрабатываются в рамках внутренних библиотек libi2pd и libi2pd_client, что позволяет прикладным программам полностью контролировать свою активность в скрытой сети.

  • I2PControl протокол, позволяющий получить информацию о работе роутера в виде запросов и ответов в формате JSON. Является альтернативой веб-консоли и используется редко, поэтому в рамках статьи рассмотрен не будет.

Webconsole: Router commands

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

  • Run peer test запустить проверку доступности роутера. Может понадобиться, если при запуске роутера рабочий порт был закрыт и статус сети отображается, как Firewalled. Роутер автоматически проверяет свою доступность примерно раз в час, но есть возможность ускорить процесс вручную.

  • Decline transit tunnels отклонять новые транзитные туннели (жизненный цикл уже созданных транзитных туннелей прерван не будет). Узлы, предлагающие нам стать частью туннелей, будут получать отказ. Команда может пригодиться при изучении сетевой активности сервера, чтобы убрать все мусорные подключения, при этом сохранив работоспособность скрытых сервисов I2P, в том числе сессию SSH.

  • Start graceful shutdown запустить корректную остановку роутера. После запуска в течение 10 минут роутер продолжит обычную работу, не принимая новые транзитные подключения. Так как все туннели живут 10 минут, этого достаточно, чтобы выключить роутер, не оборвав туннели других участников сети.

  • Force shutdown незамедлительная остановка I2P-роутера.

  • Logging level (none, error, warn, info, debug) смена режима логирования. Может пригодиться при неожиданно возникшей потребности в дебаге. Логи продолжат писаться в стандартный файл (/var/log/i2pd/i2pd.log).

  • Transit tunnels limit позволяет сменить лимит количества транзитных туннелей. По умолчанию 2500.

Webconsole: Local Destinations

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

Base64 полный адрес конечной точки, закодированный в base64. Включает в себя публичный ключ шифрования, публичный ключ подписи и прочую служебную информацию. Обычно этот массив составляет 391 байт. Кстати, хеш SHA256 в кодировке base32 от этого массива Base64 образует привычный адрес *.b32.i2p.

Address registration line позволяет получить строку для регистрации домена на ресурсах reg.i2p (поддерживается сообществом разработчиков i2pd) и stats.i2p (поддерживается командой Java-роутера). Домен будет привязан к актуальному ключу, для которого открыта строка регистрации.

Регистрация коротких доменов будет подробно рассмотрена в следующей.

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

Inbound tunnels и Outbound tunnels входящие и исходящие туннели конечной точки, размещенной на локальном роутере. Суть обозначений входящего туннеля приведена на иллюстрации, для исходящих туннелей всё аналогично.

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

Tags список адресов, при взаимодействии с которыми локальная конечная точка использовала одноразовые криптографические ключи, называемые тегами. Amount это количество тегов. Минимальное число генерируемых тегов, как видно на скриншоте, равняется четырем. Нулевое количество означает израсходование ранее сгенерированных тегов. Применяется при использовании алгоритма ElGamal (внутреннее обозначение типа шифрования 0).

ElGamal считается очень ресурсоемким и устаревшим алгоритмом. На смену ему приходит тип шифрования 4 новый быстрый протокол сквозного шифрования ECIES-X25519-AEAD-Ratchet. Теги здесь тоже присутствуют, но в другом виде.

При этом алгоритме ключи не передаются по сети: каждый абонент выводит их математическим путем локально. Параметр Incoming Tags обозначает количество выведенных тегов на будущее, а Tags sessions отображает количество сессий и адреса, с которыми они установлены. Status говорит о состоянии сессии, где 4 означает Established, а всё, что меньше сессия по каким-то причинам зависла. Больше 4 тоже норма.

Streams стримы (TCP-сессии передачи информации), активные подключения внешнего приложения к I2P через локальный роутер. Соответствуют клиентским соединениям TCP/IP. Stream ID номер туннеля. Необходим для возможности различать разные потоки, сравним с номером порта. Пиктограмма с крестиком позволяет закрыть, т.е. прервать стрим. Destination адрес конечной точки на другом конце провода. Sent и Received объем отправленной и полученной информации в байтах.

RTT время в миллисекундах от отправки пакета до подтверждения его получения. Window текущий размер окна для отправки, измеряется в пакетах. Buf количество неотправленных байт, ожидающих места в окне. Out количество пакетов, находящихся в окне без подтверждения. In количество полученных пакетов, которые клиентское приложение еще не приняло. Status состояние стрима, где 1 означает открытое соединение.

Размеры пакетов: 1730 байт для ElGamal и 1812 байт для ECIES-X25519-AEAD-Ratchet.


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

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

Webconsole: LeaseSets

Пункт, актуальный для роутеров, являющихся флудфилами. Содержит список лизсетов, опубликованных у нас скрытыми ресурсами, т.е. анонимными конечными точками сети. Имя лизсета является доменом *.b32.i2p без обозначения этого окончания. Лизсет содержит информацию о входном туннеле целевого ресурса и срок годности (в среднем 10 минут). Также существуют зашифрованные лизсеты, не поддающиеся очевидному анализу. Подробно тема лизсетов будет рассмотрена в следующей статье.

Webconsole: Tunnels / Transit tunnels

Во вкладке Tunnels можно увидеть все входящие и исходящие туннели роутера, инициированные самим роутером. Туннели с пометкой exploratory являются зондирующими они строятся автоматически через небольшой промежуток времени, имеют низкое движение трафика и служат для исследования сети: получение трех случайных роутеров от случайного флудфила. Также через них иногда ходят служебные запросы роутера и публикация своего Router Info.

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

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

Webconsole: Transports

Страница с отображением прямого взаимодействия с другими роутерами с указанием количества соединений по каждому протоколу (NTCP2, NTCP2v6, SSU, SSUv6). В квадратных скобках указывается количество [отправленных : полученных] байт. Стрелки демонстрируют статус соединения: входящее или исходящее.

Webconsole: I2P Tunnels

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

Отображается три типа туннелей: клиентские, серверные и Server Forwards. Туннели типа Forwards являются UDP-туннелями: могут быть как серверными, так и клиентскими.

Webconsole: SAM sessions

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

Подключение к веб-консоли удаленного роутера

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

Такой подход чреват уязвимостью в случае, когда подключение к веб-консоли осуществляется через обычный интернет без использования дополнительного шифрования трафика (https). Одним из самых практичных и безопасных способов является подключение к веб-консоли через SSH с прокинутым портом. Протокол SSH не нуждается в дополнительной защите, так как имеет встроенное шифрование, и отлично подходит для повседневного использования в силу простоты и распространенности. Локальный порт прокидывается на удаленную машину через флаг -D: ssh -D 8888 user@<server ip> -p <ssh port>.

Приведенная команда позволит подключиться в браузере на SOCKS-прокси по адресу 127.0.0.1:8888 и выходить в глобальную сеть с IP-адреса сервера, а также иметь доступ к локальным ресурсам удаленной машины, словно браузер запущен на ней. В том числе получится подключиться по локальному адресу 127.0.0.1:7070 к веб-консоли I2P-роутера, развернутого на сервере.

Конфигурационный файл

Несмотря на способность роутера работать с передаваемыми значениями (параметры при запуске), распространенной практикой является использование конфигурационного файла. На Debian при установке из пакета конфиг i2pd.conf находится в директории /etc/i2pd/. При запуске бинарника без установки (например, после ручной компиляции роутера), конфигурационный файл читается из директории ~./i2pd/. На Android все рабочие файлы роутера (в том числе конфиг) лежат в одной папке, чаще всего это /sdcard/i2pd/. На Windows стандартной рабочей директорией является %AppData%\i2pd.

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

Конфигурационный файл поддерживает два вида синтаксиса:

  1. Указание конфигурируемой секции в квадратных скобках с перечислением параметров этой секции ниже до следующих квадратных скобок;

  2. Указание параметра через точку после имени секции.

Параметры по умолчанию (в том числе при запуске без конфигурационного файла):

  • Веб-консоль включена, доступна по адресу http://127.0.0.1:7070

  • HTTP-прокси включен, доступен по адресу 127.0.0.1:4444

  • SOCKS-прокси включен, доступен по адресу 127.0.0.1:4447

  • SAM включен, доступен по адресу 127.0.0.1:7656

  • Активен фоновый режим работы роутера (демон)

  • Логирование на уровне warn (от warning внимание!)

  • IPv4 включен, IPv6 отключен

    Неупомянутые параметры по умолчанию неактивны.

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

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


[reseed] Параметры получения стартового пакета (ресида) с несколькими роутерами для начала взаимодействия с сетью I2P. В первую очередь, ресид важен при первом запуске, когда локальная база сети пуста (папка netDb).

verify Проверка подписи полученного ресида. По умолчанию параметр является отключенным. Однако, в стандартном конфиге в состоянии true. Подразумевается, что экземпляр конфигурационного файла имеется после установки из пакета, в который входят сертификаты стартовых узлов (папка certificates). Если верификацию включить, не имея сертификатов, роутер не сможет стартовать.

urls веб-адреса, с которых будет скачен ресид (например, https://example.ru/).

yggurls адрес IPv6 Yggdrasil, с которого будет скачен ресид.

file путь до локального .su3-файла, или прямая ссылка https.

zipfile путь до локального zip-архива базы роутера, или прямая ссылка https.

proxy прокси, используемый при обращении к ресиду.

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


[persist] Секция, отвечающая за сохранение на диск некоторой динамической информации.

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

addressbook отвечает за сохранение полных адресов. При отключении уменьшает нагрузку на диск.

Послесловие

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

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

Подробнее..

MaxPatrol 8 Работа с системой

01.04.2021 10:10:31 | Автор: admin


Коллеги, добрый день!

Мы с вами продолжаем знакомиться с системой контроля защищенности и соответствия стандартам MaxPatrol 8 от Positive Technologies.

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

На вкладке Сканирование существуют задачи, профили и учетные записи.
Вкладка Учетные записи служит для задания учетных данных, используемых при проведении проверок в режимах сканирования Audit и Compliance.



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



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



Вкладка Задачи состоит из двух областей: активные сканы и настройки.



Своеобразная единица работы для сканера это задача. В ней сопоставляются профили сканирования с возможностью переопределения и активы (узлы).



Сканирования запускаются со вкладки Задачи, но желательно создавать расписания сканирования на вкладке Планировщик.



Теперь поговорим о настройке профилей и выборе режима сканирования
Режимов сканирования 3: Pentest, Audit и Compliance. Включаются они независимо друг от друга в настройке профиля.

Pentest


Сканирование в режиме PenTest направлено на получение оценки защищенности со стороны внешнего злоумышленника. Основные характеристики данного режима:

  1. Использование минимальных привилегий по отношению к тестируемой системе (анонимный доступ или доступ уровня пользователя)
  2. Идентификация и анализ уязвимостей серверного программного обеспечения
  3. Расширенная проверка нестандартных портов
  4. Эвристические алгоритмы идентификации типов и версий сетевых служб по особенностям протоколов
  5. Поиск уязвимостей и отсутствующих обновлений Microsoft Windows без использования учетной записи
  6. Эвристический анализ веб-приложений
  7. Эвристический механизм определения операционной системы
  8. Проверка стойкости паролей

Существуют преднастроенные профили сканирования Pentest



(Pentest) Bruteforce основное предназначение это подбор учетных записей, сканирует только стандартные порты сервисов.
(Pentest) DoS scan профиль включает максимально полный набор проверок, включая и DoS-атаки. Использовать его необходимо с осторожностью.
(Pentest) Fast Scan профиль предназначен для быстрой проверки на наличие уязвимостей и выполняет только безопасные проверки.
(Pentest) Inventory описан в предыдущей статье.
(Pentest) PCI DSS ASV предназначен для проверки на соответствия требованиям PCI DSS. Сканирование занимает длительное время, увеличено время ожидания ответов от сканируемого актива, сканирование происходит в безопасном режиме и само по себе достаточно длительное по времени.
(Pentest) Safe scan профиль очень похож на Fast Scan за исключением того, что тут задан более широкий диапазон портов.
(Pentest) Service Discovery предназначен для быстрого обнаружения работающих узлов, открытых на них портов и определения служб. Не настроен на поиск уязвимостей.
(Pentest) Web Scan предназначен для сканирования веб-ресурсов. Сканирование занимает значительное время, задействует небезопасные проверки, проверке подлежат только стандартные HTTP-порты.

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



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



Вы можете добавлять необходимые записи в уже существующие справочники или создавать свои:



Audit


Сканирование в режиме Audit используется для контроля обновлений, анализа конфигурации, локальной оценки стойкости паролей и т.д. Сканирование производится посредством удаленного доступа к объектам сканирования с использованием сетевых транспортов и учетных данных, при этом MaxPatrol 8 не требует наличия агента на сканируемом узле.
Сканирование в режиме Audit позволяет собрать наиболее полные данные об активах и установленных на них ПО и благодаря проверке с использованием учетной записи с необходимыми привилегиями выдает намного больше уязвимостей актива чем в сканирование в режиме Pentest.
Также в режиме Audit можно собирать данные о контроле целостности конкретных файлов и производить подбор учетных записей с помощью справочников аналогично сканированию в режиме Pentest.
Стоит отметить, что список поддерживаемых систем, которые можно просканировать режимом Audit большой, но есть и неподдерживаемые системы.

Compliance


Сканирование в режиме Compliance позволяет проводить проверки на соответствие требованиям различных стандартов. При этом могут быть учтены как простые технические проверки (длина или возраст паролей), так и более сложные, например, отсутствие устаревшего программного обеспечения.
Режим Compliance предусматривает обработку результатов сканирования, выполненных в режимах PenTest и Audit, а также добавляет проверки, специфичные для данного режима.
В MaxPatrol 8 существует достаточно большой перечень встроенных стандартов, которые содержат в себе рекомендации компетентных организаций (Best Practice) и международные или государственные стандарты (требования регуляторов).



Также режим Compliance может быть дополнительно настроен с учетом требований корпоративных стандартов.
В системе MaxPatrol предусмотрено три механизма адаптации стандартов под корпоративные нужды:

  1. Добавление/удаление требований
  2. Переопределение параметров требований
  3. Создание пользовательских проверок

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

  1. Состояние службы
  2. Допуски к файлу
  3. Контрольную сумму файла
  4. Допуски к ключу реестра
  5. Наличие или отсутствие определенной строки в файле конфигурации
  6. Значение элемента реестра

Отчеты


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


В системе существуют несколько типов отчетов:

  1. Информация
  2. Дифференциальный
  3. Аналитический
  4. Сравнительный аналитический
  5. Динамический аналитический



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



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



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



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

Все отчеты могут быть сформированы в трех форматах:

  1. web-archive (MHT)
  2. PDF
  3. XML

Также стоит отметить, что для формата XML существует несколько типовых шаблонов, некоторые из которые открываются с помощью Excel. Также можно бесплатно запросить разработку кастомного шаблона под свои нужды.
Пример отчета по шаблону paf_by_host_report:



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



Например для вывода только уязвимостей, в которых присутствует идентификатор BDU необходимо осуществить фильтрацию по полю fstec со значением exists.



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

Аналитика в SD-WAN как она выглядит и зачем нужна?

09.04.2021 18:04:19 | Автор: admin
Привет, я работаю инженером в КРОК, где у нас есть своя SD-WAN-лаборатория. И когда заказчик приходит с вопросами вроде А вот у меня в сети сейчас всё работает так, а как это будет работать, если я захочу перейти на SD-WAN? И будет ли работать вообще? мы можем быстро собрать нужную схему, оттестировать и показать.

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

Расскажу, как эти решения работают в паре и как все настроить.




Принцип работы аналитики в SD-WAN


Работа SD-WAN-сети Cisco, напомню, определяется набором компонентов управления:
vManage управляет конфигурациями и собирает данные для мониторинга сети
vSmart рассылает маршрутную информацию и политики управления трафиком
vBond связывает все компоненты решения воедино



SD-WAN-роутеры получают маршрутную информацию по проприетарному протоколу OMP. В традиционной сети маршрут всегда выглядит как сеть 192.168.4.0/24 доступна через шлюз X. В случае с OMP всё несколько непривычно, например, вот так:



По сути вывод выше означает сеть 192.168.4.0/24 доступна через маршрутизатор с идентификатором 1.1.255.21, через два вида транспорта (MPLS и Private1), а передаваемый туда трафик необходимо упаковать в IPSEC. Все эти навороты необходимы для обеспечения SD-WAN-функционала.

Вдобавок к маршрутам, есть ещё и политики, определяющие выбор вида транспорта, например, Голосовой трафик передавать через MPLS, если MPLS не выдаёт нужное качество, перейти на LTE. Вот так:



Понять, куда пойдёт трафик конкретного приложения в конкретный момент времени становится сложно. Проверить что именно мы настроили можно с помощью инструмента симуляции потоков (Simulate Flows) в vManage



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

LiveAction устанавливается в виде сервера или кластера серверов, интегрируется с vManage по API, получает оттуда список маршрутизаторов и данные об их конфигурации, а потом опрашивает их по SNMP и получает данные по cFlowd (аналог NetFlow).

Интеграция


Связались с vManage через API:



Получили список устройств:



Разрешили на них доступ по SNMP (Стандартный Internet OID, добавляется в SNMP-шаблон в vManage):



Настроили отправку cFlowd с помощью политики vManage:



И получаем в LiveAction информацию о сети, например, вот в таком представлении:



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



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



Заглянуть поглубже


По клику на потоке трафика на диаграмме система умеет подтягивать с vManage политики, влияющие на него, опять же через API:



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



Из неё можно увидеть, что, например, трафик FTP-Data из VRF 2 передавался с меткой DSCP 0 через транспорт с названием Private1. В нижней части доступен бегунок, позволяющий определить интересующий нас промежуток времени и кнопка Play, чтобы посмотреть, как менялось поведение маршрутизатора во времени. Таким образом можно не только убедиться в том, что трафик того или иного приложения передавался так, как мы этого хотели, но и расследовать какие-то инциденты в работе сетевого приложения, имевшие место в прошлом. Например, если три дня назад с 12:00 до 12:30 у нас плохо работала видеоконференцсвязь, можно увидеть, что мы почему-то передавали её трафик не через тот канал и без нужной метки DSCP.

Можно вывести список потоков трафика между двумя площадками в виде таблицы:



А потом зайти в конкретный поток и посмотреть путь его прохождения вместе, скажем, с загрузкой интерфейсов, CPU и памяти устройств, участвовавших в передаче данных:



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

И ещё глубже


Помимо веб-интерфейса у LiveAction есть инженерная консоль. Она позволяет увидеть потоки трафика даже в пределах одного устройства. Вот так, к примеру, выглядит маршрутизатор Cisco CSR1000v:



Для каждого устройства можно смотреть так называемый Historical Playback то, как менялись потоки трафика во времени:



Дашборды


Для текущего мониторинга SD-WAN-сети в LiveAction доступны преднастроенные и кастомизируемые с помощью виджетов дашборды. Доступно около 30 различных виджетов, можно создавать свои. Вот пример готового дашборда для отслеживания производительности туннелей SD-WAN:



Для любого дашборда можно сделать постоянную ссылку и вывести его в контрастном виде на плазменную панель в NOC:



Чем полезен LiveAction на этапе тестирования


Наш опыт работы с решением Cisco SD-WAN показывает, что для его успешного тестирования и внедрения особенно важно понимать, какой именно трафик гуляет по сети, какими маршрутами и в каких объёмах. Традиционные сети фокусировались на connectivity соединить площадки A, B, C с ЦОД. Максимум, что можно было сделать для обеспечения качества работы конкретных приложений это шейпинг трафика и распределение его по очередям QoS.

Задачу connectivity, кстати, SD-WAN решает быстрее и проще традиционных сетей, но главная его фишка адаптация под требования сетевых приложений. Real-Time трафик мы можем перебрасывать с одного канала на другой, измеряя задержку и джиттер. Вот как это работает. На трафик, критичный к потерям применяем коррекцию ошибок или передаем его одновременно по двум каналам, а тяжёлый и некритичный трафик сгружаем на дешёвые каналы. Система аналитики как раз позволяет увидеть какие приложения передают трафик по сети и отнести их к тому или иному классу. Причём сделать это можно не только после внедрения SD-WAN, но и до, на этапе тестирования:

  1. Поставить LiveAction и собрать первичные данные с сети
  2. Выбрать для тестирования SD-WAN площадки, паттерн трафика на которых наиболее репрезентативен для текущего состояния сети
  3. Сделать предположения о том, какие политики повысят качество передачи данных
  4. Установить SD-WAN-маршрутизаторы и настроить в тестовом SD-WAN-сегменте политики, согласно предположению
  5. С помощью LiveAction проанализировать результаты работы и скорректировать политики. Увидеть самим и продемонстрировать заинтересованным лицам повышения качества передачи данных
  6. Получить готовую к развёртыванию на всю сеть конфигурацию SD-WAN.

Резюме. Польза от аналитики на уже работающей SD-WAN-сети


Тем, кто уже внедрил у себя решение SD-WAN от Cisco, система аналитики поможет:

  • Проследить за тем, как операторы связи соблюдают SLA и какое вообще качество выдают на своих каналах связи;
  • Увидеть проблемы в работе критичных приложений до того, как их пользователи начнут жаловаться;
  • Корректно подстраивать сеть под работу новых приложений, которые внедряются;
  • Быстрее находить ошибки в настройках, допущенные специалистами по эксплуатации сети;
  • Понять, насколько лучше стала использоваться доступная пропускная способность каналов связи, а значит и оценить эффективность миграции на SD-WAN в деньгах.

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

Общее введение в I2P

12.04.2021 22:14:50 | Автор: admin

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

Сейчас пойдет речь про I2P некоммерческую сингулярность сетевой приватности и анонимности, где никто кроме вас не знает куда и кто передает вашу информацию. Сеть I2P (расшифровывается как Invisible Internet Project, Проект невидимого интернета) это оверлейная децентрализованная одноранговая сеть. Оверлейная значит работает поверх других сетей, например, обычного интернета; децентрализованная распределенная, не имеющая единой точки отказа: упадет один узел, полсети, или во всей сети останется 3 пользователя I2P все равно будет функционировать. I2P является одноранговой сетью, так как все участники имеют равные права и возможности: каждый пользователь скрытой сети строит свои туннели через других участников и сам является потенциальным звеном в цепочке другого пользователя. При этом естественная сетевая активность никак не компрометирует абонента перед домашним провайдером или участниками скрытой сети.

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

Отличие традиционной сети от скрытой

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

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

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

Жители общаются через окна это обмен информацией по открытым каналам. Обратите внимание на наличие уполномоченного соседа (домик 2), который все слышит, и, как мы знаем, записывает. Проведем аналогию шифрования информации с тайным языком: даже если соседи говорят на незнакомом для шпиона языке, как минимум он знает, что определенные дома поддерживают контакт. В случае обычного интернета провайдер хранит информацию о сайтах, которые вы посещаете. Ему не обязательно знать, что именно вы писали на оппозиционном форуме. Один факт посещения подобного ресурса говорит о многом. У двух домов (4 и 5) имеются связанные подземные туннели они обмениваются сообщениями без крика на улицу. Шпион не видит, что эти люди общаются.

Важный термин, который понадобится в дальнейшем это DPI (deep packet inspection). На нашей иллюстрации этим понятием можно охарактеризовать навык шпиона понимать тайное значение услышанных слов. Например, люди будут кричать в окно слово труба перед тем, как начать общаться через скрытые туннели. Шпион быстро это поймет и станет рыскать возле домов, откуда донеслось кодовое слово. Это будет называться выявлением при помощи технологии DPI.

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

Базовое понимание криптографии

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

Симметричные алгоритмы более просты и за счет этого работают в разы быстрее: в них для шифрования и расшифровки информации используется один ключ. Слабое место такого подхода это передача ключа от одного пользователя другому. Если злоумышленник сможет перехватить ключ, он получит доступ к секретной информации. Фактором безопасности в симметричном шифровании (в частности AES распространенном алгоритме) является вектор инициализации (IV). Вектор инициализации критически важная составляющая, имитирующая первый блок информации. Так как при AES-шифровании каждый блок из 16 байт влияет на следующий блок, целостность информации критически важна.

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

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

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

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

Общие принципы работы I2P

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

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

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

Конечная точка наоборот является осмысленной сущностью либо сервером, либо клиентом, но ее реальное местоположение неизвестно. В качестве адресов конечных точек сети I2P используются идентификаторы, выведенные из открытого ключа подписи: хеш-сумма дает уникальную строку фиксированной длины, в конце которой для удобочитаемости подставляется псевдодоменная зона .b32.i2p так получается привычный внутрисетевой адрес. Для использования человекочитаемых доменов в зоне .i2p, например acetone.i2p, существуют бесплатные регистраторы, достаточно незамысловатые в использовании. Привязка домена происходит к полному адресу.

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

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

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

По умолчанию длина туннелей составляет 3 узла, но в зависимости от потребностей пользователя может составлять 1 транзитный узел или целых 8, и даже 0, тогда будет происходить прямое подключение к туннелю второй стороны. Как видим, администратор конечного ресурса имеет входной туннель в 4 узла. Получив запрос, веб-ресурс отсылает ответ во входной туннель пользователя через свой выходной туннель, т.е. по абсолютно другому пути. Смотря на схему, можно представить насколько сложно пользователю определить реальное местоположение собеседника. Учитывая, что каждые 10 минут происходит смена существующего туннеля на новый с новыми цифровыми подписями и ключами шифрования, деанонимизация кого-либо вовсе кажется фантастикой.

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

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

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

Помимо поиска лизсетов, белый шум генерируется зондированием сети: каждый роутер с небольшой периодичностью опрашивает случайный флудфил, получая от него в ответ три новых роутера (таким образом увеличивая собственный рисунок сети и находя новые флудфилы). Главным источником сетевого шума на роутере является транзитный трафик: он создает большую сетевую активность вне зависимости от конечных точек, расположенных на роутере. Также, будучи транзитным звеном, роутер подмешивает к трафику чужих туннелей полезную нагрузку трафик своих скрытых сервисов. Чем больше транзитного трафика на роутере, тем абсолютнее секретность его конечных точек: какие-либо действия на скрытом ресурсе, даже DDoS-атаку, нельзя сопоставить с сетевой активностью конкретно взятого сервера. Активный узел сети имеет в своей базе в среднем 5000 активных роутеров и принимает сотни, а то и тысячи абсолютно случайных транзитных подключений. Как говорится: попробуй проанализируй.

Отдельно отметим механизм выбора флудфила пользователем. Это важный вопрос, которому при разработке было уделено надлежащее внимание. Так как любой из флудфилов может содержать злонамеренный пользователь, стояла задача сделать его попытки анализа и прочих недобросовестных действий не применимыми к конкретному человеку. Флудфил для запроса выбирается следующим образом: берется целевой адрес и сегодняшняя дата. Из этой информации выводится хеш SHA256 получаются данные той же длины, что и обычный адрес. Затем осуществляется поиск флудфила в локальной базе роутера: используется тот, который при операции ИСКЛЮЧАЮЩЕЕ ИЛИ с блоком целевой адрес + дата даст наименьшее число. Подобный подход делает выбор узла для служебных запросов непредсказуемым и ежедневно изменяющимся для каждого адреса. В рамках этого материала упоминается случайный флудфил, однако знайте, что кроется за этими словами.

Недавно мы упомянули DPI исследование сетевых пакетов с целью выявления типа передаваемой информации. Упомянули не зря, потому что вы должны знать об этой технологии, а также о том, что весь трафик I2P устойчив перед анализом. Трафик сети зашифрован с самого низа, начиная с транспортных протоколов. В I2P используются: NTCP2, как крипто-аналог TCP, и SSU, как крипто-аналог UDP. I2P-роутер принимает сетевой трафик прикладных программ, обращающихся в скрытую сеть, и оборачивает привычные протоколы в их зашифрованные аналоги. После обработки в сетевых пакетах невозможно выявить что-либо вразумительное, потому что шифруется все, в том числе заголовки и размер. Размер пакетов скрывается паддингом, т.е. заполнением пакетов случайными данными до определенного размера. Информация о настоящем размере сетевого пакета передается в нем же в зашифрованном виде. При расшифровке на конечном устройстве примешанный мусор просто отбрасывается. Таким образом белый шум сети, т.е. практически бессмысленная для человека информация смешивается с пользовательской информацией и со стороны абсолютно от нее неотличима.

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

Дополняя и закрепляя все сказанное, подробно опишем процесс от первого запуска роутера до открытия веб-страницы. При первом запуске роутер не имеет каких-либо данных о сети, поэтому происходит обращение к случайному ресид-серверу, который отдает пользователю свою базу известных роутеров. Ресиды держат энтузиасты, их список имеется в свободном доступе. По сути дела, информация от ресида представляет собой zip-архив папки netDb, в которой каждый роутер хранит информацию о сети. Так как передача данных происходит через обычный интернет, во избежание подмены по пути, архивы подписываются цифровым ключом. Публичные ключи всех актуальных ресидов содержатся в самом I2P-роутере. Если по каким-то причинам мы не хотим обращаться к публичным ресид-серверам, можно использовать уже имеющиеся базы сети, например, с других наших роутеров. Обращение к ресиду не происходит, если в папке netDb имеется не менее 25 роутеров. После подключения к нескольким актуальным участникам начинается автоматическое непрерывное расширение рисунка сети.

Построение туннелей

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

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

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

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

Протокол I2P не предусматривает туннели длиннее 8 участников, однако на практике 4 транзитных узла считаются исчерпывающим решением.

В чесноке содержится информация для каждого участника:

  1. Номер туннеля на его роутере (случайные 4 байта).

  2. Адрес следующего роутера и номер туннеля на нем (почти как IP-адрес и номер порта в обычной сети).

  3. Ключ симметричного шифрования и ключ шифрования вектора инициализации (IV). Сам вектор инициализации содержится в начале сообщения.

  4. Роль узла в цепочке: конечный или промежуточный.

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

В зависимости от типа туннеля (входящий или исходящий), последнее звено принимает роль либо Endpoint, либо Gateway. Между участниками одного туннеля зашифрованная информация передается блоками по 1 килобайту это нынешний стандарт протокола. Задача последнего исходящего узла собрать информацию в более весомый пакет и переслать нужному пользователю на его входящий туннель. Работа роутера входящего туннеля обратная: он разделяет полученную информацию на блоки и отправляет ее на другой конец туннеля. Каждый туннель существует 10 минут. Во избежание разрыва соединения, стороны заранее создают новые туннели и обмениваются их лизсетами.

Модель взаимодействия

По умолчанию, i2pd предоставляет для прикладных программ SOCKS и HTTP прокси. Прокси это посредник. В нашем случае посредник для выхода в скрытую сеть. По умолчанию SOCKS5 доступен по адресу 127.0.0.1:4447, HTTP-прокси на порту 4444. Чтобы открыть веб-страницу, размещенную в сети I2P, в браузере необходимо установить соответствующие настройки. В Firefox прокси удобно настраивается через конфигурацию сети, либо через плагин FoxyProxy. Когда мы ввели адрес сайта в настроенном браузере, I2P-роутер получил наш запрос и начал работу.

Сначала происходит обращение к случайному флудфилу с запросом лизсета нужной точки назначения. Выходной прокси пользователя является конечной точкой, т.е. скрытой сущностью. Чтобы не раскрыть ее местоположение, обращение к флудфилу происходит через цепочку транзитных узлов. Также мы сообщаем ему данные нашего входного туннеля для ответа. Допустим, что флудфил не знает нужного адреса, поэтому вместо лизсета он возвращает три случайных флудфила из своей базы. Из полученных новых флудфилов случайным образом выбирается один, к которому роутер повторяет прежний запрос. В нашем примере второй флудфил дает нужный лизсет: всю необходимую информацию для связи с конечной точкой, которая включает в себя сведения о входных туннелях и ключах. Входных туннелей, как правило, не меньше трех. Выбрав случайный входной туннель получателя, роутер отправляет через него запрос на сервер. Если все прошло успешно и запрос дошел, сервер отсылает нам веб-страничку. В обычной сети это происходит по тому же пути, откуда пришел запрос, но в I2P дела обстоят совсем иначе. Свой лизсет для ответа конечная точка локального прокси отправляет вместе с нашим запросом. Достучавшись до сервера, мы сообщили ему адрес для ответа: чтобы веб-страница открылась в браузере, серверу необходимо через свой исходящий туннель отправить ответ в наш входящий. Приняв ответ через входящий туннель, наш роутер обрабатывает информацию и в нашем браузере открывается заветная страничка!

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

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

Практическое использование

Область применения I2P обширна и не ограничивается только веб-сайтами. Вы можете размещать в I2P любые веб-ресурсы: форумы, доски объявлений, гит-репозитории, блоги и персональные одностраничники. Вполне реально организовать даже сетевые пошаговые игры, не требующие низкой задержки при передаче пакетов, например, шахматы или карты. Также найти применение I2P можно в построении выходных туннелей из неопределенного места в глобальную сеть, для полноты картины размещая выходные прокси на анонимно оплаченных серверах. Организуя ssh-доступ к арендуемой машине через I2P, вам всего лишь единожды потребуется зайти на сервер посредством других сетей, чтобы установить i2pd и сконфигурировать туннель, который будет принимать подключения. Единственное ограничение фантазий скорость передачи данных внутри сети. Надо заметить, что от года к году скорость становится все ближе к привычным показателям обычного интернета благодаря оптимизации программного кода и общему росту количества узлов.

Разработка протокола

се это интересно, но напрашивается закономерный вопрос: кто за этим стоит? Судя по сложности протокола, можно подумать, что это как и в случае с сетью Tor что-то связанное со спецслужбами и государственным финансированием, но нет. I2P полностью свободный проект, рожденный и поддерживаемый энтузиастами по сей день. Разработка I2P на языке программирования Java была начата неким JRANDOM. Первый релиз состоялся в 2003 году. Несколько лет спустя JRANDOM отошел от разработки, не оставив о себе вестей, а его место занял пользователь с никнеймом zzz американец, предположительно из района Нью-Йорка, который на момент выхода статьи все еще курирует разработку. Так прошло 10 лет: сообщество росло, I2P-роутер писали как могли, также в это время была написана официальная документация. При поисковом запросе I2P первая ссылка, как правило, ведет нас на сайт geti2p.net официальную страницу того самого I2P-роутера на Java. Но история на этом не заканчивается.

В 2013 году русскоговорящий пользователь orignal с французским никнеймом, судя по всему большой любитель пиратской литературы, обнаружил в онлайн-библиотеке Флибуста сообщение о недоступности скачивания книг через клирнет, т.е. обычный интернет. Вместо этого пользователям предлагалось использовать I2P. Однако Ориньяль, как он говорит, не нашел существующей нормальной реализации протокола, а только некое поделие на джаве. Несмотря на то, что разработка этого поделия уже велась десять лет, orignal, как искушенный программист, ее не оценил. На тот момент в сети лежало еще с десяток попыток написать i2p-роутер на языках C и C++, в которых не было сделано совсем ничего. Что-то было в продукте под названием i2pcpp, но до чего-то годного тоже было далеко. И что делает orignal: за три месяца он написал на С++ рабочую программу, пригодную для скачивания книг с Флибусты, и на этом уже хотел остановиться. На дворе был июль 2013 года. Однако некий человек уговорил его изложить свой опыт в статье на Хабре. Дело в том, что orignal пришлось вникать в дебри джава-кода, т.к. официальная документация оказалась не полноценной и имела разрозненную структуру. После публикации первой статьи что-то случилось: наверное, заметив интерес общественности, и почувствовав некоторый азарт, присущий всем программистам, писателям и композиторам, orignal взялся за написание полноценного клиента сети. Дебютный релиз 0.1.0 состоялся 17 октября 2014 года. Для его реализации orignal пришлось собственноручно реализовать на С++ несколько криптографических функций (которые с расширением библиотеки OpenSSL в дальнейшем были заменены на библиотечные). Новый клиент получил название i2pd Invisible Internet Protocol Daemon. После первого релиза к orignal присоединились энтузиасты, которые также начали работу над совершенствованием нового I2P-роутера. Сообщество разработчиков получило имя PurpleI2P.

В первые годы к инициативе i2pd было проявлено много скептицизма сторонних наблюдателей: в PurpleI2P искали руку Кремля, закладки от ФСБ, следы масонов и рептилоидов. Само название Purple в апогее наркотического прихода отдельные индивидуумы сводили к флагу Российской Федерации: смешение красного, синего и белого цветов дает тот самый фиолетовый. Однако orignal, ведущий разработчик i2pd, пояснил, что название PurpleI2P не содержит великой тайны: название было придумано после кружки английского эля с оглядкой на королевскую корону Британской империи. Наверное, это можно считать отсылкой к лидерству i2pd перед изначальным клиентом на Java.

Ориньяль по сей день продолжает публиковать русскоязычные статьи про I2P, рассказывая широким массам о развитии протокола. В команде программистов-энтузиастов появляются новые никнеймы, другие наоборот уходят в перманентный оффлайн. В основном планирование разработки происходит в IRC, в сети ILITA. Русскоязычное сообщество достаточно активно и в IRC на самом деле обсуждается все: от новых фич в I2Pd до климата в Африке и новых мемов.

Каждая версия роутера сменяется следующей, сообщество живет, разработчики постоянно что-то кодят. Чтобы не возникало вопросов что же меняется, если и так все работает хорошо, вкратце скажем о развитии протокола: мало ли параноики решат, что протокол не меняется, а оттачивается только бэкдор от силовых структур. В начале пути, ветки джава-роутера и роутера на C++ развивались не синхронно, согласование нюансов с соседним лагерем происходило с некоторой задержкой. Сейчас разработчики, не смотря на расхождения во взглядах, вместе реализуют значимые решения. Самое заметное изменение за последние годы: переход с транспортного протокола NTCP на NTCP2. Этот протокол является адаптированным крипто-аналогом привычного TCP и используется повсеместно: начиная открытием веб-страницы и заканчивая загрузкой торрента. Главное различие двух протоколов заключается в использовании алгоритма шифрования: в старом NTCP используется Диффи-Хеллман, очень медленный и жадный до системных ресурсов, а в NTCP2 алгоритм на основе эллиптических кривых тренд в сфере скоростных криптосистем, превосходящий по криптостойкости и производительности своего предшественника. Это изменение сделало I2P-роутеры более легковесными и полностью пригодными для использования на малых устройствах вроде одноплатных компьютеров и смартфонов (по крайней мере i2pd точно). Замена алгоритма согласования ключей Диффи-Хеллмана новыми решениями происходит и в других частях протокола. Для зрителей, понимающих в криптографии, особо заметим, что сеть I2P постепенно переходит на криптографические протоколы семейства Noise, что тоже является хорошим решением для производительности, анонимности и надежности. I2P-роутеры, как и все программы на свете, подвержены недочетам вроде багов и неполноценной реализации каких-то функций, что влечет дальнейшее развитие, исправление, и новые релизы. Если интересны детали, более подробную информацию можно найти через поисковик и в чатах сообщества.

Почему стоит использовать i2pd на C++ вместо роутера на Джаве? Ответ прост: потому что i2pd архитектурно превосходит поделие на Джаве. I2P кладезь различной криптографии, реализация которой на Джаве была бы жутко тормозной. Потому в Джава-роутере используются библиотеки, написанные на языке С. И все бы ничего, но каждый вызов этих библиотек это большие накладные расходы. И как бы разработчики не старались, а тормоза есть. Не такие большие, как могли бы быть, но до скорости нативной (т.е. встроенной) криптографии из i2pd им очень далеко. Также весь трафик джава-роутера локально проходит через фактически лишний протокол I2CP, что, не вникая в детали, сильно портит качество работы, в то время как в i2pd этот протокол существует исключительно для совместимости с приложениями на джава-роутерах. Для пытливых умов можно сказать более подробно: главная проблема I2CP в том, что через него сессии TCP (которые называются стримами) не могут контролировать доступ к туннелям и лизсетам. Также I2CP лишает пользователей джава-роутера нормальной поддержки UDP-туннелей: их поддержка обеспечивается отдельным приложением streamr. Как уже знает бывалый зритель, протокол UDP используется для быстрой потоковой передачи данных, например, голос собеседника при онлайн-звонке. Сложно переоценить качественную поддержку этого протокола. В I2Pd UDP-туннели поддерживаются без каких-либо проблем и дополнительных программных наслоений.

Помимо более быстрой работы i2pd, этот роутер также потребляет меньше системных ресурсов в сравнении с джаво-версией, т.к. программа на C++ напрямую взаимодействует с системой, в отличие от Джавы, где все крутится внутри виртуальной машины дополнительной прослойке между операционной системой и программным обеспечением. Дальше только больше: исследуя просторы внутрисетевых площадок, вы не однократно наткнетесь на описание различнейшних проблем с производительностью сети I2P, где источником проблем будет не протокол, а его кривая реализация в популярном клиенте. В рамках тестов со скоростными серверами и сетью, полностью исключающей наличие джава-роутеров, удалось достичь скорости чуть меньше мегабита в секунду. Сегодня такой показатель на фоне средних нескольких десятков килобит кажется невероятным! В видео, по тексту которого составлена эта статья, приведен скриншот недавней переписки двух ведущих разработчиков: orignal и zzz. В то время, как через i2pd в тестовом режиме гоняют видеостримы, джава-роутер не позволяет слушать даже онлайн-радио. Чтобы увеличить среднюю скорость сети I2P нужно: во-первых, каждому держать свой узел включенным максимально доступное время, во-вторых, это должен быть узел сети, работающий на i2pd.

Сравнение с другими сетями

Если вы имеете представление о сети Tor и о меш-сетях вроде Yggdrasil Network, после всего сказанного об I2P, не имеет большого смысла говорить, чем они различаются. Это абсолютно разные концепции. Однако для начинающих читателей приведем несколько основных пунктов.

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

Про Yggdrasil и аналогичные меш-сети: подобные разработки ориентируются на легкость развертки, скорость передачи данных и самоорганизацию. Трафик внутри Yggdrasil искусственно не путается, сеть имеет простой и интуитивно понятный рисунок. Пользователи имеют устойчивые двунаправленные зашифрованные туннели, и чем короче тем лучше. Как видно, у I2P с Тором совсем мало общего, а с распространенными меш-сетями и того меньше. Разве что I2P может свободно работать через Yggdrasil (поддержка в i2pd с версии 2.36.0). Через Тор тоже, кстати говоря. На этом, пожалуй, все.

Послесловие

Последнее по теме I2P и скрытых сетей в целом: этично ли это? Устоявшееся общественное мнение таково, что любые попытки анонимизации расцениваются, как преступный умысел. Например, в скрытых сетях люди могут размещать то, что будет заблокировано в цензурируемой сети. Это конечно бесит цензоров. Не умолчим и про криминал, который может найти себе пристанище в I2P, все это очевидно. Но что об этом думают разработчики I2P, у которых также могут быть семьи, дети и тяга к справедливости, и как считает большинство криптоанархистов? Если кратко: кухонным ножом можно нарезать хлеб, а можно причинить вред, но из-за возможного злоупотребления кухонные ножи не запрещают. Так же и тут: нельзя бороться с технологиями приватности под предлогом борьбы с преступностью, так как самое распространенное преступление сегодня это нарушение гражданских прав и свобод: тотальный контроль и продажа личных данных.

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


Текст статьи и иллюстрации являются адаптированными исходниками видео про I2P: на русском и английском. Материал в формате PDF размещен на i2pd.website. Оригинальная статья опубликована в блоге дата-центра ITSOFT на Хабре.

Подробнее..

Обеспечение сетевой безопасности совместно с брокерами сетевых пакетов. Часть вторая. Активные средства безопасности

13.04.2021 20:10:28 | Автор: admin

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

Активные средства безопасности

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

Среди наиболее популярных активных средств информационной безопасности остановимся на IPS, NGFW, SWG, AMP, DLP и Anti-DDoS, а также рассмотрим способы их развёртывания на базе Bypass и брокеров сетевых пакетов для обеспечения гарантированной безопасности сети.

Системы предотвращения вторжений (IPS)

Системы предотвращения вторжений (Intrusion Prevention Systems - IPS) это программные и аппаратные средства, предназначенные для обнаружения и предотвращения попыток несанкционированного доступа к конфиденциальным данным, повышения привилегий, использования уязвимостей программного обеспечения и вывода из строя компьютерных систем. Такие попытки вторжений осуществляются главным образом через Интернет или локальную сеть, могут иметь форму атак хакеров/инсайдеров или же быть результатом действий вредоносных программ.

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

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

В России требования к системам обнаружения вторжений (под понятием СОВ подразумеваются как пассивные IDS системы, так и активные IPS системы) появились еще в 2011 году, тогда ФСТЭК России поделила СОВ на 6 классов защиты. Отличия между классами заключаются в уровне информационных систем и непосредственно информации, которая подлежит обработке (персональные данные, конфиденциальная информация, государственная тайна). Соответствие требованиям регулятора является важным фактором при выборе СОВ, в то же время это положительно сказывается на развитии отечественного рынка IPS/IDS решений.

В пространстве IPS решений представлены продукты следующих производителей: Positive Technologies, Код Безопасности, Smart-Soft, Info Watch, Инфотекс, Stonesoft, Trend Micro, Fortinet, Cisco, HP, IBM, Juniper, McAfee, Sourcefire, Stonesoft, Trend Micro, Check Point, Palo Аlto Networks.

Межсетевые экраны нового поколения (NGFW)

Межсетевые экраны нового поколения (Next-Generation Firewall - NGFW) это эволюция типовых межсетевых экранов с возможностью отслеживания состояния соединений. Поскольку всё большее число компаний сейчас используют онлайн-приложения и службы SaaS, то классический контроль портов и протоколов уже недостаточен для обеспечения эффективной сетевой безопасности. В отличие от предыдущего поколения, в новых устройствах добавлена тесная интеграция дополнительных возможностей, таких как встроенная глубокая проверка пакетов (DPI), предотвращение вторжений (IPS) и проверка трафика на уровне приложений (Web Application Firewall). Некоторые NGFW также включают проверку зашифрованного трафика TLS/SSL, фильтрацию веб-сайтов, управление пропускной способностью, QoS, антивирусную проверку и интеграцию со сторонними системами управления идентификацией (LDAP, RADIUS и Active Directory). Решения NGFW в скором времени заменят традиционные межсетевые экраны, предотвращая вторжения и контролируя приложения как по периметру, так и внутри сети.

Производители NGFW решений: UserGate, Континент, Huawei, Check Point, Сisco, Fortinet, McAfee, Palo Alto Networks и Sourcefire.

Шлюзы информационной безопасности (SWG)

Прокси-серверы с функциями информационной безопасности (Security Web Gateway SWG), также известные как веб-фильтры это программно-аппаратные комплексы (ПО + сервер), разработанные и оптимизированные для соблюдения политик веб-безопасности компании и контроля доступа пользователей к веб-сайтам. Веб-сайты, которые содержат вредоносное ПО или неприемлемый контент (например, порнографию или азартные игры), блокируются на SWG, тем самым повышая производительность труда сотрудников, ограничивая ответственность компании и защищая компьютерные устройства пользователей от вреда.

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

Производители SWG решений: Ростелеком-Солар, Smart-Soft, UserGate, ESET, Kaspersky, Sophos, TRENDmicro, Huawei, Blue Coat, Cisco, McAfee, Trustwave и Websense.

Advanced malware protection (AMP)

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

Для защиты от этих угроз существует категория решений сетевой безопасности - AMP (Advanced Malware Protection). Основная задача AMP проверка файла, пересылаемого через сетевое устройство и/или записываемого на конечное оборудование, на наличие вредоносного кода. Система AMP осуществляет ретроспективный анализ и обеспечивает защиту не только до момента атаки или во время атаки, но и после того, как атака прошла. Кроме того, это решение позволяет отследить все пути распространения файла и может заблокировать файл на уровне сети.

Производители AMP решений: Kaspersky, Malwarebytes, Cisco, Damballa, FireEye и Palo Alto Networks.

Системы предотвращения утечки данных (DLP)

Системы предотвращения утечки данных (Data Loss Prevention или Data Leakage Prevention - DLP) это программно-аппаратные комплексы (ПО + сервер), которые предназначены для обнаружения и предотвращения потенциальных нарушений конфиденциальности данных и личной информации (номера кредитных карт, номера телефонов, данные паспорта и т. д.) путём мониторинга данных в нескольких состояниях:

  • при использовании (Data-inUse) на рабочем месте пользователя

  • при передаче (Data-inMotion) в сети компании

  • при хранении (Data-atRest) на серверах и рабочих станциях компании

Производители DLP решений: InfoWatch, Инфосистемы Джет, SmartLine Inc, Гарда Технологии, Zecurion, Ростелеком-Солар, Falcongaze, Атом Безопастность, ESET, SearchInform, CoSoSys, Blue Coat, Check Point, Cisco (IronPort), Fidelis, McAfee, RSA, Verdasys, Symantec, Websense.

Системы предотвращения распределённого отказа в обслуживании (DDoS Protection, Anti-DDoS)

Системы предотвращения распределённого отказа в обслуживании (Distributed Denial of Service (DDoS) Protection или Anti-DDoS) это специализированные программно-аппаратные и программные средства, предназначенные для защиты веб-серверов/сайтов компании от распределённых атак типа Отказ в обслуживании.

Атака типа отказ в обслуживании (DoS) - это попытка одного компьютера сделать другой компьютер недоступным для его предполагаемых пользователей путём забивания его полосы пропускания и/или вычислительных ресурсов паразитным трафиком, часто через поток пакетов SYN или ICMP. Распределённый отказ в обслуживании (DDoS) это DoS-атака, инициируемая ботнетом (совокупностью компьютеров, называемых ботами, которые заражены зомби-агентами или троянами), обычно используется для атак на целевые веб-сайты. Все боты в данном ботнете запрограммированы на выполнение действий в точно согласованное время, как это предписано центральной системой управления и контроля (Сommand and Сontrol - С&C), управляемой преступником.

На предприятиях системы Anti-DDoS помогают выявлять и предотвращать DDoS-атаки путём использования проприетарных алгоритмов и оценки механизмов защиты.

Средства безопасности в этой области производят компании: DDOS-GUARD, СТОРМ СИСТЕМС, Variti, Гарда Технологии, Kaspersky, Inoventica Technologies, Qrator Labs, Akamai Technologies, CloudFlare, Imperva, Sucuri, F5 Networks, Arbor Networks, Cisco, Corero и VeriSign.

Типичные проблемы развёртывания систем сетевой безопасности

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

Кейс 1 Развёртывание нескольких копий активных средств безопасности для обработки трафика в современных высоконагруженных сетях 40G/100G

В настоящее время широко распространяются стандарты 40G/100G. Производители активных средств безопасности стараются не отставать и предлагают высокопроизводительные инструменты для обеспечения защиты сетей данных стандартов. К сожалению, далеко не все предлагаемые современные инструменты могут обработать трафик высоконагруженных сетей стандартов 40G/100G. А те немногие, которые способны, имеют высокую стоимость и делают это с ограничениями.

Задача: Сеть компании построена по стандарту 40G. Существующая система NGFW имеет интерфейсы 40G, но её производительности хватает только при нагрузке в сети до 30%. При повышении нагрузки в сети установленная NGFW уже не справляется и начинает терять трафик. Необходимо внедрить решение, которое будет обеспечивать работоспособность сети с использованием существующей активной системы NGFW и минимально возможными инвестициями.

Решение: Для решения данной задачи необходимы: брокер сетевых пакетов и дополнительная единица NGFW (в некоторых случаях даже менее производительная). Существующую и вновь приобретённую NGFW нужно подключить к брокеру сетевых пакетов, который, в свою очередь, подключить через Bypass к сети компании. Пакетный брокер будет балансировать получаемый из cети трафик на входы NGFW с сохранением целостности сессий и агрегировать трафик с выходов NGFW для дальнейшей передачи. Таким образом, нагрузка будет равномерно распределяться на две системы NGFW, что позволит поддерживать необходимую пропускную способность и быстродействие сети компании.

Кейс 2 Безопасное развёртывание нескольких активных средств безопасности последовательно

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

Задача: В компании, в сетевой инфраструктуре которой развёрнута система межсетевого экрана, планируется внедрить активные системы IPS и Anti-DDoS. При этом необходимо обеспечить бесперебойность работы сети при выходе из строя средств ИБ.

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

Кейс 3 Поддержка отказоустойчивых сетевых конфигураций и активных систем информационной безопасности

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

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

Задача: В компании поставлена задача по организации отказоустойчивой конфигурации сети с активными средствами ИБ. Необходимо обеспечить бесперебойное функционирование системы ИБ в случае отказа группы систем и/или одного из элементов группы. Построенный сегмент активных средств ИБ не должен влиять на работоспособность общей сетевой инфраструктуры компании. Также требуется предусмотреть возможность дальнейшей масштабируемости и повышения производительности активных систем ИБ без изменения общей конфигурации сети.

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


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

Резюмируя, хочется выделить преимущества применения брокеров сетевых пакетов:

  • Простота интеграции, надёжность и отказоустойчивость сети

  • Масштабируемость активных средств контроля трафика без усложнения топологии сети

  • Постоянный мониторинг доступности каждого активного устройства ИБ и различные сценарии реагирования на аварии

  • Один Bypass для нескольких активных средств

  • Вариативность пропускания трафика через активные системы ИБ

  • Простота внедрения новых решений в инфраструктуру

Подробнее..

Как замедлили Twitter? Что такое DPI? Разбор

13.04.2021 20:10:28 | Автор: admin
Наверное, вы слышали, что на этой неделе стартовало так называемое замедление Twitter.

С 10 марта 100% мобильного и 50% стационарного трафика Twitter в России официально замедлены. Все это стало возможным благодаря технологии DPI. Мы решили разобраться, как это работает и как устроен механизм замедления.

Почему это важно? Можно предположить, что Twitter это репетиция перед замедлением/блокировкой Facebook, а потом YouTube.

Поэтому сегодня разберемся, что такое DPI, как работает и какие у него возможности.

Будет ли у нас как в Китае? И как от этого защититься?



Начнем издалека, в ноябре 2019 года вступил в силу закон, по которому операторы связи должны были начать установку специальных технических средств противодействия угрозам (ТСПУ).

Позднее выяснилось, что за аббревиатурой ТСПУ скрывалась известная любому сисадмину технология DPI Deep Packet Inspection или Глубокий анализ пакетов. Не путать с плотностью пикселей на дюйм это тоже DPI, но Dots Per Inch.



И вот она дошла до тестирования в масштабах страны. На примере твиттера.

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

Как работает DPI?


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

Так вот DPI умеет просматривать данные разного уровня и сами пакеты. И оно может понять не только откуда и куда идет трафик, но и что это за трафик конкретно: текстовое сообщение, картинки или видео, голосовой трафик Skype или может даже торрент.А дальше сделать с ним, то что хочется:
  • Приоритизировать
  • Ограничить по скорости
  • Перенаправить
  • Заблокировать
  • Ну или, конечно, передать получателю.

Кстати насколько именно замедляется Twitter сейчас непонятно. Лично я проблем пока не наблюдаю. Но почему так мы еще поговорим.



Это сильно упрощает задачи по блокировке сайтов и сервисов. Почему?

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

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

Но как вся эта вундер-технология работает?


Есть две вещи, которые анализирует DPI: сами пакеты информации, причем как метаданные и заголовки, так и внутреннее содержимое. И второе это так сказать поведение пакетов данных.



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



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





С зашифрованным трафиком сложнее.Тут инфы намного меньше. Система увидит, какой порт используется (это дает намек на тип приложения), IP-адреса, тип шифрования. А все остальное зашифровано, даже URL-адрес.

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



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



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

Кроме этого DPI смотрит на частоту и размер пакетов, потому что разные приложения тоже имеют свои особенности. Например, торренты очень своеобразно отправляют пакеты.

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

Как можно использовать DPI?


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

Но если вы Роскомнадзор, у вас вероятно другие приоритеты.

Но вопрос в том, кто будет определять, какой трафик приоритетный а какой нет, остается открытым. Например, при помощи DPI вполне можно продвигать одни сервисы и замедлять другие: отдавая приоритеты отечественным аналогам. К примеру, можно замедлить YouTube и при этом ускорить Rutube.В общем, вариантов для фантазии масса.

Архитектура или почему все снова пошло не по плану?


Но если существует такой мощный инструмент, почему же с Twitter по-прежнему все весьма неплохо?

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

Вы обратили внимание, что анонсировано: Замедление для 100% мобильного трафика, а для стационарного только 50%? Распространять опасный по мнению РКН контент через компы не так опасно, что ли? Нет.

Просто внедрили технологию далеко не все. С тусовкой мобильных операторов удалось договориться. А маленьких местных провайдеров интернета огромное количество. Но это полбеды.

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

CDN Content Delivery Network сеть доставки контента.




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

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



Чтобы наверняка ограничить доступ к интернет-сервису, использующему CDN, требуется ограничить доступ практически ко всей сети CDN-провайдера, у которого могут быть десятки тысяч серверов по всему миру. Иными словами, чтобы заблокировать Twitter, надо заблокировать CDN-провайдера, а от этого снова ляжет половина интернета.

И я даже не буду останавливаться на курьезной ситуации, когда ограничивают полосу пропускания не только для домена twitter.com, но и для всех доменов, в названии которых есть сочетание t.co это короткий домен, принадлежащий твиттеру. Таким образом, ограничениям подвергались и другие сайты, к примеру: reddit.com, microsoft.com и даже сайт Russia Today rt.com. Предположительно по этой же причине прилегли сервера ростелекома.

Впрочем, со временем это вроде починили. Интересно другое.

Ограничения DPI. Что делать?




Но самое любопытное: поскольку это своего рода гадание, нет единого стандарта DPI. У каждого поставщика оборудования свои алгоритмы и технологии.

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



Ну и наконец, DPI достаточно легко обойти при помощи VPN, так как VPN шифрует весь трафик и подменяет ваш IP-адрес, то и DPI для него не страшен.



Но ожидается и более простое решение. Протоколы шифрования тоже не стоят на месте. И с приходом TLS 1.3 и DNSSEC еще больше данных приложения и пользователя будут скрыты от DPI. И понять, что в системе за пакет будет еще сложнее. Такие дела.
Подробнее..

30 предстоящих вебинаров Huawei выбираем, критикуем, оставляем заявки

05.04.2021 14:09:20 | Автор: admin
С марта и до конца 2020 года мы в Huawei Russia проводили вебинары, иной раз не по одному в неделю. Сперва смотрели на этот формат как на вынужденную меру (нам нравились наши офлайн-ивенты, и тусовки после них тоже!), потом вошли во вкус. В 2021-м у нас намечено ещё больше трансляций по куче технологий и продуктов. Сейчас мы вас оперативно сориентируем, чего и когда ждать.



Мы уже составили распорядок вебинаров на следующие пять месяцев и регулярно апдейтим его. Круг тем широк (слишком даже широк, я бы сузил, проворчит кто-нибудь вслед Достоевскому, но мы бы, признаться, даже расширили бы). Перечислять все не станем: проще посмотреть по ссылке. Но, пожалуй, больше всего в этом году у нас будет контента про видеорешения, средства сетевой виртуализации, тонкости работы с высокопроизводительными СХД и управление современными ЦОДами. И про все новые продукты компании, разумеется, тоже в том числе только готовящиеся к релизу.

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

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

  • 8 апреля: Huawei IdeaHub, разрушитель мостов в видеосвязи, рассказываем и трогаем, ведущий специалист по видеорешениям Huawei Егор Купцов;
  • 14 апреля: Новое поколение распределенных систем хранения данных OceanStor Pacific, ведущий менеджер по продукту Huawei Дмитрий Сивокоз;
  • 13 мая: Двойная виртуализация удалённое тестирование Dorado V6 на базе Huawei, ведущий системный архитектор (HCIE-Storage) Treolan Алексей Козьмин.


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

Предварительное расписание вебинаров сформировано у нас до августа-2021 включительно, чтобы вы могли планировать свои контент-заплывы заранее. Ну да на то расписание и предварительное, что ничто не мешает нам добавить трансляцию (и не одну). Если вас живо занимает какое-то направление, в котором действует Huawei, или конкретная наша технология, или продукт, но в списке не нашлось ничего похожего, пишите, пожалуйста, в комментах: что именно и в каких аспектах разобрать. Будет интерес к теме запросто устроим и вебинар по ней. Stay tuned!
Подробнее..

SRAPS (cлужба безопасного перенаправления и настройки)

07.04.2021 10:06:45 | Автор: admin

Здравствуйте, наши читатели.
Наверняка у каждого кто занимается телекоммуникациями и работает с оконечными устройствами, хотя бы раз, а скорее всего и не один, возникала задача преднастройки множества аппаратов. Если вы пользуетесь устройствами Snom и имеете доступ в интернет из сети где будут находиться телефоны, в этом нет ничего сложного!
Добро пожаловать в обзор службы безопасного перенаправления и настройки, или просто SRAPS.

Сервис доступен после бесплатной регистрации по ссылке: https://sraps.snom.com/

Функционал

Главный вопрос любого обзора: зачем нужно то или иное решение, давайте начнем с него.
SRAPS позволяет вам:

  • Безопасно направлять устройства на ваш локальный или удаленный сервер Autoprovision.

  • Удаленно настраивать устройства.

  • Удаленно обновлять программное обеспечение устройств Snom.

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

Преимуществ у такого решения множество главное из которых состоит в том, что вы можете администрировать и обновлять устройства, вне зависимости от вашего и их местоположения. При этом интерфейс платформы позволяет делать это просто, не углубляясь в процесс написания текстовых конфигурационных файлов, и безопасно, благодаря SHA-2 шифрованию. Добавлять устройства в систему можно заранее, зная их MAC-адрес, также заранее можно подготовить шаблон настроек, который телефоны подхватят при подключении. Физически сервера системы расположены во Франкфурте-на-Майне, система соответствует как строгому немецкому закону о защите данных, так и Европейскому общему регламенту о защите данных (GDPR).
Отдельным плюсом можно выделить тот момент, что система бесплатна и доступна для всех партнеров и клиентов Snom.
Основной минус такой системы связан с методом ее реализации. Поскольку система развернута в облаке, вам необходимо чтобы ваши устройства имели доступ в интернет для взаимодействия с ней.

Как это работает?

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

Направление устройств на локальный или удаленный сервер Autoprovision

Алгоритм работы телефона с нашей системой, следующий:
Любой телефон Snom при включении направляет запрос на сервер SRAPS для уточнения адреса сервера настроек. Каких-либо действий с аппаратом для этого производить не требуется, запрос отправляется в любом случае после загрузки устройства.

В ответ телефон получает ссылку с адресом сервера Autoprovision. Для вашего аппарата в этом случае неважно расположение самого сервера настроек. Находится ли ваш сервер относительно телефона локально или удаленно, получив адрес ссылки телефон направится по адресу, на который направил его SRAPS.
С сервера настроек в этом случае телефон загружает xml-файл с параметрами. Файл вам необходимо заранее выгрузить с настроенного телефона или написать вручную и разместить на сервере, отдельно для каждого устройства.

Удаленная настройка устройств

Второй вариант использования создание конфигурации для телефона непосредственно в системе SRAPS. Процесс добавления конкретных параметров через интерфейс SRAPS мы рассмотрим чуть позже в этом же обзоре. Принципиальное отличие удаленной настройки от простого перенаправления состоит в меньшем количестве шагов подготовки, у нас нет необходимости разворачивать http(s) сервер в своей сети или вне ее. Конфигурация наших устройств будет храниться непосредственно в системе SRAPS. Минус такого метода состоит в том же, в чем и минус самой платформы. Все ваши настройки хранятся удаленно и, если у вас нет доступа в интернет из сети с телефонами или из VLAN-а где они находятся, вам либо придется его предоставить, либо отказаться от использования системы. Это актуально в первую очередь для полностью закрытых сетей, в других случаях принципиальных проблем не возникает.

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

Удаленное обновление программного обеспечения

Одно из самых часто выполняемых действий при администрировании парка аппаратов обновление программного обеспечения. В обычных условиях для обновления ПО большого количества телефонов необходимо решить 2 задачи:

  • Развернуть сервер и разместить на нем ПО

  • Направить аппараты на данный сервер за файлами

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

Интерфейс

Система встречает нас стандартной формой входа. Вводим логин и пароль и начинаем рассматривать разделы интерфейса:

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

Управление конечной точкой

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

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

Раздел Профили автонастройки позволяет создавать шаблоны конфигурации для настройки ваших аппаратов.Интерфейс создания шаблона выглядит так:

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

Настройки телефона

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

Настройки

Этот раздел отвечает за параметры самой системы и вашей учетной записи в ней.

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

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

Система

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

Последний по счету, но не по значимости раздел, API

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

Второй подраздел является ссылкой на подробную документацию по использованию API данной системы, с которой мы, естественно, рекомендуем вам познакомиться.

Итог

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

Подробнее..

Самое крупное в истории бесконечное ограбление и преступление против человечества, о котором все знают, но все молчат

08.04.2021 06:13:50 | Автор: admin
Все мы знаем о больших ограблениях, об очень больших ограблениях. Но какое из известных ограблений не взять в прошлом, там везде объемы грабежа конечны. Но вот пришла эпоха компьютеров и интернета, и произошло (началось) самое колоссальное ограбление, которое длится уже многие годы, и потенциально бесконечно. Многие знают об этом ограблении, которое бесконечно по масштабам, а по циничности на уровне преступления против человечности, но почти никто не придает ему никакого значения.
Много негодуют, если происходит ограбление на миллиарды, да даже на миллионы или просто даже угон домена, как это плохо Но это всего лишь 1 случай 1 домена. Но совершенно никто десятилетиями не негодует, даже не переживает, что угнаны бесконечное множество доменов, даже еще тех которые не придуманы.
Вот любой из вас, может придумать доменное имя. Что он делает заходит к регистратору! (обратите внимание регистратору, не к богу, не к дьяволу, не к всевышнему, а к регистратору). И что он видит человек вводит только что придуманное им (свое творение, то что можно сказать авторство) ну пусть это будет (kasdfuirewkdsbdks14783487.ru), и опа, что он видит чаще всего этот домен свободен, хорошо....но он НАША собственность, вы можете его купить за 100-200-100000. И как бы бесконечно много вы не придумали имен любое из них уже будет собственностью каких то непонятных элементов, которые предложат вам их купить.
А с какого перепуга он их? Уверен, что они до этой секунды даже не знали и ни разу не видели и не произносили этот набор букв, но он уже их собственность.
Вот это реальный УГОН доменов. У людей угнали всё бесконечное множество доменов какое может быть. Это самое большое ограбление в истории бесконечное множество сворованного, даже еще того, что не создано. Т е это тот случай, когда своровано даже не созданное еще и сразу в бесконечном объеме.
А кто они такие? С чего это вдруг регистраторы (от слова регистрировать) становятся собственниками по умолчанию? Да и даже с чего они вдруг регистраторы, с какого перепуга, и почему они. Почему само это право монополизировано.
А мы готовы охать по угону одного домена или миллиарда долларов, писать статьи на 100 страниц слёзные, но не замечаем и ни одного слова, об угоне бесконечного.
С чего это люди должны покупать то, что только что придумали.
Нужна уже давно децентрализованная система регистрации доменов ну и IPv6 (которую саботируют), в идеале на технологии блокчейна. Почему кто то захватил само право на все имена, монополизировал это право и грабит людей, причем бесконечно как в объеме, так и во времени. Как такое вообще произошло в современном обществе, где скандал начинается по любому мелкому нарушению прав человека, но на самое огромное ограбление и нарушение прав человека на придумывание вообще ноль реакции.
Почти такая же история с IP адресами, только там искусственно создается дефицит, опять же чтобы постоянно грабить людей на пустом месте, за воздух. Да даже не за воздух а за цифры.
И более того, я больше чем уверен, что не будь искусственного дефицита IP адресов, многим людям доменные имена вообще не нужны бы были. Многим бы достаточно было бы доступ оп IP. Большинство людей вообще не смотрят давным давно на доменное имя, и не запоминают и тем более не вводят вручную.
Этот ограбление в интернете можно сравнить, как если бы в обычной жизни у нас украли бы воздух, или право на речь, или право взять себе имя и дату рождения, или вообще на алфавит.
Этот обман должен быть вскрыт и уничтожен, пресечь навсегда и никогда не дать такому больше повториться. Присвоение всего множества доменных имен это как преступление против человечества, даже более масштабнее. Нужно точно определить, что это огромное лицемерие, зло и цинизм по уровню сопоставимые с рабством, и чтобы оно никогда больше не повторялось в истории развития человечеств, особенно дальнейшего цифрового развития.
Подробнее..

Что сегодня есть у Huawei для построения цифровых беспроводных офисов

13.04.2021 16:13:10 | Автор: admin
В этом посте мы обрисуем современные тенденции в построении беспроводных кампусов, рассмотрим сценарии и реальные кейсы цифровой трансформации корпсетей, а также покажем, как двум специалистам обслуживать сеть на 25 тыс. абонентов, включающую в себя 20 тыс. сетевых устройств.



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

С появлением Wi-Fi 6 и софта для управления SDN эти неудобства уходят в прошлое. Короткое видео ниже наглядно показывает, какие возможности дают беспроводные кампусы нового поколения, на примере одного из китайских офисов Huawei.



Итак, реальная беспроводная сеть с непрерывным роумингом, включающая в себя 20 тыс. устройств и обслуживающая 25 тыс. абонентов, управляется всего двумя (!) инженерами. Развёрнута она на базе самых современных технических решений Huawei, о которых и пойдёт речь сегодня.



Основа цифровой трансформации 2.0


В процессах цифровой трансформации сеть становится элементом, связывающим между собой людей и IT-сервисы. В практическом плане мы говорим о гаджетах, находящихся на уровне edge (носимых терминалах, смартфонах, устройствах AR/VR, датчиках IoT и пр.) и множеством способов взаимодействующих между собой, а также с облаком или ЦОДом.



Умные рабочие места без проводов


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

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

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



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



CloudCampus 2.0


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

CloudCampus 2.0 включает в себя систему управления и мониторинга сети, построенную на базе SDN-контроллера iMaster NCE. Он берёт на себя всю работу по поддержанию функционирования сети, начиная с Zero Touch Provisioning (ZTP) и заканчивая автоматическим анализом неисправностей. Система построена на базе алгоритмов искусственного интеллекта, что позволяет ей с высокой вероятностью предсказывать состояния сети и проактивно устранять потенциальные точки отказа.

Немаловажно и что iMaster NCE посредством Northbound interface (NBI) легко интегрируется с вышестоящими решениями, в том числе от других вендоров. Это могут быть системы управления активами, учётом рабочего времени, гибким производством, автоматизированным складским оборудованием и др. Таким образом, сеть превращается в сервис, способный интегрироваться в любой IT- или IoT-комплекс.

Возможности CloudCampus 2.0 делятся на три основные группы.

Благодаря iMaster NCE сеть может функционировать в режиме умной эксплуатации, позволяющем оптимизировать работу с опорой на прогнозную аналитику и обнаруживать до 85% неисправностей с помощью ИИ.

С помощью Умной связи сеть быстро настраивается из единой консоли. Применение современных проводных коммутаторов и беспроводных точек доступа WiFi 6 даёт возможность строить конвергентный доступ в сеть для IoT-устройств.

Наконец, третий пункт можно условно назвать суперёмкостью, так как этот комплекс возможностей подразумевает достижение пропускной способности на уровне 10,75 Гбит/с на одну точку доступа.



В конце марта Huawei представила CloudCampus 3.0 и целый ряд новых решений, которые оптимальны для внедрения при реализации этой концепции. Среди прочего пополнение в семействе точек доступа AirEngine Wi-Fi 6 и умный маршрутизатор NetEngine AR8140, которые показывает пропускную способность до 20 Гбит/с (SD-WAN). Скоро мы расскажем в нашем хабраблоге о CloudCampus 3.0 во всех подробностях.


Wi-Fi 6 для гибкого производства


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

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

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



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

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

Уже сейчас беспроводная связь предыдущего поколения зачастую не позволяет надёжно подключать необходимое количество автоматизированных устройств и пропускать требуемый каждому из них поток трафика. В то же время одна точка доступа Huawei с поддержкой WiFi 6, демонстрирующая минимальные задержки и способная передавать свыше 10 Гбит данных в секунду, в состоянии поддерживать работу более десятка роботов оптического контроля.



Настоящая действующая линия гибкого производства для производства смартфонов Huawei P40 уже развёрнута на одном из заводов нашей компании. Особенность линии то, с какой частотой вносятся изменения в рабочие процессы, а именно до нескольких раз в неделю. Это стало возможным лишь благодаря широкому внедрению роботизированных комплексов, умеющих быстро подстраиваться под меняющиеся требования. Все эти комплексы подключены к беспроводной сети на базе топовых точек доступа AirEngine 8760-X1-PRO.

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



70 миллисекунд для VR и AR


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

Важной точкой роста технологий VR/AR в ближайшее время станет обучение, благо дети прекрасно осваивают сложные технические решения. А значит, грядёт и резкий рост спроса на соответствующие устройства, которым также потребуются широкие каналы связи.

Вместе с тем очевидно, что контент для шлемов VR/AR будет размещаться на серверах в ЦОДах: централизация ресурсов целесообразна экономически. Это неизбежно вызовет повышение требований к пропускной способности сетей.



Чуть подробнее остановимся на сетевой задержке, критически важной для VR/AR. В приложениях, где пользователи интенсивно взаимодействуют со средой и друг с другом, она не должна превышать рекомендованного значения 70 мс. Причём примерно 20 мс необходимо терминальному устройству на обработку действия пользователя, ещё столько же на формирование нового изображения в ЦОДе. Получается, на передачу данных в обе стороны по проводным и беспроводным сетям остаётся не более 3040 мс. Это вполне достижимо, если проводная сеть правильно сконфигурирована и демонстрирует показатели, близкие к максимально возможным (10 мс), а беспроводная сеть построена на современных технологиях WiFi 6 (10 мс).



Wi-Fi 6 для операционных офисов


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



Новые офисы обходятся минимальным количеством операционистов, в то время как количество услуг, предоставляемых автоматизированными системами, растёт и растёт. Привычные банкоматы соседствуют с куда более функциональными умными терминалами STM (Smart Teller Machine). С их помощью можно получить любую услугу, будь то выдача пластиковой карты или оформление договора на открытие счёта. Эти устройства способны собирать биометрические данные и сканировать документы, позволяют получить консультацию удалённого специалиста в режиме видеоконференции и пр.

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

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



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

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

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

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



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

***


Узнать больше о Wi-Fi 6 и технологиях Huawei вам помогут наши многочисленные вебинары: вот их расписание на ближайшие месяцы.
Подробнее..

Перевод FTP исполнилось 50 лет

18.04.2021 00:07:30 | Автор: admin
image


16 апреля 1971 года-это не только день, когда The Rolling Stone впервые выпустила Brown Sugar, но и день публикации RFC 114, знаменующий день рождения FTP.

В те дни вьетнамская война была в центре внимания, TCP/IP еще не существовал, Джими Хендрикс умер 6 месяцев назад, telnet был новым крутым парнем, а некоторые из самых влиятельных рок-н-ролльных артистов собирались выпустить свои шедевры, в то время как FTP использовал сетевой протокол под названием NCP.

За прошедшие годы протокол FTP был усовершенствован 16 раз, добавивилась поддержка TCP/IP, безопасного расширения, также известного как FTPS, которое использует ту же технологию, что и HTTPS, и более поздние дополнение, такое как поддержка IPv6.



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

В 2021 году то, что кажется признанным прогрессом, принимает форму проприетарных протоколов, сделанных за закрытыми дверями и без каких-либо RFC. Вместо этого поставщикам, желающим создать конкурирующие серверы, остается реверс-инжиниринг SDK, как это сделал Minio с S3.

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

Развитие FTP


RFC 114 (апрель 1971 г.)
RFC 697 (июль 1975 г.): CWD Command
RFC 765 (июнь 1980 г.): TCP/IP
RFC 959 (октябрь 1985 г.): Первоначальная спецификация FTP
RFC 1579 (февраль 1994 г.): FTP с поддержкой firewall
RFC 1635 (май 1994 г.): Как использовать анонимный FTP
RFC 1639 (июнь 1994 г.): операция по большим адресным записям
RFC 1738 (декабрь 1994 г.): унифицированные указатели ресурсов
RFC 2228 (октябрь 1997 г.): Расширения безопасности FTP.
RFC 2389 (август 1998 г.): механизм согласования функций для протокола передачи файлов.
RFC 2428 (сентябрь 1998 г.): расширения для IPv6, NAT и расширенного пассивного режима.
RFC 2577 (май 1999 г.): соображения безопасности FTP
RFC 2640 (июль 1999 г.): интернационализация FTP
RFC 3659 (март 2007 г.): Расширение команд FTP
RFC 5797 (март 2010 г.): Реестр команд и расширений FTP.
RFC 7151 (март 2014 г.): Команда HOST для виртуальных хостов
Подробнее..

Всё о проекте Спутниковый интернет Starlink. Часть 27 Первые итоги. Часть вторая проблемная

12.04.2021 18:13:34 | Автор: admin
Предлагаю ознакомиться с ранее размещенными материалами по проекту Starlink (SL):
Часть 20. Внутреннее устройство терминала SL Часть 21. SL и проблемы поляризаци Часть 22. Проблемы электромагнитной совместимости c другими спутниками. Часть 23. Промежуточные итоги аукциона RDOF Часть 24. Лазерные Каналы -2 Часть 25. EPFD Часть 26. Первые итоги. Часть первая позитивная


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

1) Начнем с главной по моему мнению проблемы, хотя и наименее доказуемой.
SpaceХ не публикует количество абонентов, принимающих участие в бета-тестировании. Единственная информация имеется от начала февраля 2021 года в презентации для ФСС более 10000 Абонентов.
По логике, имея 700000 заявок, право на установку 1 млн терминалов в США и контракт на производство 1 млн терминалов, производство должно быть в пределах: если контракт на 1 год то 80000 терминалов в месяц, если на 2 года (ну это конечно очень долго) то 40000 терминалов. И за эти полтора-два месяца 2021 года SpaceX могла получить и разослать около 50000 терминалов. В то же время наблюдения за реддитом говорит о том, что темп рассылки практически не растет, там нет бума радующихся новичков по 1000 в день (и даже по 100) с радостными криками Вот моя Диша! Спасибо Илон за нашу счастливую жизнь!.

При этом новые ячейки/адреса постоянно появляются зона предоставления сервиса на территории США растет.

Моя трактовка этого имеется дефицит терминалов и либо наличие узкого места в их производстве (это может быть как неотработанная технология сборки/пайки там очень плотное расположение различных слоев и как следствие много брака на выходе), либо банальный дефицит каких-то элементов и материалов. Недавно я наткнулся на статью о кризисе на рынке электронных изделий из-за обрывания цепочек снабжения из Китая и Европы, связанного с КОВИДом. Учитывая узкую специализацию производств и огромную кооперацию поставок в этой отрасли, проблемы с поставками компонент для МикроЭлектроникс вполне могут быть причиной низкого уровня производства терминалов. Проблема некритичная, но однозначно это потери десятков, а может и сотен тысяч долларов, ведь спрос на услуги Starlink в США сейчас очень большой.

Вот типичный разговор на реддите:
Мне повезло, мы ждали около двух недель между предварительным заказом на 99 долларов и полным заказом на 500 долларов. Теперь просто жду 2-3 недели доставки.

Эй, братан 26000, это низкий, держись там, твой должен быть быстрым. Мой заказ был как ORD-559 000- 65231-2

Мой заказ ord-100999. До сих пор не отправлено в северо-западную часть страны.
https://www.reddit.com/r/Starlink/comments/md4cu2/how_long_have_you_all_waited_for_this_after_you/

2) А вот ЭТО уже видимая проблема, и она теоретически может быть решена. Имя ей нестабильность сервиса.
Сейчас у абонента скорость доступа колеблется от десятка Мбит до сотен (причем независимо от потребностей и желания абонента). На мой взгляд, многих из них устроит сервис со стабильными 50 Мбит, чем тот который сейчас 200, а через минуту 20
Цитирую с Реддита:
Сильно различается. У меня было 200 вчера и 16 сегодня утром. На данный момент 70.

3) Перерывы связи и потери пакетов.
Просто приведу сколько обсуждений на эту тему:

Как я понял это не только при ПОТЕРЯ СВЯЗИ, это иногда и потеря пакетов в работающем канале
От этого абоненты Starlink сейчас начинают изобретать велосипед и резервировать Starlink наземным дорогим и медленным, но надежным каналом:
Я приобрел подписку на Speedify. Отличное решение для меня. Я вернул себе рассудок. Я не мог больше терпеть пытки, когда Диши ронял каждый раз спутник. Speedify имеет специальную скидку 50% на следующие несколько недель, если вы используете код купона SPEEDIFY11. Я заплатил 56 долларов за 3 года безлимитного обслуживания. Для меня это было лучшее предложение, если я использую его последние 5 месяцев. Похоже, я сделаю это.
www.reddit.com/r/Starlink/comments/md4wwt/resorted_to_speedify

4) Похоже появились первые проблемы с перегрузкой ячеек Starlink, где много абонентов
05 03 2021 Beta Tester Patient-Access95 I use Starlink from 6 am to 6pm (work), Stable, 15 seconds of Beta downtime 100+Mbps speeds., I then switch to DSL. (7Mbps), stable, as Starlink is usually between 3-9Mbps unstable (zero obstructions) during the late evenings hours due to congestion in my cell.
https://www.reddit.com/r/Starlink/comments/lyqz65/this_might_have_some_relevant_information_as_to/

В целом, проблема пропускной способности ИСЗ Starlink является очень острой, особенно в разрезе конкурса RDOF, конкуренты утверждают, что у SpaceХ физически нет пропускной способности, чтобы дать каждому абоненту, который будет подключен по программе RDOF, обещанные 100 Мбит. И здесь, в отличие от обычных абонентов и практики операторов, говорить о коэффициенте переподписки и сервисе уровня best efforts и тд уже невозможно это федеральные деньги налогоплательщиков и FCC будет требовать от провайдера 100% гарантии выполнения им требований конкурса.

Появились и первые отказники, то что у нас операторов называется churn
Unfortunately Dishy has to go back. Cancelling the service was simple enough, but nowhere can I find where to send the hardware back too, or whether or not an RA is required. I'm trying to make the 30 day window for full refund, but Starlink isn't making it easy. I've checked all the support pages, and put it in a specific support question, but I'm coming up with nothing. I suppose it's staring me in the face somewhere but I don't see it. Anyone have any info?
пока, конечно, это абсолютная редкость

5) Из мелочей отметим неудобную конструкцию терминала,(который поставляется с кабелем, который нельзя отсоединить и нельзя прикрутить самому разъемы) требующим того, чтобы в стене сверлили отверстие диаметром 25 мм для того, чтобы просунуть разъем. При том, что диаметр самого кабеля не более 8 мм
Хотелось бы, чтобы у тарелки был короткий провод, который можно было отсоединить от 100 футов провода PoE. Я потратил много времени и сил, чтобы проложить провод к моему офису, пройдя через чердак вниз по стене для подключения

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

6) Теперь о внешних проблемах.
Основной на сегодня проблемой является отсутствие разрешения FCC на смену высоты с 1100 км до 550 км для остальных 3000+ спутников, составляющих группировку Ку/Ка диапазона. Напомню, что сейчас разрешение FCC есть только на 1584 спутника на орбиту с наклонением 53 градуса. Разрешения для смены орбиты остальных спутников (соответственно и права на запуски на полярную орбиту) НЕТ. Первые 10 ИСЗ были запущены на нее по индивидуальному разрешению FCC. Для экспериментов хорошо, но для развертывания услуги нет. При этом из 1584 ИСЗ первой фазы осталось запустить максимум еще 240, то есть 4 пуска. По сути один месяц, если брать за образец март 2021 года, и что тогда?
При этом у нас там смена руководителя FCC, смена администраций, и

7) Усилившаяся борьба против SpaceX на административном уровне, где старые космические фирмы, спутниковые провайдеры ХьюзНет и Виасат, классические телеком-операторы, конкуренты типа УанВэба и Куйпера выступают единым фронтом, но с разных направлений, забрасывая ФСС различными петициями, жалобами, кляузами и возражениями. И все их FCC должно рассмотреть, проанализировать и ответить, причем часто привлекая внешних экспертов, которые теоретически должны быть нейтральными, но откуда их взять. Независимый эксперт должен где-то кормиться, то есть он на кого-то ранее все равно работал, и у него есть какие-то личные симпатии/антипатии.

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

Также как и отсутствие сейчас у SpaceX позиции как работать на рынках, отличающихся правилами игры от рынков США и других условно демократических стран с рыночной экономикой, которых сейчас около 15 (если принять ЕС за 1). Что делать с Африкой и Юго-Восточной Азией, где доходы явно не позволят заплатить за терминал 500 Долларов.

В заключение еще раз повторюсь, что это анализ на 31 марта 2021 года. Через 6 месяцев все может стать по-другому. Но сегодня картина по моему мнению выглядит именно так: катастрофы НЕТ, проблемы и трудности ЕСТЬ
Подробнее..

Анализ сетевого трафика и базовый траблшутиг (бесплатный видео курс)

08.04.2021 10:11:09 | Автор: admin

Прошло уже почти два года с момента публикации моего последнего курса и наконец я опять в деле! Как и прежде, весь контент на ресурсе NetSkills предназначен для подготовки начинающих инженеров. Этот курс не стал исключением и посвящен основам анализа трафика и базовому траблшутингу с помощью таких популярнейших инструментов как tcpdump и wireshark! Одна из важнейших тем, которая совершенно точно пригодится любому сетевику, админу или даже безопаснику. Я бы рекомендовал приступать к этому курсу только после окончания Курса молодого бойца, т.к. данный материал предполагает, что вы понимаете базовые принципы работы компьютерных сетей. В этом же курсе мы погрузимся в детальное изучение работы стэка TCP/IP - тема, которую многие старательно избегают. Однако, по завершению курса вы получите знания и навыки, которые выведут ваше понимание сетей на принципиально новый уровень. Вы поймете саму суть работы сетей и что важнее - научитесь видеть проблемы в ее работе.

Повторюсь, мы будем анализировать трафик с помощью утилит tcpdump и wireshark, которые уже давно являются стандартом в мире анализа и траблшутинга. Вы просто обязаны уметь ими пользоваться! При этом большинство использует их от силы на 10% от возможностей (если вообще используют). Я же постараюсь научить вас это делать, как профессионалы.

Содержание

  1. Три главных способа сбора сетевого трафика

    Обсудим, что такое вообще сбор, как он осуществляется и какие преимущества и недостатки у этих способов.

  2. Основы tcpdump

    Поработаем с утилитой tcpdump, рассмотрим основные ключи и пару практических кейсов. Думаю, после урока вы будете работать с этой утилитой гораздо увереннее.

  3. Фреймы, пакеты, сегменты

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

  4. Основы Wireshark

    Запустим Wireshark и обсудим основы сбора трафика. Поупражняемся с интерфейсами, профилями и т.д.

  5. Исследование сети

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

  6. Основы фильтрации

    Более плотно поработаем с фильтрацией, колонками, протоколами, полями и т.д. Т.е. научимся выделять нужную информацию в большом объеме данных. Это очень важный навык в работе с Wireshark.

  7. Основы TCP

    Опять перейдем к фундаментальным вещам - основам TCP. Уже на примере дампа реального трафика рассмотрим как работает 3 way tcp handshake - важнейший механизм в сетевом взаимодействии.

  8. RTT & Window Size

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

  9. Визуализация данных

    Да, wireshark умеет и это. Причем в некоторых кейсах это очень помогает в решении проблем.

  10. Реальные кейсы

    Ну и под конец мы рассмотрим несколько типовых проблем в сети и научимся их решать с помощью Wireshark.

Видео курс

Данный курс, как и Курс молодого бойца, бесплатно опубликован на ютуб-канале:

Смотрите, оставляйте комментарии, принимается любая конструктивная критика.

Спасибо за внимание!

Подробнее..

Way to Geneve

10.04.2021 22:12:11 | Автор: admin

Хабр, привет.

Меня зовут Аркадий и я сетевой инженер в одном из сервис провайдеров. Кому интересны основные отличия VXLAN от Geneve добро пожаловать под кат. Избегая выстрела в ногу, хочу отметить, что основа статьи это выжимки из RFC и открытой информации WMware.

В NSX-T VMware уходит от Overlay на базе VXLAN в пользу Geneve. Внедрение Geneve лоббируется помимо VMWare такими компаниями как : Intel, Microsoft, Red Hat. Маркетинг называет следующую причину к Geneve : "Geneve сочетает в себе лучшее от протоколов VXLAN (Virtual Extensible LAN), NVGRE(Network Virtualization using Generic Routing Encapsulation), and STT(Stateless Transport Tunneling)." Разберем отличия нового Overlay протокола и почему ему отдано предпочтение ведущими вендорами виртуализации.

Теперь по порядку:

Geneve - туннельный протокол работающий поверх UDP (port number) для построения туннелей между NVEs (Network Virtualization Edge) через IP underlay. Описан в RFC8926, который в свою очередь заменил предшествующий драфт draft-gross-geneve 2020-11-06.

Протокол разрабатывался рабочей группой IETF с целью унификации и агрегации преимуществ протоколов VXLAN, NVGRE и STT. Недостатками которых являлись гибкость и ограниченность масштабирования в условиях стремительного развития виртуализации и сервисов на базе глобальных облачных провайдеров.

Основной задачей технологии (протокола) является виртуализация L2 домена работающего поверх базовой IP сети. Широко применяется в облачных средах, в связи с ограничениями по размеру поля VLAN Tag 802.1q в 2 ^ 12 = 4094.

Geneve

Минимальный размер заголовка Geneve составляет 8 байт.

Geneve headerGeneve header

Ver (2 bits) Версия протокола. Текущее значение 0.

Opt Len (6 bits) указание размера поля Variable Length Options. Минимальный размер заголовка + значение Opt Len = полный размер заголовка.

O (1bit) Control packet. Интерпретируется TEPs (tunnel end points). Может использоваться для передачи пакета на обработку выше по стеку.

C (1bit) Critical options present. Установленный бит указывает на необходимость парсинга опций на TEPах. На TEPах поддерживающих парсинг опций пакет должен быть отброшен.

Rsvd.(6 bits) Reserved. Значение поля должно быть = 0 при передаче пакета и игнорируемо на конечных хостах.

Protocol type (16 bits) - 0x6558 Transparent Ethernet Bridging.

VNI (24 bits) Virtual Network Identifier уникальный идентификатор сегмента виртуальной сети. Идентифицирует L2 домен которому принадлежит оригинальный Ethernet фрейм. NSX-T использует диапазон VNI от 5000 до 16777216.

Reserved (8 bits). Значение поля должно быть = 0 при передаче пакета и игнорируемо на конечных хостах.

За базовым заголовком Geneve следует поле опций в TLV формате. Каждая опция состоит из заголовка в 4 байта и данных интерпретируемых в соответствии с полем Type опции. В базовом заголовке предусмотрено поле для идентификации типа опции по организации, технологии, или вендору. Определенный блок IANA зарегистрировала для тестов и оптимизации протокола. Поле опций в заголовке Geneve по тексту RFC в большей степени предусмотрено для масштабирования протокола и возможностей оптимизации протокола разработчиками. В поле тип определено место контрольного бита (C) Critical являющегося глобальным по отношению ко всем TEPs. При обработке TEP пакета при выставленном бите C и не определенным типом опции пакет должен быть отброшен.

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

В сравнении с VXLAN (RFC7348)

VXLAN Header (8 bytes)VXLAN Header (8 bytes)

VXLAN Flags (8 bits) Набор флагов, в котором I должен быть выставлен в 1 для валидного VNI, R зарезервированные флаги выставленные в 0 при передаче и игнорируемы на приеме

Reserved (24 bits) - Зарезервированные флаги выставленные в 0 при передаче и игнорируемы на приеме

VNI (24 bits) - уникальный идентификатор сегмента виртуальной сети. Идентифицирует L2 домен. Размер поля такой же как у Geneve (порядка 16М номеров).

Reserved (8 bits) - Зарезервированные флаги выставленные в 0 при передаче и игнорируемы на приеме.

Ссылка на vxlan.pcap

Summary по заголовкам пакетов VXLAN и GENEVE:

Одинаковый минимальный размер заголовка 8 байт с возможность расширения Geneve за счет поля опций разной длины. Geneve обладает следующими преимуществами:

  • Поддерживает проприетарные* значения полей type, length, value;

  • Обладает гибкостью в отношении включения дополнительных метаданных в заголовок;

* ИМХО это кажется основной причиной описания нового стандарта и активного его внедения ведущими вендорами, а не маркетинговый булщит на тему сочетания в себе преимуществ предшественников.

Целиком пакет Geneve over IPv4 выглядит так:

Ссылка на Geneve.pcap

Требования к IP Underlay сетевой инфраструктуры следующие:

  • IP связность между TEP

  • Отсутствие на пути трафика блокировок UDP6081 Geneve или UDP4789 VXLAN

  • Минимальный MTU 1600 байт

Итого

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

Получилось достаточно кратко. В будущем планирую рассмотреть процесс построения таблиц соответствия (которых три) и этапы передачи Geneve пакета между TEP примере NSX-T.

Подробнее..

Перевод Настройка сетевого стека Linux для высоконагруженных систем

05.04.2021 18:06:45 | Автор: admin

Максимизируем количество входящих соединений

В рамках набора учащихся на курс "Administrator Linux. Professional" подготовили перевод полезного материала.

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

О том как изменять параметры ядра, описываемые здесь, можно прочитать в статье Linux Kernel Tuning for High Performance Networking: Configuring Kernel Settings.

Очередь приема и netdev_max_backlog

Каждое ядро процессора перед обработкой пакетов сетевым стеком может хранить их в кольцевом буфере. Если буфер заполняется быстрее, чем TCP-стек обрабатывает пакеты, то пакеты отбрасываются и увеличивается счетчик отброшенных пакетов (dropped packet counter). Для увеличения размера очереди следует использовать параметр net.core.netdev_max_backlog.

net.core.netdev_max_backlog параметр задается на ядро процессора.

Очередь ожидающих запросов на соединение и tcp_max_syn_backlog

Соединения создаются для SYN-пакетов из очереди приема и перемещаются в очередь ожидания (SYN Backlog Queue). Также соединение помечается как "SYN_RECV" и клиенту отправляется "SYN+ACK". Эти соединения не перемещаются в очередь установленных соединений ожидающих обработки accept() (accept queue) до тех пор, пока не будет получен и обработан соответствующий ACK. Максимальное количество соединений в этой очереди устанавливается параметром net.ipv4.tcp_max_syn_backlog.

Для просмотра очереди приема используйте команду netstat. На правильно настроенном сервере при нормальной нагрузке значение не должно быть больше 1. При большой нагрузке значение должно быть меньше размера очереди ожидания (SYN Backlog):

# netstat -an | grep SYN_RECV | wc -l

Если в состоянии "SYN_RECV" находятся много соединений, то можно также подстроить продолжительность нахождения SYN-пакета в этой очереди.

SYN Cookie

Если SYN cookie отключены, то клиент просто повторяет отправку SYN-пакета. Если включены (net.ipv4.tcp_syncookies), то соединение не создается и не помещается в SYN backlog, но клиенту отправляется SYN+ACK, так как если бы это было сделано на самом деле. SYN cookie могут быть полезны при нормальной нагрузке, но при всплесках трафика некоторая информация о соединении может быть потеряна и клиент столкнется с проблемами, когда соединение будет установлено. Подробнее о SYN cookie можно прочитать в статье Грэма Коула (Graeme Cole) SYN cookies ate my dog (SYN cookie съели мою собаку), в которой подробно объясняется, почему включение SYN cookie на высоконагруженных серверах может привести к проблемам.

Повторы SYN+ACK

Что происходит, если SYN+ACK отправлен, но ответа ACK нет? В этом случае сетевой стек сервера повторит отправку SYN+ACK. Задержка между попытками вычисляется таким образом, чтобы обеспечить восстановление сервера. Если сервер получает SYN и отправляет SYN+ACK, но не получает ACK, то тайм-аут повторной передачи вычисляется по экспоненте (Exponental Backoff) и, следовательно, зависит от количества повторных попыток. Количество повторных попыток отправки SYN+ACK задается параметром ядра net.ipv4.tcp_synack_retries (по умолчанию равно 5). Повторные попытки будут через следующие интервалы: 1с, 3с, 7с, 15с, 31с. При шести попытках последняя будет примерно через 63 секунды после первой. Это позволяет удержать SYN-пакет в очереди ожидания более 60 секунд до истечения времени ожидания пакета. Если очередь SYN backlog мала, то не требуется большого количества соединений, чтобы возникла ситуация, когда полуоткрытые соединения никогда не завершатся и тогда никакие соединения не смогут быть установлены. Установите количество повторных попыток SYN+ACK равным 0 или 1, чтобы избежать такого поведения на высоконагруженных серверах.

Повторы SYN

Несмотря на то что повторные SYN-пакеты отправляются клиентом во время ожидания SYN+ACK, они могут влиять и на высоконагруженные сервера, работающие с прокси-соединениями. Например, сервер nginx, устанавливающий несколько десятков прокси-соединений к бэкенд-серверу, из-за всплесков трафика может на некоторое время перегрузить сетевой стек, а повторные попытки создадут дополнительную нагрузку на бэкэнд как в очереди приема, так и в очереди ожидания (SYN backlog). Это, в свою очередь, может повлиять на клиентские соединения. Повторные попытки SYN контролируются параметром net.ipv4.tcp_syn_retries (по умолчанию 5 или 6 в зависимости от дистрибутива). Ограничьте количество повторных попыток SYN до 0 или 1, чтобы не было долгих повторных попыток отправки в течение 63130 с.

Более подробно о проблемах с клиентскими соединениями при обратном прокси-сервере читайте в статье Linux Kernel Tuning for High Performance Networking: Ephemeral Ports.

Очередь установленных соединений ожидающих принятия (accept queue) и somaxconn

Очередь запросов на соединение создает приложение, используя listen() и указывая размер очереди в параметре "backlog". Начиная с ядра 2.2 поведение этого параметра изменилось с максимального количества неоконченных запросов на соединение, которое может удерживать сокет, на максимальное количество полностью установленных соединений, ожидающих, пока они будут приняты. Как описано выше, максимальное количество неоконченных запросов на соединение теперь задается с помощью параметра ядра net.ipv4.tcp_max_syn_backlog.

somaxconn и параметр backlog в listen()

Хотя за размер очереди для каждого слушателя отвечает приложение, есть ограничение на количество соединений, которые могут находиться в очереди. Размером очереди управляют два параметра: 1) параметр backlog в функции listen() и 2) параметр ядра net.core.somaxconn, задающий максимальный размер очереди.

Значения по умолчанию для очереди

Значение по умолчанию для net.core.somaxconn берется из константы SOMAXCONN, которая в ядрах Linux вплоть до версии 5.3 имеет значение 128, но в 5.4 она была увеличена до 4096. Однако, на момент написания этой статьи, ядро 5.4 еще не очень распространено, поэтому в большинстве систем значение будет 128, если вы не модифицировали net.core.somaxconn.

Часто приложения для размера очереди по умолчанию используют константу SOMAXCONN, если этот размер не задается в конфигурации приложения. Хотя некоторые приложения устанавливают и свои значения по умолчанию. Например, в nginx размер очереди равен 511, который автоматически усекается до 128 в ядрах Linux до версии 5.3.

Изменение размера очереди

Многие приложения позволяют указывать размер очереди в конфигурации, указывая значение параметра backlog для listen(). Если приложение вызывает listen() со значением backlog, превышающим net.core.somaxconn, то размер очереди будет автоматически усечен до значения SOMAXCONN.

Потоки

Если очередь большая, то подумайте также об увеличении количества потоков, которые обрабатывают запросы в приложении. Например, установка для nginx очереди ожидания в 20480 для HTTP-listener без достаточного количества worker_connections для управления очередью приведет к тому, что сервер будет отказываться отвечать на запросы на установку соединения.

Соединения и файловые дескрипторы

Системные ограничения

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

# cat /proc/sys/fs/file-nr1976      12       2048

Вывод показывает, что используется 1976 файловых дескрипторов. Выделено, но не используется 12 (для ядер 2.6+), а максимальное количество 2048. В высоконагруженной системе значение должно быть достаточно большим, чтобы справиться как с большим количеством соединений, так и с потребностями в файловых дескрипторах других процессов.

Пользовательские ограничения

Помимо системного ограничения количества файловых дескрипторов, у каждого пользователя есть свои лимиты. Они настраиваются в системном файле limits.conf (nofile) или, при запуске процесса под управлением systemd, в unit-файле systemd (LimitNOFILE). Чтобы увидеть значение по умолчанию запустите:

$ ulimit -n1024

Для systemd (на примере nginx):

$ systemctl show nginx | grep LimitNOFILE4096

Настройка

Для настройки системных ограничений установите параметр ядра fs.max-file в максимальное количество файловых дескрипторов, которое может быть в системе (с учетом некоторого буфера). Например:

fs.file-max = 3261780

Для настройки пользовательского лимита установите достаточно большое значение, чтобы хватило сокетам и файловым дескрипторам рабочих процессов (также с некоторым буфером). Пользовательские ограничения устанавливаются в /etc/security/limits.conf, в conf-файле в /etc/security/limits.d/ или в unit-файле systemd. Например:

# cat /etc/security/limits.d/nginx.confnginx soft nofile 64000nginx hard nofile 64000# cat /lib/systemd/system/nginx.service [Unit]Description=OpenResty Nginx - high performance web serverDocumentation=https://www.nginx.org/en/docs/After=network-online.target remote-fs.target nss-lookup.targetWants=network-online.target[Service]Type=forkingLimitNOFILE=64000PIDFile=/var/run/nginx.pidExecStart=/usr/local/openresty/nginx/sbin/nginx -c /usr/local/openresty/nginx/conf/nginx.confExecReload=/bin/kill -s HUP $MAINPIDExecStop=/bin/kill -s TERM $MAINPID[Install]WantedBy=multi-user.target

Количество worker'ов

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

Системные ограничения

Процессы могут создавать рабочие потоки. Максимальное количество потоков, которые могут быть созданы, задается параметром ядра kernel.threads-max. Для просмотра максимального и текущего количества потоков, выполняющихся в системе, запустите следующее:

# cat /proc/sys/kernel/threads-max 257083# ps -eo nlwp | tail -n +2 | \    awk '{ num_threads += $1 } END { print num_threads }'576

Пользовательские ограничения

Есть свои ограничения и у каждого пользовательского процесса. Это также настраивается с помощью файла limits.conf (nproc) или unit-файла systemd (LimitNPROC). Для просмотра максимального количества потоков, которое может создать пользователь запустите:

$ ulimit -u4096

Для systemd (на примере nginx):

$ systemctl show nginx | grep LimitNPROC4096

Настройка

В большинстве случаев системные ограничения достаточно большие, чтобы справиться с высокой нагрузкой. Однако их его можно настроить через параметр ядра kernel.threads-max. Установите его значение в максимальное количество потоков, необходимых системе, плюс некоторый буфер. Например:

kernel.threads-max = 3261780

Как и в случае с nofile, ограничения для пользователей (nproc) устанавливаются в /etc/security/limits.conf, в conf-файле в /etc/security/limits.d/ или в unit-файле systemd. Пример с nproc и nofile:

# cat /etc/security/limits.d/nginx.confnginx soft nofile 64000nginx hard nofile 64000nginx soft nproc 64000nginx hard nproc 64000# cat /lib/systemd/system/nginx.service [Unit]Description=OpenResty Nginx - high performance web serverDocumentation=https://www.nginx.org/en/docs/After=network-online.target remote-fs.target nss-lookup.targetWants=network-online.target[Service]Type=forkingLimitNOFILE=64000LimitNPROC=64000PIDFile=/var/run/nginx.pidExecStart=/usr/local/openresty/nginx/sbin/nginx -c /usr/local/openresty/nginx/conf/nginx.confExecReload=/bin/kill -s HUP $MAINPIDExecStop=/bin/kill -s TERM $MAINPID[Install]WantedBy=multi-user.target

Обратный прокси и TIME_WAIT

При большом всплеске трафика прокси-соединения, застрявшие в "TIME_WAIT", суммарно могут потреблять много ресурсов при закрытии соединения. Это состояние говорит, что клиент получил последний FIN-пакет от сервера (или вышестоящего worker'а) и находится в ожидании для корректной обработки пакетов. Время нахождения соединения в состоянии "TIME_WAIT" по умолчанию составляет 2 x MSL (Maximum Segment Length максимальная длина сегмента), что составляет 2 x 60 с. В большинстве случаев случаях это нормальное и ожидаемое поведение, и значение по умолчанию в 120 с вполне приемлемо. Однако много соединений в состоянии "TIME_WAIT" может привести к тому, что приложение исчерпает эфемерные порты для соединений к клиентскому сокету. В этом случае следует уменьшить FIN тайм-аут.

Управляет этим тайм-аутом параметр net.ipv4.tcp_fin_timeout. Рекомендуемое значение для высоконагруженных систем составляет от 5 до 7 секунд.

Собираем все вместе

Очередь приема (receive queue) должна быть рассчитана на обработку всех пакетов, полученных через сетевой интерфейс, не вызывая отбрасывания пакетов. Также необходимо учесть небольшой буфер на случай, если всплески будут немного выше, чем ожидалось. Для определения правильного значения следует отслеживать файл softnet_stat на предмет отброшенных пакетов. Эмпирическое правило использовать значение tcp_max_syn_backlog, чтобы разрешить как минимум столько же SYN-пакетов, сколько может быть обработано для создания полуоткрытых соединений. Помните, что этот параметр задает количество пакетов, которое каждый процессор может иметь в своем буфере, поэтому разделите значение на количество процессоров.

Размер SYN очереди ожидания (SYN backlog queue) на высоконагруженном сервере должен быть рассчитан на большое количество полуоткрытых соединений для обработки редких всплесков трафика. Здесь эмпирическое правило заключается в том, чтобы установить это значение, по крайней мере, на максимальное количество установленных соединений, которое слушатель может иметь в очереди приема, но не выше, чем удвоенное количество установленных соединений. Также рекомендуется отключить SYN cookie, чтобы избежать потери данных при больших всплесках соединений от легитимных клиентов.

Очередь установленных соединений, ожидающих принятия (accept queue) должна быть рассчитана таким образом, чтобы в периоды сильного всплеска трафика ее можно было использовать в качестве временного буфера для установленных соединений. Эмпирическое правило устанавливать это значение в пределах 2025% от числа рабочих потоков.

Параметры

В этой статье были рассмотрены следующие параметры ядра:

# /etc/sysctl.d/00-network.conf# Receive Queue Size per CPU Core, number of packets# Example server: 8 coresnet.core.netdev_max_backlog = 4096# SYN Backlog Queue, number of half-open connectionsnet.ipv4.tcp_max_syn_backlog = 32768# Accept Queue Limit, maximum number of established# connections waiting for accept() per listener.net.core.somaxconn = 65535# Maximum number of SYN and SYN+ACK retries before# packet expires.net.ipv4.tcp_syn_retries = 1net.ipv4.tcp_synack_retries = 1# Timeout in seconds to close client connections in# TIME_WAIT after receiving FIN packet.net.ipv4.tcp_fin_timeout = 5# Disable SYN cookie flood protectionnet.ipv4.tcp_syncookies = 0# Maximum number of threads system can have, total.# Commented, may not be needed. See user limits.#kernel.threads-max = 3261780# Maximum number of file descriptors system can have, total.# Commented, may not be needed. See user limits.#fs.file-max = 3261780

И следующие пользовательские ограничения:

# /etc/security/limits.d/nginx.confnginx soft nofile 64000nginx hard nofile 64000nginx soft nproc 64000nginx hard nproc 64000

Заключение

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


Узнать подробнее о курсе "Administrator Linux. Professional".

Смотреть вебинар Практикум по написанию Ansible роли.

Подробнее..

VMware SD-WAN обзор решения

03.04.2021 18:14:06 | Автор: admin

Этим материалом мы начинаем цикл статей о решении VMware SD-WAN. Сегодня поговорим о том, какие рыночные предпосылки сформировали его появление, какие задачи решает SD-WAN и каковы технические особенности решения VMware.

Появление SD-WAN

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

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

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

Казалось бы, почему не перейти на интернет? Это дешево и сердито, а скорость доступа к облакам выше. Ответ прост: в случае с интернетом невозможно гарантировать качество сервиса. Да, MPLS дорогой и неудобный, но провайдеры как минимум на уровне контракта гарантируют качество. А в случае с интернетом обещать, что приложения, физически находящиеся бог знает где, через конкретного провайдера будут хорошо работать, нельзя. Сами сервисы находятся вне зоны ответственности провайдера.

Иными словами, те, кто отвечают за канал связи, не отвечают за приложения, и наоборот. Заказчик оказывается между Сциллой и Харибдой.

Решения SD-WAN долгое время оставались уделом стартапов. В стадию зрелости технология перешла всего несколько лет назад, когда крупные компании начали активно приобретать специализированные проекты. VMware выкупила стартап Velocloud, который делил первое место на рынке с аналогичным проектом Viptela, примерно в то же время купленным Cisco. Еще пару лет заняла консолидация: одни стартапы разорялись не всем удавалось сохранить нужные темпы роста и найти свое место на рынке, наиболее перспективные и успешные переходили под крыло крупных вендоров.

Чтобы нарастить конкурентные преимущества, каждой компании пришлось найти собственную уникальную нишу. Решение Velocloud создавалось для того, чтобы бизнес мог получать надежный и качественный доступ к приложениям независимо от того, где они находятся: в локальном дата-центре или в облаке, доступ в которое осуществляется через интернет. Спойлер: реализовать это удалось благодаря архитектурному компоненту решения SD-WAN Cloud Gateways. Идея состоит в том, что облачные технологии можно использовать и в мире сетевых подключений.

Как работает SD-WAN

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

Этот неудобный подход просуществовал вплоть до появления SDN. Технология программно-определяемых сетей позволила централизовать control plane и management plane, что дало существенный выигрыш в плане управляемости и масштабируемости сети. Стало возможным без труда управлять распределенной сетью из сотен и даже тысяч устройств, выросла скорость внесения изменений, а также появилась возможность более интеллектуальной обработки потоков данных.

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

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

Далее мы подробно рассмотрим все компоненты VMware SD-WAN и поговорим о каждом из них отдельно.

Компоненты решения

VMware SD-WAN Orchestrator

SD-WAN Orchestrator это облачный портал управления, мониторинга и диагностики сети. С его помощью можно буквально в один клик запустить виртуальные сетевые службы в филиале, облаке или в корпоративном ЦОДе. Фактически, это веб-портал управления сетью SD-WAN, который можно получить как SaaS или развернуть в локальном ЦОД.

Архитектура оркестратора позволяет легко масштабировать сеть с нескольких узлов до нескольких тысяч. Управление на основе политик и профилей-шаблонов позволяет за минуты распространять изменения в сети. Этим функционал оркестратора не ограничивается.

  • Мониторинг. Данные о состоянии узлов сети, SLA по каналам, сетевая активность по приложениям и клиентам, а также продвинутая система построения отчетов

  • Zero-Touch Provisioning (ZTP). Активация оконечного устройства в филиале не требует выезда отдельного специалиста на площадку. Весь процесс укладывается в несколько простых шагов. Сотрудник в удаленном офисе подключает к устройству все кабели и включает его. Через интерфейс оркестратора создается новый Edge и высылается email со ссылкой для активации. Там зашиты нужные параметры для настройки WAN-интерфейса оборудования. Сотрудник в филиале, подключившись через провод или WiFi с планшета, переходит по этой ссылке, а устройство получает автоматически связность с оркестратором, вне зависимости от типа подключения к интернету.

  • Диагностика сети. В панели управления можно посмотреть состояние протоколов маршрутизации, портов, таблиц ARP и NAT, запустить Ping или Traceroute и многое другое без необходимости подключения к устройствам через CLI/SSH.

  • Журнал событий. Изменения и уведомления со всех устройств доступны для поиска и просмотра на SD-WAN Orchestrator.

  • Автоматизация через API. SD-WAN Orchestrator предоставляет REST API, примеры использования можно посмотреть на SD-WAN Dev Center.

Посмотрим, как это выглядит.

SD-WAN Dashboard общий вид на всю сеть:

Список филиалов и их расположение на карте:

Статистика по приложениям и клиентам:

Информация о качестве каналов Quality of Experience:

Детальные характеристики каналов:

VMware SD-WAN Gateway

SD-WAN Gateways это сетевые шлюзы, развернутые в высоконадежных ЦОД по всему миру. В первую очередь, они выполняют функцию Control Plane, но в зависимости от задачи могут брать на себя сразу обе плоскости и control plane, и data plane. Эти шлюзы позволяют соединить между собой разрозненные офисы и обеспечивают оптимальный путь от филиала к данным и приложениям в ЦОД и облаках. Потребность в установке мощных концентраторов или устройств координации непосредственно в филиалах отпадает.

На уровне Control Plane обеспечивается и обмен маршрутной информацией между филиалами, так как Gateway выполняет роль рефлектора маршрутов. Филиалы получают обновления маршрутов от Control Plane, благодаря чему настраивать протоколы маршрутизации между устройствами Edge не требуется.

Ещё одна важная роль SD-WAN Gateway помощь в определении характеристик каналов связи. При активации устройства Edge выполняется подключение к Gateway и замер полосы пропускания канала, также автоматически определяется MTU.

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

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

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

Хороший пример использование облачных сервисов совместной работы, например, Microsoft Office 365, Dropbox, Zoom, Skype for business и других. В месте их фактического расположения установить SD-WAN Edge невозможно,но получить преимущества SD-WAN Overlay (подробнее в разделе о протоколе VCMP) нужно. SD-WAN Gateway выполняет функцию шлюза в большой интернет с балансировкой между каналами, компенсацией ошибок и выбором наиболее оптимального канала для передачи пакетов конкретного приложения.

VMware SD-WAN Edges

VMware SD-WAN Edge это физическое или виртуальное устройство с функциями безопасности. Фактически, это маршрутизатор, который может как заменить уже размещенные в филиалах устройства, так и работать с ними в тандеме. Он поддерживает функции сетевого шлюза, Site-to-Site VPN, DHCP-сервера, NAT и файрвола, а также различные протоколы маршрутизации для интеграции с физической сетью.

SD-WAN Edge в виртуальном исполнении подойдет тем, кто планирует использовать концепцию Software-Defined Branch или обеспечивать доступ к своим приложениям в ЦОД через SD-WAN. Виртуальный Edge в ЦОД подходит как в качестве связующего звена ресурсов ЦОД и удаленных площадок, так и в роли хаба для агрегации и распределения трафика внутри сети SD-WAN.

SD-WAN Edge поддерживает основные варианты резервирования есть возможность объединения в отказоустойчивую пару или подключение по протоколу VRRP.

И если компоненты решения руки, ноги и голова технологии VMware SD-WAN, то его сердце технология DMPO. Именно она и позволяет реализовать уникальные фишки по обработке сетевых пакетов при передаче данных (между филиалами и ЦОД, филиалами и облаками) и обеспечивает высокое качество связи. Поговорим о ней подробнее.

Технология DMPO

Технология DMPO (Dynamic Multi-Path Optimization) позволяет нам за счет гибкого управления трафиком на уровне приложений агрегировать потоки и обеспечивать высокое качество связи. DMPO работает на уровне отдельных пакетов, однако учитывает, к каким приложениям эти пакеты относятся. Транзакционным приложениям, таким как веб-сайты, инструменты передачи файлов, не принципиально, придет пакет вовремя или чуть позже, главное, чтобы он вообще дошел. А приложениям реального времени (стриминговые сервисы, приложения для голосовых вызовов и т.п.) очередность пакетов важна. Из-за мелких неполадок может рассыпаться картинка на экране или собеседник не расслышит слово. Поэтому важно, чтобы SD-WAN устройства понимали, что это за приложение. В этом помогает движок распознавания приложений (Deep Application Recognition), работающий на каждом устройстве SD-WAN Edge.

Приложений существует огромное множество, 3000+ из них есть во встроенной базе DPI VMware SD-WAN. Кроме того, можно добавить и кастомные (самописные) сигнатуры, если вдруг какого-то приложения не хватает. Посмотрим, какие функции выполняет DMPO.

Непрерывный мониторинг качества каналов

Для мониторинга состояния WAN-каналов в реальном времени стандартные сетевые технологии вроде BFD или ICMP Probes не совсем подходят, т.к. тестовые пакеты отличаются от пользовательского трафика (другие классы DSCP, другой размер пакетов), а интервал проб слишком высок, чтобы достоверно и быстро определить ухудшение качества. Например, даже при замерах BFD или ICMP каждую секунду за время между этими замерами у обычного пользователя с ноутбуком передается 200+ пакетов (проверьте сами, сняв дамп трафика). Чтобы зафиксировать уровень потери в 2%, потребуется не менее 50 BFD пакетов (50 с). Если использовать более агрессивные значения, например, 100 мс, все равно потребуется не менее 5 секунд, чтобы обнаружить потери в 2% на канале. За это время тысячи пакетов с пользовательскими данными могут быть потеряны.

Поэтому в решении Velocloud используется собственный протокол инкапсуляции Velocloud Multipath Protocol (VCMP), который добавляет к каждому пакету специальные заголовки, помогающие отследить время его прохождения (Latency, Jitter) и факт доставки. Это позволяет обнаружить ухудшение качества каналов практически мгновенно, а затем перенаправить пакеты на канал с лучшими показателями незаметно для пользователя.

За точное время в сети отвечает Control Plane уже известные нам SD-WAN Gateways. Устройства SD-WAN Edge синхронизируют свое время с центром управления сетью. Таким образом можно гарантировать, что все временные метки будут достоверны. В стандартных сетевых протоколах такие возможности отсутствуют.

Состояние каналов отслеживается даже в том случае, если пользовательского трафика на данный момент нет. Ведь когда этот трафик появится, его нужно сразу же отправить по оптимальному пути. Для этого устройства SD-WAN Edge обмениваются служебными пакетами VCMP, только без User Payload, каждые 100 или 500 мс. Как только появляется пользовательский трафик, система снова начинает отслеживать SLA для каждого пакета.

Динамическая балансировка трафика и агрегация каналов

DMPO позволяет определять, какие приложения используют сеть, при помощи политик манипулировать поведением SD-WAN и настраивать приоритеты.

Решение VMware умеет автоматически (за счет работы overlay-протокола VCMP) выбирать наилучший способ обработки и доставки трафика приложений. К примеру, если конкретному приложению требуется ускорить передачу данных, то есть агрегировать несколько каналов, умное SD-WAN устройство начнет передавать данные сразу по нескольким путям. Для балансировки используются все доступные подключения.

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

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

Из-за особенностей каналов связи трафик между точками А и В может идти неравномерно: в одну сторону с задержкой 10 мс, обратно 20 мс. В то же самое время канал работает наоборот: туда 20 мс, сюда 10 мс задержки. По сети VMware SD-WAN такая сессия будет передаваться по обоим каналам сразу, в одну сторону по каналу с задержкой 10 мс, и так же обратно по каналу с наилучшими характеристиками.

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

Раньше администраторам приходилось вручную определять эту логику, либо настраивать схемы вида: каждые N секунд проверяем, какой канал и в какую сторону работает лучше и перестраиваемся при необходимости. Реализовать такую схему без разрывов пользовательских сессий практически невозможно. Ценность SD-WAN заключается в том, что вся эта запутанная логика делегирована алгоритмам они быстрее и точнее, чем даже самые сложные проверочные скрипты. Логика VMware SD-WAN работает на разных типах сессий и на разных транспортных протоколах, никак не нарушая логику работы TCP/IP.

Технологии корректировки ошибок

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

Получатель: Так, к нам идут пакеты. Первый, второй, третий, пятый Стоп. Почему пятый? Требую выслать мне пакет 4 как можно скорее! Прием!

Отправитель: Посмотрим, к какому приложению относился этот ваш пакет. Ага, вот оно! Высылаю компенсацию, подтвердите получение!

В случае транзакционного приложения устройству-отправителю будет достаточно найти в буфере нужный пакет и повторить отправку так работает технология NACK (Negative Acknowledgement). В устройствах SD-WAN используется серверная память гораздо большего объема, чем в обычных маршрутизаторах. Самая младшая модель имеет на борту 4 Гб, на старших 32 Гб и выше. Это позволяет держать буфер данных и по необходимости досылать потерявшиеся пакеты.

С realtime-приложениями ситуация обстоит иначе. Повторно отправлять пакеты не имеет смысла, важно предотвратить потери в будущем. Поэтому устройство-отправитель включает упреждающую коррекцию ошибок (Forward Error Correction, FEC), и каждый пакет начинает передаваться в двух экземплярах. Таким образом повышается вероятность успешной доставки пакетов, а лишние автоматически отбрасываются на принимающей стороне. На практике это позволяет использовать телефонию и видеоконференции на каналах с потерями до 30-40%.

Под капотом у провайдера

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

Разделение зон ответственности

Первая задача, с которой столкнется компания при самостоятельном внедрении построение облачной инфраструктуры SD-WAN: деплой контроллеров, виртуальных машин, выделение ресурсов, администрирование и многое другое. Построение такой инфраструктуры повлечет за собой значительные расходы в виде выделения или покупки дополнительных серверов и ПО, а также обеспечения условий Disaster Recovery. Эти сложности и расходы особенно трудно обосновать при постепенном внедрении SD-WAN. Во-вторых, для построения надежной отказоустойчивой сетевой связности требуется детально проработать целевую схему подключения, определить движение потоков данных, настроить политики безопасности.

Когда вы обращаетесь к провайдеру, все эти задачи ложатся на него. Он обеспечивает инфраструктуру, круглосуточный мониторинг, администрирование сети и защищенных распределенных ЦОД, уровень доступности и выполнение SLA. Провайдер поможет выбрать оптимальное оборудование и даст рекомендации по модернизации сети, чтобы она соответствовала всем требованиям качества и надежности. При этом клиенту остается только запросить доступ к облачному порталу управления сетью и создать учетные записи для администраторов. На любые вопросы по использованию услуги и настройке сервисов SD-WAN поможет ответить круглосуточная русскоязычная техническая поддержка.

Оркестратор и сетевые шлюзы находятся в зоне ответственности провайдера и разворачиваются на его инфраструктуре. Заказчику понадобится только установить на своей стороне Edge. Арендовать его можно прямо у провайдера при необходимости он поможет и с установкой.

Распределенная инфраструктура провайдера

Общая инфраструктура ИТ-ГРАД и #CloudMTS насчитывает 10 ЦОД в СНГ и множество точек присутствия по всему миру. Где бы ни находился филиал, он будет подключен к ближайшему SD-WAN Gateway, что позволит минимизировать задержки и оптимизировать доступ к любым приложениям в локальных ЦОД и любых облаках. Наличие распределенной инфраструктуры также позволяет обеспечивать георезервирование для сети SD-WAN любого масштаба.

Инфраструктура ИТ-ГРАД и #CloudMTS на территории РФ

В каждом ЦОД резервируются каналы, обеспечивается высокопроизводительная связность шлюзов SD-WAN с внешним миром. Дата-центры подключены к глобальной опорно-магистральной сети МТС, которая обеспечивает доступ к мировым публичным точкам обмена трафиком DE-CIX (Франкфурт), AMS-IX (Амстердам), HK-IX (Гонконг), LINX (Лондон), Equinix, NY-IX и т.д.

Кроме того, в распоряжении наших заказчиков:

  • PNI (Private Network Interconnect) с гиперскейлерами и крупными генераторами трафика. Среди них Amazon AWS, Microsoft, Google Cloud, Apple, Facebook, Valve, Twitch, Netflix, Twitter и прочие.

  • CDN-сети: Akamai, Google Cash и Google CDN, Cloudflare, Gcore labs, Microsoft и прочие.

Интеграция с IaaS и другими сервисами

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

  • VDI, Skype for Business компенсация ошибок, умная балансировка пакетов между всеми каналами, подключенными к площадке. Использование решения обеспечивает гарантированное качество для сервисов реального времени за счет приоритезации на уровне приложений и компенсации ошибок на каналах.

  • Резервное копирование SD-WAN позволяет наладить максимально быструю и надежную транспортировку бэкапов по сети (с агрегацией каналов и обеспечением отказоустойчивости) по всем доступным каналам до облака.

  • S3 хранилище, облачный диск при использовании сервисов блочного, объектного и файлового хранилищ подключение по SD-WAN позволяет передавать большие файлы на максимальных скоростях. Это достигается за счет отсутствия ретрансмитов при передаче данных и агрегирования каналов связи, подключенных к устройству SD-WAN.

  • GPU Super Cloud высокоскоростная передача больших объемов данных для обработки в облачной среде.

Все чаще наши клиенты для подключения своих офисов к виртуальным дата-центрам ИТ-ГРАД и #CloudMTS вместо выделенных каналов выбирают SD-WAN и интернет-каналы. Клиенты, уже использующие выделенные каналы, применяют SD-WAN для агрегации существующих каналов, многократно повышая производительность и надежность подключения к облаку.

Будем рады пообщаться с вами в комментариях! В следующей статье мы проведем тестирование сервиса и на практике посмотрим, какие преимущества дают технология DMPO и протокол VCMP.

Подробнее..

Рунета роста пост

07.04.2021 02:11:55 | Автор: admin

Так вышло, что у меня и у Рунета 7 апреля - День рождения. Ему в этом году 27, мне... чуть больше. На дне рождения часто можно услышать от "о, как вырос!!!" и "уже отца перерос" до "а ты совсем не изменился" или "каши надо больше есть".

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

Сегодня я предлагаю вашему вниманию свою оценку - в интернет-провайдерах и их связях.

Кстати, на Хабре есть подробный рассказ про устройство Интернета.

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

Примерно так атрибут AS_PATH превращается в графПримерно так атрибут AS_PATH превращается в граф

Поскольку имеем дело с аристократами графами, то и подход к их хранению и анализу нужен специальный. Я остановился на СУБД Neo4j тыц тыц.

В качестве исходных данных выбрана система сбора маршрутной информации Routing Information Service со следующими ограничениями:

  • рассматриваются маршрутные данные только коллектора на MSK-IX и только по префиксам IPv4;

  • период рассмотрения: 2006 2020 годы (коллектор начал работу в 2005 году);

  • каждый год представлен данными только за 1 день: 7 апреля

Немного про предобработку исходных данных

Таблицы маршрутизации представлены в формате MRT и нативного загрузчика в БД Neo4j нет, поэтому исходные данные преобразуются в формат csv:

as_from,as_to
28917,1299
1299,701
701,703
703,8057

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

Применение интернет-провайдерами искусственного удлинения маршрутов приводит к тому, что в атрибуте AS_PATH одна и та же АС присутствует несколько раз подряд. Для устранения избыточности в csv-файл не добавлялись связи АС с самой собой (петли).

Для создания графа Рунета были отобраны связи между российскими АС (по данным из этого источника).

После загрузки в БД имеем 15 графов для глобальной сети и столько же для Рунета. В качестве метрик выбраны:

  • количество АС

  • количество связей АС

  • максимальная степень связности АС

  • распределение степени связности АС

Количество АС

Тут без сюрпризов - линейный рост количества провайдеров во всемирной сети более чем в 3 раза. Полученные данные совпадают с результатами Джефа Хьюстона (Geoff Huston). В Рунете темп роста количества АС значительно замедлился в 2012-2013 годах - интернет-провайдеры стали появляться реже.

Количество связей АС и максимальная степень связности АС

Вместе с количеством вершин растет и количество связей, это ожидаемо.

В глобальной сети максимальная степень связности АС за 15 лет выросла почти в 3 раза, однако рост нельзя назвать линейным: в 2008, 2016 и 2019 годах зафиксированы ее уменьшения.

В Рунете максимальная степень связности выросла более чем в 5 раз, и это без учета связей с зарубежными АС! На графике хорошо виден спад максимальной степени связности в 2012 году, после которого выйти на прежнее максимальное значение получилось только к 2016 году.

Распределение степени связности АС

Предложенная учеными Альбертом-Ласло Барабаши и Рекой Альберт модель безмасштабного (scale-free) графа адекватно описывает граф связей АС. В этой модели степени вершин распределены в соответствии с показательным законом и учитывается принцип предпочтительного присоединения: чем больше степень вершины в графе, тем больше вероятность появления инцидентных ей ребер. Учитывая контекст повествования, можно сказать - чем крупнее интернет-провайдер, тем быстрее растет его связность.

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

Посмотрев на картинки, можно с уверенностью сказать - закономерности роста Рунета соответствуют закономерностям роста глобальной сети.

В планах - с применением граф-ориентированных алгоритмов из библиотеки Graph Data Science попытаться в графе АС найти следы пиринговых войн, а также построить модель для предсказания связей между интернет-провайдерами.

Всем графов!

Подробнее..

Организация удалённой работы BIM-команды посредством HPE Edgeline, NVIDIA, VMware

11.04.2021 12:12:58 | Автор: admin

В РФ ведётся широкое внедрение цифрового строительства и использование цифровых моделей здания (BIM building information modelling) на законодательном уровне. Например, с 18 марта 2021г. вступило в действие Постановление Правительства РФ от 05.03.2021 331 "Об установлении случая, при котором застройщиком, техническим заказчиком, лицом, обеспечивающим или осуществляющим подготовку обоснования инвестиций, и (или) лицом, ответственным за эксплуатацию объекта капитального строительства, обеспечиваются формирование и ведение информационной модели объекта капитального строительства". Выбор технической базы для внедрения новой технологии должен быть оправдан технико-экономическим обоснованием. Подобными исследованиями занимаются зарубежные интеграторы. Данная заметка является вольным переводом исследования от независимого системного архитектора Томаса Поппельгаарда.

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

Новые предложения от компании HPE имеют расширенные возможности графического процессора с HPE Proliant m750 и предоставляют выделенный графический процессор от NVIDIA, адаптированный для видеокарт NVIDIA P1000 или NVIDIA T4. Это решение разработано для удовлетворения требований опытных дизайнеров, архитекторов и 3D-дженералистов.

Для организации удалённой работы с высокопроизводительными графическими приложениями HPE имеет 3 аппаратных решения в различных исполнениях по форм-фактору:

  • HP Moonshot 1500;

  • HPE Edgeline EL4000;

  • HPE Edgeline EL8000 / EL8000t.

VMware уже поддерживает установку на серверах без предустановленной операционной системы (bare-metal). Применительно к BIM, данный функционал требует внимательного рассмотрения. 4 недели назад HPEобъявило об официальной поддержке выпускаемого ПО VMware Horizon на bare-metal в HPE Moonshot.

Архитектура HPE Edgeline и VMware Horizon 8

HPE Edgeline и VMware Horizon показывают на рисунке ниже, что вы можете использовать VMware Horizon cloud, но он также полностью поддерживается инфраструктурой On-Premise VMware Horizon, если у вас есть для этого требования. Вы можете использовать тонкий клиент от HP 740, который является лучшим аппаратным тонким клиентом на рынке, который также может декодировать несколько мониторов 4K без каких-либо неудобств для пользователя. Самое замечательное в нижеприведенной архитектуре заключается в том, что вы можете иметь 4 физических рабочих станции в 1U, установленных в вашем центре обработки данных или ином расположении, без ущерба для пользовательской виртуализации. Сила bare-metal в том, что вы выжать максимум от возможностей оборудования. Функциональная схема такой системы показана ниже.

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

Коротко о HPE Proliant m750

В модели HPE m750 установлен 8-ядерный процессор AMD16-core с технологией Hyper-threading, что вдвое больше по сравнению с оборудованием, выпущенными за последние 7 лет. Это пригодится пользователям, которым требуется многопоточность, и тем, кто работает с HCI или виртуализацией. Платы также могут быть сконфигурированы с NVMe емкостью до 16 ТБ, что наводит на мысли о невероятно малом форм-факторе и о том, как мало энергии он потребляет (максимум 90 Вт). HP m750 также работает под управлением любой операционной системы и гипервизора. Также он использует iLO 5, используя который системный администратор имеет большее удобство в управлении сервером.

Коротко о NVIDIA T4

NVIDIA T4 - это однослотовый графический процессор от NVIDIA, использующий архитектуру Тьюринга от NVIDIA и являющийся частью серии Quadra. Этот графический процессор обладает возможностями RTX и адаптирован для трассировки лучей в реальном времени. Графический процессор имеет 16 ГБ выделенного кадрового буфера GDDR6, который требуется для высокопроизводительных САПР-приложений. Драйвера Nvidia Т4 могут быть использованы и в bare-metal, и на виртуальных машинах. В сочетании с NVIDIA vGPU буфер кадров может быть разделён на сегменты от 2 ГБ до 16 ГБ. Это означает, что вы можете запустить до 8 виртуальных пользователей. Идея в том, чтобы дать пользователю выделенную мощность m750 (5 ГГц CPU 8c/16c, до 16 ТБ NVMe, объём памяти 64 ГБ) и заставить его перейти в удалённый центр обработки данных. NVIDIA T4 требует лицензий vGPU как в установке bare-metal, так и в виртуализированной среде.

Тестирование HPE Edgeline m750 + GPU от Nvidia с VMware

Для тестирования были выбраны следующее оборудование: HPE m750 с процессором Intel Xeon и встроенным графическим процессором Intel P630, NVIDIA P1000. В качестве программного обеспечения, устанавливаемого на серверную платформу, использовались Windows 10 1909 и VMware Horizon 8.

Суммарный перечень программ, используемых в тестировании на быстродействие удалённого рабочего места:

  • Adobe Photoshop CC 2020 с дополнением Puget System;

  • Autodesk Inventor Professional 2020 с дополнением Inventor;

  • Furmark (OpenGL);

  • SPECworkstation 3;

  • SPECviewPerf3;

  • Basemark GPU;

  • Unigine Superposition.

Итог тестирования

Гибкость развертывания bare-metal (m750/P1000) или сборки с виртуализацией (m750/T4) измерялась в зависимости от требований приложения и по показателю изменения соотношения вычислений к загрузке графического процессора. Виртуализация на EL4000/m750/T4 оказалась экономически эффективным методом централизации и предоставления удаленного доступа для пользователей САПР малого и среднего бизнеса. Вы можете использовать либо 1-2 блока EL4000 настенного монтажа для небольшого числа пользователей (до 32), либо укладывать до 20 блоков в стойку для смешанного развертывания до 300 пользователей. Как оборудование будет располагаться в 19" стойке отражено на картинке ниже.

Для программ Autodesk Revit 2020, Autodesk Navisworks 2020, Autodesk Inventor 2020, Autodesk 3DSMax 2020 HP T740 обеспечивает лучшее отображение на 2-х 4K-мониторах при работе пользователя VMware Blast Extreme для m750 с NVIDIA P1000. У пользователя есть возможность работать с HP Thinpro с помощью клиента VMware Horizon. NVIDIA P1000 обеспечивает отличную работу с BIM-образцами средней детализации. Если клиентам требуются более крупные наборы данных, то NVIDIA T4 является предпочтительным выбором для использования с HPE m750. NVIDIA vGPU является предпочтительным выбором, если клиенты хотят масштабировать свой центр обработки данных и достичь высокой плотности пользователей виртуальных машин с максимальной производительностью.

В процессе тестирования наблюдалось изменение полосы пропускания с пиками до 30 Мбит/с на пользователя при изменении масштаба или вращении больших визуальных объектов в САПР-приложениях. Протокол VMware blast адаптируется и оптимизируется из коробки в последней версии с 2D/3D приложениями и не требует настройки оптимизации. При переходе от dual HD к dual 4K следует учитывать, что пропускная способность будет использоваться в 4 раза больше.

Рекомендации

Решение 1 предназначено для клиентов, которые хотели бы использовать процессор 5 ГГц для приложений с высокими требованиями производительности и для работы с 2D-графикой на отдельном процессоре. Например, AutoCAD, 4K video, Office365. Предлагаемый сервер вместе с VMware Horizon обеспечивает отличную производительность даже на мониторах 4K, где VMware обеспечивает аппаратную возможность декодирования как с процессором, так и с графическим процессором.

Решение 2 предназначено для клиентов, использующих базовые возможности САПР таких как AutoCAD, Revit, Navisworks, Inventor. Видеокарта NVIDIA P1000 обеспечивает отличную производительность с VMware Horizon и декодированием GPU из коробки на мониторах 4K.

Решение 3 предназначено для клиентов, которые использующих расширенные возможности работы с AutoCAD, Revit, Navisworks, Inventor. Виртуализация m750, сочетание технологии NVIDIA T4 с технологией vGPU, работающей на VMware vSphere - отличное решение, масштабируемое от 4 до 32 пользователей. Клиенты получают лучшую производительность за эти деньги, так как они могут эффективно использовать аппаратное обеспечение. Трассировка лучей в реальном времени также поддерживается NVIDIA vGPU но для более высоких рабочих нагрузок рекомендуется использовать большие фреймбуферы.

Решение 4 предназначено для клиентов, использующих высокопроизводительные приложения, такие как Autodesk VRED, Maya, Arnold, 3DSMax или Dassault Catia. Решение полностью поддерживает трассировку лучей в реальном времени, поскольку графический процессор NVIDIA T4 способен обеспечить эти возможности. Это решение также предпочтительно, если клиенты хотят использовать VR-решения, такие как NVIDIA CloudXR, где они могут объединить его с VMware Horizon.

Подробнее..

VxLAN фабрика часть 5. Multisite

12.04.2021 14:15:58 | Автор: admin

Привет, Хабр! Наконец заканчиваю цикл статей,посвященных запуску курса"Дизайнер сетей ЦОД"от OTUS, по технологии VxLAN EVPN. И сегодня обсудим реализацию подключений различных ЦОД или сайтов.

Предыдущие части цикла можно найти по ссылкам:

1 часть цикла - L2 связанность между серверами
2 часть цикла - Маршрутизация между VNI
2.5 часть цикла - Теоретическое отступление
3 часть цикла - Подключение внешнего маршрутизатора/firewall
4 часть цикла - Multipod



Сегодня рассмотрим второй способ подключение различных ЦОД - Multisite.

Для начала вспомним как строится Underlay при построении фабрики с помощью Multipod. И снова получаем несколько вариантов построения такой сети. То есть:

  1. Underlay сеть может быть единой и, например, использовать OSPF для IP связанности между всеми устройствами в фабрике.

  2. Underlay повторяет логику BGP для настройки EVPN и каждый POD находится в своей AS, как показано на рисунке ниже

Однако, вспоминая предыдущую часть, приходим к тому, что во всех случаях возникают свои проблемы. Так в 1 случае, при едином OSPF процессе, может появиться слишком большое количество устройств (например более 100-150 устройств) и динамическая маршрутизация станет работать заметно медленнее и больше нагружать сетевые устройства. Во 2-м случае возникает еще больше проблем (ниже указаны не все проблемы, а только основные):

  1. Смена Next-Hop. С использованием eBGP, при выходе update из AS, Next-hop меняется. То есть не забываем делать соответствующие настройки;

  2. Общая проблема для обоих случаев - значение Route-target в автоматическом режиме работать не будет. То есть необходимо использовать статическую настройку, однако это решается автоматизацией таких настроек и сети в целом;

  3. С увеличением количества клиентов, увеличивается и количество MAC/IP адресов и BUM трафик соответственно.

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

Для начала обсудим какие преимущества дает сегментация сети:

  1. Уменьшение домена рассылки Broadcast для поиска какого-либо клиента сети;

  2. Упрощается объединение различных подов через сеть интернет;

  3. Проблемы в одном сайте никак не влияют на другой сайт;

  4. Так как теперь каждый сайт независим от другого, то возможно использовать на одном сайте ingress replication, а на другом Multicast. То есть ЦОДы с различными технологиями объединяются без каких-либо проблем миграции.

Осталось разобраться как работает данная технология. Для начала рассмотрим теоретическую часть.

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

Но на самом деле, поставить BGW возможно в любое место в сети, главное обеспечить IP связанность

Осталось разобраться как же это все работает. Однако, для начала вернемся к предыдущим частям и вспомним как все работает в рамках одного POD. В одном POD тоннель устанавливается напрямую между VTEP, как показано ниже и LEAF коммутаторы напрямую обмениваются информацией о MAC/IP адресах.

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

Получается что в Multisite тоннель от Leaf строится до BGW, далее BGW строит совершенно другой тоннель до второго BGW, находящего на другом сайте, и далее строится еще один тоннель уже в рамках другого сайта. Именно такая логика работы, когда между сайтами строится отдельный тоннель, позволяет сегментировать сеть, упростить поиск и устранение неисправностей, так как удаленный сайт полностью скрывается за 1 устройством(но рекомендуется использовать как минимум 2 BGW на каждом сайте для отказоустойчивости). Далее перейдем к настройке BGW, так как все остальные устройства не меняют свою настройку и никакие изменения на них не совершаются. Для начала на BGW необходимо включить следующие feature:

feature ospf - для организации Underlay в своем сайте

Настройка самой Underlay сети в данном разделе рассматриваться не будет, так как ничем не отличается от обычной реализации пода. При этом для IP связанности так же можно использовать IP unnumbered или адреса на point-to-point линках с маской /30 или /31.

После настройки Uderlay сети на BGW необходимо указать интерфейс, который смотрит в локальный сайт:

Interface Ethernet1/50description SITE-INTERNALevpn multisite fabric-tracking - указываем где находится локальный сайт

Далее готовим настройки для Overlay сети. Выглядят они практически аналогично настройкам на Leaf коммутаторах. В целом это логично, так как BGW так же имеет роль VTEP.

feature bgpfeature nv overlaynv overlay evpn

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

evpn multisite border-gateway <site-id> номер сайта одинаковый у всех BGW в одном сайте

Продолжаем настройку BGW и создаем интерфейс NVE

interface nve1  host-reachability protocol bgp  source-interface loopback1 - как и на LEAF, интерфейс используется для построения тоннеля в рамках своего сайта  multisite border-gateway interface loopback100 - новая настройка, используется для построения тоннеля между сайтами

Если у вас есть несколько BGW(а их должно быть хотя бы 2), то loopback100 должен иметь одинаковый адрес на всех устройствах с этой ролью - anycast адрес для сайта

Далее настраиваем протокол BGP для работы в локальном сайте. Настройка ничем не отличается от настройки на других устройствах в сетевой фабрике:

router bgp 65501  neighbor 10.100.100.201    remote-as 65501    update-source loopback0    address-family l2vpn evpn      send-community      send-community extended   neighbor 10.100.100.202    remote-as 65501    update-source loopback0    address-family l2vpn evpn      send-community      send-community extended

На данном этапе мы произвели настройки необходимые для первого тоннеля между LEAF и BGW

Переходим ко второй части настройки - тоннель между сайтами. Сразу уточню, что этот тоннель всегда должен работать только в режиме ingress replication.

interface Ethernet1/1  evpn multisite dci-tracking - команда указания, что интерфейс является внешним локального сайта и смотрит в сторону второго сайта

Последнее, что осталось настроить - BGP соседство со вторым сайтом:

router bgp 65501  neighbor 10.52.52.52 - удаленный сосед    remote-as 65036    update-source loopback0 - устанавливаем так же с loopback    ebgp-multihop 5    peer-type fabric-external - указываем, что удаленный пир, относится к фабрике в другом сайте    address-family l2vpn evpn      send-community      send-community extended      rewrite-evpn-rt-asn - Так как можем использоваться автоматическая настройки RT, то его необходимо изменить на новое значение

Напомню, что RT - это route-target и в автоматическом режиме формируется из двух значений AS:VNI

Аналогично необходимо завести всех остальных соседей в других сайтах. При этом необходимо настроить Full-Mesh между всеми маршрутизаторами с ролью BGW во всех сайтах. Либо возможно использовать Route-reflector в eBGP. Настройка RR выглядит следующим образом:

router bgp 65036  address-family l2vpn evpn    retain route-target all - принимаем все анонсы с любом RT  template peer OVERLAY-PEERING    update-source loopback0    ebgp-multihop 5    address-family l2vpn evpn      send-community both      route-map UNCHANGED out - запрещаем менять значение атрибута Next-Hop neighbor 10.100.100.21 remote-as 65501    inherit peer OVERLAY-PEERING    address-family l2vpn evpn      rewrite-evpn-rt-asn - так же переписываем значение RT, при автоматическом режиме установки RTroute-map UNCHANGED permit 10 - route-map в котором указываем запрет смены NH  set ip next-hop unchanged 

Этап выше настраивает тоннель между сайтами, как показано на рисунке ниже:

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

  1. Вариант, что рассмотрели выше, без каких-либо настроек;

  2. VPC BGW - до 2-х устройств;

  3. Anycast BGW - до 4-х устройств.

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

Далее рассмотрим оставшиеся 2 подхода к реализации BGW и начнем с VPC BGW:

  • только 2 устройства с физическим Peer-link и keepalive link(возможно использовать виртуальный, однако с точки зрения надежности я бы рекомендовал использовать прямой физический канал), что добавляет еще больше линков, нежели в 1 варианте подключения;

  • Используется для небольших внедрений

Настройка VPC ничем не отличается от настройки VPC на Leaf коммутаторах. Так же требуется на интерфейсе Loopback создать secondary адрес, до которого будет строится VxLAN тоннель.

Anycast BGW и тут может возникнуть вопрос, чем же Anycast лучше. Разберемся по порядку. :

  • до 6 устройств BGW в одном сайте;

  • простой сценарий отработки проблем в сети, то есть все устройства независимы друг от друга, в отличии от VPC(да-да, там тоже разный Controle-Plane, однако это не спасает от багов);

  • сеть любой сложности;

  • простое развертывание с нуля устройств BGW, не влияя на сеть в целом.

То есть все устройства BGW Anycast прячутся за одним виртуальным адресом, как показано на рисунке ниже

Настройка мало чем отличается от реализации рассмотренной в начале данного материала:

 interface loopback100 - интерфейс указанный как multisite border-gateway description MULTI-SITE INTERFACE  ip address 10.10.10.10/32 - одинаковый адрес на всех BGW  ip router ospf UNDERLAY area 0.0.0.0 - IP связанность в рамках локального сайта

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

Ниже предлагаю пройти опрос, на какой стадии использования VxLAN EVPN вы сейчас находитесь.

Подробнее про работу технологии можно посмотреть в RFC-7432 и в draft-ietf-bess-evpn-overlay, draft-ietf-bess-evpn-prefix-advertisement, draft-ietf-bess-evpn-inter-subnet-forwarding


Современная IT инфраструктура все больше виртуализируется, уплывая в Облака. Модели "все как сервис"- SaaS, PaaS, IaaS используются повсеместно, но все эти решения, по-прежнему используют сети передачи данных и машинные ресурсы для их обработки. За последние 20 лет, сети ЦОД, претерпели множество изменений, с которыми попробуем познакомиться ближе и разобрать основные технологические этапы этой эволюции с присущими им технологиями и архитектурными решениями в рамках бесплатного демо-урока по теме: "Эволюция сетевых технологий в ЦОД".

Записаться на демо-урок

Подробнее..

Категории

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

© 2006-2021, personeltest.ru