helcoder
-
Постов
36 -
Зарегистрирован
-
Посещение
Достижения helcoder
Пользователь (2/5)
2
Репутация
-
Я всё это слил в один config.json, можете разбить на несколько если нужно.
-
Хотел поделиться тем как мне в итоге удалось настроить fakedns, может кому пригодится. Идея была сделать по схеме аналогичной той что используется в antizapret-vpn, а именно перенаправлять на xray только DNS запросы идущие на определённый адрес (-d 8.8.8.8 --dport 53) и весь траффик который идёт на пул адресов fakedns (-d 198.18.0.0/15). Может пригодиться тем кто как и я хочет чтобы проксировались выборочно только определённые ресурсы по доменам. Преимущества: Нет необходимости перенаправлять весь траффик на xray или как-то ограничивать его по портам Не ломается штатный DNS резолвер для локальных имён, т.к. перенаправление DNS запросов идёт с цепочки OUTPUT Сервисы кинетика можно оставить на 443 порту Не нужно блокировать QUIC для правильного определения домена ECH не мешает определять домен Недостатки: В xray поддерживаются только основные IP-запросы (записи A и AAAA) для DNS, поэтому остальные типы запросов либо блочить, либо отправлять напрямую через System DNS profile кинетика (я сделал именно так), либо можно пустить их через прокси если сильно хочется Не получится пустить все запросы где используется ECH через прокси, что довольно актуально с учётом того что они у нас заблокированы Инструкция: Настроить xkeen в Mixed моде Заменить всё что находится в /etc/xray/configs на config.json из аттача В config.json поменять shadowsocks outbound на нужный вам и добавить в fakedns нужные вам домены Заменить /etc/init.d/S24xray на тот что в аттаче В интерфейсе кинетика создать новый DNS профиль с типом Default на адрес 8.8.8.8, обязательно снять галку с транзитных запросов (они должны быть заблокированы) и назначить этот профиль клиентам для которых хотите использовать fakedns Выполнить xkeen -start Сам уже пару месяцев пользуюсь и пока каких-то проблем не заметил. В скрипте S24xray все изменения пометил комментариями начинающимися с #fakedns S24xray config.json
-
Прошу прощения что не совсем по теме, но я тут пока пытался настроить fakedns обратил внимание что у меня не открывается https://1.1.1.1/help/ ~$ curl https://1.1.1.1/help/ curl: (7) Failed to connect to 1.1.1.1 port 443: No route to host Грешил на то что я чего-то напортачил настраивая xkeen, но если вообще отключить opkg и перезагрузить роутер, то ничего не меняется. Помогает только разрешить транзитные DNS запросы, хотя я честно говоря не совсем понимаю причём здесь DNS когда обращение идёт напрямую по IP. DNS провайдера галка стоит в игнор. Кто-нибудь может у себя попробовать выполнить "curl https://1.1.1.1/help/" с выбранным DNS профилем где транзитные DNS запросы заблокированы? Хочу просто понять это какой-то лично мой косяк или это нормальное поведение кинетика. Если что вот связанная тема, но там вряд ли кто-то ответит, а тут хоть тема живая. Сам попробовал бы если бы второй кинетик был, но такого к сожалению не имеется.
-
Всем доброго дня! В DNS Resolution Profiles настроен профиль google с адресом 8.8.8.8, у него стоит "Transit requests blocked". Клиент у которого выбран этот профиль не может открыть https://1.1.1.1/help/ $ curl https://1.1.1.1/help -v * Trying 1.1.1.1:443... * TCP_NODELAY set * connect to 1.1.1.1 port 443 failed: No route to host * Failed to connect to 1.1.1.1 port 443: No route to host * Closing connection 0 curl: (7) Failed to connect to 1.1.1.1 port 443: No route to host Если сделать "Transit requests allowed", то всё сразу начинает работать: curl https://1.1.1.1/help -v * Trying 1.1.1.1:443... * TCP_NODELAY set * Connected to 1.1.1.1 (1.1.1.1) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=cloudflare-dns.com * start date: Jul 30 00:00:00 2024 GMT * expire date: Jan 21 23:59:59 2025 GMT * subjectAltName: host "1.1.1.1" matched cert's IP address! * issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1 * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x56243c0030e0) > GET /help HTTP/2 > Host: 1.1.1.1 > user-agent: curl/7.68.0 > accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * Connection state changed (MAX_CONCURRENT_STREAMS == 100)! < HTTP/2 301 < date: Fri, 22 Nov 2024 14:09:07 GMT < content-length: 0 < location: https://one.one.one.one/help < report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=Ush%2F6SN%2FttSZ6SJJivW1%2FylLGcA6q6gmbQ3GHoNoJRKLQM5TzjT3ikkMgi0la6hQ3TGOj%2BJxCE%2B4Vzr%2FIRt3R1Xhvkinwb%2FJYS0wq%2F4nqP9Tp0B2la7YWiE%3D"}],"group":"cf-nel","max_age":604800} < nel: {"report_to":"cf-nel","max_age":604800} < server: cloudflare < cf-ray: 8e697ed88ef0ec5b-DME < * Connection #0 to host 1.1.1.1 left intact Подскажите почему такое поведение? С другими ресурсами проблем не замечал, да и тут вроде как директивно по ip обращение идёт, не совсем понимаю причём тут DNS.
-
https://habr.com/ru/news/856344/ - случилось вот что, теперь в SNI у многих сайтов значится cloudflare-ech.com. Тут либо прописывать домен cloudflare-ech в рулы для проксирования, либо в браузере понижать tls до 1.2
-
Пробовал, чуть выше мой пост с экспериментами над DNS и политикой xkeen. Рестарт вроде как помогает, но стоит после этого устройству поменять политику и начинаются проблемы. Возможно если каждый раз рестарт делать после смены политики устройства то всё будет работать нормально, но не уверен, надо пробовать.
-
Доброго дня! Подскажите, можно ли как-то настроить так чтобы xkeen процессил DNS запросы исключительно для устройств с политикой XKeen? А то сейчас он процессит для всех устройств если добавить dns.json и плюсом конфликтует со штатным резолвером.
-
Пробовал только 53 порт, но ничего не изменилось. А для чего нужны остальные порты? На этом мои познания заканчиваются 🙂 Года 3 назад последний раз вникал в работу iptables, сейчас уже забыл как точно работают все эти команды. Тут как я понимаю перенаправление с 53 порта на порт прокси для политики xkeen? Если так, то мне кажется это ничего не даст, т.к. если создать конфиг DNS для xray и удалить все DNS записи из кинетика, то ему становится пофиг на политики и все DNS запросы идут через xray.
-
Была у меня такая мысль тоже, но я так понимаю в этом случае все кто вне политики xkeen отвалятся, что мне не очень подходит.
-
Подскажите пожалуйста как правильно сделать DNS over VLESS? Пытался сделать по этой инструкции, и оно вроде как что-то даже делает, но https://browserleaks.com/dns упорно показывает DNS указанные в настройках кинетика, ну и соответственно Cloudflare, Russia, Moscow. При этом если делать из консоли nslookup, то выглядит что всё работает как надо, т.к. если менять outboundTag для dns-in, то адреса другие резолвятся. Ещё есть небольшой сайдэффект, почему-то после всех этих манипуляций у Keenetic Buddy горит красный индикатор. UPD: ещё сейчас вот обнаружил что если удалить все DNS из кинетика, то browserleaks начинает показывать правильно, как это работает? 🙂 UPD2: в общем это крайне странно работает: убрал девайс из политики XKeen вернул DNS настройку в кинетик резолвится напрямую добавил девайс в политику XKeen резолвится через VPS убрал девайс из политики XKeen ничего не резолвится, таймауты добавил девайс в политику XKeen резолвится через VPS убрал девайс из политики XKeen ничего не резолвится, таймауты сделал restart -xkeen резолвится напрямую Что-то я определённо не доделал 🤨 // 07_dns.json { "dns": { "tag": "dns_in", "servers": [ "8.8.8.8" ] } } // 05_routing.json { "routing": { "rules": [ { "inboundTag": ["dns_in"], "outboundTag": "shadowsocks", "type": "field" }, { "port": 53, "outboundTag": "dns-out", "type": "field" }, ... // 04_outbounds.json ... { "tag": "direct", "protocol": "freedom", "settings": { "domainStrategy": "UseIPv4" } }, { "protocol": "dns", "tag": "dns-out" } ...
-
Это ещё более жёсткий вариант, но спасибо за совет 🙂
-
Подскажите, можно ли как-то пустить торрент траффик мимо xray вообще, при этом не ограничивая работу xkeen по портам? А то процессор нагружается до 100% и роутеру совсем плохо.
-
Я ещё видел что у xray можно настроить fakedns, в xkeen соответственно это тоже возможно?
-
В общем виноват оказался всё же QUIC... видимо как-то я неправильно на роутере его отрубил, если выключить явно в браузере или добавить рул на xray то всё работает как надо. С QUIC я так понимаю фильтр по доменам нормально работать не может?
-
Для использования вообще не принципиально, я его просто для теста использовал и обратил внимание что есть такая проблема и думаю что потенциально может ещё где-то вылезти. Пока выглядит так что рулы неправильно матчатся по домену, т.к. если сматчить по ip то работает всё как ожидается. Вот такой пример работает: { "routing": { "rules": [ { "inboundTag": ["redirect", "tproxy"], "outboundTag": "shadowsocks", "type": "field", "id": [ "104.19.223.79", "104.19.222.79" ] }, { "inboundTag": ["redirect", "tproxy"], "outboundTag": "direct", "type": "field" } ] } } Или если поменять местами direct и shadowsocks, то проблема та же только в обратную сторону, постоянно бьётся IP VPS, хотя должен IP провайдера: { "routing": { "rules": [ { "inboundTag": ["redirect", "tproxy"], "outboundTag": "direct", "type": "field", "domain": [ "domain:whatismyipaddress.com", "domain:2ip.ru" ] }, { "inboundTag": ["redirect", "tproxy"], "outboundTag": "shadowsocks", "type": "field" } ] } } Пробовал также "regexp:\\.com$" и просто "com" проблема остаётся. Он будто засниффать не может хоста из SNI.
