Сетевое оборудование

Как устроено тестирование телеком-продуктов

Есть множество видов тестирования, их классифицируют по различным признакам: уровню, целям, степени автоматизации, знаниям о системе, а также типу проверяемых сценариев (функциональные и нефункциональные). Расскажем подробнее о реализации разных видов тестов, которые проводятся в лабораторных условиях: 

• Модульные (unit) и компонентные (component) тесты реализуют сами разработчики. Они позволяют проверить корректность работы отдельных модулей и компонентов на ранней стадии.

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

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

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

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

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

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

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

«Ростелеком» уточнил, что при аномально высоком трафике, в десятки или сотни раз превышающем средний уровень, скорость интернета может быть временно снижена. Это необходимо для проверки и защиты сетевой инфраструктуры, чтобы обеспечить стабильное предоставление услуг всем пользователям, согласно п. 3.4.11 Единых правил оказания услуг.

Этот пункт гласит, что «в случае создания абонентом значительной нагрузки на сеть связи, в том числе с использованием протоколов peer-to-peer», оператор не может гарантировать скорость передачи данных.

Control Plane и User Plane в мобильной связи: зачем нужны два типа трафика и как они работают

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

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

Физически между базовой станцией и опорной сетью проходят два потока:

• Control Plane — управляющий трафик. Отвечает за процедуры подключения к сети, аутентификации, переключения между станциями, сессий и т. д.

• User Plane — пользовательский трафик. Это все, что идет от приложений пользователя: стриминговые сервисы, мессенджеры, браузер и так далее.

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

В статье Елена Степанова, ведущий инженер-программист в YADRO, объясняет, чем опорная сеть отличается от базовой станции, зачем в 5G сотни микросервисов и как устроена архитектура мобильной связи.

Какую информацию содержит FRU EEPROM и как с ней работать

Набор возможных данных, хранимых во FRU EEPROM, определяется спецификацией Intel IPMI FRU Information Storage. Вся информация разделена на пять областей, присутствие каждой из которых не обязательно и определяется информацией в общем заголовке FRU EEPROM, где размещены указатели на данные каждой из них в следующем порядке:

1. Область для внутреннего использования (Internal Use Area) — ее
содержимое не описано спецификацией. Предполагается, что эта часть EEPROM может использоваться программным обеспечением BMC или другого контроллера на плате для хранения какой-то служебной информации (например, внутренних состояний).

2. Область информации о шасси (Chassis Information Area) — здесь содержится базовая информация о «корпусе» или «шасси» устройства, описываемого этим FRU EEPROM. Основным параметром тут является «тип шасси», который представляет собой целое число, выбираемое согласно спецификации SMBIOS (см. DMTF DSP0134, Table 17). Например, значение 0x17 соответствует типу «Rack Mount Chassis». Также в этой области может содержаться информация о серийном номере шасси и его артикуле (part number).

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

Какие еще есть области во FRU EEPROM, и как утилита frugen и библиотека libfru помогают с ними работать — читайте в статье Александра Амелькина, технического эксперта департамента разработки BIOS и BMC в компании YADRO, а также автора и мейнтейнера проекта frugen / libfru.

Уязвимость в протоколе REALITY XTLS/Xray-core: быстрый фикс уязвимости Aparecium

На прошлой неделе была обнаружена уязвимость в известном ПО для создания прокси соединений XTLS/Xray-core, а именно в протоколе REALITY, позволяющая выявлять работу этого протокола.

Для тех, кто не в курсе: REALITY — это уникальный протокол прокси, который позволяет маскировать прокси-трафик под легитимное посещение реальных сайтов (например, google.com или любого другого), при этом не требуя покупки домена и настройки TLS-сертификата на своем сервере.

Обнаружение уязвимости

В начале июня 2025 года исследователь под ником ban6cat6 опубликовал утилиту под названием Aparecium. Ее цель — находить серверы, использующие протоколы вроде REALITY.

В чем была суть уязвимости?
Утилита обнаружила, что серверы на базе OpenSSL после завершения основного TLS-рукопожатия (handshake) обычно отправляют клиенту один или два служебных сообщения NewSessionTicket. Это стандартное поведение, позволяющее возобновлять сессии. Протокол REALITY в своей реализации это поведение не имитировал.

