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

Прихований побічний канал: як параметри QoS викривають активність користувача

Під час надсилання мережевими застосунками IP-пакетів операційна система класифікує трафік за допомогою точки коду диференційованих послуг (DSCP - Differentiated Services Code Point), 6-бітного сегмента в байті Type of Service (ToS) протоколу IPv4 або Traffic Class протоколу IPv6, стандартизованого в RFC 2474. Застосунки голосового зв'язку (VoIP) зазвичай встановлюють клас прискореного пересилання (DSCP EF, двійковий код 101110, число 46), відеоконференції позначають клас гарантованого пересилання (наприклад, 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 підтримує наскрізну політику QoS у довірених мережах, у публічному сегменті інтернету вона порушує конфіденційність, розкриваючи характер трафіку стороннім особам.

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

У моделі Pipe тунель вважається виділеним ізольованим каналом зв'язку з власною незалежною політикою пріоритетів:

На вузлі входу зовнішній заголовок отримує значення DSCP відповідно до політики тунельного оператора, без урахування пріоритету внутрішнього пакета.
Зовнішнє поле DSCP фіксується у значенні Best Effort (0x00) або на узгодженому базовому рівні.
Модифікації транзитних мереж впливають виключно на проходження зовнішніх пакетів.
Під час деінкапсуляції зовнішній заголовок видаляється, а внутрішній пакет повністю відновлює початкове значення DSCP.

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

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

Модель Short-Pipe працює ідентично моделі Pipe на всьому транзитному маршруті. Відмінність виникає на кінцевому вузлі: інтерфейс деінкапсуляції використовує зовнішній клас для локального планування черги, перш ніж передати оригінальний внутрішній пакет кінцевому отримувачу.

Небезпека моделі Uniform у комерційних сервісах VPN

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

Чинник загрози	Наслідки моделі Uniform	Захист моделі Strict Pipe
Профілювання даних	Високі: провайдер виокремлює дзвінки, відео та файли	Відсутні: зовнішній потік має однорідну мітку Best Effort
Вибіркове уповільнення	Провайдер обмежує швидкість відеопотоків (AF4x)	Трафік обробляється однаково як стандартний UDP
Витоки через побічні канали	Розпізнавання натискань клавіш через мітки термінала	Часові затримки приховані єдиною формою пакетів
Зовнішні спотворення	Транзитні вузли пошкоджують внутрішні мітки QoS	Зовнішні маніпуляції скидаються на виході

Коли оператори зв'язку мають змогу бачити зовнішні мітки DSCP, вони отримують інструмент для селективного обмеження смуги пропускання без потреби зламу алгоритмів шифрування.

Розмежування сигналів ECN (RFC 6040) та очищення поля DSCP (RFC 2474)

Типовою помилкою під час запобігання витокам метаданих є повне обнулення байта 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. Сучасні алгоритми активного керування чергами (AQM, такі як CoDel, FQ-CoDel та CAKE) покладаються на ECN для запобігання надлишковим буферним затримкам. Без ECN проміжні маршрутизатори змушені знищувати пакети, що викликає стрибки пінгів і зниження продуктивності.

Стандарт RFC 6040 чітко визначає принципи обробки ECN у тунелях:

Під час інкапсуляції зовнішні біти ECN повинні повторювати можливості внутрішнього пакета.
Під час деінкапсуляції, якщо зовнішній заголовок отримав сигнал перевантаження (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 у 0 */
    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. Створення зовнішнього заголовка зі строгим значенням DSCP CS0 (0x00).
  4. Обчислення бітів ECN згідно з вимогами стандарту RFC 6040.
             |
             v
[ Загальнодоступний інтернет / Мережа провайдера ]
  - Зовнішній вигляд: однорідний потік пакетів UDP без ідентифікаційних міток.
  - Жодна стороння система не може класифікувати тип користувацького трафіку.
             |
             v
[ Шлюз деінкапсуляції RiceGuard ]
  1. Перевірка автентичності та безпечне дешифрування даних.
  2. Зчитування сигналів перевантаження ECN та перенесення у внутрішній пакет.
  3. Відновлення початкового маркування DSCP для локальної мережі призначення.

Однорідна зовнішня структура: Усі пакети, що прямують від пристроїв до інфраструктури VPNRice, маркуються класом CS0. Зовнішні спостерігачі не мають змоги розмежувати важливі інтерактивні потоки та передавання файлів.
Підтримка ECN без втрат: Повна відповідність стандарту RFC 6040 забезпечує своєчасне реагування на перевантаження каналів алгоритмами AQM без знищення корисних даних.
Надійний захист у ядрі: Апаратні та системні фільтри виключають спотворення параметрів пакетів, гарантуючи передбачуваний рівень захищеності у публічних мережах.

Повне усунення витоків метаданих QoS гарантує користувачам VPNRice надійний захист від статистичного аналізу трафіку за будь-яких умов.