В Китае запустили первую в мире коммерческую оптоволоконную систему, которая работает сразу в трёх диапазонах длин волн: S, C и L. Обычные магистрали задействуют преимущественно C-диапазон, поэтому одновременное использование трёх окон прозрачности сразу расширяет доступную полосу.
Вторая составляющая решения это четырёхъядерное волокно. В одном физическом волокне проложены четыре световедущих ядра, и по каждому идёт свой поток данных. Пространственное разделение каналов внутри одного кабеля умножает ёмкость без прокладки дополнительных линий.
По данным разработчиков, пропускная способность одного ядра выросла почти на 50 процентов, а суммарная ёмкость системы превышает показатели обычного одномодового оптоволокна более чем в пять раз.
Ключевой момент в том, что испытания прошли не в лаборатории, а на действующей линии длиной 35 километров. Она соединила вычислительные центры в Циндао провинции Шаньдун, то есть режим эксплуатации был близок к реальной нагрузке между дата-центрами.
Для задач машинного обучения пропускная способность межсоединений имеет прямое значение. Крупные модели обучают на кластерах из тысяч ускорителей, и скорость обмена между узлами и между дата-центрами часто становится узким местом. Более широкий канал снижает простои дорогого железа.
Если технологию удастся масштабировать, операторы и облачные провайдеры смогут поднять пропускную способность на уже проложенных трассах. Это дешевле и быстрее, чем строить новые линии с нуля.
Теперь можно отслеживать стабильность работы сайтов, серверов и приложений, размещенных в нашей инфраструктуре или на сторонних платформах.
Если что-то пойдет не так, вы сразу получите уведомление на почту, в Телеграм или Макс. О восстановлении — тоже.
Что можно мониторить:
Сайты и веб-приложения. Интернет-магазин упал ночью — узнаете сразу, а не утром по потерянным заказам.
Доступность серверов. Сервер перестал отвечать на запросы — среагируете до того, как это заметят остальные.
TCP-порты сервисов — базы данных, почта, API. База перестала отвечать — увидите до того, как приложение начнет спамить юзеров ошибками.
SSL-сертификаты. Продлите сертификат заранее — пока пользователи не заметили в браузере предупреждение о небезопасном соединении.
Проверки идут из нескольких регионов — без ложных алертов из-за временных сетевых сбоев.
Бонусом: история инцидентов по каждому сервису, дашборд с аптаймом, настройка интервала и таймаута, пауза без потери настроек. Подробнее в документации →
Стоимость — 30 ₽ в месяц за сервис, списания почасовые.
Собрал клиент AmneziaVPN для Ubuntu 22 ...и сделал это через Dockerfile, который Вы можете отредактировать для любого дистрибутива
Зачем понадобилось
Свежие блокировки Роскомнадзора отрезали меня от различных VPN, которыми я периодически пользовался для доступа к зарубежным продуктам, официально в РФ не представленным. Например, к Gemini.
Моей последней надеждой стала self-hosted Амнезия. Я восстановил доступ на всех своих устройствах, кроме одного - домашнего ПК под GPU-вычисления, работающего на Ubuntu 22.04.
Последние версии клиента AmneziaVPN 22-ю убунту не поддерживают: релизы для Linux собираются на Ubuntu 24.04, поэтому есть ограничения в поддержке дистрибутивов из-за версии glibc.
Как это может помочь другим
22-я убунта - это всего лишь пример. Если Ваши вкусы специфичны, да настолько, что AmneziaVPN не работает на выбранном дистрибутиве, докерфайл с лёгкостью можно адаптировать. Единственная дистрибутиво-зависимая часть в докерфайле - вызов apt-get
Что сделано
Я подготовил докерфайл, который из чистого образа ubuntu:22.04 устанавливает Qt и все прочие зависимости, качает репозиторий клиента AmneziaVPN, собирает проект и готовит инсталлятор. Выходная сборка, for my best knowledge, аналогична релизам авторов проекта. Вот здесь PR в официальный репозиторий со всеми объяснениями.
Я писал докерфайл в личных целях, мог что-то не учесть, открыт к критике и предложениям.
Как воспользоваться
Подготовка
Докерфайл качает официальный Qt-инсталлятор (я работал по инструкции вот здесь), поэтому потребуются активный Qt-аккаунт и IP-адрес не из РФ. Qt запрещает скачивания по российским IP-адресам. Нужно либо включить VPN, либо собирать на хостинге за пределами РФ (например, Казахстан). Да, я знаю, что это недостаток - пока не придумал, что с этим делать.
По умолчанию инсталлятор Qt смотрит на учётные данные в файле $HOME/.local/share/Qt/qtaccount.ini. Этот файл прокидывается в докер, поэтому он должен быть на машине для сборки. Если этого файла нет, можно перед запуском докера скачать любой GUI/CLI установщик Qt и пройти в нём страницу логина. Если не хочется возиться с инициализацией аккаунта на машине, то я оставил лазейку по прямой передаче логопасса в докер.
Сборка
Скачать мой форк репозитория, перейти в папку с ним и запустить докер.
Голландская полиция совместно с NCSC-NL отключила прокси-ботнет из 17 миллионов устройств. Это одна из крупнейших операций по выводу из строя вредоносной инфраструктуры.
Перехват C2. Следователи получили наводку и выяснили, что более 200 управляющих серверов физически размещены у местного нидерландского хостинг-провайдера. Вместо блокировок на уровне DNS полиция просто арестовала сами серверы, физически отключив командную инфраструктуру.
Инфраструктура оказалась связана с сервисом Asocks, который продавал доступ к миллионам IP-адресов. Через зараженные устройства злоумышленники прогоняли спам, фишинг, организовывали DDoS-атаки и обходили антифрод-системы банков и маркетплейсов.
Зараженные устройства. В сеть массово угоняли роутеры, IoT-камеры, смартфоны и ПК. География огромная — затронуто 163 страны. Вредонос превращал их в резидентские прокси. Устройства работали как скрытые exit-узлы, обеспечивая преступникам анонимность в сети.
Вы попали в следующую ситуацию: граница, проверка, оператор просит разблокировать телефон. Отказаться нельзя или невыгодно. Что можно?
Стандартные ответы у мессенджеров слабые. Обычный app-lock PIN открывает то же приложение, под принуждением бесполезен. «Удалить аккаунт по PIN» лучше, но видно что что-то стёрто. Облачные TTL текущий запрос не закрывают.
В RCQ сделали по-другому. Локальная история шифруется AES-256-GCM, ключ выводится из PIN’а через PBKDF2-HMAC-SHA256 на 400к раундов с per-install salt в keychain. Разные PIN’ы открывают разные хранилища.
400к раундов это около секунды CPU на iPhone, достаточно медленно чтобы offline-bruteforce был дорогой. Но реальная защита это длина PIN’а: 4-значный перебирается за десятки минут на M-чипе, 8-значный за месяцы. Default 6-8 символов.
Четыре режима
Real PIN - открывает реальный аккаунт.
Decoy PIN - открывает отдельный аккаунт с собственным UIN и SQLite. Не пустой экран (пустой это сигнал), а правдоподобно освоенный: пара контактов, несколько сообщений.
Wipe PIN - тихо стирает оба SQLite, чистит keychain, дёргает DELETE /auth/account. Без подтверждений и прогресс-баров. Через 3 секунды приложение перезапускается как свежеустановленное.
Biometric - опциональная вторая дверь к real. Не совмещается с decoy/wipe (скорее для удобства).
Честно про границы
Защищает от: казуального осмотра, принуждённой разблокировки, ситуации «5 секунд до того как заберут».
Не защищает от: forensic-лаб с offline-bruteforce’ом короткого PIN’а, jailbroken устройства с активным debugger’ом, человека рядом который видел как вы вводите PIN (разумеется).
Threat model правильный: «есть несколько секунд до того как кто-то откроет приложение, дальше я не контролирую устройство». Для «forensic с неограниченным временем» нужны другие инструменты. Главное из них: не пользоваться телефоном для чувствительных переписок вообще.
Стек живёт в RCQ, открытая бета на iOS. Код открытый: github.com/rcq-messenger/rcq-ios. Про маскировку самого факта установки приложения будет отдельно.
YouTube начал требовать отключить средства обхода блокировок для просмотра видео. Ограничение касается каналов с жёсткими региональными правами на контент: в первую очередь спортивных — «Формула 1», некоторые футбольные лиги, отдельные музыкальные лейблы. Это каналы, где рекламодатели платят за показы в конкретных странах, а правообладатели продают лицензии по регионам. YouTube обязан контролировать, из какой страны смотрит зритель, — иначе нарушаются условия лицензий.
Для обычных видео — летсплеев, обзоров, подкастов, авторского контента — ничего не изменилось. Средства обхода блокировок работают как прежде. Явление касается единичных каналов с крупными медиапартнёрами и существует уже не первый год — просто периодически всплывает у новых пользователей и вызывает волну тревоги.
Прятать данные в TLS-трафике: как выглядит настоящий стелс
Больше 70% интернет-трафика — зашифрованный TLS. Это не баг, это фича: тонны HTTPS-соединений, WebSocket-потоков, мобильных приложений и игровых клиентов создают идеальный фон для передачи данных без привлечения внимания.
Идея простая: если нужно спрятать дерево, прячь его в лесу. В случае интернета этот лес состоит из миллионов TCP/443-соединений, которые выглядят настолько обычно, что именно это делает их интересной средой для экспериментов.
Почему TLS-трафик — удобная маскировка
TLS скрывает содержимое пакетов. DPI может видеть метаданные — размер, timing, SNI в Client Hello, но не payload. Если ваше соединение выглядит как обычный HTTPS-запрос или долгоживущий WebSocket, оно сливается с фоном.
Практическая сторона: можно передавать данные внутри легитимных TLS-сессий, используя существующие протоколы как транспорт. Это не новая идея — стеганография в сетевых протоколах обсуждается десятилетиями, но TLS даёт дополнительный слой: шифрование на уровне протокола скрывает структуру payload от внешнего наблюдателя.
Где это может быть полезно
Обход блокировок в странах с жёстким DPI — если трафик неотличим от обычного HTTPS, его сложнее фильтровать
Распределённое хранилище данных в трафике — архивные данные можно держать не на диске, а в виде пакетов, циркулирующих между нодами
Covert channels для исследований в области безопасности — тестирование систем мониторинга и обнаружения аномалий
Технические ограничения и риски
Главное ограничение — timing и packet size analysis. Если трафик выглядит нетипично по объёму или интервалам, статистические методы могут его вычислить. Traffic shaping помогает, но не решает проблему полностью.
Второе — легитимность. Если используешь чужую инфраструктуру или протоколы без согласия провайдера, это может нарушать ToS. В корпоративной среде такие эксперименты быстро привлекут внимание security-команды.
Третье — надёжность. Пакеты теряются, соединения рвутся, данные нужно восстанавливать. Без механизмов коррекции ошибок и redundancy хранилище в трафике превращается в лотерею.
В итоге: технически возможно, но требует продуманной архитектуры, понимания сетевых протоколов и готовности к тому, что решение будет хрупким. Как proof-of-concept — интересно. Как production-инструмент — сомнительно.
Передача параметров ssh с помощью суффиксов имени хоста
В случае, если доступ к определённым хостам по протоколу SSH требует запуска ssh с кучей параметров, стандартной рекомендацией является внесение всех этих параметров в отдельную секцию Host файла конфигурации ssh, пример которой приведён ниже. Данные параметры подробно описаны в ssh_config(5).
Host tproxy
Hostname srv-10-79.dmz.company.com
User srv_user
Port 36602
DynamicForward 127.10.0.79:1080
LocalForward 127.10.0.79:4445 127.0.0.1:445
LocalForward 127.10.0.79:8080 127.0.0.1:8080
У этой рекомендации есть один существенный недостаток — она не обеспечивает модульность конфигурации и вынуждает дублировать информацию. В случае, если требуется обеспечить подключение к тому же серверу из интернета через NAT или через SSH-прокси, или без SOCKS5-прокси и переадресации портов, причём во всех возможных комбинациях:
изнутри с переадресацией портов,
изнутри без переадресации портов,
снаружи с перадресацией портов,
снаружи без переадресации портов,
для данного сервера придётся добавить ещё три секции Host, часть сведений в которых будет дублироваться. Если же компания подключилась к двум провайдерам и сэкономила на маршрутизации BGP, понадобятся уже шесть частично дублирующих друг друга секций Host. Дублирования сведений, как известно, желательно избегать, и для этого следует каким-либо образом доработать исходную рекомендацию.
Сущность предлагаемой доработки
Мною были перепробованы различные варианты доработки исходной рекомендации и, в итоге, был найден достаточно простой способ, заключающийся в разбиении конфигурации на отдельные секции в зависимости от суффиксов, добавляемых к имени хоста, передаваемого в качестве параметра команде ssh. Для отделения суффиксов от имени хоста и друг от друга оптимально использовать символ-разделитель "+" (плюс). Этот символ не используется в именах DNS, а также интуитивно понятнее любых других, указывая на то, что суффикс что-то добавляет к исходной конфигурации хоста. Распознавание добавляемых суффиксов следует производить с помощью команды Match originalhost с шаблоном суффикса.
В случае, если суффикс должен добавлять параметры, специфичные для определённого хоста, например, его реальное имя DNS, или параметры переадресации портов, в которых фигурирует адрес локального сокета, индивидуальный для каждого из хостов, команда Match должна будет содержать два аргумента originalhost: один — с шаблоном имени хоста, и второй — с шаблоном суффикса. Пример:
Match originalhost "tproxy+*" originalhost "*+rtk,*+rtk+*"
# Подключение через РостелеТелеком (NAT)
Hostname srv-10-79.rtk.company.com
Match originalhost "tproxy+*" originalhost "*+yota,*+yota+*"
# Подключение через Yota
ProxyJump gate-10-1+yota
Match originalhost "tproxy+*" originalhost "*+fwd,*+fwd+*"
DynamicForward 127.10.0.79:1080
LocalForward 127.10.0.79:4445 127.0.0.1:445
LocalForward 127.10.0.79:8080 127.0.0.1:8080
За секциями, специфичными для хоста с указанием суффиксов, в обязательном порядке должна следовать секция для этого же хоста с параметрами по умолчанию. Прежде всего эта секция нужна для того, чтобы заменить переданное ssh имя хоста его именем DNS, если добавленные к имени хоста суффиксы не ссылались на секцию Match, содержащую команду Hostname. Также в этой секции следует указывать параметры ssh, одинаковые для всех возможных способов подключения, например: имя пользователя, номер порта, используемые алгоритмы шифрования, типы ключей, и так далее. Для секции Match хоста по умолчанию достаточно одного аргумента originalhost. Пример:
Match originalhost "tproxy,tproxy+*"
Hostname srv-10-79.dmz.company.com
User srv_user
Port 36602
В случае, если добавляемые суффиксом параметры не содержат специфических для хостов аргументов, в команде Match достаточно указать один аргумент originalhost с шаблоном суффикса. Такие секции следует располагать в самом конце файла настроек ssh.
Match originalhost "*+rsa,*+rsa+*"
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
Виртуальные бои с взаимной блокировкой сайтов и сервисов перешли в реальный мир. Евросоюз изучает возможность проложить оптические магистрали в Азию через Арктику. Почему не хватило текущей надёжности Интернета, который разрабатывался как сеть, способная сохранить работоспособность после ядерной войны?
Азия и Ближний восток: риски и возможности
Вместо локальной системы связи для одной страны Интернет стал глобальной сетью. При этом магистральные каналы прокладывались не равномерно, а там, где удобно. В результате оказалось, что большая часть магистральных каналов между Европейским союзом и Китаем, Индией и другими важными партнёрами из Юго-Восточной Азии проложена через Россию или Ближний Восток.
В 2024 году в Красном море Йемен повредил четыре подводных кабеля в Красном море. А уже в этом году Иран угрожал блокировать не только Ормузский пролив, но и интернет-каналы, проходящие у его берегов. Так как долговременное примирение геополитических противников никто не гарантирует, ЕС задумался над прокладкой кабелей через арктический регион.
Трафик через полюс
У Европы два варианта прокладки интернет-кабелей — через Северо-Западный проход. Аналог Северного морского пути в обход Канады и Аляски по Северному Ледовитому океану. Однако придётся решать вопросы работы в сложных ледовых условиях. Есть опыт многомесячных перерывов в ремонте интернет-магистралей, находящихся в подобных условиях. Альтернатива — не проще: проложить кабели непосредственно через Северный полюс.
Кажется, что в таких условиях получат новые возможности спутниковые сервисы связи. Однако в текущей ситуации захочет ли Европа зависеть от американских компаний? А OneWeb вряд ли потянет полноценную связь регионов. Часть коммерческой нагрузки может взять на себя сервис спутниковой связи IRIS, основное назначение которого — связь для европейских госструктур и силовиков.
В любом случае реализация обхода через Арктику намечена к 2030 году. За 5 лет может ещё всё измениться.
ИТ-компаниям приходится учитывать не только требования локальных регуляторов, но и геополитику, чтобы готовиться к сложностям с доступностью электронных компонентов и каналов связи. К сожалению, на это уходят ресурсы, и приходится прикладывать дополнительные усилия, чтобы это не сказывалось на пользователях.
Дела становятся еще детектнее, а запуск новой версии PT NAD 13.0 — еще ближе ☄️
Уже 4 июня, ровно в 14:00, команда системы поведенческого анализа сетевого трафика от Positive Technologies — PT NAD — прольет свет на каждый темный уголок вашей инфраструктуры в новом сезоне «Очень детектных дел» (отсылка не случайна).
В этот день вы сможете вместе с нами узнать, как поменяют правила игры:
автоматизированное реагирование;
облачное детектирование;
архивное хранение метаданных.
Чтобы точно все это успеть, вот чек-лист ваших действий прямо сейчас:
Опубликовали программу infra.conf'26 — большой конференции про инфраструктуру и высоконагруженные сервисы
Команда Yandex Infrastructure открыла полную программу infra.conf 2026, которая состоится 4 июня в Москве и онлайн. Фокус конференции этого года — построение и особенности эксплуатации инфраструктуры в эпоху ML.
В трёх треках программы обсудим не только ML‑инфраструктуру, но и базы данных, стораджи, инструменты разработки, observability‑решения, SRE и эксплуатацию и управление трафиком.
Среди докладов от инженеров и разработчиков Яндекса, Сбера, X5 Tech, Wildberries & Russ и других компаний нас ждут темы:
«Как появилась Алиса AI: путь одной LLM» (Аркадий Альшан, Яндекс)
«ML‑платформы для больших компаний» (Антон Алексеев, AvitoTech)
«Как мы построили два больших GPU‑кластера на Kubernetes» (Иван Юмашев, Ozon)
«Два подхода к надёжности распределённых систем» (Евгений Дюков, Yandex Cloud)
«ИИ‑агенты для MLOps‑инфраструктуры» (Марк Кузнецов, Альфа‑банк)
«Особенности observability LLM‑приложений и агентов» (Даниэль Халиулин, Yandex Infrastructure)
Также участникам будут доступны мастер‑классы и выставочная зона инженерных команд.
Infra.conf'26 пройдёт 4 июня в Москве в пространстве TAU. Для участия нужно зарегистрироваться и дождаться приглашения. Также посмотреть доклады в прямом эфире можно будет на сайте конференции.
Представлен сервис «taken.» который позволяет оценить, какую информацию о вас знают сайты в интернете. Спойлер: они знают буквально всё — от вашего местоположения до точных настроек системы, заряда батареи и даже установленных шрифтов.
dpi-checkers — open-source инструмент от hyperion-cs — показывает, каким именно методом ваш провайдер режет трафик: RST после 16-го пакета, SNI-дроп или CIDR-вайтлист. Прогнал на трёх подключениях — картина неожиданная.
Пользователи рунета давно заметили: «интернет дома» и «интернет у бабушки в области» — это два разных интернета. YouTube грузится на одном провайдере и не грузится на другом. Discord висит на мобильном, но работает на проводе того же оператора. Это не случайность и не деградация сети — за каждым таким симптомом стоит конкретный технический механизм на L4/L7.
Набор тестов dpi-checkers (часть на Go как CLI-утилита, часть в браузере на JS) позволяет идентифицировать метод фильтрации, который применяет конкретный ISP. Я прогнал проверки на трёх подключениях: домашнем у федерального провайдера, мобильном у одного из «большой четвёрки» и через знакомого в другом регионе.
Пять методов которые реально встречаются в РФ. DPI — не одна технология, а класс решений. Современный Deep Packet Inspection анализирует не только заголовки L3/L4, но и содержимое L7: по особенностям TLS handshake система определяет сервис назначения даже без знания IP и применяет политику — пропустить, сбросить, замедлить. Когда в новостях пишут «провайдер замедляет YouTube» — это упрощение. Технически применяется один из нескольких методов, и симптомы у пользователя разные в зависимости от метода.
CIDR-вайтлисты — блокировка по IP-подсетям. Трафик к адресам вне «доверенного» списка не пропускается. Жёсткий метод, чаще встречается на мобильных тарифах 4G+/5G.
TCP 16-20 (rps-разрыв) — DPI ждёт первые 16–20 пакетов TLS-сессии, детектирует SNI нежелательного хоста и отправляет RST обеим сторонам. Клиент видит «сайт упал», хотя сервер жив. Основной механизм замедления YouTube в 2024–2025.
Подмена DNS-ответов — перехват запроса на уровне провайдера, возврат заглушки или 0.0.0.0. Старый метод, обходится DoH/DoT, но используется как первая ступень.
SNI-блокировка — поле Server Name Indication в TLS handshake передаётся открытым текстом до установки шифрованного канала. DPI читает его и сбрасывает соединение по домену.
QUIC-блокировки — UDP/443 режется целиком или деградирует, чтобы клиент откатился на TCP, где уже работает SNI-фильтрация.
Что показал dpi-checkers на трёх подключениях. Домашний федеральный провайдер — TCP 16-20 в чистом виде: соединение с рядом зарубежных сервисов рвётся ровно после 16–18 пакетов в TLS-сессии, RST приходит от «провайдерского» адреса, не от сервера назначения. Мобильный оператор — комбинация SNI-дропа и QUIC-блокировки: UDP/443 не проходит вообще, TCP-соединение с теми же хостами рвётся по SNI до завершения handshake. Региональный провайдер через знакомого — DNS-подмена как первая ступень плюс CIDR-ограничения на часть подсетей Cloudflare.
Исследования Citizen Lab и проект net4people фиксируют схожие паттерны по всему рунету — методы стандартизированы, оборудование у операторов в основном одно и то же (ТСПУ от Эшелона и аналоги). Различия между провайдерами — в настройке порогов и в том, какие именно списки им спустили.
Для меня как человека, который строит корпоративные сети, это не абстрактный research. Когда у сотрудника «не работает» корпоративный сервис — первый вопрос теперь не «а VPN включён?», а «какой метод фильтрации у его провайдера?». TCP RST лечится иначе, чем DNS-подмена, и иначе, чем QUIC-блок. dpi-checkers даёт ответ за пять минут вместо часа диагностики вслепую.
Как определить свой внешний IP когда действуют белые списки Минцифры
Когда Министерство цифровой деградации России начинает ограничивать Интернет по своим белым спискам, внезапно обнаруживается, что из привычных инструментов не работает ничего. Невозможно зайти ни на один сайт: 2ip.rumyip.ruifconfig.meipify.orgwhatismyipaddress.comwww.whatismyip.comipinfo.io потому что никто из них не занесён в белые списки. Timeweb есть в белых списках, timeweb.com/check-ip страница открывается, но во время работы белых списков все поля пустые. Из поисковых серверов в этот момент доступен только Яндекс, но он тоже ничем не может помочь в данной ситуации, потому что не готов к такому, и предлагает те же самые сайты которые недоступны.
Вспоминаем жизнь до появления поисковых серверов - создаём свои коллекции нужных ссылок вручную.
В момент действия белых списков мне через моего сотового провайдера «Мегафон» (физически я нахожусь в СПб или Ленобласти) доступен очень ограниченный перечень сайтов. Возможно, что в том месте где Вы находитесь белый список будет другим. Просмотрев вручную всё что мне доступно по состоянию на 7 мая 2026 нашёл всего две ссылки которые показывают мой IP адрес: Яндекс Интернетометр yandex.ru/internet и Reg.ru reg.ru/web-tools/myip В Интернетометре Яндекса можно ещё и скорость померить. Из сервисов whois рабочий нашёл только один nic.ru/whois Разумеется, не надо заходить на эти ресурсы через свою выходную ноду VPN. Также, в момент когда действуют белые списки, возможно ещё и замедление скорости доступа даже к тому что разрешено. Привычный дизайн сайтов может быть нарушен, из-за того, что внешние ресурсы подгружаемые сайтом недоступны во время работы белых списков.
IP адрес который выдал Вашему устройству сотовый провайдер можно посмотреть на самом устройстве. На Android это вот тут: Settings / About phone / Status / IP Address
Возможны другие варианты. На BlackView BV9800: Settings / System / Advanced / About Phone / IP Address
Во время работы белых списков на смартфоне 100.82.28.67 а внешний IP на сайте Яндекс Интернетометр в это же время показывает 178.178.244.80
100.64.0.0 — 100.127.255.255 (маска подсети 255.192.0.0 или /10). Данная подсеть рекомендована согласно RFC 6598 для использования в качестве адресов для CGN (Carrier-Grade NAT); Вики
PS: Запасайте наличные рубли, во время работы белых списков либо оплата наличными, либо предоплата на сайте. Оплата банковской картой в это время не работает. Видимо эквайринг Сбербанка в белые списки не попал.
Сервис Your IP Security & Privacy Audit проверяет подключение пользователя на предмет утечек, а также на безопасность сетевого соединения. Решение просматривает: IP, утечку гео и WebRTC, DNS, чёрный список IP-адресов, цифровые отпечатки в браузере.
Если вы считаете, что вы обманули белые списки Роскомнадзора с помощью VLESS и прочих квн-чудес, то просто представьте, как всё это держится на Yandex Cloud и VK Cloud за счет того, что они арендуют сервера с диапазонами айпи в белых списках...
На днях решил посмотреть свой IP через VPN и заметил хостинг YANDEX CLOUD или VK LLC. И вот непопулярное мнение с ноткой теории заговора, но я задумался о том, почему ВК и Яндекс вообще допускают диапазоны IP своих VDS (про сервисы не говорим, так как исключения легко можно настроить) и особо не спешат блокировать свои IP, и хочу высказать догадку.
Не видел такой точки зрения, но мне кажется, что ВК и Яндексу выгодно и очень прибыльно хостить сервера, айпи которых в белом списке, так как это тот самый важный элемент для КВН, обходящих белые списки и без точки входа во внешний Интернет, оно бы не заработало.
Представлен открытый проект TapMap, который следит за всеми подключениями на интерактивной карте и показывает, к серверам в каких странах отправляет запросы ПК пользователя.
Проект сканирует приложения, сервисы, страны и порты за последние 30 дней. При этом данные никуда не улетают — всё локально на компьютере.
Представлен открытый проект FMHY Filterlist — это список вредоносных ресурсов и другого сомнительного ПО в сети, где есть фейковые сайты популярных репакеров, торрентов и софта, пиратские сайты, где хоть раз нашли вирусы, а также «серые» ресурсы, сервисы с сомнительной репутацией вроде Avast, McAfee, Tlauncher, 360 Total Security и других. Разработчики проекта постоянно обновляют список угроз. Фильтр уберёт большинство вредоносных сайтов из доступной сети и не даст пользователям перейти на них.
