Ground_Zerro

Максимальное удобство и простота. Браво! Отправил на релиз. Попробую изобразить что-то типа инсталлятора - установка/удаление одной командой.

Только вчера подумал о том, что это уже есть в роутере и нужно просто вытащить. Но было поздно - лег спать )) Исправлю на гит. Спасибо. Может есть смысл ещё более упростить скрипт? Например пусть он проходит по всем nwg интерфейсам, чтобы не нужно было их явно указывать в самом скрипте. Не думаю что на домашнем роутере их больше одного - трёх. А пингует какой-нибудь четко заданный узел, условный 8.8.8.8, который не закроет icmp от пары пингов в минуту, посчитав это за ddos. Вариативности будет меньше, в том смысле например если нужно проверять доступность каких-то конкретных узлов сети через WG. Но в таком случае скрипт становится максимально простым для использования бОльшим числом пользователей. Полностью отпадёт необходимость тонкой настройки самого скрипта. Можно будет написать opkg или sh который нужно будет просто один раз установить и всё.

Попадались в сети подобные штуки, но ссылок не сохранял т.к. регулятор работает по черному списку, а нам соответственно проще его "обелить". Гонять весь трафик через VPN не всегда имеет положительный результат. У меня например страдает пинг в играх. Еще мой хостер берет 1$ за каждый 1ТБ трафика (вх+исх), можно конечно его и поменять но он дешев, стабилен, быстр и дополнительная плата за трафик в его случае полностью оправдана.

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

Каким-то малоэффективным путем идете товарищи. Попробуйте решения AGH или подобные, они есть здесь на форуме, вот например инструкция (жми) с четким алгоритмом на основе опыта пользователей с этого форума. Просить маршруты у кого-то, вообще "такое себе" и вот почему (жми). Если без маршрутов совсем уж никак, то есть возможность сформировать их самостоятельно более простым путем (жми) ну или аналогами.

Рад, что помогло. Не смотря на то, что сменил роутер и перешел на решения использующие etware поднавляю утилиту и списки доменов если появляются запросы от пользователей. Сейчас вот посмотрел - как же она все-таки сильно изменилась с момента ее появления, а ведь не так уж и много времени прошло..

Готовое решение (ЖМИ). Тема на github. === Ниже первый пост === Умельцы придумали скрипт для микротика, который в случае отсутствия рукопожатия у WG рвет соединение и пытается переподключить его добавляя отправку на WG порт сервера небольшого мусора непосредственно перед самими рукопожатием. Пишут, что многим удалось таким образом реанимировать WG соединения на узлах где ТСПУ блокирует WG протокол. Скрипт для Микротик: Попросил ИИ адаптировать код для Keenetic с entware, вот что получилось: Сможет кто-то доработать и дать ума идее на Keenetic устройствах? Если уже есть аналогичное готовое - дайте пожалуйста ссылку.

UP В родных и красивых менюшках ковыряться приятней чем в консоли или специфичном CLI (когда USB у кинетика нема).

Интересная идея 👍, вот бы ее в сторону DNS-RouteSync-Navigator развернуть. А что? Дал IP (или автоматом брать если пользак в домашней сети), telnet или SSH логин + пароль и у тебя на роутере свежая статика по выбранным категориям. Хотя да - безопасность в этом варианте уже даже не хромает, ну и резолвить DNS вдали от целевого устройства такое себе, хотя к моему удивлению это многих устраивает.. 😄 К слову, сегодня к DM прикрутил агрегацию сетей до /24, не знаю какая от этого польза, но в pull requests попросили.

Я-> тут <-пытался собрать DNS имена связанные с Ютубом, попробуйте поковырять. По не проверенной информации чтоб престал тормозить видеопоток достаточно резолвить всего одно DNS имя: googlevideo.com

Уточню, на всякий случай.. Это не тот которым можно проверить пинг на роутере в разделе "диагностика", это который "Контроль состояния интернет-подключения (Ping Check)". До конца не понимал как это работает. Сложу себе в копилку. Спасибо.

