Keenetic VPN BAT: маршрутизация через bat-файлы для выборочного обхода блокировок

Что такое bat-файл маршрутов для Keenetic и зачем он нужен

В операционной системе KeeneticOS реализована возможность загружать статические маршруты не по одному, а целым файлом в формате, привычном для Windows. Речь идёт о bat-файле, в котором каждая строка содержит команду route ADD с указанием сети, маски и шлюза. Такой подход радикально упрощает настройку выборочной маршрутизации: вместо десятков ручных записей через веб-интерфейс или SSH достаточно один раз сгенерировать файл и импортировать его.

Зачем это нужно? Типичный сценарий — доступ к зарубежным сервисам, которые блокируют трафик из определённых стран, или к ресурсам, заблокированным на уровне провайдера. Вместо того чтобы гнать через VPN весь интернет (что снижает скорость и ломает доступ к локальным сервисам), на роутере Keenetic создаются маршруты только для нужных подсетей. Весь остальной трафик идёт напрямую через основного провайдера. Файл .bat позволяет применять сотни маршрутов за секунды, что особенно важно при работе с CDN-сетями, где у одного сайта могут быть десятки IP-адресов.

Важно понимать: Keenetic не выполняет bat-файл как сценарий Windows, а лишь разбирает его строки, извлекая сети и маски. При импорте через веб-интерфейс значение шлюза (gateway) игнорируется — все маршруты автоматически привязываются к выбранному VPN-интерфейсу. Это удобно, поскольку не нужно думать о шлюзах, но требует внимательности: если забыть выбрать интерфейс, маршруты могут попасть не туда или не создаться вовсе.

Как Keenetic обрабатывает bat-файлы: синтаксис и ограничения

При загрузке bat-файла KeeneticOS ожидает строки формата Windows route ADD, например: route ADD 1.1.1.0 MASK 255.255.255.0 0.0.0.0. Каждая строка должна содержать сеть (в виде адреса), ключевое слово MASK, маску подсети и шлюз (обычно 0.0.0.0). Keenetic самостоятельно преобразует эти строки во внутренние команды ip route , где ` — это подсеть в бесклассовой адресации, а ` — имя интерфейса VPN.

Ключевые ограничения:

• Максимальное количество маршрутов в одном файле — 1024. Это техническое ограничение KeeneticOS. Если маршрутов больше, файл нужно разбивать на несколько частей и загружать их по очереди.
• Файл должен иметь расширение .bat (или .txt в некоторых прошивках, но рекомендуется .bat).
• Комментарии (строки, начинающиеся с REM) обычно игнорируются, но для совместимости лучше их не включать, особенно если вы используете сторонние генераторы.
• Шлюз в файле не важен — он игнорируется. Keenetic использует выбранный при загрузке интерфейс.

Также стоит учесть: KeeneticOS умеет загружать маршруты только в формате IPv4 через bat-файлы. Для IPv6 необходимо использовать отдельные файлы или другие методы, о чём подробнее будет сказано ниже.

Генерация bat-файла: NetRoute Pro и другие инструменты

Самый простой способ получить bat-файл — использовать браузерное расширение NetRoute Pro для Chrome. Оно анализирует открытый сайт, собирает все IP-адреса, с которыми он взаимодействует, и генерирует файл маршрутов. Пользователю достаточно открыть нужный ресурс, нажать на иконку расширения, выбрать платформу Windows (именно этот формат принимает Keenetic) и скачать результат.

Расширение позволяет настроить маску агрегации: вместо отдельных IP можно объединять их в подсети /24 или крупнее, что уменьшает количество записей. Также доступна опция RIPE BGP-оптимизации, которая заменяет отдельные IP на реальные BGP-префиксы, анонсируемые автономной системой (ASN) провайдера. Однако здесь есть нюанс: для мультитенантных CDN (например, Cloudflare, AWS) BGP-оптимизация приведёт к включению десятков тысяч IP, не относящихся к целевому сайту. Поэтому для shared CDN рекомендуется оставлять обычную агрегацию /24, а BGP-оптимизацию использовать только для single-tenant ASN.

