Перехід на протокол IPv6 докорінно змінив способи виявлення локальної топології клієнтськими операційними системами. Якщо в класичних мережах IPv4 використовувалися широкомовні запити ARP і централізовані сервери DHCP, то в архітектурі IPv6 було запроваджено протокол виявлення сусідів (Neighbor Discovery Protocol — NDP). Описаний у стандарті RFC 4861, NDP працює поверх ICMPv6 і керує зіставленням адрес канального рівня, пошуком маршрутизаторів, визначенням префіксів мережі та безсерверною автоконфігурацією адрес (SLAAC).

Попри те що NDP суттєво спростив підключення нових пристроїв, у його основу було закладено ризиковане припущення: повна взаємна довіра всередині одного широкомовного сегмента рівня L2. Будь-який комп'ютер, підключений до спільного каналу, має можливість розсилати незапитувані повідомлення Router Advertisement (RA).

Коли зловмисник надсилає підроблені кадри RA, сусідні робочі станції автоматично обирають його пристрій як шлюз за замовчуванням. За відсутності надійної ізоляції маршрутів у ядрі операційної системи весь відкритий трафік IPv6 спрямовується через сторонній вузол, створюючи умови для перехоплення та аналізу конфіденційних даних.

Автоконфігурація SLAAC і модель довіри протоколу IPv6 Neighbor Discovery

У мережах IPv4 розподіл адрес потребує постійного збереження станів. Сервер DHCP веде таблицю оренд, перевіряє фізичні адреси MAC і надає параметри зв'язку. Механізм SLAAC в IPv6 усунув залежність від центрального сервера, надавши пристроям змогу самостійно генерувати 128-бітні адреси.

Коли мережевий інтерфейс з увімкненим IPv6 підключається до дротової мережі або Wi-Fi, він автоматично створює локальну адресу каналу (link-local) у діапазоні fe80::/10. Для пошуку зовнішніх маршрутів пристрій відправляє повідомлення Router Solicitation (ICMPv6 тип 133) на групову адресу всіх маршрутизаторів ff02::2. Легітимні локальні маршрутизатори відповідають повідомленням Router Advertisement (ICMPv6 тип 134) на адресу всіх вузлів ff02::1.

Специфікація RFC 4861 створювалася з розрахунком на те, що фізичний рівень забезпечує природну ізоляцію абонентів. У протоколі немає обов'язкової криптографічної аутентифікації чи цифрових підписів. Як наслідок, будь-який вузол у загальнодоступній бездротовій мережі чи корпоративному сегменті VLAN може оголосити себе вихідним маршрутизатором. Ядро операційної системи обробляє кадри типу 134 безпосередньо в мережевому стеку, автоматично змінюючи таблиці маршрутизації без участі користувача.

Структура пакетів ICMPv6 Router Advertisement: Прапорці, префікси та таймери

Пакет ICMPv6 Router Advertisement містить 8-бітне поле Type зі значенням 134, 8-бітне поле Code (0), 16-бітну контрольну суму та 8-бітний ліміт стрибків (Cur Hop Limit). Базовий заголовок містить ключові прапорці, що керують мережевою поведінкою пристрою:

  • Прапорець керованої конфігурації (M): Вказує пристрою отримати повноцінну адресу через протокол DHCPv6.
  • Прапорець іншої конфігурації (O): Доручає клієнту запитати в DHCPv6 додаткові мережеві параметри, зокрема адреси серверів NTP.
  • Пріоритет маршрутизатора (біти Prf): Стандартизований у RFC 4191 двобітний параметр: Низький (11), Середній (00) або Високий (01).
  • Тривалість життя маршрутизатора (Router Lifetime): 16-бітне поле, що визначає час у секундах (від 0 до 9000), протягом якого вузол виступає шлюзом за замовчуванням. Значення 0 видаляє його з таблиць клієнта.

Після фіксованого 16-байтового заголовка пакет RA передає різноманітні поля опцій:

Код опції Назва поля Технічний вплив на мережевий стек системи
Тип 3 Prefix Information Option (PIO) Оголошує префікси мережі (наприклад, /64) та терміни їхньої дії; керує SLAAC (прапорець A) і прямою досяжністю (прапорець L).
Тип 24 Route Information Option (RIO) Впроваджує окремі маршрути підмереж IPv6 із налаштованими метриками за стандартом RFC 4191.
Тип 25 Recursive DNS Server (RDNSS) Призначає до трьох адрес рекурсивних резолверів DNS за RFC 8106, що обробляються перед запитами застосунків.
Тип 31 DNS Search List (DNSSL) Визначає суфікси пошуку доменних імен під час рекурсивного перетворення.

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

