t800
-
Постов
191 -
Зарегистрирован
-
Посещение
Достижения t800
Продвинутый пользователь (3/6)
39
Репутация
-
Мы как на разных языках говорим. Вопроса "мало" или "много" вообще нет сейчас. Я хочу разобраться, уменьшится ли число DNS-запросов для одного и того же пакета трафика с приведённой выше конфигурацией (принимая, что xkeen -dns активен).
-
Так я не хочу через dns keenetic. Я хочу, чтобы xray выполнил резолв перехваченного запроса, ответил на него, кешировал ответ и при получении пакета уже на пересылку, использовал бы кешированные данные, когда выполнял повторный запрос по тому же доменному имени
-
Ну тогда вернёмся в самое начало моего вопроса. Вот я настроил перехват DNS, используя фичу 1.1.3.9, потом сделал настройки: 05_routing, самое верхнее правило: "rules": [ { "port": 53, "outboundTag": "dns-out" }, 04_outbounds: { "protocol": "dns", "tag": "dns-out" } Судя по логам, запросы корректно стали заворачиваться в сервера, указанные в 02_dns. Вопрос тот же - я уменьшил число запросов за счёт кеширования встроенным DNS-сервером xray?
-
Я пытаюсь открыть страницу в сети. Например aaa.com. DNS-запрос уходит в кинетик, тот его резолвит и далее браузер идёт на полученный IP-адрес. Этот пакет перехватывается xray, там включён sniffing. xray в свою очередь ТОЖЕ делает резолв, чтобы получить IP-адрес для маршрутизации по IP. Или я не прав, и xray не делает резолв, потому что видит домен в SNI и destination IP в пакете?
-
Я прочитал. Но именно из этого описания не понял с ходу о чём речь. Сейчас уже более-менее разобрался, спасибо. Буду очень признателен, если поможете понять следующее. Вот моя конфигурация 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-адрес?
-
Помогло, спасибо На 5.0.* 1.1.3.9 обязательно использовать? Или в общем можно и на 1.1.3.8 работать? upd. Пришлось откатиться на стабильную версию, потому что, судя по логам, по какой-то причине запросы 53 порт роутера перехватывались и отправлялись в туннель. Причём, не у всех клиентов. Глубоко я копать не стал, потому что вой из-за неработающего интернета стоял до небес. На 1.1.3.8 ситуация выправилась и жалобы "тут работает, вот тут как-то не работает" ушли.
-
Привет Честно искал в теме ответ на свой вопрос, но не преуспел. У одного меня restart отрабатывает порядка минуты? Версия - 1.1.3.9, обновлял сегодня. Включал логи, выглядит так, как будто и стоп, и старт прям подолгу длятся.
-
Просто для информации: сегодня в AppStore релизнули версию официального клиента для IOS с поддержкой 2.0. Что в моём понимании говорит о том, что финальная стадия пройдена Всем тем, кто тут так нетерпеливо ждёт новой версии протокола, дам подсказку. Внутри РФ даже базовый wireguard не блокируется. И виртуальную машину с любым линуксом на борту внутри РФ поднять можно не только недорого, но и быстро. Sapienti sat.
-
Кейс в поддержку открыли? Селф-тест в момент, когда проблема наблюдалась, сняли и приложили?
-
А профиль DNS влияет? Должен использоваться только системный профиль или это не принципиально и можно указать один из предустановленных профилей «интернет-фильтров»?
-
5.0 beta 0 Клиенты, подключённые по WiFi к экстендеру Keenetic Giga III, отображаются в списке клиентов контроллера как "подключённые по проводу" Это штатное поведение, или дефект? Сам экстендер, понятно, отображает всех клиентов корректно - с указанием диапазона подключения и т.п.
-
Поддержу вопрос. Понятно, что бета, но прям совсем приходится интуитивно пробираться. Системный профиль DNS используется для маршрутизации по доменным именам? Upd. Да, в итоге это системный профиль, всё получилось настроить. @Le ecureuil Насколько трудоёмко реализовать именованные списки подсетей для блока IPx-Маршруты аналогично тому, как это сделано для DNS-маршрутизации? В существующих реалиях есть потребность суммарно загружать порядка 600+ записей с подсетями. Это можно сделать и сейчас, но тогда список пользовательских маршрутов превращается в бардак, в котором бегло невозможно разобраться, когда дело доходит до отладки проблем. Я проверил DNS-маршрутизацию, списки распознают только отдельные IP-адреса. Подсеть в формате X.Y.Z.W/S распознается как доменное имя и, вероятно, не работает (не могу проверить в настоящий момент). Быть может, имеет смысл разрешить вставлять подсети помимо адресов, ведь ipset'ы их поддерживают?
-
Например потому, что мне на уровне entware желательно иметь один сетевой интерфейс, соответствующий wireguard-туннелю. А не несколько потенциальных, чтобы не городить потом соответствующую логику
-
Прочитал, спасибо Стало понятно почему оно так работает, а вот легче не стало. Хороший вариант решения с прозрачным выбором пира был бы.
-
Спасибо за ответ. Такая логика предусмотрена спецификацией протокола?
