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

helcoder

Участники форума
 Профиль  Обзор контента

  • Постов

    36

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

  • Посещение

 Тип контента 

Сообщения, опубликованные helcoder

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    Хотел поделиться тем как мне в итоге удалось настроить 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 через прокси, что довольно актуально с учётом того что они у нас заблокированы

     

     

    Инструкция:

    1. Настроить xkeen в Mixed моде
    2. Заменить всё что находится в /etc/xray/configs на config.json из аттача
    3. В config.json поменять shadowsocks outbound на нужный вам и добавить в fakedns нужные вам домены
    4. Заменить /etc/init.d/S24xray на тот что в аттаче
    5. В интерфейсе кинетика создать новый DNS профиль с типом Default на адрес 8.8.8.8, обязательно снять галку с транзитных запросов (они должны быть заблокированы) и назначить этот профиль клиентам для которых хотите использовать fakedns
    6. Выполнить xkeen -start

     

     

    Сам уже пару месяцев пользуюсь и пока каких-то проблем не заметил. В скрипте S24xray все изменения пометил комментариями начинающимися с #fakedns

    S24xray config.json

    • Спасибо 2

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    Прошу прощения что не совсем по теме, но я тут пока пытался настроить 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 запросы заблокированы? Хочу просто понять это какой-то лично мой косяк или это нормальное поведение кинетика.

     

    Если что вот связанная тема, но там вряд ли кто-то ответит, а тут хоть тема живая. Сам попробовал бы если бы второй кинетик был, но такого к сожалению не имеется.

    "Failed to connect to 1.1.1.1 port 443: No route to host" when DNS transit requests blocked

    в Обмен опытом

    Опубликовано

    Всем доброго дня!

    В 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.

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    17 hours ago, Lgedmitry said:

    прочитано, настроено и пару месяцев все работало.

    Где что случилось, что половина сайтов отъехала не понятно

    https://habr.com/ru/news/856344/ - случилось вот что, теперь в SNI у многих сайтов значится cloudflare-ech.com. Тут либо прописывать домен cloudflare-ech в рулы для проксирования, либо в браузере понижать tls до 1.2

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    14 minutes ago, Neytrino said:

    helcoder, попробуйте остановить Xkeen и запустить снова... У меня такое наблюдается после перезагрузки роутера (и не только у меня)

    Пробовал, чуть выше мой пост с экспериментами над DNS и политикой xkeen. Рестарт вроде как помогает, но стоит после этого устройству поменять политику и начинаются проблемы. Возможно если каждый раз рестарт делать после смены политики устройства то всё будет работать нормально, но не уверен, надо пробовать.

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    9 hours ago, Skrill0 said:

    Доброго Вам дня)
    При создании файла dns.json в конфигурациях и настройке dns секции в нем, XKeen сам добавляет маршрутизацию 53-го порта)

    Доброго дня! Подскажите, можно ли как-то настроить так чтобы xkeen процессил DNS запросы исключительно для устройств с политикой XKeen? А то сейчас он процессит для всех устройств если добавить dns.json и плюсом конфликтует со штатным резолвером.

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    13 hours ago, seeii said:

    Screenshotfrom2024-11-0623-32-26.thumb.png.d7c9f6d112e92a8f33b6c41b3b2cf835.png
    А порт 53, 5351, 1900 не пробовал через Xkeen пустить? xkeen -ap 53, 5351, 1900

    Пробовал только 53 порт, но ничего не изменилось. А для чего нужны остальные порты?

     

    13 hours ago, seeii said:

    там наверно руками придётся и в начало таблицы маршрутов I место A 

    iptables -t mangle -I xkeen -p udp --dport 53 -j TPROXY --on-port 61219 --tproxy-mark 0x111/0x111
iptables -t mangle -I xkeen_mark -p udp --dport 53 -j MARK --set-mark 111

