Перейти к содержанию

t800

Участники форума
  • Постов

    195
  • Зарегистрирован

  • Посещение

Весь контент t800

  1. @Ponywka Вы не рассматриваете возможность реализовать резервный маршрут? Например, в группе указать целевой интерфейс nwg1, и резервный - ppp0? Сейчас МТ работает по принципу "эксклюзивный" маршрут. И если интерфейс падает, то доступа к доменам/подсетям в группе больше не будет, хотя при этом вполне может существовать и альтернативный рабочий интерфейс.
  2. @Ponywka Сегодня поймал ситуацию, когда при добавлении новой группы (и правил в ней) МТ внезапно потерял примерно две трети списка, который был до этого Воспроизвести не возьмусь, но мне показалось, что это совпало с очень длинным ожиданием "сохранение изменений", когда я не дождался окончания и перезагрузил страницу
  3. @Ponywka Перезагрузил роутер (менял состав компонентов), МТ автоматом не поднялся. /opt/etc/init.d # ./S99magitrickle status Checking MagiTrickle Daemon... dead. При этом в логе кинетика: I [Feb 15 11:40:14] root: Started MagiTrickle Daemon from .
  4. Вчера нарвался на ситуацию, когда добавлял в уже существующую группу запись с Wildcard и кнопка сохранения изменений так и не стала активной. Пришлось перезагрузить страницу, и со второй попытки всё сработало. Понятно, что из этой истории выводов не сделать, но тем не менее, как минимум один раз с таким столкнулся.
  5. Мы как на разных языках говорим. Вопроса "мало" или "много" вообще нет сейчас. Я хочу разобраться, уменьшится ли число DNS-запросов для одного и того же пакета трафика с приведённой выше конфигурацией (принимая, что xkeen -dns активен).
  6. Так я не хочу через dns keenetic. Я хочу, чтобы xray выполнил резолв перехваченного запроса, ответил на него, кешировал ответ и при получении пакета уже на пересылку, использовал бы кешированные данные, когда выполнял повторный запрос по тому же доменному имени
  7. Ну тогда вернёмся в самое начало моего вопроса. Вот я настроил перехват DNS, используя фичу 1.1.3.9, потом сделал настройки: 05_routing, самое верхнее правило: "rules": [ { "port": 53, "outboundTag": "dns-out" }, 04_outbounds: { "protocol": "dns", "tag": "dns-out" } Судя по логам, запросы корректно стали заворачиваться в сервера, указанные в 02_dns. Вопрос тот же - я уменьшил число запросов за счёт кеширования встроенным DNS-сервером xray?
  8. Я пытаюсь открыть страницу в сети. Например aaa.com. DNS-запрос уходит в кинетик, тот его резолвит и далее браузер идёт на полученный IP-адрес. Этот пакет перехватывается xray, там включён sniffing. xray в свою очередь ТОЖЕ делает резолв, чтобы получить IP-адрес для маршрутизации по IP. Или я не прав, и xray не делает резолв, потому что видит домен в SNI и destination IP в пакете?
  9. Я прочитал. Но именно из этого описания не понял с ходу о чём речь. Сейчас уже более-менее разобрался, спасибо. Буду очень признателен, если поможете понять следующее. Вот моя конфигурация 02_dns.json: { "dns": { "servers": [ { "address": "https+local://1.1.1.1/dns-query", "skipFallback": false }, { "address": "https+local://8.8.8.8/dns-query", "skipFallback": false } ], "useSystemHosts": true, "queryStrategy": "UseIPv4", "tag": "dns_in" } } Я правильно понимаю, что, если перехват DNS-запросов выключен, то фактически обращение к любому ресурсу по fqdn выльется в два запроса: один запрос отправит маршрутизатор, чтобы вернуть IP клиенту, а второй запрос потом отправит xray, чтобы применить правила маршрутизации по доменному имени? При этом, если перехват включён, то теоретически запрос внешнему DNS-серверу будет один: когда запрос от клиента кинетику будет перехвачен и отправлен в xray, потому что ответ кешируется и сам xray уже будет использовать кешированный IP-адрес?
  10. Помогло, спасибо На 5.0.* 1.1.3.9 обязательно использовать? Или в общем можно и на 1.1.3.8 работать? upd. Пришлось откатиться на стабильную версию, потому что, судя по логам, по какой-то причине запросы 53 порт роутера перехватывались и отправлялись в туннель. Причём, не у всех клиентов. Глубоко я копать не стал, потому что вой из-за неработающего интернета стоял до небес. На 1.1.3.8 ситуация выправилась и жалобы "тут работает, вот тут как-то не работает" ушли.
  11. Привет Честно искал в теме ответ на свой вопрос, но не преуспел. У одного меня restart отрабатывает порядка минуты? Версия - 1.1.3.9, обновлял сегодня. Включал логи, выглядит так, как будто и стоп, и старт прям подолгу длятся.
  12. t800

    AWG 1.5 и 2.0

    Просто для информации: сегодня в AppStore релизнули версию официального клиента для IOS с поддержкой 2.0. Что в моём понимании говорит о том, что финальная стадия пройдена Всем тем, кто тут так нетерпеливо ждёт новой версии протокола, дам подсказку. Внутри РФ даже базовый wireguard не блокируется. И виртуальную машину с любым линуксом на борту внутри РФ поднять можно не только недорого, но и быстро. Sapienti sat.
  13. Кейс в поддержку открыли? Селф-тест в момент, когда проблема наблюдалась, сняли и приложили?
  14. А профиль DNS влияет? Должен использоваться только системный профиль или это не принципиально и можно указать один из предустановленных профилей «интернет-фильтров»?
  15. 5.0 beta 0 Клиенты, подключённые по WiFi к экстендеру Keenetic Giga III, отображаются в списке клиентов контроллера как "подключённые по проводу" Это штатное поведение, или дефект? Сам экстендер, понятно, отображает всех клиентов корректно - с указанием диапазона подключения и т.п.
  16. Поддержу вопрос. Понятно, что бета, но прям совсем приходится интуитивно пробираться. Системный профиль DNS используется для маршрутизации по доменным именам? Upd. Да, в итоге это системный профиль, всё получилось настроить. @Le ecureuil Насколько трудоёмко реализовать именованные списки подсетей для блока IPx-Маршруты аналогично тому, как это сделано для DNS-маршрутизации? В существующих реалиях есть потребность суммарно загружать порядка 600+ записей с подсетями. Это можно сделать и сейчас, но тогда список пользовательских маршрутов превращается в бардак, в котором бегло невозможно разобраться, когда дело доходит до отладки проблем. Я проверил DNS-маршрутизацию, списки распознают только отдельные IP-адреса. Подсеть в формате X.Y.Z.W/S распознается как доменное имя и, вероятно, не работает (не могу проверить в настоящий момент). Быть может, имеет смысл разрешить вставлять подсети помимо адресов, ведь ipset'ы их поддерживают?
  17. Например потому, что мне на уровне entware желательно иметь один сетевой интерфейс, соответствующий wireguard-туннелю. А не несколько потенциальных, чтобы не городить потом соответствующую логику
  18. Прочитал, спасибо Стало понятно почему оно так работает, а вот легче не стало. Хороший вариант решения с прозрачным выбором пира был бы.
  19. Спасибо за ответ. Такая логика предусмотрена спецификацией протокола?
  20. У меня есть настроенный рабочий туннель Wireguard, через который клиенты кинетика исправно ходят в интернет. В силу нестабильности VPS, было решено поднять еще одну, в другом регионе, но возник вопрос как организовать резервирование. Первый вариант - на уровне политик: создать новую, два туннеля, и так далее. Второй, который мне показался проще, это добавить пир в существующее подключение. Создал, прописал Allowed Ips так же, как на первом пире - 0.0.0.0/0, и весь трафик пошёл через новый пир. ОК, я его отключил на VPS, чтобы посмотреть отработает ли фоллбэк в том или ином виде. Не отработал. Трафик в первый пир не пошёл. Появились вопросы: 1. Почему после создания нового пира трафик пошёл именно и только через него? 2. Почему после его отключения, трафик не пошёл через старый пир? Спасибо Upd.: перевключение туннеля не помогает. Похоже, что новый пир имеет абсолютный приоритет, и, даже если старый пир живой, то кинетик его игнорирует, не взирая на то, что отключение нового пира зафиксировано (индикация серая). В конфигурации как на скрине счётчик растёт только на пире Holland (новом). Помогает только удаление пира из туннеля и рестарт туннеля Версия прошивки - 4.3.5 и 4.3.4
  21. Сегодня вот такая ситуация возникла. Стал лагать ютуб (при включённом на роутере VPN). Подключился посмотреть, оказалось, что впн в порядке (я его еще и перевключил): Но при этом в приоритетах подключений ВПН канал неактивен, и трафик заруливается в Ростелеком. Победить удалось традиционно - рестартом. Но диагностику снял. @Le ecureuil обратите внимание, пожалуйста.
  22. Внутри бриджа трафик всегда нетегированный? То есть, если мне нужно два (и так далее) VLAN пропустить через радиоканал, нужно создавать бриджи по числу вланов?
  23. В настоящее время для того, чтобы настроить работу с конкретным ресурсом в VPN или наоборот - сделать исключение, чтобы обращение шло через стандартный канал (не VPN), приходится создавать статические маршруты, указывая для хоста или подсети соответствующий целевой интерфейс. Но количество подсетей может быть довольно большим. Для яндекса, например, это десятки подсеток. Получается, что для одного ресурса приходится создавать много статических маршрутов и единственный способ как-то разобраться в большой таблице - это комментарии. Что крайне неудобно. Предлагаю доработать этот функционал таким образом, чтобы запись в таблице маршрутизации привязывалась не к подсети, а ссылалась на таблицу с подсетями/хостами. Таким образом, при редактировании подсетей пользователь не будет менять запись в таблице маршрутизации, он будет корректировать связанную с ней таблицу подсетей/хостов. Я вижу это как отдельную вкладку, на которой создаётся именованная таблица подсетей/хостов. После того как таблица создана, в неё вносятся подсети/хосты. Далее таблица будет видна в выпадающем списке при создании нового пользовательского маршрута (так же как интерфейсы выбираются).
      • 1
      • Лайк
  24. У меня пока тоже всё ок, но я далёк от оптимизма, потому что проблема явно плавающая и никакой логики её проявления мне пока уловить не удалось
  25. Я почему спросил: когда системный профиль применяется я вижу как сервера ростелекома, так и cloudflare почему-то. По крайней мере, так определяет ipleak.net
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.