Разработка и отладка сетевых протоколов (TCP/IP, QUIC, HTTP/3) с помощью Scapy и Wireshark‑CLI в Termux

Termux — удобная среда для полевых испытаний и быстрой отладки сетевых сценариев прямо на Android. В этой статье мы рассмотрим практический рабочий цикл: подготовка инструментов, генерация/модификация трафика на уровне пакетов, захват сетевого трафика с Wireshark‑CLI и последующий разбор для валидации реализации TCP/IP и изучения поведения протоколов QUIC и HTTP/3.

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

Подготовка Termux: пакеты, права и базовая инфраструктура

Цель — получить инструменты для генерации пакетов и для анализа захваченного трафика. Для захвата обычно требуется сетевой доступ и достаточные привилегии в зависимости от модели устройства и настроек ОС. Начните с установки базового набора:

pkg update
pkg upgrade
pkg install python git
pkg install tshark wireshark-cli
pkg install tcpdump

Дальше установим Scapy. В Termux чаще всего удобнее использовать pip:

pip install --upgrade pip
pip install scapy

Проверка готовности:

python -c "from scapy.all import *; print('Scapy OK', conf.version)"
tshark --version

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

Рабочий процесс: захват → фильтрация → интерпретация → валидация

Условный цикл отладки протоколов:

Собираем трафик в PCAP через Wireshark‑CLI или tcpdump.
Быстро фильтруем и извлекаем метрики через tshark.
Проверяем гипотезы: последовательности флагов TCP, тайминги, поведение транспорта QUIC/UDP, маркеры HTTP/3.
Сравниваем с ожидаемым поведением вашего протокола/скрипта.

Благодаря CLI‑подходу вы можете автоматизировать разбор для итераций разработки.

Разработка и анализ на уровне TCP/IP: проверка рукопожатия и параметров

Для TCP/IP удобнее всего начать с захвата и последующего анализа. Допустим, вы хотите проверить поведение соединения (SYN/SYN-ACK/ACK) и параметры сегментов. На этапе анализа используйте tshark.

Сценарий 1: просмотр TCP-фрагментов из PCAP.

# Допустим, у вас уже есть capture.pcap
tshark -r capture.pcap -Y "tcp" -T fields -e frame.time -e ip.src -e ip.dst -e tcp.flags -e tcp.len

Сценарий 2: фильтрация по конкретным флагам (например, SYN):

tshark -r capture.pcap -Y "tcp.flags.syn == 1" -T fields -e ip.src -e ip.dst -e tcp.flags.syn -e tcp.seq -e frame.time

Сценарий 3: получение окна, MSS и связанных опций (в зависимости от наличия опций в захваченном трафике):

tshark -r capture.pcap -Y "tcp.options.mss || tcp.options" -T fields -e ip.src -e ip.dst -e tcp.options -e frame.time

Такой подход полезен, когда вы сравниваете: как ваш клиент формирует соединение vs как ведёт себя целевая реализация.

Генерация тестовых TCP-сценариев с Scapy (в рамках разрешённых испытаний)

Scapy позволяет строить пакеты и выполнять быстрые эксперименты. Для TCP важно понимать: без полноценной TCP-стек-логики на стороне машины вы не всегда добьётесь «настоящего» обмена на уровне соединений. Но можно тестировать отдельные этапы и параметры, а затем проверять, как трафик анализируется Wireshark‑CLI.

Пример: формирование IP/TCP заголовков для подготовленного SYN-пакета (используйте только там, где это легально и разрешено):

from scapy.all import IP, TCP, send

dst = "192.0.2.10"   # замените на тестовый адрес в вашей среде
sport = 12345

pkt = IP(dst=dst)/TCP(sport=sport, dport=80, flags="S", seq=1000)
print("Sending SYN to", dst)
send(pkt, verbose=True)

После отправки не забудьте захватить трафик в PCAP и проверить, что SYN был корректно сформирован и как система реагирует на него.

Практика отладки: меняйте seq, window, опции TCP (где допустимо) и сверяйте, что конкретно вы наблюдаете в Wireshark‑CLI.

Переход к QUIC: ключевое — наблюдаем UDP и маркеры QUIC

QUIC работает поверх UDP. Поэтому логика отладки меняется: вы собираете UDP‑трафик, а затем используете дешифрирование/анализаторы Wireshark (когда возможно) для понимания QUIC-поля и логики обмена.

На уровне CLI начните с выделения UDP потоков:

tshark -r capture.pcap -Y "udp" -T fields -e frame.time -e ip.src -e ip.dst -e udp.port -e udp.length

Если в вашей среде используется известный порт (например, 443/UDP), фильтруйте по нему:

tshark -r capture.pcap -Y "udp.port == 443" -T fields -e frame.time -e ip.src -e ip.dst -e udp.length

Для более предметного анализа QUIC можно попробовать включить поля протокола (зависит от того, распознаёт ли Wireshark ваш трафик как QUIC). Примерно так:

