t800
-
Posts
172 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by t800
-
-
До кучи перестал интернет работать: поломались днсы. Гора вот таких сообщений:
Dns::Secure::DotConfigurator: unable to obtain addresses for "cloudflare-dns.com".
и так для всех днс. Пришлось откатить на 3.9.6. Впервые за все время так фатально поломалась альфа
-
1
-
-
@hellonow Я прошу прощения за деревянность, но я не понимаю, какая связь между включением/выключением PC, подключённого в ethernet-порт экстендера, рестартом DHCP на контроллере (откуда информация о его рестарте?), и уведомлением об отключении экстендера от сегмента. Почему тогда по второму экстендеру нет никаких проблем в этот момент?
В техподдержку - ок, могу открыть кейс, но обычно они рекомендуют по бетам и драфтам писать на форум.
-
@hellonow прошу прощения, будет какой-то комментарий по этому вопросу? Проблема никуда не делась, воспроизводиться 100% чётко.
-
@hellonow понимаете, получается так, что линк падает всегда когда ПК включается и выключается. Как такое может быть? FastEthernet0/1 - это порт, куда включён комп. Получается, что up и down по этому порту провоцирует сетевую недоступность шлюза через FastEthernet0/0. Быть может с чипом какая-то проблема?
А самое главное, не было такого раньше. Мне не пришло в голову зафиксировать момент, когда впервые стали приходить эти уведомления, но началось это именно на 3.9
-
Чтобы было проще копать в файле диагностики: последний раз проблема наблюдалась сегодня, 24.11.2022 ~10:20
Из облака пришло два пуш-сообщения в телефон.
-
Привет
Keenetic Air (KN-1610) RU (в режиме экстендера) после обновлений до одной из альф 3.9 внезапно стал рапортовать через приложение Keenetic аварии по отключению от домашнего сегмента. Аварии короткие, почти сразу приходит уведомление о том, что соединение восстановлено. Закономерность удалось поймать: это совпадало с включением/выключением ПК, включенного в ethernet порт. У меня достаточно большой парк кинетиков, больше ни на одной модели такого не наблюдается. Диагностика - в скрытом посте.
-
Мелькает в диагностике экстендеров строка:
Селф-тест добавлен в скрытое сообщение
Upd. Сообщение появляется в отладке после того как я захожу в "Изменить список установленных компонентов"
Core::Configurator: not found: "show/rc/ntp/master" [http/rci].
-
1
-
-
Аналогично. Пробовал с айфона пока, правда. Ни в сафари, ни в хроме нет страницы
Upd. Проверил на айпаде - та же история. Под виндой - норм, тестировал в хроме. В общем, похоже, что с IOS девайсами какая-то несрастямба у WebUI вышла в 3.8.1
-
Проблема решилась полным сбросом ретранслятора и повторным его добавлением в wifi-систему
-
После обновления вижу ретранслятор в списке незарегистрированных устройств гостевого сегмента. Кроме того, он же присутствует в списке устройств, которые можно добавить в систему. При том, что уже добавлен фактически, и давно.
Так и задумывалось?
-
1
-
-
@Xambeyтакого функционала нет, увы. Я решил это "от противного": всё по дефолту идёт в VPN за исключением тех ресурсов, которые через VPN работать отказываются. Благо их не так много.
-
Только что, enterfaza сказал:
а каким образом пускать один и тот же хост на разные домены на разных каналах?
Только маршрутизацией по подсетям.
-
6 минут назад, Xambey сказал:
Где я тут могу ввести список доменов для которых будет использовано определенное подключение?
Где в вашем исходном сообщении вы пишете о доменах? Цитата: "Очень хочется иметь возможность создать список хостов, которые будут ходить через определенный интерфейс (vpn например)".
-
В 09.04.2022 в 22:19, Xambey сказал:
список хостов, которые будут ходить через определенный интерфейс (vpn например), невероятно актуальная фича!!!
Именно в таком виде (привязка хост-подключение) невероятно актуальная фича давно реализована и прекрасно работает. См. раздел управления "приоритеты подключений"
-
1
-
-
39 минут назад, Le ecureuil сказал:
службы и интерфейсы не разделяются как таковые
Да, ок. Я просил вашего коллегу это подтвердить в рамках запроса, но от явного ответа он ушел в тот момент. 🙂 Сейчас всё понятно, спасибо за разъяснения!
-
8 минут назад, Le ecureuil сказал:
И да, ACL имеет высший приоритет
Спасибо за ответ. Но хочу пояснить почему вообще возник мой вопрос. Я предполагал, что ACL имеет наивысший приоритет только для сетевых интерфейсов. Ssh-сервер, всё-таки, это служба, пусть и имеющая настройку security-level. Поэтому, разрешив входящий трафик из Wireguard0, я ожидал, что ssh-сервер не пустит входящий коннект от public-интерфейса, раз это явно запрещено. Исходя из вашего объяснения, получается, что ssh-сервер имеет тот же подход в работе уровней безопасности, что и сетевые интерфейсы. Это всё объясняет, но было бы неплохо в какой-то форме отразить это в документации. Допускаю, что я один такой тугой, но всё-таки служба <> интерфейс, отсюда и вопросы.
-
20 минут назад, Le ecureuil сказал:
Пришлите туда пожалуйста. Пока вообще ничего непонятно из вашего описания, потому без технических подробностей не хочу обсуждать что там происходит
Отправил в запрос.
Виноват, обычно вполне внятно изъясняюсь. Попробую еще раз:
1. Есть два кинетика - Giga и Giga-III, между ними поднят Wireguard-тоннель, имя интерфейса на обоих - Wireguard0
2. На Giga-III Wireguard0 имеет уровень public.
3. Подключения с хостов в домашней сети Giga 192.168.1.0/24 по ssh к Giga-III проходят успешно. На мой взгляд это неверно, потому на Giga-III настроено
ip ssh security-level privateЯ понимаю это так, что ssh-сервер должен принимать входящие соединения только с интерфейсов с уровнем private. Таким образом, с Wireguard0 ssh-соединения в текущей конфигурации проходить не должны. Но они проходят, и я хотел бы разобраться в причинах.
-
15 минут назад, Le ecureuil сказал:
self-test отправляли в поддержку с гига-1? Если да, то скажите номер в zendesk.
Не отправлял, только куски конфигурации. Но инженер поддержки и не просил, с его точки зрения всё очевидно, а я неправ в своих ожиданиях. Посмотрите - запрос № 578948
-
17 часов назад, r13 сказал:
Потому что у acl приоритет выше
Приоритет выше для интерфейса же, на котором ACL создан, а не для всех прочих интерфейсов или компонентов, имеющих настраиваемый уровень безопасности.
17 часов назад, r13 сказал:Лучше покажите какие acl созданы для интерфейса. Возможно там и еет ничего
Есть. Разрешён входящий трафик по протоколу IP; источник - удалённая сеть (192.168.1.0/24), цель - локальная сеть (192.168.0.0/24)
-
12 минуты назад, r13 сказал:
Public private - это пресеты для настройки firewall. Если настроили acl то будет использоваться acl, у них приоритет выше.
Согласен. Только причём здесь ssh-сервер? ACL это набор запретов и разрешений для интерфейса. Для ssh-сервера я не создаю никаких ACL. Почему ACL на интерфейсе Wireguard0 оверрайдит прямой запрет на коннект с public интерфейсов на ssh-сервере?
-
Добрый день
Столкнулся вот с такой ситуацией. Есть два кинетика. Локальный - Гига-1 и удалённый - Гига-2. Настройки ssh-сервера у меня в Гиге-1:
ip ssh security-level private lockout-policy 5 15 3 session timeout 3600То есть, явно указано, что принимаются входящие соединения только с интерфейсов, где security-level установлен = private. Далее, в Гига-1 настроен WG-туннель до Гига-2. Интерфейс имеет уровень public:
interface Wireguard0 description WG-Tunnel security-level public ip address 10.0.0.2 255.255.255.0 ip mtu 1324 ip access-group _WEBADMIN_Wireguard0 in ip tcp adjust-mss pmtu wireguard peer *** !WG-S endpoint ****:16332 keepalive-interval 30 allow-ips 10.0.0.0 255.255.255.0 allow-ips 192.168.1.0 255.255.255.0 allow-ips 192.168.2.0 255.255.255.0При этом ssh соединения, входящие на этот интерфейс (из сети с Гига-2) без проблем устанавливаются с сервером на Гига-1. Открыл кейс в поддержку. Первый ответ был вообще удивительным. Мол, исходно соединение приходит из Home сегмента удалённого кинетика (Гига-2), где тип интерфейса - private. Поэтому Гига-1 принимает входящие ssh соединения.
На мой вопрос откуда известен тип исходного интерфейса, особенно если на удалённом конце мог быть НЕ кинетик вообще, я получил второй ответ. Что соединение устанавливается, потому что у меня есть аксесс-лист, разрешающий входящие соединения из удалённой сети. Но это же ерунда, аксесс-лист не меняет тип интерфейса и не меняет логику ssh-сервера, он просто разрешает входящие соединения извне! Тем не менее, такой ответ предоставлен официально, я на него дал свои комментарии, но хотел бы услышать мнение сообщества. Может я чего-то не понимаю и исходно неправ в ожиданиях?
-
Собрал wifi-систему (Giga - основной + Air и Extra - репитеры), стык медью, бэкхол выключен. Для AppleTV после регистрации настроил запрет работать через Air и Extra, чтобы не прыгал с точки на точку. В итоге, когда перезагружал wifi на гиге, appletv перескочил в экстру и назад не вернулся. Логика работы настройки непонятна. Буду признателен за пояснения и решение.
Скриншоты и селф-тесты - в следующем сообщении
-
22 часа назад, r13 сказал:
Не, это не вариант, ssid в mws же реплицируются
Совершенно верно. У меня аккурат такая ситуация. Сегмент, созданный для работы строго на одном рутере (контроллере меш-системы) в итоге присутствует на всех без исключения экстендерах, что уже приводило к переключениям его клиентов
-
Только что, AndreBA сказал:
Что за ковычки у вас в каманде в конце?
Кавычки у меня там двойные. Пустой пароль. У меня такая команда отработала и с добавлением в Wifi-систему после неё проблем не было.
Keenetic OS 4.0 Alpha 18 мобильное приложение не видит подключение
in Тестирование Dev-сборок
Posted
Яндекс не проверял, но adguard и cloudflare точно не работают. И это только в 4.0а18. Откатился на 3.9.6 - всё заработало снова. Пробовал дважды, результат один и тот же.