Защита трафика в публичных Wi-Fi для ВКР: от pocket-роутера до корпоративного VPN-шлюза
Поддомен: Cybersecurity / Network Security. Роль: специалист по ИБ. Схема подачи: A (Введение → Темы ВКР → Основная часть → Ошибки → FAQ → Чек-лист → CTA → Эксперт → Источник).
Семантический анализ (кратко): Primary — защита трафика в публичных Wi-Fi для ВКР. LSI: Zero Trust, WireGuard, IPsec/IKEv2, WPA3-Enterprise, RADIUS, Captive Portal, OWASP Top 10, ISO/IEC 27001, ISO/IEC 25010 (security), TLS 1.3, kill-switch, DPI, MTTR/MTTD. Сущности: ГОСТ 34, ГОСТ 19, ISO/IEC 25010, OWASP, C4/UML.
Введение: почему кейс Roam 7 — не про «игрушку для путешествий»
Обзор TP-Link Roam 7 выглядит как заметка для туриста: компактный роутер поднимает персональную сеть там, где вокруг открытые точки доступа кафе, аэропортов и коворкингов. Но для выпускника направления «Информационная безопасность» или «Инфокоммуникационные технологии» здесь спрятана готовая постановка задачи. Публичный Wi-Fi — это классический вектор: перехват трафика (evil twin, ARP-спуфинг), подмена DNS, captive-порталы с фишингом. Pocket-роутер с предварительно настроенным туннелем превращает чужую недоверенную среду в контролируемый периметр.
Именно этот разрыв — «недоверенная сеть доступа ↔ доверенный корпоративный контур» — защищаемая тема для ВКР. Она позволяет показать и теорию угроз, и конкретную реализацию, и измеримые метрики эффективности. Не абстрактный «анализ безопасности», а работающая схема с числами.
Темы ВКР: три сценария, которые защитимы в 2026 году
| Тема | Актуальность (отсылка к статье) | Цель | Задачи | Структура |
|---|---|---|---|---|
| Проектирование защищённого VPN-шлюза для мобильных сотрудников | Roam 7 продвигает идею «личной доверенной сети» в публичном пространстве; корпоративный аналог — Always-On VPN | Разработать архитектуру шлюза с Zero Trust-политикой доступа | 1) анализ угроз публичного Wi-Fi; 2) выбор протокола (WireGuard/IPsec); 3) реализация и конфигурация; 4) нагрузочное тестирование | Гл.1 — анализ угроз и стандартов; Гл.2 — проектирование (C4, UML); Гл.3 — тесты, метрики задержки и пропускной способности |
| Снижение рисков работы в открытых Wi-Fi для распределённой команды | Кейс «сеть в кармане» иллюстрирует персональный периметр; в ВКР масштабируем на команду | Построить модель рисков и предложить организационно-технические меры | 1) классификация угроз по OWASP/ISO 27005; 2) матрица рисков; 3) выбор контрмер; 4) оценка остаточного риска | Гл.1 — теория рисков; Гл.2 — модель и политики; Гл.3 — количественная оценка (TCO, снижение риска в %) |
| Мониторинг безопасности мобильного доступа на базе OpenTelemetry | Roam 7 — управляемый «чёрный ящик»; в дипломе показываем, как видеть события в туннеле | Реализовать сбор и визуализацию ИБ-метрик мобильного шлюза | 1) выбор метрик (MTTD, MTTR, доля неуспешных handshake); 2) инструментирование; 3) дашборд; 4) эксперимент | Гл.1 — обзор observability; Гл.2 — архитектура сбора; Гл.3 — эксперимент и валидация метрик |
Основная часть: как превратить обзор в главы ВКР
Глава 1. Анализ угроз публичных сетей
Начните с таксономии. Возьмите классические векторы (evil twin, captive-portal phishing, DNS-подмена, downgrade до WPA2-TKIP, MAC-спуфинг) и добавьте актуальные — перехват токенов сессии в браузере, MITM на уровне HTTPS через подмену сертификата, слабые политики Captive Portal. Для каждого — вероятность, влияние, ссылка на OWASP Top 10 и раздел security в ISO/IEC 25010. Здесь уместна диаграмма в нотации UML Use Case: «сотрудник → сценарий подключения → источники угроз».
Глава 2. Проектирование туннеля и периметра
Опишите архитектуру через C4: Context (сотрудник, публичная точка, шлюз, корпоративные ресурсы) и Container (клиент, роутер, VPN-сервер, аутентификация). Pocket-роутер из статьи — это физический клиент-енклавиш; в ВКР его модель разумно заменить или дополнить — например, показать, что устройство с предустановленным профилем WireGuard ведёт себя как «доверенный контейнер».
# Пример: минимальный конфиг WireGuard-клиента в роутере
[Interface]
PrivateKey = <client_private>
Address = 10.8.0.5/24
DNS = 10.8.0.1
MTU = 1380
# Kill-switch: при падении туннеля трафик не уходит открытым
[Peer]
PublicKey = <server_public>
Endpoint = vpn.example.org:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
Обратите внимание комиссии на спорные моменты: MTU, handshake, поведение при роуминге между точками доступа, влияние на задержку. Это первые вопросы на защите.
Глава 3. Тестирование и метрики
Реализуйте сценарий: клиент подключается через подконтрольную «evil twin»-точку, вы замеряете утечки. Метрики — не абстракция:
- задержка до шлюза (ping, RTT до и после туннеля);
- пропускная способность (iperf3);
- доля неуспешных handshake (журнал wireguard / journalctl);
- MTTD/MTTR по событию «разрыв туннеля»;
- прирост энергопотребления (если используете мобильный роутер).
# Верификация утечек после отключения туннеля
curl --interface eth0 -s ifconfig.me # должен вернуть ошибку/таймаут
ip route get 1.1.1.1 # должен уйти в wg0, иначе kill-switch не работает
Нормоконтроль: где ломается большинство ВКР по ИБ
Схемы архитектуры оформляйте по ГОСТ 34.602/ГОСТ 19.701 или в единой нотации UML 2.5 — не смешивайте. Листинги — в приложения, со ссылкой в тексте. Выводы по главам должны отвечать задачам из введения дословно. Метрики фиксируйте с указанием среды (стенд, характеристики, версия ядра Linux) — иначе результат невоспроизводим.
Практические выводы: чему вы научитесь
- Проектировать доверенный контур поверх недоверенной среды доступа;
- Настраивать WireGuard/IPsec и включать kill-switch без потери связности;
- Считать MTTD/MTTR и задержки, строить сравнительные графики;
- Оформлять архитектуру в C4/UML и согласовывать с ГОСТ 34;
- Оценивать TCO решения «свой роутер + туннель» против «корпоративный клиент».
Типичные ошибки студентов
1. «Анализ ради анализа». Глава 1 пересказывает угрозы из статей без привязки к собственной архитектуре. Как избежать: сразу вводите таблицу «угроза → контрмера → метрика», и в главах 2–3 ссылайтесь на неё.
2. Метрики без стенда. Как в обзоре Roam 7 — «быстро и приватно» — но для ВКР нужны числа. Указывайте ОС, версию ядра, модель точки доступа, число прогонов.
3. Путаница областей. Обещали «снижение рисков», а измеряете только RTT. Разделите метрики ИБ (утечки, handshake) и производительности (bandwidth, latency).
FAQ
Какой стек использовать: WireGuard или IPsec?
Для диплома WireGuard проще в воспроизведении и понятнее комиссии. IPsec берите, если тема связана с корпоративными стандартами и требует IKEv2. Оба варианта защищаемы, если есть стенд и метрики.
Где брать данные для главы 1?
OWASP Top 10, отчёты NIST, материалы ISO/IEC 27005, публичные исследования угроз public Wi-Fi. Плюс — собственные логи стенда.
Нужен ли физический роутер?
Нет. Виртуальная топология (Linux namespace, Docker, GNS3) достаточна. Но если есть реальный pocket-роутер — добавьте главу с натурным экспериментом: это сильный аргумент на защите.
Как считать «эффективность» защиты?
Через снижение вероятности успешной атаки на стенде (было/стало) и через MTTD. Формулируйте как «снижение X% при условии Y», а не «полная защита».
Что проверить перед сдачей
- Задачи из введения совпадают с выводами по главам и заключением;
- Все схемы — в одной нотации, ссылки на рисунки в тексте есть;
- Метрики воспроизводимы: указана среда и версии;
- Список литературы содержит стандарты (ГОСТ 34/19, ISO/IEC 25010, OWASP);
- Приложения содержат листинги и полные конфиги;
- Уникальность текста проверена, заимствования в норме.
Если тема кажется слишком широкой — это нормально. На бесплатной консультации мы поможем сузить её до защищаемого объёма, собрать стенд и оформить главы. Профессиональная поддержка рассчитана на 120 часов работы и охватывает любую тему по ИБ, сетям и разработке. Иногда проще заказать диплом с готовой архитектурой и метриками, чем месяцами бороться с формулировками. Если хотите разобраться сами — мы подскажем, с чего начать как написать ВКР без переписывания с нуля.
Источник: I stopped stressing about public Wi-Fi after using this pocket router - why it works (опубликовано 2026-03-26)