maksimkurb

Решил перепроверить сейчас на Viva KN-1910 (версия 4.3.2), поведение разное в зависимости от того, заполню ли я в Keenetic'е поле "Адрес и порт пира" (Endpoint) или нет. Если на стороне Keenetic поля Endpoint и PersistentKeepalive заполнены, а со стороны сервера оба поля не заполнены - всё работает так, как Вы и сказали. При восстановлении подключения по основному каналу, трафик WG сразу начинает идти через него. Конфиг на сервере из двух строчек: PublicKey и AllowedIPs Если на стороне Keenetic поля Endpoint и PersistentKeepalive пустые, а со стороны сервера заполнены - то Keenetic переключается на резервный канал связи, а обратно на основной канал не возвращается, оставаясь на резервном. Конфиг на сервере из четырёх строчек: PublicKey, AllowedIPs, Endpoint и PersistentKeepalive Видео-демонстрация: https://www.youtube.com/watch?v=OZJTzrk1d28 UPD: Назначать интерфейс пирам, у которых не указан Endpoint как оказалось нельзя. А у таких пиров обычно IPшник серый и динамический (иначе почему бы не указать Endpoint), их только как-то костылять блокировкой по порту на уровне межсетевого экрана, наверное. Wireguard::Interface error[75505872]: "Wireguard0": "xxxx": unable to set connect interface without endpoint.

В конкретно описанном выше сценарии да. Но у меня есть ещё один VPN канал для подключения к NAS и его бы хотелось оставить с резервированием (при необходимости файлики перекачать или т.п.). И получается, что если роутер перейдёт на резервный канал, а потом обратно, туннель может остаться на лимитированном подключении и я не замечу, как выжру весь трафик, хотя проводной уже давно мог быть доступен. Сейчас можно костыльно это решить, если сделать два VPN-туннеля и всегда ходить через один IP, а если он не доступен, то только тогда через IP резервного VPN, но это не очень удобно (у меня split-brain DNS и придётся два сервера держать и как-то между ними переключаться на клиентских машинах в случае отвала основного канала)

Спасибо большое, не знал про такую возможность! В таком случае можно считать, что фича уже есть, а по поводу того, что WireGuard не переключается автоматически с резервного на основной канал можно считать багом? В какой подфорум такое лучше переместить?

Добрый день! Прошу рассмотреть возможность добавить для WireGuard опцию выбора WAN-интерфейса ("Подключаться через"), как это реализовано в других VPN-клиентах: Ситуация: основной канал на роутере А — проводной интернет; резервный канал на роутере А — мобильный 4G-модем с лимитом трафика; WireGuard используется для передачи потокового видео с камер; На стороне роутера А Endpoint в пире не заполнен, инициирует подключение роутер Б. При потере основного канала WireGuard на роутере А автоматически продолжает пытаться подключиться к удалённому пиру, но уже через мобильный WAN, что приводит к нежеленной передаче трафика и расходу лимитированного пакета. При этом в настройках WireGuard на роутере А у пира не указан endpoint, а на роутере Б был указан внешний IP основного канала роутера А (который уже выключен). При этом соединение магическим образом продолжает работать. Видимо роутер А закешировал себе IPшник и порт роутера Б и продолжает стучаться туда же, но уже с резервного WAN, и WireGuard туннель продолжает работать, но уже по 4G. При этом, даже при восстановлении основного канала, WireGuard не переключается на основной канал автоматически, из-за чего за ночь трафик резервного канала был практически исчерпан. Желаемое поведение: Иметь возможность ограничить WireGuard-интерфейсу список WAN-интерфейсов, через которые он может направлять трафик. После восстановления основного канала, трафик WireGuard по резервному идти больше не должен.

