Мережеві тунелі традиційно розглядали маршрутизацію пакетів і криптографічний захист як два відокремлені модулі. У класичних VPN операційна система спершу спрямовує пакети через віртуальний інтерфейс, застосовує правила фаєрволу і лише після цього передає дані стороннім базам політик безпеки. WireGuard долає цю фрагментацію за допомогою концепції криптографічної маршрутизації (Cryptokey Routing, CKR). Пов'язуючи відкриті ключі пірів зі списком авторизованих підмереж (AllowedIPs), WireGuard об'єднує маршрутизацію, пошук криптографічної сесії та захист від підробки IP-адрес в єдину операцію на рівні ядра.

Проблема відокремлення маршрутизації від шифрування у класичних VPN

У традиційних рішеннях, таких як IPsec (RFC 4301) та OpenVPN, параметри маршрутизації та політики шифрування функціонують у різних площинах. Типове розгортання IPsec у середовищі Linux спирається на стек XFRM: пакет спрямовується до інтерфейсу тунелю, але перехоплюється базою політик безпеки (SPD). Ядро вимушене виконувати багатовимірний пошук за адресами джерела, одержувача, протоколом і портами для знаходження асоціації у базі SAD.

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

  1. Россинхронізація станів: Зміна маршрутів на інтерфейсі без коригування бази SPD призводить до раптового скидання пакетів або до їх витоку у незашифрованому вигляді через зовнішній адаптер.
  2. Складність конфігурації: Одночасне адміністрування таблиць маршрутизації, правил фаєрволу (iptables або nftables) та політик IPsec вимагає значних зусиль, збільшуючи ризик помилки.
  3. Високі накладні витрати: Послідовний пошук за селекторами для кожного пакета навантажує центральний процесор, обмежуючи пропускну здатність на гігабітних каналах.

OpenVPN у просторі користувача має аналогічні недоліки. Пакет багаторазово переміщується між ядром і прикладними процесами через пристрої tun/tap, спричиняючи втрати часу на перемикання контексту.

Фундаментальна концепція: як Cryptokey Routing об'єднує ідентичність та IP-шляхи

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

Інтерфейс WireGuard (наприклад, wg0) працює подібно до мережевого комутатора. Замість прив'язки MAC-адрес до фізичних портів інтерфейс пов'язує відкриті ключі з IP-префіксами. У налаштуваннях кожного піра параметр AllowedIPs містить список дозволених діапазонів IPv4 та IPv6:

# Приклад конфігурації піра WireGuard
[Peer]
PublicKey = 2b6w8mQv8J7yV9hZ0k1LmNoPqRsTuVwXyZ123456789=
Endpoint = 198.51.100.10:51820
AllowedIPs = 10.200.0.2/32, 2001:db8:cafe:1::2/128

Ця конфігурація суворо визначає правила для вихідного та вхідного потоків трафіку.

Архітектура подвійної перевірки: вихідний пошук та вхідна верифікація

WireGuard розділяє обробку пакетів на два послідовні процеси:

  • Вихідний трафік (Outbound): Коли ядро спрямовує нешифрований IP-пакет до інтерфейсу wg0, модуль аналізує IP-адресу призначення і виконує пошук найдовшого збігу префікса (LPM) у локальній таблиці AllowedIPs. Визначивши потрібного піра, WireGuard шифрує пакет ключами ChaCha20-Poly1305 і відправляє сформовану датаграму UDP на зафіксовану кінцеву точку.
  • Вхідний трафік (Inbound): Отримавши зашифрований пакет, ядро розшифровує та автентифікує його за допомогою сесійних ключів рукостискання Noise IK. Після розшифрування WireGuard перевіряє внутрішню IP-адресу джерела. Вона обов'язково повинна входити до списку AllowedIPs, закріпленого за цим піром.

Захист від спуфінгу на швидкості інтерфейсу: заміщення правил фаєрволу

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

Перевірка вхідного пакета:
[Відкритий ключ: Key_A] -> Внутрішній IP джерела: 10.200.0.99
Пошук у дереві AllowedIPs: адреса 10.200.0.99 належить Key_B, а НЕ Key_A.
Дія: ПАКЕТ ВІДКИДАЄТЬСЯ (Збільшення лічильника rx_dropped)

