Max/XTLS_Xray-docs-next
1
0
Fork 0
mirror of https://github.com/XTLS/Xray-docs-next.git synced 2026-09-28 01:47:59 +03:00
Code Issues Packages Projects Releases Wiki Activity

sync RU docs (#789)

Browse Source 
* ECH and Sniffing: Explaining when to block QType 65
* Router: Clarifying the logic between GeoIP matchers
* Explaining the impact of domainStrategy on happyEyeballs
* Add link to inbound and outbound protocols
* rewrite routing with dns tutorial + add images
* rewrite dns page
* Make proxySettings clearer
* Metrics: Add goroutine pprof file requirement for memory issues
* upd RU lang
This commit is contained in:
Nikita Korotaev
2025-12-27 15:09:02 +05:00
committed by GitHub
parent 2fe85b2064
commit e9fb4de05b
10 changed files with 374 additions and 275 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ru/document/level-1/routing-with-dns.md
+172 -72
View File
@@ -1,98 +1,151 @@
# Реализация маршрутизации трафика с помощью модуля DNS
# Реализация точного разделения трафика с помощью DNS
## Обычные методы маршрутизации и их недостатки
## Традиционные методы маршрутизации и их недостатки
Когда Вы пытаетесь вручную настроить правила прокси, у Вас неизбежно возникает вопрос: какой трафик пускать через прокси, а какой - напрямую?
Когда вы пытаетесь вручную создать правила проксирования, неизбежно возникает вопрос: какой трафик пускать через Proxy, а какой — через Direct?
Обычно ответ - черные/белые списки.
Обычный ответ — использование черных и белых списков (Blacklist/Whitelist).
За более чем десять лет сообщество создало огромный список правил, и появилось множество выдающихся проектов:
За более чем десять лет сообщество создало огромные списки правил, и появилось множество отличных проектов:
- https://github.com/gfwlist/gfwlist
- https://github.com/v2fly/domain-list-community
- https://github.com/Loyalsoldier/v2ray-rules-dat
Но они не могут охватить все веб-сайты и не являются на 100% надежными.
Однако они не могут охватить абсолютно все веб-сайты, обладают задержкой в обновлении и не являются на 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))
- А что, если домена нет в списке?
- `geosite:cn` — это "сборная солянка": туда добавляют всё, что хоть как-то связано с Китаем. Даже если домен был заблокирован (GFW), его могут не успеть вовремя удалить из списка.
Если вы полагаетесь только на наличие целевого домена в этом списке для направления в Direct, это не сработает. Например, `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))
- А что, если домена вообще нет в списке?
Это, несомненно, создает проблемы с маршрутизацией. Если ваши правила не обновляются вовремя, вы можете столкнуться с тем, что трафик, который должен идти напрямую, направляется через прокси, а некоторые сайты могут даже не открываться.
Это создает проблемы при маршрутизации. Если ваши правила обновляются несвоевременно, трафик, который должен идти через Direct, может пойти через Proxy, или некоторые сайты вообще перестанут открываться.
Что делать, если неизвестный домен имеет сервер в Китае, и вы хотите подключиться к нему напрямую, но после всех настроек сталкиваетесь с утечкой DNS?
Что делать, если неизвестный домен имеет сервер в Китае, и вы хотите максимально использовать Direct, но после настройки сталкиваетесь с пресловутым [DNS Leak](https://github.com/XTLS/BBS/issues/3#issuecomment-3505661189)?
Так существует ли способ добиться 100% безопасной и точной маршрутизации?
Существует ли способ добиться 99.99% безопасности и точности маршрутизации?
Ответ: Конечно.
Ответ: Безусловно.
## Использование DNS-модуля Xray-core для точной маршрутизации
## Использование DNS-модуля Xray-core для точного разделения трафика
Разумно используя встроенные функции DNS в Xray, такие как fallback, EDNS, фильтрация IP, добавление тегов и т.д., и тщательно настраивая их порядок, вы получите наиболее точные IP-адреса в качестве условия для маршрутизации.
Рационально используя мощные возможности встроенного DNS в Xray (Fallback, ECS, фильтрация по IP, тегирование), и тщательно настраивая порядок серверов, вы получите IP-адрес как условие маршрутизации, который будет гораздо точнее и актуальнее, чем `geosite cn/!cn`. Это связано с тем, что принадлежность IP к региону (GeoIP), особенно к Китаю, меняется довольно редко.
Прежде чем продолжить чтение этой статьи, вам необходимо полностью прочитать и понять «Обзор функции маршрутизации (routing) [Часть 1](./routing-lv1-part1.html) и [Часть 2](./routing-lv1-part2.html)».
В то же время, вы уже, вероятно, до дыр зачитали официальное руководство по настройке, поэтому вы полностью понимаете роль `domainStrategy` в маршрутизации и исходящих соединениях, опции `sniffing` во входящих соединениях, а также поведение, возникающее при различных комбинациях их значений.
Прежде чем продолжить чтение, вам необходимо внимательно изучить и понять: "Основы: Краткий анализ функции маршрутизации (routing) — [Часть 1](./routing-lv1-part1.html), [Часть 2](./routing-lv1-part2.html)".
Предполагается, что вы уже досконально изучили официальное руководство по конфигурации и полностью понимаете работу `domainStrategy` в Routing и Outbound, назначение опций `sniffing` в Inbound, а также поведение системы при различных комбинациях этих параметров.
Все готово? Попробуйте понять следующий отрывок:
Всё готово? Попробуйте осмыслить следующий абзац:
При входящих соединениях `sock` и `http` запрашивается доменное имя. После этого на этапе маршрутизации `domainStrategy`, отличная от `AsIs`, может использовать встроенный DNS для разрешения IP-адреса, который временно используется для сопоставления с правилами маршрутизации. При локальном исходящем соединении `direct`, `domainStrategy`, отличная от `AsIs`, в настройках исходящего соединения может снова использовать встроенный DNS для разрешения IP-адреса для исходящего подключения. Запрос, отправляемый на сервер Xray, содержит только доменное имя, а конкретный IP-адрес для доступа зависит от настроек исходящего соединения `direct` на сервере.
При входящих соединениях `socks` или `http` запрашивается домен. Когда запрос попадает в Routing, стратегия `domainStrategy` (если она отлична от `AsIs`) может использовать встроенный DNS для резолвинга IP, который временно используется для сопоставления правил маршрутизации. При отправке в локальный `direct` Outbound, если его `domainStrategy` не `AsIs`, встроенный DNS снова резолвит IP для исходящего соединения. Запрос, отправляемый на удаленный сервер Xray, содержит только домен; какой именно IP будет использован для доступа, зависит от `direct` Outbound на сервере.
В случае прозрачного прокси ситуация усложняется: `sniffing` для входящих соединений включен, а `destOverride` содержит `[http, tls]`:
В режиме прозрачного прокси (Transparent Proxy) ситуация сложнее. Если включен `sniffing` на Inbound и `destOverride` содержит `[http, tls]`:
- Если `routeOnly = false`, то IP-адрес запроса будет удален, и дальнейший процесс будет таким же, как и для входящего соединения `sock`.
- Если `routeOnly = true`, то будут доступны и домен, и IP-адрес. На этапе маршрутизации можно напрямую сопоставлять правила для доменов и IP, и локальное исходящее соединение `direct` также будет использовать этот IP. Запрос, отправляемый на сервер Xray, содержит только IP-адрес. Как сервер его обработает? Пройдет тот же процесс заново.
- Если `routeOnly = false`, запрошенный IP будет стерт, и дальнейший процесс аналогичен `socks` Inbound.
- Если `routeOnly = true`, то доступны и домен, и IP. В Routing можно напрямую сопоставлять правила по домену и IP, а локальный `direct` Outbound также будет использовать этот IP. Запрос к серверу Xray содержит только IP. Как сервер его обработает? Повторит описанный выше процесс.
Возникли трудности? Вам нужно продолжать перечитывать официальное руководство и пытаться понять его. В противном случае вам будет сложно использовать результаты разрешения DNS-модуля из примеров ниже для правильной маршрутизации.
Возникли трудности? Вам нужно вернуться к официальному руководству и попытаться вникнуть. В противном случае вам будет сложно использовать результаты резолвинга DNS-модуля из примеров ниже для правильной маршрутизации.
---
#### Пример 1: Эта конфигурация разрешает точные, дружественные к CDN IP-адреса, гарантирует отсутствие утечек DNS и, при наличии узлов в Китае, отдает им приоритет при разрешении. Она идеально подходит для сценариев с прозрачным прокси и `realIp`.
#### Пример 1: Конфигурация для получения точного, дружественного к CDN IP-адреса. Гарантирует отсутствие DNS Leak. Если в Китае есть сервер, он будет разрешен приоритетно. Идеально подходит для сценариев RealIP в прозрачном прокси.
```json
{
"dns": {
"servers": [
// Предотвращение зависания Google CAPTCHA и мониторинга Google China
// (так как многие сторонние сайты могут загружать шрифты Google и т.д.)
{
"address": "1.1.1.1",
"skipFallback": true,
"domains": ["geosite:google", "geosite:google-cn"]
},
{
"address": "8.8.8.8",
"skipFallback": true,
"domains": ["geosite:google", "geosite:google-cn"],
"finalQuery": true // Завершить цепочку запросов
},
// Резолвим через Direct домены, которые сообщество считает имеющими узлы в Китае.
// Если результат не соответствует ожидаемому, возможно, домен заблокирован или ушел из Китая.
// Резолвим через Proxy домены, считающиеся китайскими, для Fallback в случае блокировки/ухода.
{
// Мы не полностью доверяем geosite:cn, но если домен уже есть в этом списке
// сначала попробуем его разрешить. Если возвращается китайский IP, это значит, что он не заблокирован. В противном случае, он с высокой вероятностью заблокирован, и мы переключаемся на 8.8.8.8 для повторного разрешения, чтобы устранить возможное DNS-загрязнение (это может привести к пустой трате прокси-трафика).
// Причина приоритетного разрешения в том, что это на 100% дружественно к CDN, вы не можете гарантировать, что все авторитетные серверы поддерживают EDNS, и это быстро.
"tag": "dns-direct",
"address": "223.5.5.5",
"port": 53,
"address": "114.114.114.114",
"skipFallback": true,
"domains": ["geosite:cn"],
"expectIPs": ["geoip:cn"]
},
{
// Аналогично предыдущему
// Мы не полностью доверяем geosite:geolocation-!cn, но если домен уже есть в этом списке
// сначала попробуем разрешить его через прокси. Если возвращается китайский IP, это значит, что у него есть серверы в стране, и мы переключаемся на 8.8.8.8 с clientIp для повторного разрешения, чтобы максимально оптимизировать прямое соединение, поскольку не все авторитетные серверы поддерживают EDNS.
"tag": "dns-direct",
"address": "223.5.5.5",
"skipFallback": true,
"domains": ["geosite:cn"],
"expectIPs": ["geoip:cn"]
},
{
"address": "1.1.1.1",
"skipFallback": true,
"domains": ["geosite:cn"]
},
{
"address": "8.8.8.8",
"port": 53,
"skipFallback": true,
"domains": ["geosite:cn"],
"finalQuery": true // Завершить цепочку запросов
},
// Резолвим через Proxy домены, которые сообщество считает НЕ китайскими.
// Если результат не соответствует ожидаемому, пытаемся оптимизировать Direct.
{
"address": "1.1.1.1",
"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,
"skipFallback": true,
"domains": ["geosite:geolocation-!cn"],
"expectIPs": ["geoip:!cn"]
},
{
"address": "8.8.8.8",
"clientIp": "222.85.85.85", // Укажите IP вашего локального ISP для получения оптимизированных A/AAAA записей
// Например, если вы используете Henan Telecom, используйте соответствующий IP.
// Не гарантирует 100% дружелюбность к китайским CDN, так как не все Authoritative DNS поддерживают ECS.
"skipFallback": true,
"domains": ["geosite:geolocation-!cn"]
},
{
"address": "8.8.4.4",
"clientIp": "222.85.85.85", // См. выше
"skipFallback": true,
"domains": ["geosite:geolocation-!cn"],
"finalQuery": true // Завершить цепочку запросов
// Здесь у вас может возникнуть вопрос: эти 4 правила кажутся избыточными по сравнению с 4 выше? Можно ли сократить?
// На самом деле нет, это сделано для достижения максимальной скорости, а также потому что некоторые Authoritative DNS не поддерживают ECS.
},
// Неизвестные домены: приоритет Китая. Если результат не соответствует, пытаемся оптимизировать Proxy.
{
"address": "8.8.8.8",
"clientIp": "222.85.85.85", // См. выше
"expectIPs": ["geoip:cn"]
},
{
"address": "8.8.4.4",
"clientIp": "222.85.85.85", // См. выше
"expectIPs": ["geoip:cn"]
},
"1.1.1.1",
"8.8.8.8"
],
"tag": "dns-proxy"
"tag": "dns-proxy",
"enableParallelQuery": true // Интеллектуальная параллельность: все параллельно, умная группировка, гонка внутри группы
},
"routing": {
"domainStrategy": "Зависит от ваших потребностей",
"domainStrategy": "Зависит от ваших требований",
"rules": [
{
// Маршрутизация для самих DNS-запросов
@@ -104,49 +157,94 @@
"inboundTag": ["dns-proxy"],
"outboundTag": "proxy"
}
// Ваши персональные правила маршрутизации, используйте domain и/или ip для разделения трафика в соответствии с вашими потребностями...
// Ваши персональные правила маршрутизации
// Для разблокировки стриминга и т.д. используйте domain, для разделения трафика (CN/!CN) всегда используйте ip
]
}
// Остальное игнорируется, настраивайте по необходимости...
// Остальное пропущено, настройте по необходимости...
}
```
Вы можете разделять трафик на основе разрешенных IP-адресов в сочетании с доменами или полностью полагаясь на IP.
```mermaid
graph TD
A[Получен DNS-запрос] --> B{Классификация домена};
В среде с прозрачным прокси и `realIp`, после перехвата DNS, вы даже можете установить `domainStrategy=AsIs` и `routeOnly=true`, чтобы избежать повторных DNS-разрешений на всем пути.
B -->|geosite:google<br>Домены Google| C["Запрос через <b>Proxy</b><br>Зарубежный DNS (1.1.1.1...)"];
C --> C_OUT[Высокая вероятность зарубежного IP];
C_OUT --> Z[Конец запроса];
---
B -->|geosite:cn<br>Известные домены CN| D["Запрос через <b>Direct</b><br>Китайский DNS (114, AliDNS)"];
D --> E{Результат - китайский IP?};
E -->|"Да (Ожидаемо)"| F_OUT[Вернуть китайский IP];
F_OUT --> Z;
E -->|"Нет (Загрязнен/Ошибка/Уход из КНР)"| G["<b>Fallback</b>: Запрос через <b>Proxy</b><br>Зарубежный DNS (1.1.1.1...)"];
G --> G_OUT[Вернуть корректный зарубежный IP];
G_OUT --> Z;
#### Пример 2: Эта конфигурация разрешает правильные, но не обязательно дружественные к зарубежным CDN адреса, гарантирует отсутствие утечек DNS и при наличии серверных узлов в Китае отдает им приоритет при разрешении. Подходит для сценариев с прозрачным прокси `fakeIp`, входящими соединениями `sock`, `http` и т.д.
B -->|geosite:geolocation-!cn<br>Известные зарубежные домены| I["Запрос через <b>Proxy</b><br>Зарубежный DNS (1.1.1.1...)"];
I --> J{Результат - зарубежный IP?};
J -->|"Да (Ожидаемо)"| K_OUT[Вернуть зарубежный IP];
K_OUT --> Z;
J -->|"Нет (Неожиданный китайский IP/Ошибка)"| L["<b>Fallback</b>: Запрос через <b>Proxy+ECS</b><br>Зарубежный DNS (8.8.8.8...)"];
L --> L_OUT[Вернуть оптимизированный китайский IP];
L_OUT --> Z;
B -->|Неизвестный домен| N["Запрос через <b>Proxy+ECS</b><br>Зарубежный DNS (8.8.8.8...)<br>Ожидание китайского IP"];
N --> O{Результат - китайский IP?};
O -->|"Да (Есть сервер в Китае)"| P_OUT[Вернуть китайский IP];
P_OUT --> Z;
O -->|"Нет (Чисто зарубежный сайт)"| Q["<b>Fallback</b>: Запрос через <b>Proxy</b><br>Зарубежный DNS (1.1.1.1...)"];
Q --> Q_OUT[Вернуть оптимизированный зарубежный IP];
Q_OUT --> Z;
```
Вы можете использовать IP-адреса, полученные с помощью этой конфигурации, в сочетании с доменами или полагаться исключительно на IP для разделения трафика.
В среде прозрачного прокси RealIP вы даже можете обеспечить полный перехват DNS по всем каналам, установив `domainStrategy=AsIs` и `routeOnly=true`, чтобы избежать вторичного DNS-резолвинга.
> Примечание: Упомянутая "дружественность к CDN" для зарубежного сегмента оптимизирована под местоположение вашего прокси-сервера. Если вы используете режим "только черный список через прокси" (а не весь зарубежный трафик через прокси), вам необходимо самостоятельно скорректировать ECS в правилах.
#### Пример 2: Конфигурация для получения корректного адреса (не гарантируется оптимизация для зарубежных CDN). Гарантирует отсутствие DNS Leak. Если в Китае есть сервер, он будет разрешен приоритетно. Подходит для FakeIP прозрачного прокси, Socks, HTTP Inbound.
```json
{
"dns": {
"servers": [
// Предотвращение зависания Google CAPTCHA и мониторинга Google China
// (так как многие сторонние сайты могут загружать шрифты Google и т.д.)
{
// Мы не полностью доверяем geosite:cn, но если домен уже есть в этом списке
// сначала попробуем его разрешить. Если возвращается китайский IP, это значит, что он не заблокирован. В противном случае, он с высокой вероятностью заблокирован, и мы переключаемся на 8.8.8.8 для повторного разрешения, чтобы устранить возможное DNS-загрязнение (это может привести к пустой трате прокси-трафика).
// Причина приоритетного разрешения в том, что это требует минимальных затрат, прямое подключение занимает всего несколько десятков миллисекунд.
"address": "1.1.1.1",
"skipFallback": true,
"domains": ["geosite:google", "geosite:google-cn"],
"finalQuery": true // Завершить цепочку запросов
},
{
// Мы не доверяем geosite:cn полностью, но если домен уже есть в списке,
// пробуем разрешить его приоритетно. Если возвращается китайский IP — он не заблокирован.
// Если нет — высока вероятность блокировки, Fallback на 8.8.8.8 для повторного резолвинга,
// чтобы устранить возможное загрязнение DNS.
// Причина приоритета: цена ошибки минимальна, Direct-запрос занимает всего ~10 мс.
"tag": "dns-direct",
"address": "223.5.5.5",
"port": 53,
"skipFallback": true,
"domains": ["geosite:cn"],
"expectIPs": ["geoip:cn"]
},
{
// Если домен не находится в geosite:cn, или если разрешение по предыдущему правилу не удалось, будет использоваться этот сервер.
// Здесь используется EDNS для попытки получения записей A/AAAA для Китая.
// Если домена нет в geosite:cn или сработал Fallback из правила выше, используется этот сервер.
// Используем ECS для попытки получения 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.
"clientIp": "222.85.85.85", // Укажите IP вашего локального ISP для получения оптимизированных A/AAAA записей
// Например, если вы используете Henan Telecom, используйте соответствующий IP.
// Не гарантирует 100% дружелюбность к китайским CDN, так как не все Authoritative DNS поддерживают ECS.
"skipFallback": false
}
],
"tag": "dns-proxy"
},
"routing": {
"domainStrategy": "Должно быть не AsIs, конкретное значение зависит от ваших потребностей",
"domainStrategy": "Обязательно НЕ AsIs, конкретное значение зависит от требований",
"rules": [
{
// Маршрутизация для самих DNS-запросов
@@ -158,32 +256,34 @@
"inboundTag": ["dns-proxy"],
"outboundTag": "proxy"
}
// Ваши персональные правила маршрутизации, используйте domain и/или ip для разделения трафика в соответствии с вашими потребностями...
// Ваши персональные правила маршрутизации
// Для разблокировки стриминга и т.д. используйте domain, для разделения трафика (CN/!CN) всегда используйте ip
]
}
// Остальное игнорируется, настраивайте по необходимости...
// Остальное пропущено, настройте по необходимости...
}
```
В этом сценарии, поскольку все запросы, отправляемые на сервер Xray, являются доменными именами, нет необходимости многократно использовать DNS для поиска оптимального результата. Достаточно быстро определить, не загрязнен ли домен, и по возможности разрешить дружественный к китайским CDN IP-адрес.
В этом сценарии, поскольку все запросы к серверу Xray передаются в виде доменов, нет необходимости использовать DNS для многократного поиска оптимального результата. Достаточно быстро определить, не "загрязнен" ли домен, и по возможности получить китайский IP, дружественный к CDN.
В этом примере китайские IP-адреса, разрешенные DNS-модулем, уже на 99% дружественны к китайским CDN, поэтому в исходящем соединении `direct` вы можете установить `domainStrategy` в значение, **отличное от** `AsIs`, чтобы использовать кэш. Если вы стремитесь к 100% дружественности к китайским CDN, вы можете установить его в `AsIs`, чтобы использовать DNS, настроенный в операционной системе, для повторного разрешения, что займет дополнительно от 1 до нескольких сотен миллисекунд.
В этом примере китайский IP, полученный DNS-модулем, уже на 99% оптимизирован для CDN в Китае. Поэтому вы можете установить `domainStrategy` в `direct` Outbound в значение **не** `AsIs`, чтобы использовать кэш, если это необходимо.<br>
Если вы стремитесь к 100% оптимизации для китайских CDN, можно установить `AsIs`, чтобы использовать системный DNS для повторного резолвинга (дополнительные затраты времени от 1 до сотен мс). Рекомендуется включить "оптимистичное кэширование" (optimistic caching) для дальнейшего снижения задержки.
## Послесловие
Известно, что многие недобросовестные китайские приложения определяют ваш внешний IP-адрес и связывают его с вашей конфиденциальной информацией, такой как GPS-координаты, номер телефона, адрес доставки еды, а затем сливают эти данные в базы социальной инженерии. ~~Большой брат следит за тобой!!!~~
Известно, что многие недобросовестные локальные приложения (в Китае) сканируют ваш исходящий зарубежный IP и связывают его с вашим GPS-положением, номером телефона, адресом доставки и другой конфиденциальной информацией, сливая эти данные в базы для социальной инженерии (社工库). ~~Большой брат следит за тобой!!!~~
Некоторые ошибочно полагают, что это происходит из-за разделения трафика и что этого можно избежать, переключившись на режим черного списка (когда только сайты из черного списка идут через прокси).
На самом деле это не так. Во-первых, черные списки очень легко «отравить»: злоумышленники могут намеренно создавать и добавлять в них сайты-приманки для определения вашего зарубежного IP-адреса.
Некоторые ошибочно полагают, что это вызвано разделением трафика, и что переход на режим "черного списка" (только сайты из черного списка идут через прокси) решит проблему.
На самом деле это не так. Во-первых, в "черный список" очень легко внедрить "отравленные" данные: злоумышленники могут намеренно создать сайты-приманки и добавить их туда, чтобы выявить ваш зарубежный IP.
Во-вторых, если любой из сайтов в черном списке размещен на Cloudflare, даже приманка не нужна. Попробуйте зайти на: https://chatgpt.com/cdn-cgi/trace
Во-вторых, если хотя бы один сайт из черного списка размещен на Cloudflare, даже приманка не нужна. Попробуйте посетить: `https://chatgpt.com/cdn-cgi/trace`
Сообразительные пользователи могут подумать: «А что, если я просто воспользуюсь еще одним публичным прокси?» Но для этого вы должны полностью доверять этому прокси — быть уверенным, что он не ведет логи и не продаст вас, и что им интенсивно пользуются многие люди из вашей страны. Когда один и тот же внешний IP-адрес в течение короткого времени связан с тысячами людей, становится невозможно отследить вас по этому IP. А с надоедливыми капчами на таких «грязных» IP можно и смириться.
Сообразительный читатель может подумать: "А что, если я найду публичный прокси и пущу трафик через него?" Это сработает при условии, что вы полностью доверяете этому прокси (отсутствие логов, продажа данных) и он активно используется множеством людей из вашей страны. Когда один зарубежный IP в единицу времени связан с десятками тысяч людей, невозможно вычислить конкретно вас через этот IP. А с назойливыми капчами на "грязных" IP придется смириться.
Разве Warp от «кибер-добряков» из Cloudflare не идеально подходит под все эти критерии? К сожалению, для сайтов, размещенных на CF, Warp не может полностью скрыть ваш IP-адрес; он эффективен только для серверов, не принадлежащих CF.
Cloudflare Warp от "кибер-филантропа" Cloudflare идеально подходит под описание? К сожалению, для сайтов, размещенных на CF, Warp не скрывает ваш IP полностью; он эффективен только для серверов, не принадлежащих CF.
А как насчет Tor? Он не очень подходит для повседневного использования. Его IP-адреса слишком «грязные», а частая смена выходных узлов может привести к блокировке ваших аккаунтов на многих сайтах.
Подойдет ли Tor? Он плохо подходит для повседневного использования: IP слишком "грязные", а выходные узлы часто меняются, что приводит к блокировке ваших аккаунтов на многих сайтах.
Поэтому, если ваш клиент не поддерживает разделение трафика по приложениям (что возможно только на телефонах и компьютерах), любой другой способ обхода блокировок приведет к утечке вашего внешнего IP-адреса.
Поэтому, если ваш клиент не умеет разделять трафик по приложениям (App split tunneling, доступно только на мобильных устройствах), любой метод обхода блокировок приведет к утечке вашего зарубежного IP.
В общем, я хочу сказать, что при обычных способах обхода блокировок утечка внешнего IP-адреса практически неизбежна. Если вам нужна повышенная защита конфиденциальности, используйте такие инструменты, как Tor. Xray-core как инструмент для борьбы с цензурой сосредоточен на противодействии блокировкам, чтобы помочь вам преодолеть файрвол, но его возможности в плане защиты конфиденциальности весьма ограничены.
В заключение хочу сказать: при обычных методах обхода блокировок утечка зарубежного IP практически неизбежна. Если вам требуется высокий уровень конфиденциальности, используйте Tor и подобные инструменты. Xray-core — это инструмент противодействия цензуре, ориентированный на пробивание "стен" (Firewall), а его возможности в области защиты приватности весьма ограничены.