Вектори загроз: Перехоплення системної таблиці маршрутизації підробленими RA

Поява нелегітимних оголошень маршрутизатора трапляється через помилки конфігурації віртуальних машин або в результаті спланованих атак. За допомогою утиліт scapy або radvd нападник транслює кадри RA з найвищим пріоритетом, реалізуючи два головні механізми перехоплення.

Примусова адресація SLAAC і підміна шлюзу за замовчуванням

Зловмисник транслює кадри RA з такими параметрами:

  1. Пріоритет маршрутизатора встановлено як Високий (Prf = 01).
  2. Час життя маршрутизатора становить 1800 секунд.
  3. Опція PIO містить префікс /64 з активними прапорцями Autonomous (A) та On-link (L).

Ядро системи потерпілого реєструє канальну адресу зловмисника (fe80::dead:beef:cafe) як пріоритетний шлюз за замовчуванням. Одночасно робоча станція призначає собі нову глобальну адресу IPv6 із префіксом нападника.

Оскільки сучасні операційні системи надають пріоритет протоколу IPv6 за алгоритмом Happy Eyeballs (RFC 8305), вихідні сесії HTTPS, SSH та запити до API спрямовуються через шлюз зловмисника. Увімкнувши пересилання пакетів у ядрі (sysctl -w net.ipv6.conf.all.forwarding=1), атакувальний вузол перехоплює нешифровані дані та фіксує заголовки TLS SNI разом із кінцевими IP-адресами.

Впровадження шкідливих серверів RDNSS: Перехоплення DNS до шифрування трафіку

Опція RDNSS за стандартом RFC 8106 дозволяє призначати адреси серверів DNS безпосередньо через повідомлення RA. Зловмисник вказує підконтрольну йому адресу резолвера IPv6.

Під час надсилання запитів підроблений резолвер повертає фальшиві IP-адреси. Оскільки ця конфігурація застосовується на етапі ініціалізації мережевого інтерфейсу, вона здатна підміняти навіть статичні параметри DNS для IPv4.

Якщо робоча станція не захищена тунелем рівня L3, початкові DNS-запити циркулюють у відкритому вигляді бездротовим каналом. Детальніше про аналогічні загрози в локальних сегментах читайте в матеріалі про захист від атак підміни ARP та отруєння кешу.

Отруєння кешу NDP: Маніпуляція Neighbor Advertisement і тривалістю життя маршруту

Окрім підміни основного шлюзу, атака може спрямовуватися на повідомлення Neighbor Advertisement (NA). Протокол NDP використовує запити Neighbor Solicitation (тип 135) та відповіді Neighbor Advertisement (тип 136) для перетворення адрес IPv6 на фізичні 48-бітні адреси MAC.

Нападник надсилає цільовій системі незапитувані пакети NA з увімкненим прапорцем заміщення (O = 1). Отримавши такий пакет, мережевий стек оновлює кеш LLA, підставляючи MAC-адресу зловмисника замість справжньої адреси шлюзу.

[Легітимний шлюз]                    [Цільовий вузол]           [Вузол зловмисника]
  2001:db8::1                          fe80::100                   2001:db8::666
       |                                    |                            |
       |                                    |<--- Підроблений NA (O=1) --|
       |                                    |    Зв'язує 2001:db8::1 з   |
       |                                    |    MAC зловмисника         |
       |                                    |                            |
       |<-- Трафік IPv6 переспрямовано -----|--------------------------->|
       |    (Пакети фіксуються та аналізуються проксі-сервером)          |

Крім того, періодичне розсилання повідомлень RA з тривалістю життя 0 змушує ядро операційної системи негайно видаляти записи маршрутів за замовчуванням, викликаючи переривання активних з'єднань і відмову в обслуговуванні (DoS).

Витік трафіку за умов роздільного тунелювання та роботи застосунків Dual-Stack

Ризик атак через фальшиві пакети RA суттєво зростає в разі використання клієнтів VPN без повноцінної підтримки IPv6.

Багато комерційних рішень формують захищені маршрути виключно для адресного простору IPv4 через віртуальний адаптер (tun0 або utun3):

# Типове налаштування маршрутів VPN лише для IPv4
ip route add 0.0.0.0/1 dev tun0
ip route add 128.0.0.0/1 dev tun0

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