Существуют и альтернативные инструменты, например, утилита AntiKeen, которая собирает актуальные списки маршрутов для заблокированных ресурсов (на основе данных itdog) и формирует готовые bat-файлы. Она представлена как в виде исполняемого файла, так и в виде PowerShell/Python-скриптов. Преимущество AntiKeen в том, что списки регулярно обновляются и учитывают ограничение в 1024 маршрута. Однако при использовании сторонних утилит важно проверять их репутацию и, по возможности, изучать исходный код, чтобы избежать вредоносных вставок.

Пошаговая загрузка bat-файла на роутер Keenetic

Процесс загрузки маршрутов из bat-файла в Keenetic интуитивно понятен и не требует специальных знаний. Рассмотрим его по шагам.

1. Убедитесь, что VPN-туннель (WireGuard, OpenVPN, IKEv2 и т.д.) настроен и работает. Проверить это можно в разделе «Интернет» → «Другие подключения»: интерфейс должен иметь статус «Подключено» и ненулевое время работы.

1. Откройте веб-интерфейс роутера, перейдя по адресу http://my.keenetic.net или по IP-адресу устройства. Войдите под учётной записью администратора.

1. Перейдите в раздел «Управление» → «Маршрутизация» (в некоторых версиях прошивки — «Система» → «Маршрутизация»). Откройте вкладку «IPv4-маршруты».

1. Нажмите кнопку «Загрузить» (или «Загрузить из файла»). В появившемся окне выберите скачанный bat-файл.

1. В выпадающем списке «Интерфейс» выберите ваш VPN-туннель. Имя интерфейса может быть, например, Wireguard0 или OpenVPN0 — зависит от конфигурации. Если не знаете точное имя, посмотрите в разделе «Интернет», какой интерфейс используется для VPN.

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

После загрузки маршруты появятся в списке «IPv4-маршруты» с указанием привязанного интерфейса. Проверить их наличие можно также через CLI-команду show ip route (доступна по SSH/Telnet). Важно понимать, что появление маршрута в списке ещё не гарантирует, что трафик реально пойдёт через VPN — необходимо проверить фактическое прохождение трафика.

Проверка работы маршрутов и устранение типичных проблем

После импорта маршрутов важно убедиться, что трафик действительно идёт через VPN, а не через ISP. Самый простой способ — с LAN-клиента (компьютера или смартфона, подключённого к роутеру) проверить внешний IP-адрес при обращении к ресурсу, маршрут до которого вы настроили. Если IP принадлежит VPN-провайдеру, а не вашему интернет-провайдеру, значит, всё работает.

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

• curl -v https://example.com 2>&1 | grep "Connected to" — покажет IP, к которому происходит подключение; он должен входить в один из ваших маршрутизируемых CIDR-блоков.
• curl -s https://api.ipify.org — вернёт ваш внешний IP; если маршрут до ipify.org идёт через VPN, результат будет соответствовать VPN-exit.

Если маршрут добавлен, но трафик не идёт через VPN, возможные причины:

• VPN-интерфейс не поднят (проверьте статус подключения).
• Не включена опция «Использовать для выхода в Интернет» для данного VPN-интерфейса. Это критично: без неё Keenetic не выполняет NAT для LAN-трафика, и VPN-сервер может отбрасывать пакеты с внутренними source-IP.
• Межсетевой экран блокирует нужные подсети (проверьте правила в разделе «Сетевые правила» → «Межсетевой экран»).

Ещё одна распространённая проблема — использование tracert/traceroute для проверки. Эти утилиты часто ненадёжны в контексте VPN, так как ICMP/UDP-пробы могут фильтроваться и показывать звёздочки на каждом хопе. Лучше полагаться на проверку exit IP.

Проблема DNS-leak: как не оставить следы у провайдера

