Create routing-with-dns.md
Nikita Korotaev
GitHub
parent
a94b73f07b
commit
6d7f80dde8
|
|
@ -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 как инструмент для борьбы с цензурой сосредоточен на противодействии блокировкам, чтобы помочь вам преодолеть файрвол, но его возможности в плане защиты конфиденциальности весьма ограничены.
|
||||
Loading…
Reference in New Issue