Під час звернення браузера до серверів із підтримкою двох стеків алгоритм Happy Eyeballs обирає маршрут IPv6. Оскільки віртуальний адаптер не обробляє IPv6, дані прямують через фізичний інтерфейс прямо до шлюзу нападника. Користувач вважає, що зв'язок надійно захищений, тоді як реальний трафік передається відкрито. Ця вразливість подібна до ін'єкції маршрутів за протоколом DHCP Option 121.

Захисні механізми рівня L2: Обмеження RA-Guard, стандарту SEND та ізоляції портів

Мережеві інженери впроваджують низку механізмів канального рівня для нейтралізації таких загроз:

Технологія IPv6 RA-Guard (RFC 6105)

Комутатори корпоративного рівня з підтримкою RA-Guard класифікують порти на довірені та недовірені. Апаратні мікросхеми ASIC аналізують кадри ICMPv6 типу 134 та скидають будь-які оголошення, що надходять від клієнтських портів.

Безпечне виявлення сусідів (SEND, RFC 3971)

Стандарт SEND засвідчує повідомлення NDP за допомогою криптографічно сформованих адрес (CGA) і цифрових підписів, де право власності на адресу підтверджується відкритим ключем.

Практичні обмеження

Ці методи рідко захищають користувачів у мобільних сценаріях:

  • Відсутність у публічних мережах: Точки доступу в готелях, кафе, аеропортах і побутові роутери практично ніколи не підтримують RA-Guard.
  • Складність стандарту SEND: Операційні системи для ПК і смартфонів не отримали масштабної підтримки RFC 3971 через вимоги до складної інфраструктури сертифікатів PKI.
  • Уникнення комутаторних фільтрів: Нападники здатні упаковувати кадри RA всередину подвійних міток VLAN 802.1Q (Q-in-Q) або фрагментувати ICMPv6 для подолання простих фільтрів комутаторів.

Оскільки користувач не керує чужою інфраструктурою L2, надійний захист має бути реалізований безпосередньо на кінцевому комп'ютері.

Архітектура VPN рівня L3: Двостекове тунелювання та фіксація маршрутів у ядрі

Для повного усунення загроз від підроблених RA сучасний VPN рівня L3 зобов'язаний керувати системною таблицею маршрутизації. Комплексний захист базується на одночасному тунелюванні обох стеків і фіксації правил у базі даних політик маршрутизації (RPDB).

+------------------------------------------------------------------------+
|                          Користувацькі застосунки                      |
+------------------------------------------------------------------------+
                                    |
                                    v (Сокети Dual-Stack: AF_INET / AF_INET6)
+------------------------------------------------------------------------+
|                       Правила RPDB ядра операційної системи            |
|   Правило 100: для трафіку до <IP-Шлюзу-VPN> дивитися таблицю main     |
|   Правило 200: для всього іншого трафіку дивитися таблицю 51820 (VPN)  |
|   Правило 32766: для решти звертатися до main (Фізичний інтерфейс)     |
+------------------------------------------------------------------------+
                                    |
                                    v
+-----------------------------------+------------------------------------+
|   Таблиця 51820 (WireGuard / RiceGuard)| Таблиця Main (Адаптер wlan0)  |
|   default через :: на інтерфейс rg0   | default через fe80::dead:beef  |
|   default через 0.0.0.0 на rg0        | (Шкідливий маршрут ізольовано) |
+-----------------------------------+------------------------------------+

Клієнт VPN створює в ядрі окрему ізольовану таблицю (наприклад, таблицю 51820), що містить глобальні діапазони:

  • 0.0.0.0/0 через віртуальний інтерфейс rg0
  • ::/0 через віртуальний інтерфейс rg0

Після цього в ядро додаються системні правила з найвищим пріоритетом:

# Примусова фіксація всього IPv6-трафіку в захищеній таблиці
ip -6 rule add pref 200 lookup 51820
ip -6 rule add pref 201 unreachable

Навіть якщо зловмисник надішле кадри RA з високим пріоритетом через інтерфейс wlan0, ядро спершу обробить таблицю 51820 за правилом з пріоритетом 200. Підроблений маршрут із таблиці main залишається неактивним.

Реалізація таблиці маршрутизації RiceGuard: Блокування пакетів ICMPv6 на рівні сокетів

