vasek00

Ранее команда была. Пример для Wireguard настройки 1. Клиент[WG-client]-----Инет------[WG-Serv]Keenetic[WG-clint]-------Инет------[WG-Serv].... 2. Клиент[WG-client]-----Инет------[WG-Serv]Keenetic[WAN-пров]-------Инет---------------.... Есть политика в ней активен WG-client Keenetic для WG интернет сервера ip policy Policy0 permit global Wireguard0 no permit global GigabitEthernet0/Vlan9 Далее есть WG-Serv для удаленных клиентов, которые подключаются к данному роутеру interface Wireguard2 description UKN-WG ... connect ! up Вводим описанную ранее выше команду ip hotspot policy Wireguard2 Policy0 заворачиваем клиентов, которые подключились по WG2 в политику "Policy0" -> получаем их выход в интернет не через п.2. а по п.1 Вариант для клиента "VPN-сервер IKEv2/IPsec" ниже или точнее еще ниже Посмотрите тему

Все что написано выше вернуло работу WG.

https://github.com/Vyacheslav-S/iperf3-public-servers-list Заходите в Web/cli и далее "exec iperf3 -c a210.speedtest.wobcom.de -P 20 -R -t 120" (где P потоки зависит от проца -> 7621 и аналоги вытягивал 400-500Мбит, -R прием, -t время в секундах) в "Системный монитор" смотрим. Можно найти подходящий iperf сервер в России в интернете.

Так как пользователи писали что и через другие страны так же проблема. Скорей всего решили навести порядок Возврат к endpoint, а не к IP адресам.

Так как стоит Entware - вариант AdguardHome не рассматривали

Вопрос чуток не по теме. На вопрос в yandex "что быстрее по отработке ipset или стат. маршрутизация" Коснусь примера есть стат маршруты их 8 ( c масками 255.255.192.0, 255.255.128.0, 255.254.0.0, 255.255.0.0, 255.255.224.0) и вариант с "object-group fqdn" на 10 записей получилось 122 ip адреса и в конечном итоге "MARK --set-xmark" Или скорей всего "выбор между ipset и маршрутизацией зависит от конкретных задач и предпочтений пользователя" B как раз решение "object group fqdn можно добавить ip-адреса".

Делала как то давно, проверил сейчас для 5.х (есть отличие от 4.х, так как теперь по MAC)

Вопрос только зачем, если он WG сервер и раньше мог быть создан в той же .../otherConnections и так же можно было управлять выходом в интернет через политику. Как и стало с ZeroTier или туннелями IPIP, GRE и EoIP для которых создали WEB.

Да хоть четвертый - ВСЕ УЖЕ БЫЛО СДЕЛАНО РАНЕЕ, для удобства настроек пользователя под все плюшки которые сейчас есть в прошивке что вывести куда вывести? всё раньше делалось через веб, кроме ip nat - про то и речь читаем выше.

По моей логике уже все было и работало, решили для пользователей вывести в WEB для настройки. Все что можно сейчас уже давно описано и реализовано, единственная фишка это управление - ручками, а будет в WEB. Плюсом сама фишка ip nat Wireguard2 ip hotspot policy Wireguard2 Policy0

Было ранее уже все и так работало, решили в WEB сделать. Ранее - заходим "otherConnections" и создаем Далее можем приклеить политику для них и все отлично работает.

А что же это по вашему Только полностью его настроил.

Можно попасть через

Новая плюшка использования iperf3. (config)> iperf3 interface - interface for Iperf3 server port - port for Iperf3 server security-level - set iperf3 server security level (config)> iperf3 (config)> iperf3 security-level Usage template: security-level (public | protected | private) Choose: public protected private (config)> iperf3 interface Usage template: interface {interface} Choose: ... Bridge0 ... (config)> iperf3 interface Bridge0 Iperf3::Server: Interface changed to Bridge0. (config)> iperf3 port Usage template: port {port} (config)> iperf3 port 5200 Iperf3::Server: Port changed to 5200. (config)> system configuration save Core::System::StartupConfig: Saving (cli). (config)> После этого она исчезает iperf3 interface Home iperf3 security-level private В запущенных сервисах ее нет. (config)> service iperf3 Iperf3::Server: Enabled. (config)> Теперь запустим (config)> service iperf3 Iperf3::Server: Enabled. (config)> 2727 root 1196 S /usr/bin/iperf3 -s --bind-dev br0 ......

У вас время выбрано "action start 00 03 * action stop 01 03 *" и повнимательней посмотрите на selftest после перезагрузки роутера (хотя бы пару раз) Делал выключение wifi в 0-0 и включение в 6-0 = проблем по времени не было никогда.

Только как вариант использования, для клиентов.

Проверил 50A8 1. WG в нем два пира (два клиента) 2. Выход в интернет их настроен через WG на Keenetic Клиент1/2 ---мобильный---[WG2]Keenetic[WG0-клиент]-----Инетернет-----[WG-Сервер].... Просьба не "ломать".

Маленькая ремарка к @Le ecureuil не испортить то что уже работает сегодня.

Заглянете в selftest

ki_rb_draft_4.01.B.2.0-0_firmware.bin и тогда https://osvault.keenetic.net/ki_rb/ Ну и в интернете 5 минут поиска

В свое время ставил на ExtraII прошивку из draft - 4.01.B2 - размером 14MB она была, это к слову про максимальная прошивка там 3.8.7 О каком telnet идет речь, есть проще 1. WEB/cli это 192.168.1.1/a и далее ввод команды 2. Хотите так сказать telnet

Не гарантирую, так как с AGH c 13 февраля, 2020 и проверять как то не хочется. Могу сказать что на ЛЮБОМ профиле и для ЛЮБОГО доп сегмента +два WG он AGH является DNS сервером, за искл. двух клиентов про которые шла речь ранее.

https не использую правда, а вот с tls проблем нет tls://security.cloudflare-dns.com tls://dns.google.com tls://safe.dot.dns.yandex.net Проверил https://dns.google/dns-query на тест Upstream без проблем прошло и скажу еще что это чистый тест через провайдера РТ.

В примере выше есть сегмент умного дома и yandex станции и как видно для них dns-proxy rebind-protect auto filter assign host preset yandex-станция1 yandex-safe filter assign host preset yandex-станция2 yandex-safe 2. для умных да по барабану а рекламы там и так не будет и как говорится без разницы куда их пускать, опять же в примере сегмент умного дома, но его контролирует AGH так же (это в моем случае, но можно и не контролировать им) 3. в AGH как раз и есть настройки для клиентов

Речь выше была например - задаем маршрут два маршрута одновременно до узла 1.1.1.1 через интерфейс nwg0 и так же 1.1.1.1 через интерфейс nwg1 тогда имеем вот что 1.1.1.1 dev nwg0 proto static scope link metric 1000 при проблеме на nwg0 тогда имеем вот что 1.1.1.1 dev nwg1 proto static scope link metric 1000 при восстановлении nwg0 тогда имеем вот что 1.1.1.1 dev nwg0 proto static scope link metric 1000 Это при использовании в основной Теперь то же самое, но в созданной политике аналогично 1.1.1.1 для двух nwg прописано оба ip policy Policy2 ... permit global PPPoE0 no permit global Wireguard1 no permit global Wireguard0 ... route 1.1.1.1 Wireguard0 auto reject route 1.1.1.1 Wireguard1 auto reject получаем, тут вопрос в какой последовательности вводить это стат маршрут, тот и в дамках, если сначала на nwg1 а потом на nwg0 то будет ~ # ip ro show table 14 default dev ppp0 scope link metric 1000 1.1.1.1 dev nwg0 scope link metric 1000 отключаем nwg0 ~ # ip ro show table 14 default dev ppp0 scope link metric 1000 1.1.1.1 dev nwg1 scope link metric 1000 и включаем nwg0 ~ # ip ro show table 14 default dev ppp0 scope link metric 1000 1.1.1.1 dev nwg0 scope link metric 1000