Эксперты что-то не торопятся помогать. Давайте попробуем опереться на мое мнение, тем более оно тут единственное. Если я ошибусь – эксперты сразу же набегут чтобы напихать мне в панамку, что в Вашем случае будет только в плюс. Далее все будет исключительно из личного опыта, личного багажа знаний и личного понимания процессов, приступим. С топологией разобрались, будем считать, что там все хорошо. Также посчитаем, что сигнал беспроводной сети возле Voyager’ов хороший и судя по всему имеет устойчивый прием. В этих условиях я бы искал проблему в настройках самого беспроводного подключения и возможно в устройстве, используемом для проведения тестов. Рассмотрел внимательней скриншот настройки 5Ghz подключения. Не все включенные технологии приводят к улучшению результата, а в некоторых случаях могут его и вовсе ухудшить. Выбор канала – часть устройств плохо работает на некоторых каналах 5ГГц., возможно Peak выбрал один из таких при запуске. Это совсем не обязательно, просто в рамках «гадания на кофейной гуще». TX Burst - на некоторых (а по мне так на подавляющем их большинстве) устройствах наоборот может снизить скорость и увеличить те самые задержки, сделав их просто гигантскими. DL MU-MIMO - ориентирован на одновременную работу с ограниченном количеством клиентов (по количеству антенн) и в местах где их много также не очень эффективен. Самое интересное это отключенное управление BBS 802.11 k/v. Зачем? Стандарты k/v помимо своего прямого назначения – управление роумингом, имеют еще некоторые особенности, позволяющие снизить нагрузку на беспроводную сеть и ее клиентов. Используемый стандарт «n/ac» - сам не люблю «a» т.к. иногда из-за него возникали проблемы, особенно с не очень новым оборудованием, НО некоторые устройства без него напрочь отказывались подключаться к 5Ghz сети. Не знаю почему так происходило, но в практике такой опыт я имел. И так, меняем: Стандарт 802.11 - a/n/ac Ширина канала – 20/40/80/160 МГц ТХ Burst - выключить Beamforming - оставить DL MU-MIMO - выключить Airtime Fairness – оставить На прием - выключить Роуминг 802.11г (FT) – Использовать для беспроводных сетей 2,4 и 5 ГГц (не переживайте 2,4 не включится от этого) ID мобильного домена – E4 (например) Управление BSS-окружением 802.11 k/v - включить Band Steering – «По умолчанию» (поставить) Все ИМХО - так это вижу я. Если результат будет также плох, то обязательно попробуйте проверить на другом беспроводном устройстве. В любом случае, если проблему не удастся решить - обратитесь в поддержку Keenetic, она весьма отзывчива и всегда старается помочь. Хотя последнее время ответа приходится ждать довольно долго, крайний раз мне отвечали в течении 3х суток и первым ответ был стандартным: скиньте селфтест и файл конфигурации роутера ))) Если сразу приложите их в первом сообщении это значительно ускорит процесс. Кстати хотел спросить почему так категорически против 2,4ГГц сети? Это ограничивает число устройств способных использовать вашу сеть, ну и 2,4 иногда бывает предпочтительней, особенно в помещениях с большим числом перегородок и металлоконструкций. PS Вспомнилась очень похожая ситуация с 5ГГц и домашним Keenetic. Связанно это было с каким-то из обновлений OC роутера, после которого началась какая-то чехарда, задержки и долгое подключение. Жонглирование галочками в настройках эффекта не давало, помог сброс на заводские установки. Но это было лишь однажды и ооочень давно. P.P.S. В соседней теме у пользователя были похожие проблемы. Развязка там оказалась неожиданной - он отключил "Ping Checker" и все заработало. У меня он давно отключен т.к. раньше тоже замечал проблемы с этим пакетом, которые могли приводить к нестабильной работе в т.ч. разрывам соединения.

So many unknowns. Give more information and then maybe someone will try to help you. Start with how the devices are connected to each other i.e. network topology. What other tasks Peak assigned to the network controller is performing - its RAM and CPU utilization. How routing and LAN is configured. Whether the network is divided into Vlan, whether VPN is used, maybe some complex routing scheme. What is the response and latency between Peak and each Voyager. From the above it seems that Voyagers are connected in series with each other using only wireless network. In this case such losses and delays are not surprising.

Роутер не за NATом, IP вполне себе белый, порты открыты, провайдер их не блочит (проверил), режимы пробовались разные и прямой и через облако и автомат. Обнова прилетела до 15 Альфы, проблема модифицировалась, но стала хотя-бы решаемой. Роутер по прежнему не пускает из внешней сети на 22 порт, но если его поменять - коннект есть (и по KeenDNS, и по IP). На скрине: подключение на 22 - связи нет, меняем на любой другой (2222 в примере) - связь есть. Трабла в роутере осталась, но тема в принципе исчерпана. Всем спасибо.

Нет. Используется KeenDNS. Не знаю где ее взять. Есть репозиторий какой-то?