DiffServ RFC 2983 и утечка метаданных DSCP в туннелях VPN

Скрытый побочный канал: как параметры QoS раскрывают активность пользователя

Когда сетевые приложения генерируют IP-пакеты, операционная система классифицирует трафик с помощью поля дифференцированных услуг (DSCP - Differentiated Services Code Point), 6-битного сегмента в байте Type of Service (ToS) протокола IPv4 или Traffic Class протокола IPv6, определенного в спецификации RFC 2474. Программы голосовой связи (VoIP) выставляют класс Expedited Forwarding (DSCP EF, двоичный код 101110, десятичное значение 46), видеоконференции высокого разрешения маркируют класс Assured Forwarding (например, AF41 со значением 34), а многопользовательские онлайн-игры используют метки минимальной задержки.

В идеальной модели безопасности инкапсуляция трафика внутри защищенного туннеля (WireGuard, IPsec ESP или OpenVPN) призвана полностью скрыть коммуникации пользователя. Зашифрованная полезная нагрузка выглядит для стороннего наблюдателя как случайный статистический шум.

Однако многие стандартные реализации туннелей содержат критический архитектурный недостаток: они слепо копируют байт ToS/DSCP исходного внутреннего заголовка во внешний заголовок IP-пакета.

Когда интернет-провайдер (ISP) или злоумышленник в локальной сети анализирует внешние заголовки зашифрованного потока данных, он не может расшифровать полезную нагрузку. Тем не менее, поскольку внешние биты DSCP полностью повторяют внутреннюю маркировку приоритетов, наблюдатель получает точную классификацию пользовательской активности:

Провайдер безошибочно определяет время начала, длительность и периодичность зашифрованных голосовых вызовов.
Сетевые фильтры легко отличают фоновую передачу файлов (Best Effort 000000) от интерактивных терминальных сессий SSH (DSCP AF11).
Системы глубокого анализа пакетов (DPI) сопоставляют размеры пакетов, интервалы между всплесками данных и явные метки DSCP для составления детального профиля используемых приложений.

Уязвимый туннель (Модель Uniform):
[ Внутренний пакет: VoIP (DSCP 46 / EF) ] ---> [ Инкапсуляция ] ---> [ Внешний IP (DSCP 46 / EF) ]
                                                                                |
                                                                                v
                                                             Провайдер фиксирует звонок!

Защищенный туннель (Модель Pipe по RFC 2983):
[ Внутренний пакет: VoIP (DSCP 46 / EF) ] ---> [ Инкапсуляция ] ---> [ Внешний IP (DSCP 0 / Best Effort) ]
                                                                                |
                                                                                v
                                                             Провайдер видит однородный поток

Модели туннелирования DiffServ по RFC 2983: Uniform и Pipe

Для стандартизации взаимодействия дифференцированных услуг с механизмами многоуровневой инкапсуляции инженерная группа IETF опубликовала документ RFC 2983 («Differentiated Services and Tunnels»). В нем определены три основные парадигмы:

1. Модель Uniform (Uniform Model)

В модели Uniform сеть рассматривает туннель как непрерывный сегмент общего маршрута:

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

Хотя модель Uniform сохраняет сквозную приоритизацию трафика в доверенных корпоративных сетях, она нарушает конфиденциальность в открытых средах, передавая контекст приложений третьим лицам.

2. Модель Pipe (Pipe Model)

В модели Pipe туннель рассматривается как изолированный выделенный канал с независимой политикой обслуживания:

На узле входа внешнему заголовку присваивается значение DSCP согласно политике оператора туннеля, без учета внутреннего класса трафика.
Внешнее поле DSCP обычно фиксируется на значении Best Effort (0x00) или едином классе массового транспорта.
Действия транзитных узлов влияют исключительно на продвижение внешних пакетов.
На выходе из туннеля внешний заголовок удаляется, а внутренний пакет восстанавливает исходное значение DSCP без искажений.

Модель Pipe обеспечивает строгую изоляцию метаданных: внешний наблюдатель видит только монотонный поток пакетов с единым приоритетом.

3. Модель Short-Pipe (Short-Pipe Model)