Оскільки фільтрація відбувається всередині драйвера до передачі пакета в основний мережевий стек, сфальсифіковані пакети не можуть вплинути на ARP-таблиці або порушити правила маршрутизації, усуваючи потребу у складних правилах rp_filter.

Реалізація у ядрі Linux: структура префіксного дерева в allowedips.c

Для досягнення мінімальних затримок передачі пакетів WireGuard відмовляється від лінійних списків. Модуль ядра Linux (drivers/net/wireguard/allowedips.c) використовує оптимізоване двійкове префіксне дерево (Radix Trie).

Пошук за найдовшим збігом префікса (LPM) у двійковому дереві

Ядро підтримує два окремі корені префіксних дерев для кожного пристрою: для діапазонів IPv4 (ключі 32 біти) та IPv6 (ключі 128 бітів). Кожен вузол представляє бітовий префікс і містить вказівники на ліву (біт 0) і праву (біт 1) гілки, а також посилання на структуру піра struct wg_peer:

/* Спрощена структура за мотивами drivers/net/wireguard/allowedips.h */
struct allowedips_node {
    struct allowedips_node __rcu *bit[2];
    struct allowedips_node *parent;
    struct wg_peer *peer;
    u8 cidr;
    u8 bits[];
};

Пошук адреси відбувається побітно від старшого біта. Алгоритм запам'ятовує найглибший вузол із дійсним посиланням на піра, забезпечуючи точний вибір найдовшого префікса за час $O(K)$, де $K \le 32$ для IPv4 та $K \le 128$ для IPv6. Операції пошуку захищені механізмом RCU (Read-Copy-Update), що дозволяє процесорним ядрам виконувати паралельні операції без блокувань.

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

Ключовим правилом криптографічної маршрутизації є однозначність напрямку: конкретна адреса призначення може вести лише до одного піра. У разі наявності перекриття префіксів WireGuard діє за чіткими правилами:

  • Якщо пір B реєструє префікс, ідентичний чинному префіксу піра A, володіння цим діапазоном переходить до піра B.
  • Якщо пір B реєструє більш точну підмережу (192.168.1.50/32) всередині ширшого діапазону піра A (192.168.1.0/24), дерево зберігає обидва записи. Пакет на адресу 192.168.1.50 буде надіслано піру B за правилом найдовшого префікса, а решта трафіку підмережі надходитиме піру A.

Це усуває будь-яку невизначеність під час передавання трафіку.

Динамічний роумінг кінцевих точок: збереження сесії при зміні сокетів

У класичних тунелях IPsec сесії жорстко прив'язані до зовнішніх адрес клієнта. Коли мобільний пристрій змінює мережу з Wi-Fi на 5G, зв'язок втрачається до завершення повторного узгодження ключів.

WireGuard відокремлює зовнішню кінцеву точку від внутрішньої криптографічної ідентичності. Параметр Endpoint є лише тимчасовою адресою:

  1. Мобільний клієнт надсилає зашифрований пакет із нової адреси (наприклад, 203.0.113.88:41234).
  2. Сервер розшифровує та автентифікує пакет за чинним ключем сесії.
  3. Після перевірки справжності сервер автоматично оновлює зареєстровану адресу кінцевої точки на 203.0.113.88:41234.
  4. Наступні пакети до цього клієнта негайно спрямовуються за новим маршрутом.

Це забезпечує безперервний роумінг без розриву активних з'єднань додатків.

Маршрутизація всього інтернет-трафіку: усунення петель через fwmark та ip rule

Під час спрямування всього трафіку через тунель (AllowedIPs = 0.0.0.0/0, ::/0) виникає рекурсивна петля: якщо всі пакети мають іти через wg0, власні зашифровані пакети WireGuard також потраплять назад у wg0.

Для розв'язання цієї проблеми застосовується маршрутизація на основі політик (Policy-Based Routing) разом із маркуванням пакетів (fwmark):

# 1. Призначення системної мітки інтерфейсу WireGuard
wg set wg0 fwmark 51820

# 2. Додавання правила для спрямування немаркованих пакетів
ip -4 rule add not fwmark 51820 table 51820
ip -4 rule add table main suppress_prefixlength 0

# 3. Налаштування маршруту за замовчуванням у таблиці 51820
ip -4 route add default dev wg0 table 51820