Статические маршруты на Keenetic направляют только IP-трафик. DNS-запросы LAN-клиентов по умолчанию обрабатываются DNS-прокси Keenetic, который, в свою очередь, перенаправляет их на DNS-серверы интернет-провайдера (ISP). Это означает, что даже если весь трафик к сайту идёт через VPN, ваш провайдер видит, какие доменные имена вы запрашиваете, — возникает утечка DNS (DNS-leak). Для многих сценариев это нежелательно.

Существует три способа решения проблемы:

1. Полностью скрыть DNS от ISP. В разделе «Интернет» → «Другие подключения» выберите ваш VPN-интерфейс и установите его как приоритетный для DNS. Также можно в разделе «Сетевые правила» → «Интернет-фильтры» задать статические DNS-серверы, указав внутренний резолвер VPN-провайдера (например, 10.0.0.1). Тогда DNS-запросы будут уходить через туннель.

1. Использовать публичные DoH/DoT. KeeneticOS поддерживает DNS-over-HTTPS и DNS-over-TLS. В разделе «Сетевые правила» → «Интернет-фильтры» → «DNS-over-HTTPS/DNS-over-TLS» добавьте, например, Cloudflare (1.1.1.1), AdGuard (94.140.14.140) или Quad9 (9.9.9.9). Это шифрует DNS-запросы, и ISP не видит их содержимое, хотя факт обращения к DoH-серверу остаётся видимым.

1. Принять утечку. Если вы не хотите усложнять настройку, можно оставить поведение по умолчанию: шифруется только IP-трафик, а DNS остаётся у ISP. Это приемлемо, если ваша модель угроз не предполагает скрытие фактов посещения сайтов от провайдера.

Проверить наличие утечки можно с помощью сервиса dnsleaktest.com с LAN-клиента: показанный резолвер должен принадлежать вашему VPN или выбранному DoH, но не ISP. На самом роутере активные DNS-серверы видны в разделе «Системный монитор» → «DNS».

IPv6 и двойной стек: почему маршруты могут не работать

Статические IPv4-маршруты покрывают только IPv4-трафик. Если у целевого сайта есть AAAA-запись (IPv6-адрес), а у вашего роутера настроено IPv6-подключение, LAN-клиенты по умолчанию будут предпочитать IPv6 (согласно RFC 6724). В результате запросы к сайту пойдут через дефолтный IPv6-маршрут вашего ISP, минуя VPN, даже если IPv4-маршрут через VPN настроен корректно.

Есть два варианта решения:

1. Настроить IPv6-маршруты. Если ваш VPN-провайдер поддерживает IPv6, сгенерируйте отдельный bat-файл с IPv6-префиксами (например, 2606:4700::/32 для Cloudflare, 2001:4860::/32 для Google) и импортируйте его так же, как IPv4-маршруты, привязав к VPN-интерфейсу.

1. Отключить IPv6 глобально. Если у VPN нет IPv6-поддержки, проще отключить IPv6 на роутере в разделе «Интернет» → «Подключения» → «IPv6». Тогда весь трафик будет идти по IPv4 и корректно тунелироваться.

Важно помнить: отключение IPv6 может повлиять на доступность некоторых ресурсов, которые работают только по IPv6, но таких сейчас меньшинство. Для большинства сценариев выборочной маршрутизации это приемлемая жертва.

Автоматизация переключения маршрутов между VPN-интерфейсами

В сценариях, когда основной VPN-сервер может выходить из строя (например, из-за DDoS-атак), возникает необходимость быстро перенаправить все маршруты на резервный туннель. Вручную переключать десятки маршрутов — утомительно, поэтому существуют способы автоматизации через RCI (Remote CLI Interface) роутера.

KeeneticOS предоставляет API для управления маршрутами. Через POST-запросы к /rci можно получить список маршрутов, отфильтровать нужные и изменить их интерфейс. Например, команда POST /rci/ { 'show': { 'ip': { 'route': {} } } } возвращает все маршруты. После фильтрации тех, что привязаны к исходному VPN-интерфейсу, можно отключить их и создать заново с привязкой к целевому интерфейсу, затем выполнить сохранение конфигурации.