Модель Short-Pipe действует аналогично модели Pipe на всем протяжении транзитного маршрута. Отличие заключается в обработке на узле выхода: при отправке пакета в локальную сеть интерфейс использует внешний транспортный класс DSCP для локального планирования очереди, после чего передает исходный пакет получателю.

Недостатки модели Uniform в коммерческих туннельных шлюзах

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

Вектор риска	Влияние модели Uniform	Влияние модели Strict Pipe
Профилирование трафика	Высокое: провайдер идентифицирует голос, видео	Отсутствует: внешний поток имеет однородный DSCP
Избирательное замедление	Провайдер ограничивает скорость видеопотоков (AF4x)	Трафик обрабатывается одинаково как стандартный UDP
Утечки по побочным каналам	Распознавание нажатий клавиш через метки терминала	Временные задержки скрыты единой структурой потока
Вмешательство в приоритеты	Транзитные узлы искажают внутренние классы QoS	Внешние манипуляции сбрасываются при выходе

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

Разделение сигналов ECN (RFC 6040) и очистки DSCP (RFC 2474)

Распространенной ошибкой при устранении утечек DSCP является полное обнуление всего байта ToS. Данный 8-битный блок логически разделен на две части:

 0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|          DSCP         |  ECN  |
+---+---+---+---+---+---+---+---+
      Класс сервиса         Сигнал перегрузки
      (Биты 0 - 5)            (Биты 6 - 7)

DSCP (Биты 0-5): Определяет уровень приоритета пакета. Эта часть должна быть маскирована (установлена в 000000) во внешнем заголовке для защиты метаданных.
ECN (Биты 6-7): Обеспечивает явное уведомление о перегрузке в соответствии со стандартами RFC 3168 и RFC 6040. Эти биты информируют конечные узлы о заполнении буферов маршрутизаторов без потери пакетов (00 = Не поддерживается, 01 = ECT(1), 10 = ECT(0), 11 = CE - Зафиксирована перегрузка).

Если системный администратор полностью сбрасывает байт (ToS = 0x00), он отключает механизм ECN. Современные алгоритмы активного управления очередями (такие как CoDel, FQ-CoDel и CAKE) полагаются на метки ECN для предотвращения явления bufferbloat. При отсутствии ECN промежуточные маршрутизаторы вынуждены сбрасывать пакеты вместо их маркировки, что приводит к задержкам и падению скорости передачи.

Стандарт RFC 6040 формулирует четкие требования к туннелированию ECN:

При инкапсуляции внешние биты ECN должны повторять возможности внутреннего пакета.
При деинкапсуляции метка перегрузки CE (11), полученная внешним заголовком, должна быть обязательно перенесена во внутренний заголовок.

Следовательно, надежная архитектура туннеля должна обнулять метки DSCP (биты 0-5), но аккуратно сохранять и передавать биты ECN (биты 6-7).

Реализация в ядре Linux: XFRM, WireGuard и Netfilter Mangle

1. Поведение подсистемы Linux IP-XFRM (IPsec)

При настройке IPsec в Linux через утилиту ip xfrm структура состояния ядра (struct xfrm_state) по умолчанию дублирует внутренний байт ToS во внешний заголовок, если не задана явная директива. Администраторы могут зафиксировать параметры через iproute2:

# Просмотр активных состояний XFRM
ip xfrm state show

# Фиксация внешнего поля ToS для реализации модели Pipe по RFC 2983:
ip xfrm state update src 203.0.113.10 dst 198.51.100.20 \
    proto esp spi 0x1000 reqid 1 mode tunnel \
    tos 0x00

2. Поведение модуля ядра WireGuard

В исходном коде модуля WireGuard для Linux (drivers/net/wireguard/) обработка внешних заголовков UDP происходит в процедуре send.c:

/* Упрощенный фрагмент формирования заголовков в WireGuard */
static void wg_send_packet(struct wg_device *wg, struct sk_buff *skb)
{
    ...
    /* WireGuard извлекает ECN, обнуляя внешний DSCP */
    u8 ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb);
    ...
}

Модуль ядра WireGuard по умолчанию реализует безопасный вариант модели Pipe: внешний пакет UDP передается с чистым нулевым значением DSCP и корректными битами ECN. Тем не менее, сторонние реализации в пространстве пользователя на других платформах иногда нарушают это правило, наследуя системные флаги сокетов.

