Перейти к содержанию

DNS, ECS и утечки геолокации: диагностика VPN/VPS на Keenetic

Статус: Observed + Confirmed fundamentals + Research для механизмов GeoIP-переатрибуции конкретных сервисов
Область применения: Keenetic/Entware, VPN/proxy/Mihomo, VPS, браузерные SOCKS/HTTP-прокси, системные TUN/VPN
Проверено на: реальных тестах владельца (Keenetic + Windows/браузер, сентябрь 2026); базовые свойства ECS сверены с RFC и официальной документацией DNS-провайдеров
Последняя проверка: 2026-09-28
Source of truth: RFC 7871; официальные документы Google Public DNS, Quad9 и Cloudflare; реальные наблюдения владельца; связанные статьи этой базы

Что решаем

Иногда европейский VPS, WARP-выход или другой внешний IP со временем начинает определяться отдельными сервисами как принадлежащий другой стране. Частая ошибка — сразу обвинить DNS, конкретный VPN-протокол или длину цепочки.

Эта статья даёт более полезную методику:

  1. отдельно проверить публичный IP;
  2. отдельно проверить DNS path;
  3. отдельно проверить ECS (EDNS Client Subnet);
  4. отдельно проверить IPv4 и IPv6;
  5. понять границу туннеля: браузерный прокси, системный TUN или маршрутизация на роутере;
  6. не выдавать предположения о внутреннем алгоритме Google/другого сервиса за установленный факт.

Материал извлечён из реального исследования сентября 2026. Сырые AI-объяснения из исходного обсуждения сохранены только как provenance и не считаются доказательством.

Контекст: четыре разных явления

1. Обычная утечка IP

Часть трафика идёт не через ожидаемый туннель/прокси и показывает прямой адрес провайдера.

Примеры причин:

  • прокси включён только в одном браузере;
  • split tunneling;
  • IPv4 идёт напрямую, а IPv6 — через VPN, или наоборот;
  • отдельные приложения и системные службы не входят в политику маршрутизации.

Это проблема границы туннеля и маршрутизации, а не ECS.

2. DNS leak

DNS-запросы уходят через неожиданный резолвер или вообще мимо ожидаемого туннеля. Наличие DNS leak не следует автоматически из того, что веб-трафик идёт через другой IP: проверять нужно отдельно.

3. ECS / EDNS Client Subnet

RFC 7871 описывает EDNS Client Subnet как EDNS0-опцию, позволяющую рекурсивному DNS-резолверу передавать авторитетному серверу информацию о сети происхождения запроса.

Официальный RFC: https://www.rfc-editor.org/rfc/rfc7871.html

Это не то же самое, что «DNS leak». Запрос может идти к правильному публичному резолверу через правильный маршрут, но сам резолвер может использовать ECS.

4. GeoIP / service-specific attribution

Базы GeoIP и внутренняя геолокация крупных сервисов не обязаны совпадать. Один и тот же адрес может одновременно определяться по-разному у разных поставщиков данных.

Важно: публичной документации, подтверждающей конкретный алгоритм вида «Google увидел один аккаунт с двух адресов и поэтому перекрасил VPS», в рамках этого исследования не найдено. Такое объяснение из исходного чата остаётся гипотезой, а не Confirmed-фактом.

Что подтверждено официально

Google Public DNS и ECS

Google документирует ECS и прямо пишет, что Google Public DNS использует ECS для более точной геолокации DNS-ответов.

Документация:

  • https://developers.google.com/speed/public-dns/docs/ecs
  • https://developers.google.com/speed/public-dns/docs/doh/json

В JSON DoH API Google есть параметр edns_client_subnet; документация рекомендует 0.0.0.0/0, если клиент не хочет отправлять часть своего IP авторитетным серверам.

Это означает: Google Public DNS нельзя автоматически считать «резолвером без ECS».

Cloudflare 1.1.1.1

Cloudflare официально указывает, что публичный резолвер 1.1.1.1 не отправляет ECS авторитетным DNS-серверам (за исключением специально описанного debug-сценария Akamai).

Источник:

https://developers.cloudflare.com/1.1.1.1/faq/

Quad9

У Quad9 профили различаются.

На 2026-09-28:

  • 9.9.9.9 / dns.quad9.net — основной профиль с threat blocking;
  • 9.9.9.10 / dns10.quad9.net — без threat blocking;
  • 9.9.9.11 / dns11.quad9.net — профиль с ECS;
  • 9.9.9.12 / dns12.quad9.net — без threat blocking, с ECS.

Официальная матрица:

https://quad9.net/service/service-addresses-and-features/