-I на -D удалить маршруты

    На этом мои познания заканчиваются 🙂 Года 3 назад последний раз вникал в работу iptables, сейчас уже забыл как точно работают все эти команды. Тут как я понимаю перенаправление с 53 порта на порт прокси для политики xkeen? Если так, то мне кажется это ничего не даст, т.к. если создать конфиг DNS для xray и удалить все DNS записи из кинетика, то ему становится пофиг на политики и все DNS запросы идут через xray.

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    39 minutes ago, seeii said:

    вроде нужно отключить DNS у кинетика

    Screenshotfrom2024-11-0622-25-37.png.ceb57ce60f792bd09c6e1a6052dc7605.png
    по аналогии с kvas
    opkg dns-override
    system configuration save

    тут есть ссылки на Материал для изучения 

     

     

     

     

    Была у меня такая мысль тоже, но я так понимаю в этом случае все кто вне политики xkeen отвалятся, что мне не очень подходит.

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано · Изменено пользователем helcoder

    Подскажите пожалуйста как правильно сделать 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"
    }
    ...

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    10 hours ago, jameszero said:

     

    Роутинг по доменам в xkeen/xray корректно работает по tcp, а QUIC это udp протокол, с ним есть нюансы, его или по IP нужно маршрутизировать, или блокировать.

    Я ещё видел что у xray можно настроить fakedns, в xkeen соответственно это тоже возможно?

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    В общем виноват оказался всё же QUIC... видимо как-то я неправильно на роутере его отрубил, если выключить явно в браузере или добавить рул на xray то всё работает как надо. С QUIC я так понимаю фильтр по доменам нормально работать не может?

    • Лайк 1

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    34 minutes ago, jameszero said:

    @helcoder а использование именно whatismyipaddress.com принципиально? Честно говоря, вызывает сомнение его точность, IP он у меня определяет правильно, но вот со страной сильно ошибается, в отличие от других аналогичных сервисов.

    Для использования вообще не принципиально, я его просто для теста использовал и обратил внимание что есть такая проблема и думаю что потенциально может ещё где-то вылезти. Пока выглядит так что рулы неправильно матчатся по домену, т.к. если сматчить по 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.

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    8 hours ago, Neytrino said:

    helcoder, попробуйте убрать "domain:" из строчек с доменами...

    С этим я как только не игрался не помогает. Ещё заметил что после рестарта xkeen на ноуте первое открытие whatismyipaddress.com даёт IP VPS, но после рефреша опять показывает IP провайдера. Ещё проверил на андроид планшете та же беда. Какая-то чёрная магия.

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    Есть вот такой простой конфиг: 

    {
  "routing": {
    "rules": [
	
	{
        "inboundTag": ["redirect", "tproxy"],
        "outboundTag": "shadowsocks",
        "type": "field",
        "domain": [
		  "domain:whatismyipaddress.com",
		  "domain:myip.ru",
		  "domain:2ip.io"
        ]
      },
      {
        "inboundTag": ["redirect", "tproxy"],
        "outboundTag": "direct",
        "type": "field"
      }
    ]
  }
}

     

    Почему-то через ноут и ПК whatismyipaddress.com выдаёт IP провайдера, а не VPS.

    myip.ru и 2ip.io показывает IP VPS как и должно быть. При этом с мобильного все 3 показывают IP VPS. Почему такое может быть?

    Ещё пробовал подобные рулы напрямую забивать в nekoray на ПК и все 3 показывают IP VPS.

    OpenVPN в Connection Policies не работает

    в Обсуждение IPsec, OpenVPN и других туннелей

    Опубликовано

    В общем поигрался ещё немного и завелось, в итоге такая комбинация помогла:

    • обязательно в конфиге должно быть прописано redirect-gateway def1
    • чекнуть "Obtain routes from the remote side"

     

    В моём случае был анчекнут "Obtain routes from the remote side", не понятно в какой момент он у меня слетел, вроде ничего давно не менял.

    OpenVPN в Connection Policies не работает

    в Обсуждение IPsec, OpenVPN и других туннелей

    Опубликовано

    Всем доброго дня. Внезапно перестал работать OpenVPN на KN-1010. Есть вот такой коннекшен:

    image.thumb.png.8aaab339083cb57ccbb18cb4a2ffdcaa.png

    В логах никаких ошибок нет, соединение установлено успешно. Вот так настроена Policy:
    image.thumb.png.2259722cde63b00a028d1de4dcb13c38.png

    Если забиндить эту полиси на девайс, то с этого девайса всё тупо висит. Когда проблема появилась точно сказать сложно, возможно с каким-то обновлением прошивки связано, т.к. последний раз я эту полиси биндил может с год назад и проблем вообще никаких не было.

     

    Ещё пара интересных наблюдений:

    1. Если в роутингах вручную прописать маршрут до какого-нибудь whatismyipaddress через OVPN, то оно работает, выдаёт IP этого самого сервера.
    2. Пробовал точно также через полиси настроить seed4me по L2TP и оно без проблем работает.

     

    Подскажите пожалуйста куда можно дальше копать, у меня что-то закончились идеи.

    Не открываются определённые ресурсы

    в Обмен опытом

    Опубликовано

    Стоит такая. Сорри, но похоже я поторопился с созданием темы, решил попробовать обновить прошивку и оно вроде как завелось... надеюсь дело было именно в прошивке, т.к. просто ребут не помогал.

    Вопрос про бэкэп всё ещё актуальный, возможно как-то сделать полный бэкап не потеряв OpenVPN конфиги?

    Не открываются определённые ресурсы

    в Обмен опытом

    Опубликовано

    Всем привет! Имеется роутер KN-1010 (OS 4.0.4), суть проблемы: есть адрес acs.alfabank.ru, который никак не хочет открываться если ПК подключен к роутеру, но если подключить кабель напрямую к ПК минуя роутер, то всё прекрасно открывается. Адрес в обоих случаях резолвится верный (217.12.101.15), т.ч. дело вроде как не в DNS. Подскажите куда можно копать чтобы понять где проблема?

     

    Думал ещё Factory Reset сделать, но что-то боюсь потерять часть настроек связанных с OpenVPN (которые кстати может и привнесли эту проблему). startup-config достаточно будет сохранить в качестве полного бэкапа? Меня просто смущает что в нём отсутствует конфиг OpenVPN соединения.

    Иногда не отрабатывает DNS

    в Обмен опытом

    Опубликовано

    Вот только что проблему словил ещё раз, интересный результат получился в этот раз:

    nslookup www.google.com
    Server:  UnKnown
    Address:  192.168.1.1

    Name:    www.google.com
    Addresses:  2a00:1450:4010:c0f::69
              2a00:1450:4010:c0f::6a
              2a00:1450:4010:c0f::68
              2a00:1450:4010:c0f::63

     

    Вернулись только ipv6, как-то всё это очень странно.

    Иногда не отрабатывает DNS

    в Обмен опытом

    Опубликовано

    Я сейчас ради интереса удалил все DNS сервера что были на скриншоте, перестало резолвиться вообще что либо. Без разницы делать "nslookup www.google.com 192.168.1.1" или "nslookup www.google.com", в браузере соответственно тоже ничего не открывается. Это разве не доказывает что все DNS запросы идут исключительно через DNS сервера указанные на скриншоте? Я это к тому что не совсем понимаю почему мне нужно что-то назначать и соотносить когда у меня всего один Home сегмент, да есть OpenVPN клиент выключенный, но повторюсь, он у меня уже очень давно, а проблема появилась буквально месяц назад.

×
×
  • Создать...

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

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

  Я принимаю