Реализация маршрутизации трафика с помощью модуля DNS

Обычные методы маршрутизации и их недостатки

Когда Вы пытаетесь вручную настроить правила прокси, у Вас неизбежно возникает вопрос: какой трафик пускать через прокси, а какой - напрямую?

Обычно ответ - черные/белые списки.

За более чем десять лет сообщество создало огромный список правил, и появилось множество выдающихся проектов:

  • https://github.com/gfwlist/gfwlist
  • https://github.com/v2fly/domain-list-community
  • https://github.com/Loyalsoldier/v2ray-rules-dat

Но они не могут охватить все веб-сайты и не являются на 100% надежными.

Вот несколько случайных примеров:

  • geosite:cn — это большая мешанина, куда попадает все, что хоть как-то связано с Китаем. Даже заблокированные домены не всегда своевременно удаляются. Если вы решите направлять трафик напрямую только потому, что домен находится в этом списке, это не сработает. Например, ai.ytimg.com и login.corp.google.com заблокированы, но до сих пор не удалены из списка.
  • В READMEОткрыть в новой вкладке v2ray-rules-dat написано, что домены Apple, Microsoft, Google CN одновременно находятся в geosite:cn и geosite:geolocation-!cn, но на самом деле это не так. (См.: PR#328Открыть в новой вкладке)
  • А что, если домена нет в списке?

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

Что делать, если неизвестный домен имеет сервер в Китае, и вы хотите подключиться к нему напрямую, но после всех настроек сталкиваетесь с утечкой DNS?

Так существует ли способ добиться 100% безопасной и точной маршрутизации?

Ответ: Конечно.

Использование DNS-модуля Xray-core для точной маршрутизации

Разумно используя встроенные функции DNS в Xray, такие как fallback, EDNS, фильтрация IP, добавление тегов и т.д., и тщательно настраивая их порядок, вы получите наиболее точные IP-адреса в качестве условия для маршрутизации.

Прежде чем продолжить чтение этой статьи, вам необходимо полностью прочитать и понять «Обзор функции маршрутизации (routing) Часть 1 и Часть 2». В то же время, вы уже, вероятно, до дыр зачитали официальное руководство по настройке, поэтому вы полностью понимаете роль domainStrategy в маршрутизации и исходящих соединениях, опции sniffing во входящих соединениях, а также поведение, возникающее при различных комбинациях их значений.

Все готово? Попробуйте понять следующий отрывок:

При входящих соединениях sock и http запрашивается доменное имя. После этого на этапе маршрутизации domainStrategy, отличная от AsIs, может использовать встроенный DNS для разрешения IP-адреса, который временно используется для сопоставления с правилами маршрутизации. При локальном исходящем соединении direct, domainStrategy, отличная от AsIs, в настройках исходящего соединения может снова использовать встроенный DNS для разрешения IP-адреса для исходящего подключения. Запрос, отправляемый на сервер Xray, содержит только доменное имя, а конкретный IP-адрес для доступа зависит от настроек исходящего соединения direct на сервере.

В случае прозрачного прокси ситуация усложняется: sniffing для входящих соединений включен, а destOverride содержит [http, tls]:

  • Если routeOnly = false, то IP-адрес запроса будет удален, и дальнейший процесс будет таким же, как и для входящего соединения sock.
  • Если routeOnly = true, то будут доступны и домен, и IP-адрес. На этапе маршрутизации можно напрямую сопоставлять правила для доменов и IP, и локальное исходящее соединение direct также будет использовать этот IP. Запрос, отправляемый на сервер Xray, содержит только IP-адрес. Как сервер его обработает? Пройдет тот же процесс заново.

Возникли трудности? Вам нужно продолжать перечитывать официальное руководство и пытаться понять его. В противном случае вам будет сложно использовать результаты разрешения DNS-модуля из примеров ниже для правильной маршрутизации.

Пример 1: Эта конфигурация разрешает точные, дружественные к CDN IP-адреса, гарантирует отсутствие утечек DNS и, при наличии узлов в Китае, отдает им приоритет при разрешении. Она идеально подходит для сценариев с прозрачным прокси и realIp.

{
  "dns": {
    "servers": [
      {
        // Мы не полностью доверяем geosite:cn, но если домен уже есть в этом списке
        // сначала попробуем его разрешить. Если возвращается китайский IP, это значит, что он не заблокирован. В противном случае, он с высокой вероятностью заблокирован, и мы переключаемся на 8.8.8.8 для повторного разрешения, чтобы устранить возможное DNS-загрязнение (это может привести к пустой трате прокси-трафика).
        // Причина приоритетного разрешения в том, что это на 100% дружественно к CDN, вы не можете гарантировать, что все авторитетные серверы поддерживают EDNS, и это быстро.
        "tag": "dns-direct",
        "address": "223.5.5.5",
        "port": 53,
        "skipFallback": true,
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        // Аналогично предыдущему
        // Мы не полностью доверяем geosite:geolocation-!cn, но если домен уже есть в этом списке
        // сначала попробуем разрешить его через прокси. Если возвращается китайский IP, это значит, что у него есть серверы в стране, и мы переключаемся на 8.8.8.8 с clientIp для повторного разрешения, чтобы максимально оптимизировать прямое соединение, поскольку не все авторитетные серверы поддерживают EDNS.
        "address": "8.8.8.8",
        "port": 53,
        "skipFallback": true,
        "domains": ["geosite:geolocation-!cn"],
        "expectIPs": ["geoip:!cn"]
      },
      {
        // Если домен не находится ни в geosite:geolocation-!cn, ни в geosite:cn, или если разрешение по предыдущим правилам не удалось, будет использоваться этот сервер.
        // Причина, по которой неизвестные домены по умолчанию разрешаются через прокси — предотвращение утечки информации о ваших намерениях внутри страны. Это и есть та самая спорная часть, известная как утечка DNS.
        // Здесь используется EDNS для попытки получения записей A/AAAA для Китая.
        // Если их нет, последовательно запрашиваются следующие DNS-серверы по умолчанию для получения записей, оптимизированных для CDN прокси-узла.
        "address": "8.8.8.8",
        "port": 53,
        "clientIp": "222.85.85.85", // Укажите IP-адрес вашего местного интернет-провайдера для получения оптимизированных для прямого подключения записей A/AAAA. Например, если вы используете Henan Telecom, вы можете использовать DNS Henan Telecom. Это не гарантирует 100% дружественности к китайским CDN, так как не все авторитетные серверы поддерживают EDNS.
        "skipFallback": false,
        "expectIPs": ["geoip:cn"]
      },
      "8.8.8.8"
    ],
    "tag": "dns-proxy"
  },
  "routing": {
    "domainStrategy": "Зависит от ваших потребностей",
    "rules": [
      {
        // Маршрутизация для самих DNS-запросов
        "inboundTag": ["dns-direct"],
        "outboundTag": "direct"
      },
      {
        // Маршрутизация для самих DNS-запросов
        "inboundTag": ["dns-proxy"],
        "outboundTag": "proxy"
      }
      // Ваши персональные правила маршрутизации, используйте domain и/или ip для разделения трафика в соответствии с вашими потребностями...
    ]
  }
  // Остальное игнорируется, настраивайте по необходимости...
}

Вы можете разделять трафик на основе разрешенных IP-адресов в сочетании с доменами или полностью полагаясь на IP.

В среде с прозрачным прокси и realIp, после перехвата DNS, вы даже можете установить domainStrategy=AsIs и routeOnly=true, чтобы избежать повторных DNS-разрешений на всем пути.

---

Пример 2: Эта конфигурация разрешает правильные, но не обязательно дружественные к зарубежным CDN адреса, гарантирует отсутствие утечек DNS и при наличии серверных узлов в Китае отдает им приоритет при разрешении. Подходит для сценариев с прозрачным прокси fakeIp, входящими соединениями sock, http и т.д.

{
  "dns": {
    "servers": [
      {
        // Мы не полностью доверяем geosite:cn, но если домен уже есть в этом списке
        // сначала попробуем его разрешить. Если возвращается китайский IP, это значит, что он не заблокирован. В противном случае, он с высокой вероятностью заблокирован, и мы переключаемся на 8.8.8.8 для повторного разрешения, чтобы устранить возможное DNS-загрязнение (это может привести к пустой трате прокси-трафика).
        // Причина приоритетного разрешения в том, что это требует минимальных затрат, прямое подключение занимает всего несколько десятков миллисекунд.
        "tag": "dns-direct",
        "address": "223.5.5.5",
        "port": 53,
        "skipFallback": true,
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        // Если домен не находится в geosite:cn, или если разрешение по предыдущему правилу не удалось, будет использоваться этот сервер.
        // Здесь используется EDNS для попытки получения записей A/AAAA для Китая.
        "address": "8.8.8.8",
        "port": 53,
        "clientIp": "222.85.85.85", // Укажите IP-адрес вашего местного интернет-провайдера для получения оптимизированных для прямого подключения записей A/AAAA. Например, если вы используете Henan Telecom, вы можете использовать DNS Henan Telecom. Это не гарантирует 100% дружественности к китайским CDN, так как не все авторитетные серверы поддерживают EDNS.
        "skipFallback": false
      }
    ],
    "tag": "dns-proxy"
  },
  "routing": {
    "domainStrategy": "Должно быть не AsIs, конкретное значение зависит от ваших потребностей",
    "rules": [
      {
        // Маршрутизация для самих DNS-запросов
        "inboundTag": ["dns-direct"],
        "outboundTag": "direct"
      },
      {
        // Маршрутизация для самих DNS-запросов
        "inboundTag": ["dns-proxy"],
        "outboundTag": "proxy"
      }
      // Ваши персональные правила маршрутизации, используйте domain и/или ip для разделения трафика в соответствии с вашими потребностями...
    ]
  }
  // Остальное игнорируется, настраивайте по необходимости...
}

В этом сценарии, поскольку все запросы, отправляемые на сервер Xray, являются доменными именами, нет необходимости многократно использовать DNS для поиска оптимального результата. Достаточно быстро определить, не загрязнен ли домен, и по возможности разрешить дружественный к китайским CDN IP-адрес.

В этом примере китайские IP-адреса, разрешенные DNS-модулем, уже на 99% дружественны к китайским CDN, поэтому в исходящем соединении direct вы можете установить domainStrategy в значение, отличное от AsIs, чтобы использовать кэш. Если вы стремитесь к 100% дружественности к китайским CDN, вы можете установить его в AsIs, чтобы использовать DNS, настроенный в операционной системе, для повторного разрешения, что займет дополнительно от 1 до нескольких сотен миллисекунд.

Послесловие

Известно, что многие недобросовестные китайские приложения определяют ваш внешний IP-адрес и связывают его с вашей конфиденциальной информацией, такой как GPS-координаты, номер телефона, адрес доставки еды, а затем сливают эти данные в базы социальной инженерии. Большой брат следит за тобой!!!

Некоторые ошибочно полагают, что это происходит из-за разделения трафика и что этого можно избежать, переключившись на режим черного списка (когда только сайты из черного списка идут через прокси). На самом деле это не так. Во-первых, черные списки очень легко «отравить»: злоумышленники могут намеренно создавать и добавлять в них сайты-приманки для определения вашего зарубежного IP-адреса.

Во-вторых, если любой из сайтов в черном списке размещен на Cloudflare, даже приманка не нужна. Попробуйте зайти на: https://chatgpt.com/cdn-cgi/trace

Сообразительные пользователи могут подумать: «А что, если я просто воспользуюсь еще одним публичным прокси?» Но для этого вы должны полностью доверять этому прокси — быть уверенным, что он не ведет логи и не продаст вас, и что им интенсивно пользуются многие люди из вашей страны. Когда один и тот же внешний IP-адрес в течение короткого времени связан с тысячами людей, становится невозможно отследить вас по этому IP. А с надоедливыми капчами на таких «грязных» IP можно и смириться.

Разве Warp от «кибер-добряков» из Cloudflare не идеально подходит под все эти критерии? К сожалению, для сайтов, размещенных на CF, Warp не может полностью скрыть ваш IP-адрес; он эффективен только для серверов, не принадлежащих CF.

А как насчет Tor? Он не очень подходит для повседневного использования. Его IP-адреса слишком «грязные», а частая смена выходных узлов может привести к блокировке ваших аккаунтов на многих сайтах.

Поэтому, если ваш клиент не поддерживает разделение трафика по приложениям (что возможно только на телефонах и компьютерах), любой другой способ обхода блокировок приведет к утечке вашего внешнего IP-адреса.

В общем, я хочу сказать, что при обычных способах обхода блокировок утечка внешнего IP-адреса практически неизбежна. Если вам нужна повышенная защита конфиденциальности, используйте такие инструменты, как Tor. Xray-core как инструмент для борьбы с цензурой сосредоточен на противодействии блокировкам, чтобы помочь вам преодолеть файрвол, но его возможности в плане защиты конфиденциальности весьма ограничены.