Опубликовано: 03.10.2026 | Источник: SecurityLab (RSS)

Встроенный VPN и обход блокировок в ВКР: от модели угроз до метрик производительности

Поддомен: Cybersecurity / Privacy Engineering. Роль автора: специалист по информационной безопасности.

Введение

26 марта 2026 года Mozilla выпустила Firefox 149 — сборку, где бесплатный VPN встроен прямо в браузер и даёт около 50 гигабайт трафика в месяц. Заодно вендор добавил стикеры для тех, у кого открыто под сотню вкладок и «всё это нужно». Новость звучит как продуктовый апдейт, но для выпускника направления «Информационная безопасность» или «Программная инженерия» это готовый полигон для диплома.

Почему? Потому что приватность переехала на уровень массового клиента. Там, где раньше стоял отдельный клиент с ручной настройкой, теперь одна галочка в браузере. Значит, меняется характер трафика в корпоративных сетях, растёт нагрузка на системы обнаружения вторжений, а инженеру нужно уметь измерять туннель, а не просто «включать его». Ниже — как превратить этот сюжет в защищаемую работу, какие схемы построить и какие метрики посчитать.

FAQ: что спрашивают до выбора темы

Законно ли брать тему, связанную с обходом блокировок, в диплом?

Формулируйте тему как исследование приватности и устойчивости соединений, а не как инструкцию по нарушению правил. Юридически чистая рамка: «анализ методов защиты трафика», «оценка устойчивости протоколов к классификации», «проектирование корпоративного защищённого канала». Задачи — измерение, сравнение, моделирование. В главе 1 обязательно раздел «Правовые и этические ограничения», это снимет половину вопросов на защите.

Где брать данные, если нет своего сервера?

Стенд поднимается на одной машине: виртуальная машина с VPN-сервером, вторая — клиент, третья — имитатор DPI (например, nDPI или собственный классификатор на датасете). Данные — синтетические, но воспроизводимые: iperf3, curl, ffmpeg-поток, замеры задержки в цикле. Плюс публичные датасеты трафика (CIC-IDS, ISCX VPN-nonVPN) — но обязательно проверьте, что вы их нормализовали и не смешали обучающую и тестовую выборки.

Обязательно ли писать свой VPN или можно анализировать существующий?

Зависит от кафедры. Аналитическая работа (сравнение WireGuard, OpenVPN, обфусцированных схем) защищается легче, если у вас есть собственная методика измерений. Разработка с нуля тянет на большой объём кода, который потом придётся тестировать. Компромисс — собственный клиентский модуль (kill switch, split tunneling) поверх готового протокола.

Что должно быть в экспериментальной части, чтобы её зачли?

Гипотеза, методика, воспроизводимый скрипт, таблица результатов, вывод. Без методики таблица — это просто числа. Привяжите измерения к ISO/IEC 25010: производительность, надёжность, безопасность, удобство использования.

Темы ВКР, которые вырастают из этой новости

• Тема 1. Сравнительная оценка производительности лёгких VPN-протоколов в условиях активного DPI.

  Актуальность: встроенный VPN в Firefox 149 расширяет массовую аудиторию туннелей — значит, растёт давление систем классификации трафика на каналы.

  Цель: построить методику сравнения WireGuard и OpenVPN по пропускной способности, задержке и заметности для DPI.

  Задачи: 1) обзор протоколов и моделей обфускации; 2) сборка стенда «клиент — сервер — имитатор DPI»; 3) серия измерений под нагрузкой; 4) выводы и рекомендации по выбору протокола.

  Структура: Глава 1 — анализ протоколов и угроз; Глава 2 — проектирование стенда и скриптов; Глава 3 — эксперимент, метрики, оценка по ISO/IEC 25010.

• Тема 2. Разработка клиентского модуля приватности: kill switch и split tunneling.

  Актуальность: браузерный VPN закрывает часть сценариев, но не управляет системным трафиком. Ниша «клиент с политиками» остаётся открытой.

  Цель: реализовать модуль, гарантирующий отсутствие утечек при разрыве туннеля.

  Задачи: 1) модель угроз по STRIDE; 2) проектирование архитектуры (C4, уровень контейнеров); 3) реализация правил маршрутизации и DNS-over-HTTPS; 4) тесты на утечки IP и DNS.

  Структура: Глава 1 — модель угроз и обзор решений; Глава 2 — архитектура и код; Глава 3 — функциональные и нагрузочные тесты.

• Тема 3. Метрическая модель качества VPN-сервиса для внутреннего корпоративного контура.

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

  Цель: разработать набор метрик и порогов для допуска VPN-клиентов в корпоративную инфраструктуру.

  Задачи: 1) анализ требований ISO/IEC 25010; 2) выбор инструментов телеметрии (OpenTelemetry, Prometheus); 3) сбор и агрегация метрик; 4) прототип дашборда и правила реагирования.

  Структура: Глава 1 — теория качества ПО и требования; Глава 2 — архитектура сбора телеметрии; Глава 3 — пилот, метрики, оценка эффективности.

Основная часть: как разложить материал по главам

Глава 1. Куда встроить новость про Firefox 149

Не пересказывайте пресс-релиз. Используйте факт как точку отсчёта: «массовый браузер начал предоставлять туннель как базовую функцию». Дальше — анализ ландшафта: корпоративные VPN, публичные сервисы, браузерные решения. Здесь же уместна диаграмма C4 уровня Context: пользователь, браузер, VPN-шлюз, DPI-система, корпоративный ресурс. Стрелки подпишите с указанием, какой трафик шифруется, а какой остаётся открытым (DNS, WebRTC, телеметрия).

Обязательный подраздел — модель угроз. Возьмите STRIDE и пройдитесь по элементам: подмена DNS, утечка реального IP, downgrade-атака, компрометация выходного узла. Именно тут появляется аргумент, зачем в работе вообще что-то измерять.

Глава 2. Проектирование стенда

Стенд описывается ASCII-схемой или UML-диаграммой развёртывания. Минимальный состав — три узла:

[Клиент: Ubuntu 24.04]         [VPN-шлюз: Debian 12]        [Имитатор DPI]
   wg0: 10.8.0.2       <=====>   wg0: 10.8.0.1        <=====>  nDPI / классификатор
   iperf3 -c            UDP 51820       iperf3 -s        логирование flow-фич
        |                                                           |
        +------------------- Замер метрик: RTT, jitter, loss -------+

Конфигурация шлюза приводится в приложении, но базовый пример — в главе 2:

# /etc/wireguard/wg0.conf на стороне шлюза
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <server_private_key>
MTU = 1420

[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.8.0.2/32
PersistentKeepalive = 25

Зафиксируйте в тексте, почему MTU именно такой и как вы это проверили (ping с флагом DF и подбором размера пакета). Такая деталь сразу отличает живую работу от компиляции.

Глава 3. Метрики и эксперимент

Скрипт прогона держите в приложении, а в тексте покажите фрагмент парсинга результатов:

import json, statistics

def summarize(path: str) -> dict:
    with open(path, encoding="utf-8") as f:
        data = json.load(f)
    rtts = [r["rtt_ms"] for r in data["samples"]]
    return {
        "n": len(rtts),
        "median_ms": round(statistics.median(rtts), 2),
        "p95_ms": round(sorted(rtts)[int(0.95 * len(rtts)) - 1], 2),
        "loss_pct": round(100 * data["lost"] / data["sent"], 3),
    }

Результаты сводите в одну таблицу и обязательно указывайте число повторов и условия: версия ядра, объём ОЗУ, тип канала, наличие фоновой нагрузки. Без этого защита превращается в разговор о вкусах.

Нормоконтроль: что и по какому документу оформлять

Схему архитектуры — по правилам ГОСТ 19.701 (виды и типы схем, обозначения). Текстовые документы и отчёт об эксперименте — по ГОСТ 7.32. Стадии создания системы, если у вас есть прототип с ТЗ, удобно расписать по ГОСТ 34.601. Требования к качеству формулируйте через ISO/IEC 25010, а для веб-панели управления не забудьте сослаться на чек-листы OWASP (Top 10 и ASVS) — это заметно усиливает главу 3.

Источник: 50 гигабайт на обход блокировок. Mozilla выпустила Firefox 149 со встроенным бесплатным VPN (опубликовано 2026-03-26)