From 6d7f80dde857d3139e843a46db01523036156efc Mon Sep 17 00:00:00 2001 From: Nikita Korotaev <104270279+iambabyninja@users.noreply.github.com> Date: Sun, 20 Jul 2025 19:56:36 +0300 Subject: [PATCH] Create routing-with-dns.md --- docs/ru/document/level-1/routing-with-dns.md | 189 +++++++++++++++++++ 1 file changed, 189 insertions(+) create mode 100644 docs/ru/document/level-1/routing-with-dns.md diff --git a/docs/ru/document/level-1/routing-with-dns.md b/docs/ru/document/level-1/routing-with-dns.md new file mode 100644 index 0000000..74f78b7 --- /dev/null +++ b/docs/ru/document/level-1/routing-with-dns.md @@ -0,0 +1,189 @@ +# Реализация маршрутизации трафика с помощью модуля 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](https://github.com/Loyalsoldier/v2ray-rules-dat) `v2ray-rules-dat` написано, что домены Apple, Microsoft, Google CN одновременно находятся в `geosite:cn` и `geosite:geolocation-!cn`, но на самом деле это не так. (См.: [PR#328](https://github.com/Loyalsoldier/v2ray-rules-dat/pull/328)) +- А что, если домена нет в списке? + +Это, несомненно, создает проблемы с маршрутизацией. Если ваши правила не обновляются вовремя, вы можете столкнуться с тем, что трафик, который должен идти напрямую, направляется через прокси, а некоторые сайты могут даже не открываться. + +Что делать, если неизвестный домен имеет сервер в Китае, и вы хотите подключиться к нему напрямую, но после всех настроек сталкиваетесь с утечкой DNS? + +Так существует ли способ добиться 100% безопасной и точной маршрутизации? + +Ответ: Конечно. + +## Использование DNS-модуля Xray-core для точной маршрутизации + +Разумно используя встроенные функции DNS в Xray, такие как fallback, EDNS, фильтрация IP, добавление тегов и т.д., и тщательно настраивая их порядок, вы получите наиболее точные IP-адреса в качестве условия для маршрутизации. + +Прежде чем продолжить чтение этой статьи, вам необходимо полностью прочитать и понять «Обзор функции маршрутизации (routing) [Часть 1](./routing-lv1-part1.html) и [Часть 2](./routing-lv1-part2.html)». +В то же время, вы уже, вероятно, до дыр зачитали официальное руководство по настройке, поэтому вы полностью понимаете роль `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`. + +```json +{ + "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` и т.д. + +```json +{ + "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 как инструмент для борьбы с цензурой сосредоточен на противодействии блокировкам, чтобы помочь вам преодолеть файрвол, но его возможности в плане защиты конфиденциальности весьма ограничены.