Коли програма ініціює з'єднання, ядро бачить, що пакет не має мітки 51820. Спрацьовує правило not fwmark 51820, направляючи пакет у таблицю 51820 і далі в wg0.

Після шифрування пакета ядро, враховуючи налаштування fwmark = 51820, позначає зовнішній пакет цією міткою. При повторній оцінці маршруту мічений пакет ігнорує таблицю 51820 і виходить у мережу через фізичний адаптер (наприклад, eth0), що повністю ліквідує петлю маршрутизації.

Порівняння Cryptokey Routing із класичною моделлю політик IPsec SPD/SAD

Архітектурні відмінності між WireGuard CKR та моделлю IPsec XFRM підтверджують ефективність інтегрованого підходу:

Критерій оцінки WireGuard Cryptokey Routing IPsec XFRM Framework (RFC 4301)
Модель відповідності Прямий зв'язок відкритого ключа та IP у Radix Trie Багатовимірна база політик безпеки (SPD)
Перевірка вхідного трафіку Вибірка за таблицею AllowedIPs за час $O(K)$ Пошук збігів за селекторами асоціацій (SA)
Захист від спуфінгу Вбудований у ядро без додаткових витрат Потребує налаштування фільтрації rp_filter
Роумінг клієнтів Автоматичне оновлення під час обробки пакетів Потребує додаткового розширення MOBIKE (RFC 4555)
Обсяг кодової бази ядра Близько 4 000 рядків верифікованого коду C Сотні тисяч рядків коду ядра та демонів IKE
Блокування потоків Паралельне читання через механізм RCU Глобальні блокування таблиць SAD та SPD

Як RiceGuard оптимізує пошук у префіксних деревах та Anycast-маршрутизацію

У системі VPNRice фірмовий модуль RiceGuard оптимізує криптографічну маршрутизацію для роботи в розподілених мережах Anycast:

  • Апаратна обробка через eBPF та XDP: RiceGuard переносить дерева AllowedIPs у структури eBPF (BPF_MAP_TYPE_LPM_TRIE). Пакети верифікуються та маршрутизуються безпосередньо на рівні мережевої карти за допомогою XDP, що забезпечує швидкість обробки понад 14 мільйонів пакетів на секунду.
  • Оптимізація маршрутів Anycast: У вузлах Anycast сервери оголошують однакові пули адрес. RiceGuard синхронізує стан клієнтів між шлюзами, запобігаючи скиданню сесій у разі змін маршрутів BGP.
  • Швидка збіжність: Під час зміни точки доступу таблиці оновлюються за мікросекунди без повторного узгодження ключів, зберігаючи мінімальні затримки для інтерактивних сервісів.

Практична перевірка внутрішніх таблиць та рішень маршрутизації WireGuard

Мережеві інженери можуть контролювати стан криптографічної маршрутизації за допомогою штатних утиліт Linux.

Перегляд активних пірів та діапазонів AllowedIPs:

# Перегляд стану адаптера WireGuard і таблиці AllowedIPs
wg show wg0

Перевірка правил маршрутизації та додаткових таблиць:

# Діагностика правил політики маршрутизації та таблиці 51820
ip rule show
ip route show table 51820

Контроль скинутих пакетів через невідповідність адреси в AllowedIPs:

# Моніторинг відкинутих пакетів на рівні інтерфейсу
ip -s link show dev wg0
grep -E "AllowedIPs" /var/log/messages 2>/dev/null

Динамічне додавання діапазону адрес без зупинки тунелю:

# Оновлення дозволених IP-адрес для активного піра
wg set wg0 peer "2b6w8mQv8J7yV9hZ0k1LmNoPqRsTuVwXyZ123456789="   allowed-ips "10.200.0.2/32,192.168.10.0/24"

Перспективи розвитку: протоколи динамічної маршрутизації поверх криптотунелів

Оскільки інтерфейс WireGuard працює як повноцінний мережевий адаптер, він легко взаємодіє з демонами динамічної маршрутизації BIRD та FRRouting (FRR).

Вказавши значення AllowedIPs = 0.0.0.0/0, ::/0 для довірених вузлів, інженери отримують захищений канал, поверх якого протоколи BGP та OSPF автоматично узгоджують метрики зв'язку та керують маршрутами.

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