← На главную

Split Tunneling в WireGuard через AllowedIPs

В WireGuard параметр AllowedIPs одновременно и ACL-фильтр, и таблица маршрутизации. NetRoute Pro генерирует готовую строку AllowedIPs из доменов любого сайта — дополнительные ip route команды не нужны, просто отредактируйте конфиг пира и перезапустите туннель.

Синтаксис команды

Синтаксис:

AllowedIPs = <CIDR1>, <CIDR2>, <CIDR3>

Пример:

AllowedIPs = 1.1.1.0/24, 8.8.8.0/24, 162.159.0.0/16

Добавьте в секцию [Peer] файла wg0.conf. Описано в официальном quickstart WireGuard.

Что понадобится

Шаг 1. Сгенерируйте AllowedIPs в NetRoute Pro

  1. Откройте нужный сайт в Chrome
  2. Нажмите на иконку NetRoute Pro в панели расширений
  3. Выберите платформу WireGuard
  4. Нажмите Analyze Website
  5. Скопируйте полученную строку вида: 
    AllowedIPs = 104.21.32.0/24, 172.67.182.0/24, ...
Совет: включите RIPE BGP оптимизацию — она подставит реальные BGP-префиксы провайдера. Получите стабильные подсети, которые не ломаются при ротации IP у Cloudflare/Fastly. Важно: RIPE BGP возвращает все префиксы анонсируемые ASN — для multi-tenant CDN (Cloudflare AS13335, AWS AS16509, DigitalOcean AS14061) это десятки тысяч IP, покрывающих несвязанные сайты. BGP-оптимизация подходит для single-tenant ASN; для shared CDN оставьте обычную /24 CIDR-агрегацию.

Шаг 2. Вставьте AllowedIPs в конфиг пира

Linux (wg-quick)

Отредактируйте файл конфига (обычно /etc/wireguard/wg0.conf) и замените строку AllowedIPs в секции [Peer]:

[Interface]
PrivateKey = <ваш приватный ключ>
Address = 10.0.0.2/32

[Peer]
PublicKey = <публичный ключ сервера>
Endpoint = vpn.example.com:51820
AllowedIPs = 104.21.32.0/24, 172.67.182.0/24, ...
PersistentKeepalive = 25

Windows / macOS (GUI)

  1. Откройте приложение WireGuard
  2. Выберите ваш туннель и нажмите Edit tunnel
  3. В секции [Peer] замените значение поля AllowedIPs
  4. Нажмите Save

Android / iOS

  1. Откройте приложение WireGuard и выберите ваш туннель
  2. Нажмите на пира → поле Allowed IPs
  3. Вставьте новый список подсетей
  4. Нажмите Save явно — приложение иногда сбрасывает изменения при выходе без сохранения

Шаг 3. Перезапустите туннель

Чтобы новые AllowedIPs применились, переподключите туннель:

DNS leak — обязательно прочитать

WireGuard через AllowedIPs направляет трафик по IP. DNS он не направляет. Браузер всё равно спрашивает у системного резолвера (обычно ISP, через DHCP) какой IP у example.com — через туннель идёт только сам IP-трафик. ISP видит какие сайты вы посещаете, даже если данные зашифрованы.

Три варианта в зависимости от модели угроз:

  1. Полностью спрятать DNS от ISP (split-DNS через wg-quick). Добавьте строку DNS = в [Interface] — wg-quick применит её при подъёме туннеля: 
    [Interface]
PrivateKey = ...
Address    = 10.0.0.2/24
DNS        = 10.0.0.1, ~example.com, ~another-site.com
    Записи ~домен заставляют systemd-resolved использовать VPN-DNS только для этих доменов (split-DNS). Без них через VPN-DNS пойдут все запросы.
  2. Снизить видимость для ISP (публичный DoH/DoT). Используйте публичный резолвер для всего: 
    DNS = 1.1.1.1, 1.0.0.1
    ISP больше не видит запросы; их видит Cloudflare.
  3. Принять leak. Уберите строку DNS совсем — шифруется только данные, lookup'ы остаются на дефолтном резолвере. Подходит для случая "просто разблокировать сайт".

Проверить: dnsleaktest.com или browserleaks.com/dns — показанный резолвер должен принадлежать вашему VPN-провайдеру или выбранному DoH, не ISP.

Утечки IP в браузере (WebRTC)

Даже когда split tunneling корректно настроен на уровне ОС, JavaScript на странице может через WebRTC (STUN/ICE) узнать ваш реальный локальный и публичный IP, минуя VPN. Это by design (для P2P видео/аудио нужны прямые адреса), не баг — но это утечка которую VPN не может предотвратить на сетевом уровне.

IPv6 dual-stack bypass

Записи AllowedIPs в WireGuard специфичны для address family. Если вы перечислили только IPv4-префиксы, трафик к тому же домену через IPv6 (а его большинство современных сайтов предпочитают согласно RFC 6724) пройдёт мимо туннеля через дефолтный v6-маршрут ISP.

Два варианта решения:

Fail-closed (kill switch)

Когда WireGuard-туннель падает (смена сети, ручной стоп, ошибка маршрутизации), ядро убирает маршруты привязанные к wg-интерфейсу — и трафик к ранее-тунелированным CIDR'ам уходит через дефолтный маршрут. Используйте PostUp/PostDown wg-quick для firewall-правил, привязанных к жизненному циклу туннеля:

[Interface]
PrivateKey = ...
Address    = 10.0.0.2/24

# Fail-closed: дропать трафик к тунелированным CIDR'ам если он не идёт через %i (этот туннель)
PostUp = iptables -I OUTPUT ! -o %i -d 1.1.1.0/24 -j REJECT
PostUp = iptables -I OUTPUT ! -o %i -d 8.8.8.0/24 -j REJECT
PostDown = iptables -D OUTPUT ! -o %i -d 1.1.1.0/24 -j REJECT
PostDown = iptables -D OUTPUT ! -o %i -d 8.8.8.0/24 -j REJECT

%i заменяется на реальное имя интерфейса (например wg0). Когда туннель поднят, трафик идёт через него; при wg-quick down правила удаляются. Если туннель падает аварийно без выполнения PostDown — CIDR'ы остаются заблокированы, что и есть безопасный failure mode (блок, не leak).

Для продвинутых: Table = off

По умолчанию wg-quick добавляет маршрут для каждого CIDR из AllowedIPs в главную таблицу маршрутизации. Table = off под [Interface] отключает автоматическую установку маршрутов — вы управляете routing'ом сами через PostUp/PostDown. Полезно когда нужен policy routing (по source IP, fwmark, процессу), кастомная routing-таблица или интеграция с frr/bird/quagga.

[Interface]
PrivateKey = ...
Address    = 10.0.0.2/24
Table      = off       # не устанавливать маршруты автоматически

# Управляйте маршрутами сами — пример policy routing:
PostUp = ip route add 1.1.1.0/24 dev %i table 100
PostUp = ip rule  add from 192.168.1.100 lookup 100
PostDown = ip rule  del from 192.168.1.100 lookup 100
PostDown = ip route flush table 100

Большинству это не нужно — дефолтное поведение (автоинсталл маршрутов из AllowedIPs) и есть то, на что рассчитан вывод NetRoute Pro.

Проверка

Команда sudo wg show отобразит пира с применёнными allowed ips:

sudo wg show

В выводе должны быть все подсети, которые вы указали. На клиенте в LAN можно дополнительно проверить:

tracert example.com     # Windows
traceroute example.com  # Linux/macOS

Первые хопы должны идти через WireGuard-эндпоинт.

Частые проблемы

Страницы зависают или грузятся частично (PMTU black hole)

Симптом: страница начинает грузиться, приходят первые килобайты, потом замирает; или одни сайты работают, другие — нет. Классический path MTU black hole — большие пакеты дробятся по пути, ICMP «fragmentation needed» блокируется upstream firewall'ом, отправитель ретрансмитит вслепую.

Дефолтный MTU WireGuard — 1420 (или 1280 по IPv6). На PPPoE реальный канал 1492; на 4G/LTE часто 1400; на некоторых CGNAT — 1280. Понизьте MTU под [Interface]:

[Interface]
MTU = 1380     # попробуйте 1380, далее 1280 / 1200 если страницы всё ещё зависают

На роутерах которые форвардят через туннель (WG-клиент на роутере с LAN-клиентами) дополнительно clamp'ните TCP MSS чтобы downstream клиенты не превышали PMTU:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
    -j TCPMSS --clamp-mss-to-pmtu

Пропал весь интернет

Убрали 0.0.0.0/0, но новый AllowedIPs не покрывает нужные подсети. Добавьте явно все подсети, которые должны идти через VPN, или верните 0.0.0.0/0.

На Android туннель бесконечно "connecting"

Приложение не сохранило изменения. Откройте туннель, ещё раз впишите AllowedIPs, явно нажмите Save и переподключитесь.

Error: AllowedIPs has invalid format

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

Пример конфигурационного файла

Готовый шаблон с комментариями. Замените примеры маршрутов выводом NetRoute Pro для ваших сайтов.


# Example WireGuard peer config with split tunneling.
# Generated by NetRoute Pro: https://alexander2k.github.io/netroute-site/
#
# AllowedIPs in [Peer] section doubles as both an ACL and routing table.
# Only the listed networks are sent through the tunnel — everything else
# uses the default route. Replace placeholders with your real keys/addresses.

[Interface]
PrivateKey = YOUR_CLIENT_PRIVATE_KEY
Address    = 10.0.0.2/24
DNS        = 1.1.1.1

[Peer]
PublicKey           = YOUR_SERVER_PUBLIC_KEY
Endpoint            = your.vpn.server:51820
PersistentKeepalive = 25

# Networks to route via VPN — add/remove based on NetRoute Pro output.
AllowedIPs = 1.1.1.0/24, 8.8.8.0/24, 162.159.0.0/16

# To route everything via VPN, use: AllowedIPs = 0.0.0.0/0, ::/0
# Apply with: sudo wg-quick down wg0 && sudo wg-quick up wg0

Подсказка: Нужен конфиг без строк-комментариев? В настройках NetRoute Pro снимите галочку «Включать комментарии в экспортируемые файлы» — расширение выгрузит только команды маршрутизации. Полезно для роутеров, которые не принимают комментарии.

Все примеры конфигов на GitHub →

Официальная документация

Готовы попробовать?

NetRoute Pro — бесплатное расширение Chrome для генерации маршрутов из любого сайта.

Установить расширение