Это тонкое различие позволяло Aparecium с высокой точностью отличать настоящий веб-сервер от сервера с REALITY, просто проанализировав последовательность TLS-сообщений.

Быстрый фикс

Информация об уязвимости была опубликована в виде issue #4778 в репозитории Xray-core. Разработчики, в частности RPRX, отреагировали практически молниеносно.

Вместо того чтобы добавить отправку фейковых NewSessionTicket, они пошли по более правильному пути. Уже через несколько дней в версии Xray-core v25.6.8 появилось «предварительное» решение:

Теперь при первом запуске сервер REALITY, используя отпечаток клиента Chrome, сам подключается к целевому сайту (dest), «подсматривает», какие именно post-handshake сообщения и какой длины тот отправляет, кэширует эту информацию и в дальнейшем идеально имитирует именно это поведение.

На это «зондирование» уходит около 30 секунд при первом старте сервера, но оно по большей части решает основную проблему. Вместе с этим был исправлен и неприятный баг с производительностью из-за неработающего аппаратного ускорения AES-NI.

Глубокий анализ

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

1. Загадка «лишнего пакета» от bilibili.com
   Один из разработчиков заметил, что при подключении к некоторым сайтам (например, bilibili.com) с отпечатком Chrome, сервер возвращает не только NewSessionTicket, но и еще один небольшой пакет. После анализа выяснилось, что это не TLS-сообщение, а кадр настроек HTTP/2 (settings frame). Это значит, что для идеальной маскировки нужно имитировать не только TLS-уровень, но и поведение прикладного протокола (HTTP/2), который был согласован в ходе рукопожатия.

2. Проблема разных отпечатков (fingerprints)
   Выяснилось, что один и тот же сайт может по-разному отвечать на ClientHello от разных клиентов. Например, на запрос с отпечатком Chrome он может отправить два NewSessionTicket и settings фрейм, а на запрос от Go-клиента — только один NewSessionTicket. Похоже, что статического зондирования недостаточно.

3. Идея «живого обучения»
   В ходе мозгового штурма родилась идея для долгосрочного решения, которое было оформлено в issue #4788. Суть в том, чтобы сервер REALITY, получив ClientHello от нового клиента, не просто использовал стандартный отпечаток для зондирования, а копировал отпечаток реального клиента и именно с ним обращался к целевому сайту. Это позволит динамически адаптироваться под любого клиента и достичь практически идеальной мимикрии.

Разработчики рекомендуют всем обновить сервера и клиенты, использующие Xray-core, до версии 25.6.8.

На GitHub опубликовали новый инструмент для обнаружения протоколов маскировки TLS Он получил название Aparecium и способен выявлять ShadowTLS v3 и REALITY, которые маскируют зашифрованный трафик под легитимный TLS 1.3.

Aparecium использует особенности реализации TLS, чтобы обнаружить аномалии в поведении протоколов маскировки. ShadowTLS и REALITY, например, часто не обрабатывают отправляемые сервером сообщения NewSessionTicket должным образом, что позволяет выявить их использование.

Серверы на базе OpenSSL отправляют два сообщения NewSessionTicket одинаковой длины в одном TCP‑пакете, что также является характерной особенностью, отсутствующей в протоколах маскировки.

Продолжая тему взаимодействия с MITRE насчёт CVE. В прошлый раз я обращался к MITRE из-за нежелания вендора Docker создавать CVE. Теперь же я попытался внести уточнение к существующей записи CVE-2018-14847, описание которой не слишком точное:

MikroTik RouterOS through 6.42 allows unauthenticated remote attackers to read arbitrary files and remote authenticated attackers to write arbitrary files due to a directory traversal vulnerability in the WinBox interface.

По такому описанию можно подумать, что уязвимы абсолютно все версии ниже 6.42. На самом деле это не так. Более точное описание есть у вендора MikroTik:

Versions affected:

• Affected all bugfix releases from 6.30.1 to 6.40.7, fixed in 6.40.8 on 2018-Apr-23

• Affected all current releases from 6.29 to 6.42, fixed in 6.42.1 on 2018-Apr-23

• Affected all RC releases from 6.29rc1 to 6.43rc3, fixed in 6.43rc4 on on 2018-Apr-23