Для доступа к RCI извне роутера есть два основных пути:

• Прямой доступ через переадресацию портов. В разделе «Сетевые правила» → «Переадресация портов» можно пробросить порт, например 81, на внутренний порт 79 (где слушает RCI). Это простой, но небезопасный способ: RCI не требует авторизации, поэтому доступ к нему из интернета открывает полный административный доступ к роутеру.

• Безопасный доступ через KeenDNS с авторизацией. Настройте доменное имя через KeenDNS, создайте пользователя с правом доступа к HTTP-прокси, затем в разделе «Доступ к веб-приложениям домашней сети» добавьте поддомен rci, указав порт 79, и разрешите доступ только этому пользователю. После этого можно отправлять запросы к RCI с авторизацией через URL вида https://rci.ВАШДОМЕН.keenetic.link/rci/....

На основе RCI можно написать скрипт (например, на JavaScript или Python), который автоматически перенаправляет все маршруты с одного интерфейса на другой. Такой скрипт полезен для админов, управляющих VPN-инфраструктурой в офисе, где простой сервисов критичен.

Продвинутые методы: WireGuard AllowedIPs и альтернативные подходы

Если вы используете WireGuard, можно отказаться от статических маршрутов и управлять выборочной маршрутизацией через параметр AllowedIPs пира. В этом случае вы указываете список подсетей, которые должны идти через VPN, прямо в конфигурации WireGuard. Это более гибкий подход: не нужно загружать bat-файлы, а изменения применяются мгновенно при переподключении туннеля.

В Keenetic для этого нужно:

1. В разделе «Интернет» → «WireGuard» выбрать ваше подключение и открыть настройки пира.
2. В поле «Allowed IPs» вставить список подсетей, разделённых запятыми (например, 1.1.1.0/24, 8.8.8.0/24).
3. Сохранить изменения.

Этот метод особенно удобен, когда список маршрутов невелик и редко меняется. Для динамических списков (например, если IP-адреса сайта часто меняются) лучше использовать bat-файлы с регулярным обновлением.

Другой альтернативой является установка Entware и использование скриптов для автоматического обновления маршрутов, но это требует наличия USB-порта на роутере и более сложной настройки. AntiKeen как раз подходит для моделей без USB, так как не требует установки дополнительного ПО.

Обслуживание и обновление маршрутов: лучшие практики

Статические маршруты требуют регулярного обновления, особенно если вы маршрутизируете трафик к ресурсам за CDN. CDN-провайдеры (Cloudflare, Fastly, Amazon CloudFront) часто меняют IP-адреса своих серверов. Если маршрут устарел, трафик к сайту пойдёт напрямую через ISP, и выборочная маршрутизация перестанет работать.

Рекомендации по обслуживанию:

• Периодически (например, раз в месяц) пересоздавайте bat-файл с помощью NetRoute Pro или AntiKeen, чтобы включить актуальные подсети.
• Используйте функцию RIPE BGP-оптимизации для single-tenant ASN, чтобы маршруты были стабильнее.
• Для shared CDN предпочитайте агрегацию /24 — это разумный баланс между количеством маршрутов и точностью.
• Следите за количеством маршрутов: KeeneticOS поддерживает сотни статических маршрутов без проблем, но при превышении лимита (1024 на файл) разбивайте загрузку на несколько этапов.
• Если используете WireGuard, рассмотрите перенос части маршрутов в AllowedIPs, чтобы уменьшить количество записей в таблице маршрутизации.

Также важно после каждого обновления маршрутов проверять их работоспособность, особенно если вы изменили VPN-провайдера или добавили новые ресурсы. Автоматизация с помощью скриптов RCI может помочь быстро переключаться между резервными VPN и минимизировать время простоя.

Вопросы и ответы