Тоже столкнулся с похожей проблемой при разработке своей утилиты "keenetic-pbr". Мне необходимо из Entware каким-то образом узнавать, активно ли текущее WireGuard/OpenVPN/etc соедниение. Через ip addr (и соотв. библиотеку netlink) можно узнать только состояние up=true/false (т.е. интерфейс административно включён или выключен). Через RCI (curl localhost:79/rci/show/interface) доступно больше информации, там есть поле connected=yes/no и link=up/down. Вот это поле connected меня полностью устраивает, чтобы понять, активно ли текущее соединение (напр. для WireGuard это значит, что keepalive пакеты проходят), однако чтобы понять, что nwg1 это то же самое, что и WireGuard1, нужно их соотностить по какому-то полю. Если бы RCI отдавал название системного интерфейса nwg1, это бы облегчило сопоставление. --- UPD: Сопоставление по IP не очень надёжное, т.к. если интерфейс выключен в Keenetic UI, то в RCI у него не будет IP-адреса, соотв. сопоставить его будет невозможно. MAC-адрес тоже есть не у всех интерфейсов (напр. у WireGuard его нет)

Добрый день. Сори, что пишу в старую тему, случайно нашёл этот тред, тот набор ansible-скриптов писал я Скрипты ansible нужно запускать на вашей собственной машине (под Linux или WSL). Ваша машина сама подключится по SSH к роутеру и всё там настроит, ставить python на роутер не нужно. Идея Ansible в том, чтобы хранить конфигурацию "как код" для последующего воспроизведения. Это удобно, если у вас есть сотня роутеров Keenetic и вы хотите одной командой поставить этот скрипт сразу на все эти роутеры. Я заархивировал этот репозиторий https://github.com/maksimkurb/ansible-keenetic-domain-routing, т.к. сам больше не пользуюсь данной конфигурацией, т.к. её сложно поддерживать и обновлять. На его замену я запаковал подобную конфигурацию в OPKG-пакет, который можно установить на роутер. Пакет содержит утилиту для скачивания и обработки списков, а также набор скриптов для простановки fwmark пакетам и создания правил маршрутизации (на подобие тому, что было в ansible-keenetic-domain-routing). Скрипты для маршрутизации написаны на BASH, чтобы их можно было поменять под себя, а утилита для обработки списков на GoLang для быстродействия (сейчас списки из 27000 ip и подсетей, а также 43000 доменов импортируются в ipset и dnsmasq за 7 секунд на моём Keenetic Viva). Одно из отличий от старого ansible-скрипта в том, что домены резолвятся не в момент импорта списка, а в момент DNS-запросов от клиентов локальной сети (через dnsmasq). Если будете этим пользоваться, дополнительно рекомендую настроить dnscrypt-proxy2 и указать у dnsmasq его как upstream-сервер вместо гугловского 8.8.8.8 по умолчанию.

Тоже наткнулся на эту проблему. У меня есть желание прокинуть через VPN-соединение только два конкретных устройства, но если назначить их на неосновную политику, проброс портов перестаёт работать. Мне нужно, чтобы отдельный сервер выходил в сеть через WireGuard-туннель, но при этом, чтобы я мог подключаться извне к этому серверу по портам 80/443. Если сделать наоборот: на основной политике поставить первым туннель и остальных клиентов перекинуть в неосновную политику (чтобы они не шли через туннель), тогда я не смогу пробросить порт уже на них.

Нет, не удалось. Написал Ansible-скрипт для автоматической настройки роутера, чтобы он сам скачивал списки и прописывал их в ipset (+ есть возможность добавить свои домены), на этом успокоился.

Тоже долго не мог разобраться (подключаюсь по L2TP/IPSec), вписывал и 192.168.xx.150 (IP клиента) и 192.168.xx.1 (Gateway IP), но решилось тем, что вписал IP адрес из параметра P-t-P из вывода ifconfig: # ifconfig ... ppp3 Link encap:Point-to-Point Protocol inet addr:192.168.xx.150 P-t-P:>>>>1.0.0.1<<<< Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1392 Metric:1 RX packets:75585 errors:0 dropped:0 overruns:0 frame:0 TX packets:50265 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:62505563 (59.6 MiB) TX bytes:3430496 (3.2 MiB) ... В моём случае будет gw = 1.0.0.1;. После этого маршруты стали нормально создаваться. Кстати, IP адрес 1.0.0.1 является публичным и принадлежит DNS-серверу Cloudflare. Это баг VPN-сервера, который я использую, в будущих версиях они собираются выдавать другой IP для L2-соединений. По L2TP таким образом заработало, а с OpenVPN настроить пока не получается (такая же ошибка "invalid gw address", что бы ни вписывал), экспериментирую.