Но, и оно не совсем правдивое. Как минимум версия 6.28 уязвима (проверял используя этот эксплоит). Я обратился в MITRE через эту форму (выбрал "Request an update to an existing CVE Entry"), объяснив всё это. В итоге MITRE лишь добавили ссылку на описание уязвимости от вендора (обновление от 28.04.2025). Это в очередной раз подтверждает, что при оценке угроз не стоит полностью полагаться ни на CVE, ни на информацию от вендора. О чём говорю не только я. Был у меня личный опыт, показывающий неточность в описании уязвимых версий со стороны вендора: Cisco UCS Manager. А если пытаться смотреть на CVE, указанные вендором по этой проблеме - так каши в голове становится лишь больше: в CVE речь о версиях bash (а какая версия bash в какой прошивке и оборудовании есть - в CVE не указывается).

Как тестируют функцию Circuit Switched Fallback, которая помогает общаться с родственниками

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

Что происходит в сети оператора при таком звонке:

• Телефон отправляет на базовую станцию (eNB) вызов.

• Базовая станция связывается с ядром сети (MME) и запрашивает процедуру CSFB для исходящего звонка, дожидается от ядра сети подтверждения о возможности такого перехода.

• После этого отправляет телефону информацию о новом подключении к 2G-сети, которое он должен установить.

• После этого базовая станция завершает обслуживание абонента в 4G-сети, обслуживание переходит к станции 2G.

• Голосовой вызов осуществляется через 2G-сеть.

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

Симулятор позволяет автоматизировать этот этап тестирования и увеличить скорость тестов и повторяемость результатов. CSFB — это базовая функциональность, поэтому проверка проходит регулярно.

Для успешной проверки CSFB задачу декомпозируют, разделяют на уровни. О двух других ступенях «пирамиды» — тестировании в GSM-сети и системном тестировании — рассказала инженер YADRO Анастасия Беднова в своей статье.

Мы используем коммутаторы Arista с rear-to-front обдувом, что очень удобно для кабель-менеджмента, поскольку вся укладка кабелей как правило происходит с тыльной стороны стойки, при этом спереди всё выглядит минималистично и без проводов. Но вот что бывает когда стойка узкая, в нашем случае всего 600мм. Стойка, кстати, российского бренда NTSS. По бокам есть Zero-U лотки для крепления PDU, но они недостаточно утоплены вглубь. Да и PDU достаточно жирные — APC 8886. Мы также попробовали установить родные PDU от NTSS, но проблему это не решило.

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