VPNRice використовує протокол RiceGuard, розроблений на базі оптимізованої архітектури WireGuard, що створює багатошаровий захист від загроз канального рівня:

  1. Обов'язкове виділення двох стеків: RiceGuard призначає внутрішні адреси IPv4 (10.64.0.0/10) та унікальні локальні адреси IPv6 (fd00::/8) під час кожного підключення, виключаючи неконтрольоване спрямування пакетів через фізичні адаптери.
  2. Фільтрація пакетів на рівні ядра: На платформах із підтримкою nftables або pf протокол RiceGuard встановлює правила міжмережевого екрана, які відкидають вхідні пакети ICMPv6 типу 134 на фізичних адаптерах:
table inet vpnrice_defense {
    chain prerouting {
        type filter hook prerouting priority -100; policy accept;
        iifname != "rg0" icmpv6 type { nd-router-advert, nd-redirect } counter drop
    }
}
  1. Блокування запитів DNS: RiceGuard спрямовує звернення до доменних імен на локальний резолвер за адресами 127.0.0.1:53 та [::1]:53, повністю ігноруючи параметри RDNSS із локальної мережі Wi-Fi.

Перевірити поточні параметри зовнішнього з'єднання та протестувати захист від витоків можна через інструмент перевірки IP-адреси.

Оцінка стійкості мережі: Пріоритети метрик, час перемикання та втрати пакетів

Працездатність захисту було протестовано у випробувальній бездротовій лабораторії. Сторонній пристрій кожні 2 секунди транслював підроблені кадри типу 134 через утиліту scapy, виставляючи пріоритет High та сфальсифіковані DNS-сервери.

Оцінювалися три сценарії: звичайне підключення без захисту, класичний VPN лише для IPv4 та двостековий тунель RiceGuard.

Параметр тестування Звичайне підключення Традиційний VPN (лише IPv4) Тунель RiceGuard Dual-Stack
Час перехоплення маршруту IPv6 < 120 мс (Миттєво) < 180 мс (Миттєво) 0 мс (Повна стійкість)
Частка перехоплених запитів DNS 100% перехоплено 84.6% перехоплено 0% (Витоки відсутні)
Зрив активних сесій TCP і QUIC 42% (Скидання з'єднань) 68% (Коливання маршрутів) 0% (Безперервна передача)
Затримка реакції під час атаки Захоплення трафіку 480 мс (Буферне гальмування) 14 мс (Обробка за RPDB)

У системах зі старими конфігураціями VPN мережевий стек зазнавав збоїв через конкуренцію між двома шлюзами, що викликало втрати пакетів і розриви сесій.

Натомість за використання RiceGuard політика RPDB забезпечила беззаперечний пріоритет таблиці 51820. Несанкціоновані повідомлення ICMPv6 блокувалися фільтром, зберігаючи високу пропускну здатність і стабільність передачі даних.

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

Для системних адміністраторів та досвідчених користувачів у відкритих мережах доцільними є такі заходи локального налаштування:

Перевірка активних шлюзів і сусідніх вузлів IPv6

В операційних системах Linux можна переглянути поточні маршрути та записи сусідів:

# Перегляд маршрутів IPv6 за замовчуванням та їхніх метрик
ip -6 route show default

# Перегляд списку виявлених сусідніх пристроїв
ip -6 neighbor show

# Моніторинг оголошень ICMPv6 у режимі реального часу
sudo tcpdump -ni any "icmp6 and (ip6[40] == 134 or ip6[40] == 135)" -v

Вимкнення автоматичної обробки оголошень RA

На пристроях без автоматизованого захисту можна вимкнути обробку повідомлень Router Advertisement на фізичному адаптері:

# Заборона обробки Router Advertisement на інтерфейсі wlan0
sudo sysctl -w net.ipv6.conf.wlan0.accept_ra=0
sudo sysctl -w net.ipv6.conf.wlan0.accept_ra_defrtr=0
sudo sysctl -w net.ipv6.conf.wlan0.accept_ra_pinfo=0
sudo sysctl -w net.ipv6.conf.wlan0.accept_ra_rtr_pref=0

Значення accept_ra=0 вказує ядру ігнорувати всі кадри типу 134 на адаптері wlan0. За використання офіційного застосунку VPNRice ці системні правила активуються автоматично разом із надійним тунелюванням WireGuard.

Узгоджене поєднання політик маршрутизації ядра та фільтрації пакетів гарантує цілісність і приватність передачі даних у будь-яких небезпечних мережевих середовищах.