tshark -r capture.pcap -Y "quic" -T fields -e frame.time -e ip.src -e ip.dst -e quic.long_header_type -e quic.packet_number -e quic.connection_id

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

HTTP/3 поверх QUIC: как выстраивать проверку последовательностей

HTTP/3 использует транспорт QUIC и передаёт семантику HTTP поверх QUIC‑стримов. Типовая отладка выглядит так:

Подтвердить, что у вас есть QUIC‑обмен (UDP‑потоки, пакеты QUIC, распознавание Wireshark).
Проверить наличие метаданных HTTP/3 (в зависимости от того, как это декодируется в Wireshark).
Сверить последовательности: установка сессии/рукопожатие QUIC → появление запросов/ответов HTTP/3.

CLI‑подход для HTTP/3 обычно начинается с попытки распознать соответствующие поля:

tshark -r capture.pcap -Y "http3" -T fields -e frame.time -e ip.src -e ip.dst -e http3.stream_id -e http3.type -e http3.method -e http3.status_code

Если http3 не детектится, это не всегда ошибка: иногда требуется иной тип анализа/декодирования. В таких случаях полезно сначала убедиться, что Wireshark видит QUIC, а затем точнее настроить фильтры по конкретным признакам.

Захват трафика в PCAP: практичные команды для Wireshark‑CLI и tcpdump

В простых сценариях можно использовать tcpdump для получения PCAP, а затем анализировать их tshark. Например, захват на устройстве:

# Пример: захват на текущем интерфейсе (название интерфейса может отличаться)
# Сначала проверьте интерфейсы:
ip link show

# Далее захват (примерно):
tcpdump -i wlan0 -s 0 -w capture.pcap

Для UDP/QUIC часто удобно ограничивать захват по фильтру, чтобы быстрее анализировать:

tcpdump -i wlan0 -s 0 -w quic_capture.pcap udp port 443

После сбора вы можете делать быстрые «сводки»:

tshark -r quic_capture.pcap -q -z io,stat,0,COUNT
tshark -r quic_capture.pcap -z udp,statistics,0

Автоматизация анализа: извлечение метрик и построение сопоставлений

Для отладки реализаций выгодно автоматизировать вывод. Например, сохранить таблицу событий в CSV‑подобном виде и сравнить два захвата (до/после изменения в коде):

# Вывод ключевых полей (пример для TCP)
tshark -r capture_v1.pcap -Y "tcp" -T fields -e frame.time -e ip.src -e ip.dst -e tcp.flags -e tcp.seq -e tcp.ack -e tcp.win_size > tcp_v1.txt

tshark -r capture_v2.pcap -Y "tcp" -T fields -e frame.time -e ip.src -e ip.dst -e tcp.flags -e tcp.seq -e tcp.ack -e tcp.win_size > tcp_v2.txt

Далее вы можете сравнить файлы в вашей среде (например, через стандартные утилиты diff на устройстве или на ПК). Такой подход особенно эффективен при итеративной разработке TCP‑логики или транспортных параметров.

Локальная безопасная среда и VPN (только для создания локальной сети)

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

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

Типовые проблемы и как их диагностировать

Трафик не распознаётся как QUIC/HTTP/3 в Wireshark. Проверьте, что захвачен именно нужный UDP поток (например, порт и направление), и что данные достаточно полные.
Пустые результаты по фильтрам. Проверьте корректность фильтра -Y и наличие соответствующих полей. Иногда правильнее начать с общего вывода (например, только udp), а затем уточнять.
Нет захвата или обрывы PCAP. Проверьте интерфейс, размер снапшота (-s 0), и ограничения прав/системы Android.
Сложности с генерацией TCP с Scapy. Для «реальных» соединений обычно нужна полноценная стейт‑машина или взаимодействие с тестовой точкой, которая поддерживает нужные этапы. Начинайте с наблюдения и сопоставления заголовков.

Мини-чеклист перед отчётом об успешной отладке

PCAP собран и доступен для повторного анализа.
Есть снимок «до/после» изменений (v1/v2 захват).
Подтверждены ключевые события: для TCP — рукопожатие и параметры; для QUIC — наличие QUIC‑распознавания на UDP; для HTTP/3 — наличие HTTP/3‑индикаторов (если декодируется).
Фильтры tshark дают воспроизводимый результат.

Заключение

Разработка и отладка сетевых протоколов в Termux становится существенно проще, если вы выстраиваете связку «генерация/наблюдение (Scapy) → захват (PCAP) → разбор (Wireshark‑CLI / tshark) → автоматизированные метрики». Для TCP/IP это помогает быстро проверить корректность заголовков и последовательностей. Для QUIC и HTTP/3 ключевым становится грамотный захват UDP‑трафика и настройка анализа так, чтобы Wireshark распознал нужные слои.

Если вам требуется помощь с настройкой стенда, подбором инструментов или разбором конкретного PCAP/сценария, обращайтесь в РыбинскЛАБ: мы выполняем консультации и помогаем довести исследования и отладку до воспроизводимого результата.