Нормализация исходящего трафика с помощью eBPF и Nftables

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

1. Фильтрация через Nftables

Следующее правило nftables обрабатывает исходящие UDP-пакеты туннеля (порт 51820), сбрасывая старшие 6 бит поля ToS и сохраняя младшие 2 бита ECN:

table inet vpn_sanitizer {
    chain egress_filter {
        type filter hook postrouting priority mangle; policy accept;

        # Установка DSCP в cs0 с сохранением ECN (биты 6-7)
        udp dport 51820 ip dscp set cs0
        udp dport 51820 ip6 dscp set cs0
    }
}

2. Нормализация с использованием eBPF (tc-bpf)

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

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <bpf/bpf_helpers.h>

SEC("classifier/egress_dscp")
int sanitize_outer_dscp(struct __sk_buff *skb)
{
    void *data = (void *)(long)skb->data;
    void *data_end = (void *)(long)skb->data_end;
    struct ethhdr *eth = data;

    if ((void *)(eth + 1) > data_end)
        return BPF_OK;

    if (eth->h_proto == __constant_htons(ETH_P_IP)) {
        struct iphdr *iph = (void *)(eth + 1);
        if ((void *)(iph + 1) > data_end)
            return BPF_OK;

        /* Проверка UDP-пакета на принадлежность к порту туннеля */
        if (iph->protocol == IPPROTO_UDP) {
            /* Сохранение битов ECN (маска 0x03) и сброс битов DSCP */
            __u8 old_tos = iph->tos;
            __u8 new_tos = old_tos & 0x03;

            if (old_tos != new_tos) {
                bpf_l3_csum_replace(skb, offsetof(struct iphdr, check),
                                    old_tos, new_tos, sizeof(new_tos));
                iph->tos = new_tos;
            }
        }
    }
    return BPF_OK;
}

char _license[] SEC("license") = "GPL";

Изоляция метаданных в протоколе RiceGuard от VPNRice

Архитектура платформы VPNRice построена на всесторонней защите метаданных сетевого уровня. В рамках протокола RiceGuard клиентские терминалы и промежуточные серверы реализуют модель Strict Pipe по стандарту RFC 2983:

[ Трафик приложений пользователя ]
  - Видеоконференции: DSCP AF41 (0x22)
  - Игровые данные:   DSCP CS2  (0x10)
  - Веб-страницы:     DSCP CS0  (0x00)
             |
             v
[ Клиентский модуль RiceGuard ]
  1. Фиксация начального состояния DSCP и ECN в памяти защищенной сессии.
  2. Шифрование данных с помощью алгоритма ChaCha20-Poly1305.
  3. Формирование внешнего заголовка IP/UDP со строгим значением DSCP CS0 (0x00).
  4. Применение правил RFC 6040 для битов ECN (6-7).
             |
             v
[ Транзитная сеть интернет / Провайдер связи ]
  - Внешний вид: полностью однородный поток пакетов UDP без индивидуальных признаков.
  - Анализ по побочным каналам не позволяет классифицировать звонки или передачу файлов.
             |
             v
[ Шлюз деинкапсуляции RiceGuard ]
  1. Проверка аутентификации и дешифрование полезной нагрузки.
  2. Считывание внешних сигналов перегрузки ECN и объединение с внутренними метками.
  3. Восстановление исходных меток DSCP для локальной сети назначения.

Однородный внешний профиль: Все пакеты, передаваемые между устройствами пользователей и серверами VPNRice, маркируются единым классом CS0. Наблюдатели лишены возможности сегментировать интерактивные сессии и фоновую загрузку данных.
Поддержка сигналов ECN: Строгое следование RFC 6040 сохраняет возможность адаптивного управления очередями (AQM), предотвращая задержки без потери пакетов.
Аппаратная стабильность: Встроенные фильтры на уровне ядра исключают манипуляции внешними параметрами трафика, обеспечивая предсказуемую защиту приватности.

Устранение утечек метаданных QoS по стандартам RFC 2983 гарантирует устойчивость пользовательского трафика к методам побочного статистического анализа.