Отдельно Quad9 сообщил, что с 15 июня 2026 DNSSEC validation включается на всех service endpoints:

https://quad9.net/news/blog/quad9-enables-dnssec-on-all-service-endpoints/

Следовательно, если цель — избежать ECS, профили dns11 и dns12 для этой задачи не подходят.

Проверка ECS

Через dig

В исходном реальном тесте использовался диагностический TXT-запрос:

dig +short TXT o-o.myaddr.l.google.com

В наблюдаемом результате возвращался адрес резолвера/выхода без строки edns0-client-subnet.

Если в ответе появляется поле наподобие:

edns0-client-subnet ...

это является признаком ECS в рассматриваемой цепочке.

Статус этой конкретной диагностической команды: Observed. Она полезна как оперативная проверка, но в этой статье не заявляется как официально гарантированный API Google.

BusyBox на Keenetic

Урезанный nslookup BusyBox может не поддерживать выбор TXT-типа в привычном синтаксисе. В реальном тесте команда вида:

nslookup -q=txt o-o.myaddr.l.google.com

не сработала.

Если dig уже установлен через Entware, лучше использовать его.

Если dig отсутствует, безопаснее выполнить проверку с обычного ПК в той же тестируемой сетевой политике.

Установка пакета:

opkg install bind-dig

изменяет Entware-среду и не нужна только ради проверки, если можно выполнить запрос с другого клиента.

Важное ограничение DoH-проверок

Запрос вида:

curl 'https://dns.google/resolve?name=...'

проверяет прямое обращение к Google DoH API, а не обязательно тот DNS-путь, который сейчас использует Keenetic/Windows/браузер.

Поэтому такую команду нельзя использовать как единственное доказательство отсутствия DNS leak или ECS в системной конфигурации.

Проверка DNS path

Для браузера/ПК полезны:

  • https://ipleak.net/
  • https://www.dnsleaktest.com/

Они позволяют увидеть, какие DNS-серверы фактически наблюдаются со стороны тестового сервиса.

Но результат нужно интерпретировать осторожно:

  • зарубежный DNS не доказывает отсутствие ECS;
  • российский DNS не доказывает, что именно он изменил GeoIP адреса;
  • наличие нескольких DNS-адресов может быть нормальным для anycast/распределённой инфраструктуры;
  • браузерный тест не обязательно описывает DNS-путь всей ОС.

Проверка границы туннеля

Браузерный прокси

FoxyProxy/аналогичный плагин меняет маршрут только того трафика, который действительно проходит через прокси-стек браузера.

Он не превращает всю ОС в VPN.

Поэтому одновременно могут существовать:

Browser -> SOCKS/HTTP proxy -> многохоповая цепочка -> внешний exit

Windows services / другие приложения -> обычный default route

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

Системный TUN/VPN

Системный TUN способен охватывать намного больше трафика, но всё равно нужно проверять:

  • split tunneling;
  • excluded routes;
  • IPv4;
  • IPv6;
  • DNS;
  • приложения с собственными сетевыми механизмами.

Маршрутизация на Keenetic

Если политика задаётся на роутере, проверять нужно уже весь путь:

клиент
  -> Keenetic policy/segment
  -> ProxyN / Mihomo / VPN
  -> upstream chain
  -> exit

Связанные статьи:

IPv4 и IPv6 проверяются отдельно

Один из реальных тестов показал важный антипример: VPN-профиль влиял на IPv6, а IPv4 продолжал выходить напрямую.

Поэтому проверка «VPN включён» сама по себе недостаточна.

Минимальная матрица:

Проверка IPv4 IPv6
Публичный IP браузера проверить проверить
DNS проверить проверить
TUN/default route проверить проверить
Приложения вне браузера проверить проверить

Если IPv6 не используется в архитектуре, безопаснее явно понимать, где он отключён, а не считать его отсутствующим по умолчанию.

Практический тест-план

Шаг 1. Зафиксировать исходное состояние

Без прокси/VPN:

  • публичный IPv4;
  • публичный IPv6;
  • DNS-серверы;
  • наличие/отсутствие ECS.

Шаг 2. Включить только браузерный прокси

Повторить те же тесты.

Если меняется только браузерная картина, это ожидаемо: граница прокси находится внутри браузера.

Шаг 3. Проверить системный TUN/VPN

Повторить тесты не только в браузере, но и для приложения/CLI вне браузера.

Шаг 4. Проверить IPv4 и IPv6 независимо

Не делать вывод по одному семейству адресов.

Шаг 5. Проверить DNS

Сравнить:

  • какой резолвер настроен;
  • какой резолвер видит leak-test;
  • используется ли ECS выбранным профилем резолвера;
  • идёт ли DNS через ту же политику маршрутизации, что и основной трафик.

