
Ground_Zerro
Участники форума-
Постов
48 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Ground_Zerro
-
Готовое решение (ЖМИ). Тема на github. === Ниже первый пост === Умельцы придумали скрипт для микротика, который в случае отсутствия рукопожатия у WG рвет соединение и пытается переподключить его добавляя отправку на WG порт сервера небольшого мусора непосредственно перед самими рукопожатием. Пишут, что многим удалось таким образом реанимировать WG соединения на узлах где ТСПУ блокирует WG протокол. Скрипт для Микротик: Попросил ИИ адаптировать код для Keenetic с entware, вот что получилось: Сможет кто-то доработать и дать ума идее на Keenetic устройствах? Если уже есть аналогичное готовое - дайте пожалуйста ссылку.
-
Интересная идея 👍, вот бы ее в сторону DNS-RouteSync-Navigator развернуть. А что? Дал IP (или автоматом брать если пользак в домашней сети), telnet или SSH логин + пароль и у тебя на роутере свежая статика по выбранным категориям. Хотя да - безопасность в этом варианте уже даже не хромает, ну и резолвить DNS вдали от целевого устройства такое себе, хотя к моему удивлению это многих устраивает.. 😄 К слову, сегодня к DM прикрутил агрегацию сетей до /24, не знаю какая от этого польза, но в pull requests попросили.
-
Я-> тут <-пытался собрать DNS имена связанные с Ютубом, попробуйте поковырять. По не проверенной информации чтоб престал тормозить видеопоток достаточно резолвить всего одно DNS имя: googlevideo.com
- 156 ответов
-
- adguardhome
- ipset
-
(и ещё 1 )
C тегом:
-
Эксперты что-то не торопятся помогать. Давайте попробуем опереться на мое мнение, тем более оно тут единственное. Если я ошибусь – эксперты сразу же набегут чтобы напихать мне в панамку, что в Вашем случае будет только в плюс. Далее все будет исключительно из личного опыта, личного багажа знаний и личного понимания процессов, приступим. С топологией разобрались, будем считать, что там все хорошо. Также посчитаем, что сигнал беспроводной сети возле 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 в примере) - связь есть. Трабла в роутере осталась, но тема в принципе исчерпана. Всем спасибо.
-
МодельAir (KN-1611) EAEU Версия ОС4.2 Alpha 13 После обновления, прямо и именно сразу после обновления с Alpha 12 до 13, нет подключения к роутеру по SSH из внешней сети. Ни по KeenDNS (прямой, облако, авто) ни по IP. Из локальной сети соединяется. Нужные галки стоят. Снимал и снова ставил галки, менял порты и пароли, пересоздавал пользователя - не помогает. HELP!!
-
Собрал DNS Инсты, какие нашел, здесь. Если есть что туда добавить - буду благодарен за фитбэк. У меня Кинетик младшей модели, энтваре на нем не доступно соответственно KVAS, ADhome, xKeen и остальное тоже. Выход только статические маршруты. Пришлось изобретать что-то что поможет держать список IP в актуальном состоянии т.к. они тоже могут меняться. По ссылке в репозитории есть собранные по группам списки dns разных сервисов и софтина на пайтон для быстрого изъятия IP через публичные DNS сервера.