Что делать — непонятно. На ум приходит только спилить эти уши, но в таком случае свитчи уже будет невозможно прикрутить к стойке. Ставить свитчи вперёд тоже плохое решение, особенно с точки зрения кабель-менеджмента, да и потребуется заменить 18 блоков питания и 36 вентиляторов чтобы развернуть направление обдува :(

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

Ставить горизонтальные PDU вместо вертикальных тоже не хотим, это усложнит кабель-менеджмент.

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

Самое печальное, по моему личному опыту, что в 99% случаев в аренду предлагают стойки шириной 600мм, не больше. А если хочешь шире — то разница в цене будет огромная, так как такая стойка занимает уже больше одной плитки. Да и в текущих реалиях ЦОДы забиты, мест для таких стоек крайне мало.

Что интересно, даже новые ЦОДы везде повально экономят на ширине стоек и ставят эти несчастные 600мм узкие стойки.

Коллеги, если вы знаете, что такое TAP и SPAN, вам не безразличны вопросы зеркалирования и оптимизации сетевого трафика, а ещё хочется узнать, как в этом помогают брокеры сетевых пакетов, то 23 апреля мы ждем вас на техническом вебинаре, где мы подробно обсудим эти темы. А ещё помимо слайдов с картинками будет живая демонстрация работы ответвителей трафика DS TAP и пакетных брокеров DS Integrity в связке c системой анализа сетевого трафика PT NAD.

Зарегистрироваться нужно тут, присоединяйтесь!

Средний счет за домашний интернет в США в 2024 года составлял для домохозяйств около $78 в месяц, по данным CNET.

Тест на тестировщика: что в коробке?

Ответ: Это Shield box — экранированная коробка, внутри которой размещаются сотовые телефоны. Ее используют тестировщики телеком-оборудования. Коробка обеспечивает изоляцию сигнала и предотвращает возможность подключения сторонних абонентов к «тестовой» сети.

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

→ Некоторые из них требуют образования по специальностям Радиотехнологии или Телекоммуникации и опыта работы с системами GSM/LTE. 

Test Engineer (LTE/GSM Radio Subsystem)

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

Field Test Engineer (LTE/GSM) 

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

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

Test Engineer (Performance Test)

Команда занимается тестированием собственного железа и ПО. Направление создает конкурентную линейки RAN-продуктов для мобильных сетей последних поколений — базовые станции LTE/GSM и удаленные системы управления ими. Опыт работы с телекоммуникационными системами GSM/LTE будет преимуществом. 

QA Automation Engineer 

Команда ищет инженеров по автоматизированному тестированию в несколько команд в направление разработки решений для телекоммуникаций. Необходимый опыт в автоматизации с использованием Jenkins GitLab — от двух лет. Здесь ждут кандидатов с уверенным знанием Python, Linux и пониманием сетей, базирующихся на TCP/IP.

Test Engineer Manual 

Вам больше по душе ручное тестирование? Есть вакансия и для вас. Здесь ждут кандидатов с уверенным знанием теории тестирования (опыт — от трех лет), Linuх и пониманием сетей, базирующихся на TCP/IP.

О направлении 

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

А как тестируют функции базовой станции, читайте по ссылке → 

3 факта о DS Proxima:
- L4 балансировщик с контролем состояния компонентов кластера на L7
- салатовый корпус, который светится в темноте
- уже в Реестре Минпромторга России

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

Зарегистрироваться нужно тут, присоединяйтесь!

Что ни месяц в наступившем году, то новое сообщение НКЦКИ о компрометации информационной инфраструктуры крупнейших российских компаний, связанных с ИБ.

Перед нами новое веяние в плане развития атак на цепочки поставок, — считает руководитель отдела развития продуктов «АйТи Бастион» Алексей Ширикалов.

Цепочки поставок, безусловно, остаются трендом атак, но от него отделяется ветка по атакам на поставщиков ИБ решений.

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

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

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

⚫️ Обязательно предъявляйте требования по ИБ исполнителю подряда кстати, мы уже ждём от регуляторов появления рекомендаций о необходимых средствах защиты информации, которые должны быть у подрядчика
🟠 Контролируйте доступы
⚫️ Контролируете ролевые модели
🟠 Убирайте избыточные доступы
⚫️ Отслеживайте выполняемые пользователем действия и выявляйте попытки нетипичных действий в рамках легитимных сессий (поведенческий анализ)
🟠 Персонализируйте УЗ для доступа — никаких root и т.д.
⚫️ Берегите учётки и пароли, особенно привилегированные

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

✅ Сообщили в НКЦКИ и организовали совместную работу
✅ Прекратили сетевое взаимодействие с клиентскими системами
✅ Подключили расследовательские команды, чтобы минимизировать последствия
✅ Проинформировали заказчиков, чтобы «задраили люки» на время полного расследования

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

Остаётся добавить немного из практического опыта — 15-минутный инцидент с пребыванием злоумышленника в инфраструктуре может затянуться на долгие месяцы расследования. А это ощутимый удар по бизнес-процессам, которые — в идеальной картине мира — должны продолжаться в части доступа к заказчикам, уже только после полного расследования атаки и устранения всех «хвостов».

У меня зазвонил телефон отвалился интернет.
Я пожаловадся провайдеру (большооой такой, на всю страну), провайдер прислал техника.

Техник с порога решил сыграть в продажника и заявил:
— У вашего роутера лампочки моргают одновременно, а надо чтоб вразнобой. Это значит что ваш роутер при смерти и вам нужно купить новый. А у нас есть вот такие модели: 1... 2... 3... И предложил мне купить одну из них.

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

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

Интернет поднялся.

В конце техник начал намекать что надо бы заплатить 500р. А чо, интернет же есть!
Я бы заплатил ему мимо кассы и даже в 2 раза больше. Если бы не дичь про "одновременно моргающие лампочки"...
Но увы, это был не его день.

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

Немного важной информации

Коллеги, добрый день! Я создал Telegram-канал от сетевика для сетевиков.
Если ты сетевой инженер, системный администратор, разработчик, студент или просто увлекаешься сетями — тебе сюда.

🔹 Что тебя ждет?

✅ Разборы глобальных сбоев и неожиданных сетевых проблем.

✅ Мини-статьи с полезными фишками и объяснением сложных тем простым языком.

✅ Истории из жизни сетевиков — в том числе от подписчиков (и за это я готов заплатить).

🚀 Без воды — только полезный контент. 

🚀 Без рекламы — только инженерные разборы от человека, который не раз облажался в серверной.

🚀 Анонимно — никаких продаж курсов, рекламы вендоров или компаний. Только чистая инженерная соль.

Большая просьба подписаться и позвать коллегу— будет интересно!

Ссылка на канал https://t.me/ProstoKirReal

Практический курс «Системный администратор Linux с нуля»

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

На курсе вы научитесь:

▫️ работать с командной строкой и основными утилитами;

▫️ управлять пользователями, файлами и правами доступа;

▫️ настраивать сети, SSH-соединения и мониторинг системы;

▫️ управлять инфраструктурой на базе Linux;

▫️ управлять пакетами и обновлениями программного обеспечения;

▫️ анализировать логи и устранять инциденты.

Занятия построены на базе SelectOS. Дополнительных знаний не требуется — достаточно базового владения компьютером и интереса к Linux.

Смотреть программу →

Cloudflare пока не фиксирует полного восстановления сервисов TikTok в США в рамках работы сетей связи ByteDance (AS396 986).

Ранее социальная медиа‑платформа TikTok сообщила о возвращении доступа пользователям в США. Однако возвращение приложения происходит без поддержки Apple и Google, поскольку оно по‑прежнему недоступно в App Store и Google Play.

19 января пользователи в США рассказали, что обход блокировки TikTok для них оказался очень сложным. Смена IP‑адреса не помогала, поскольку ограничение действует как по местоположению, так по стране регистрации устройства. ByteDance сама ограничила доступ к сервису по геолокации. Кроме того, бан TikTok в США ограничил доступ к сервису для пользователей из Канады.

Разработчик Python‑библиотеки TikTokLive Айзек Коган рассказал о способе обхода блокировки TikTok в США. Коган настроил прокси‑сервер в Германии и направлял все запросы в TikTok через этот IP‑адрес, чтобы обойти основные ограничения. Таким образом он получил доступ к фронтенд‑серверам, в том числе HTML‑страницам. Разработчик сделал это заранее — до бана китайской платформы.

Схема «якорного резака» — устройства для резки подводных кабелей, разработанного морскими инженерами из Университета Лишуй в Китае, 2020 год. Источник: Университет Лишуй.

Город с двумя столицами: роль ASIC и CPU в L3-коммутаторе

Внутри коммутатора два физических устройства: CPU и ASIC. CPU принято называть Control Plane, там крутится сетевая операционная система, как правило, Linux. ASIC также называют Data Plane. 

CPU (Control Plane) отвечает за:

• сложную логику,

• обработку служебного трафика,

• управление ASIC.

ASIC (Data Plane) ответственен за:

• простую логику на основе таблиц,

• быструю обработку большого числа пакетов,

• разбор заголовков, выбор выходного порта и выходного набора заголовков,

• буферизацию, очереди, политики. 

Администратор, который сидит в CLI, находится на CPU, а интерфейс, который он конфигурирует, — на соседнем устройстве ASIC.  

Для простоты понимания можно думать о физическом устройстве коммутатора как о двух соседних городах. Первый город CPU — административный центр, он управляет своим соседом. Второй город ASIC — промышленный центр с крупными транспортными развязками и светофорами. 

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

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

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

Еще больше про устройство коммутатора читайте в статьях Антона Гузарева, тимлида команды, которая разрабатывает ПО для управления сетевыми устройствами в YADRO. Через кейс с ошибкой в коммутаторе он последовательно рассмотрела каждый его уровень в двух статьях:

→ Разбираемся с железом и настройками конфигурации

→ Ищем проблему с доставкой картинок с котиками на разных уровнях L3-коммутатора: от CLI до SDK