Шаг 6. Не смешивать выводы

Корректные формулировки:

  • «Наблюдается прямой IPv4 вне туннеля».
  • «В браузерном тесте виден только зарубежный DNS».
  • «Профиль Quad9 dns11 официально использует ECS».
  • «В тесте o-o.myaddr... ECS не наблюдался».

Некорректные без дополнительных доказательств:

  • «Google перекрасил VPS именно из-за DNS».
  • «Google перекрасил VPS именно из-за одного аккаунта».
  • «Любая нода DNS в определённой стране автоматически меняет GeoIP».
  • «Если ipleak зелёный, вся ОС гарантированно не течёт».

Что делать с DNS-профилями

Если задача именно в минимизации передачи client subnet:

  • выбирать профиль, для которого политика ECS документирована;
  • не считать имя провайдера достаточным — у одного провайдера могут быть разные профили;
  • перепроверять документацию при изменении endpoint;
  • не смешивать anti-malware, DNSSEC, ECS и географию DNS-ноды в один признак «хороший/плохой DNS».

Для текущей практики Keenetic отдельная реализация upstream DNS через ProxyN/Mihomo описана в keenetic-dns-via-mihomo.md. Эта статья не дублирует её конфигурационный контракт.

Типичные проблемы

«В браузере всё зарубежное, но система всё равно видна напрямую»

Вероятная причина: браузерный proxy scope не охватывает остальные приложения.

Проверка: сравнить браузерный тест и CLI/другое приложение без proxy-настроек браузера.

«DNS зарубежный, но ECS всё равно есть»

Страна DNS-ноды и ECS — разные свойства. Проверить конкретный resolver profile и диагностический TXT-ответ.

«VPN работает, но один адрес остаётся прямым»

Проверить IPv4/IPv6 отдельно и таблицу маршрутизации.

«Включили DoH, значит утечек нет»

Шифрование DNS не равно правильной маршрутизации DNS и не равно отсутствию ECS.

Rollback / recovery

Статья преимущественно диагностическая и не требует изменения persistent-конфигурации.

Если ради проверки временно менялись DNS/VPN/policy routing:

  1. вернуть исходный DNS-профиль;
  2. вернуть исходную policy routing;
  3. перепроверить IPv4/IPv6 и DNS после отката;
  4. не оставлять экспериментальные resolver endpoints как постоянные только потому, что они один раз прошли leak-test.

Что подтверждено, а что нет

Confirmed:

  • назначение ECS по RFC 7871;
  • Google Public DNS поддерживает/использует ECS;
  • Cloudflare 1.1.1.1 заявляет отсутствие ECS для обычных запросов;
  • Quad9 имеет отдельные ECS и non-ECS профили;
  • браузерный прокси не является системным TUN и сам по себе не маршрутизирует весь трафик ОС.

Observed:

  • на Keenetic BusyBox nslookup в тестовом окружении не принял TXT-опцию;
  • bind-dig через Entware дал возможность выполнить TXT-проверку;
  • в одном из тестов TXT-ответ не содержал edns0-client-subnet;
  • браузерный FoxyProxy менял наблюдаемый выход только внутри браузерного сценария;
  • отдельный VPN-сценарий продемонстрировал раздельное поведение IPv4 и IPv6.

Historical / source material:

  • подборка сторонних DoH/DoT endpoint из чата сентября 2026;
  • конкретные публичные адреса, увиденные leak-test сервисами;
  • AI-объяснения причин возможного GeoIP «перекрашивания».

Still research / unknown:

  • точный внутренний алгоритм Google для изменения географической атрибуции конкретного IP;
  • достаточность/вес аккаунт-корреляции, DNS/ECS и других сигналов в таком алгоритме;
  • пригодность сторонних resolver endpoint из старой подборки без отдельной актуальной проверки.

Источники и provenance

Официальные источники

  • RFC 7871 — https://www.rfc-editor.org/rfc/rfc7871.html
  • Google Public DNS ECS — https://developers.google.com/speed/public-dns/docs/ecs
  • Google DoH JSON API / edns_client_subnet — https://developers.google.com/speed/public-dns/docs/doh/json
  • Cloudflare 1.1.1.1 FAQ — https://developers.cloudflare.com/1.1.1.1/faq/
  • Quad9 Service Addresses & Features — https://quad9.net/service/service-addresses-and-features/
  • Quad9 DNSSEC endpoint change (2026) — https://quad9.net/news/blog/quad9-enables-dnssec-on-all-service-endpoints/

Внутренний provenance

Связанные материалы