Снова про DNS утечки в sing-box

Censorship circumvention methods & software
, , ,
24

Согласен, что использовать разные софтины для сервера и клиента - странно, я всегда задавался этим вопросом, но натыкался на “просто берите xray для сервера - singbox для клиента, так хорошо“

Я думаю, что раньше причина была в том, что sing-box поддерживал режим tun и фильтр по процессам из коробки, что часто бывает нужно юзерам на венде (игры и т.д.), поэтому его советовали как клиент, в то время как хрей так не умел (с недавних пор умеет). В хрее в свою очередь есть мощный функционал фоллбеков, который может быть полезен на сервере, которого нет в синге.

25

Ну вот! :nerd_face:

Еще кстати в xray есть load balancing из коробки, а в sing-box - нет…

По теме: мне кажется ответ на мою проблему это routeOnly, судя по этому посту. Проверю.

26

В общем добавил routeOnly: true на xray сервере и левые dns запросы на системном резолвере пропали + как следствие пропал dns leak

27

А в логах на Xray сервере домены вообще присутствуют?

28

До добавления routeOnly были такие

Там и недолжно быть никаких логов о резолве домена, потому что резолвит не xray а sing-box через xray тунель

29

Собственно вполне ожидаемо. Я зачем спросил?
Потому что как следствие пропадает возможность роутинга по доменам на сервере.
Если установлены routeOnly true и domainStrategy AsIs - это значит для роутинга доступны и домены и IP адреса, но только для роутинга. Целевой адрес для freedom будет IP.
Но на клиенте, при подобной настройке на сервер всегда отправляется IP, а не домен. Поэтому Xray получает уже готовый IP, который как следствие не нужно резолвить.

В этом случае Xray сопоставляет только IP. И то что там матчится по IP работать будет. А вот geosite работать не будет. Формально он работает, но ситуация когда туда прилетит домен в данном случае исключена, а значит как следствие правила в geosite не сработают никогда. Поэтому в конкретном случае это просто лишняя писанина в конфиге сервера, которая никак не работает. Можно её смело удалить и ничего не изменится. Это не хорошо и не плохо. Просто факт.

30

Все так. Но для спокойствия души я домены не буду удалять :distorted_face: А то потом что-нибудь поменяю и отвалится все…

Падажи, тут в доке написано:

Use the sniffed domain only for routing; the proxy destination address remains the IP. The default value is false.

Я конечно не из Англии, но по моему тут написано, что домены снифаются и используются для роутинга. Роутинга по geosite, не? Иначе нафига снифать домен, чтобы потом роутить по IP…

31

Верно, домены снифаются и используются для роутинга, я так и написал:

НО при такой настройке xray (и именно при такой настройке синг-бокса), повторяю вопрос ещё раз:

Полагаю, чтобы снифать домен для этого туда должен сперва попасть домен. Домены точно попадают в модуль маршрутизации, чтобы было что снифать?

32

А почему домен должен был не попасть? Это обычный https запрос идущий через тунель xray, со всеми вытекающими, а именно SNI.

Чтобы не быть голословным вот логи с routeOnly:true 
app/dispatcher: sniffed domain: medium.com
app/dispatcher: default route for tcp:medium.com:80
transport/internet/tcp: dialing TCP to tcp:162.159.152.4:80
transport/internet: dialing to tcp:162.159.152.4:80
33

Тоже замечал. Поэтому я через dnscrypt пропускаю все запросы которые протекают. Порт 53 закрыл через брандмауэр. На крайняк можно просто в настройках адаптера прописать днс, у кого серверов в России нет. Гугл например.

34

Норм, но вроде пока через конфиг sing-box разрулилось.

35

Подскажите, есть-ли в sing-box 1.13.11-extended-2.0.0-arm64-v8a возможность отправлять dns-https запросы в туннель wireguard? У меня почему-то напрямую уходят, хотя адрес dns сервера попадает в cidr для tun и wg. Пробовал комментить hijack-dns, не помогает. Пробовал добавлять resolve для inbound tun, тоже безрезультатно.

Конфиг 
{
  "dns": {
    "servers": [
      {
        "type": "https",
        "tag": "t-rdns",
        "server": "--.--.--.--",
        "tls": {
          "enabled": true,
          "server_name": "name"
        }
      }
    ],
    "strategy": "ipv4_only",
    "cache_capacity": 4096,
    "reverse_mapping": true
  },
  "endpoints": [
    {
      "type": "wireguard",
      "tag": "t-wgep",
      "domain_resolver": "t-rdns",
      ...
      }
    }
  ],
  "inbounds": [
    {
      "type": "tun",
      ...
    }
  ],
  "route": {
    "rules": [
      {
        "action": "sniff"
      },
      {
        "protocol": "dns",
        "action": "hijack-dns"
      }
    ],
    "final": "t-wgep",
    "auto_detect_interface": true,
    "override_android_vpn": true
  }
}
36

detour t-wgep?

37

Пробовал для dns, тоже не прокатило. Проблема в том, что ркн-бесы начали блочить публичные dns по ip, и теперь нужно туннелировать.

38

А если попробовать тоже самое, но через vless а не wg и в ориг релизе и бете sing-box? И что в дебаг логе после днс запроса?

39

detour t-wgep помогло, но с другим dns, премного благодарен. :+1:

40

Правильно-ли понимаю, если на клиенте с outbound vless сделать так

Спойлер 
{
  "dns": {
    "servers": [
      {
        "type": "local",
        "tag": "t-rdns",
        "detour": "t-vlout"
      }
    ]
  }
}

то resolve будет на серверных sing-box dns через серверный hijack-dns?

41

Не пробовал, делал udp dns на 1.2.3.4 адрес

42

Проверил, работает на любом dns протоколе

43

Проясните плиз кто в исходниках разбирался. Вот примеры конфигов где нет action sniff в route пример 1
А тут нет и hijack-dns пример 2
Не понятно как тогда работает hijack-dns без shiff, если у автора в примере sniff идет перед hijack-dns Client - sing-box

На вопрос навел наблюдаемый глюк, при котором возникают проблемы с обработкой dns, если делать как у автора. А если убрать sniff или поставить после hijack-dns, то вроде работает. Но тогда непонятно для чего нужен sniff, если не для работы hijack-dns. В общем тьма какая-то беспросветная… :man_shrugging: