ТСПУ перехватывает открытый DNS: почему в офисе «интернет есть, а сайты не открываются»

Здравствуйте! Меня зовут Семёнов Евгений Сергеевич, и я руковожу компанией «АйТи Фреш». За мои 15 лет работы я обслужил не одну сотню офисов на 10–50 рабочих мест в Москве и области, и почти в каждом из них DNS был настроен «как получится» — публичные резолверы в свойствах сетевой карты, пара адресов в роутере, и все довольны. В последние дни августа 2026 года эта привычная схема перестала работать, и у нескольких моих клиентов почти одновременно появились одинаковые жалобы. В этой статье я разберу, что именно изменилось, покажу замеры, которые мы сделали на собственных серверах в Москве и за границей, и расскажу, как я перевожу офисы клиентов на шифрованный DNS — по шагам, чтобы вы могли повторить это у себя или проверить своего подрядчика.

В последние дни августа в нескольких наших клиентских офисах почти одновременно появились одинаковые жалобы: «интернет работает, почта ходит, а часть сайтов и сервисов не открывается — то работает, то нет». Причина оказалась не в роутере и не в провайдере в привычном смысле: изменилось поведение DNS на уровне ТСПУ. Ниже — что мы намерили на собственных серверах, как отличить эту проблему от десятка похожих и что мы делаем в клиентских сетях, чтобы закрыть вопрос за час.

Раньше запрос вида «дай мне IP-адрес сайта», отправленный на публичный резолвер 8.8.8.8 (Google) или 1.1.1.1 (Cloudflare), доходил до этого резолвера. Домены из реестра блокировались уже на уровне доступа к самому сайту — DNS при этом отвечал честно.

С 26 августа 2026 года картина изменилась. Оборудование ТСПУ на магистралях распознаёт DNS-протокол внутри UDP-пакета и перенаправляет такой пакет на инфраструктуру НСДИ (адрес 195.208.5.1). Пользователю ответ возвращается с подменённым адресом отправителя — визуально «как будто от 8.8.8.8». Для заблокированных доменов ответ — NXDOMAIN, то есть «такого домена не существует».

Ключевая деталь, которую многие упускают: подмена касается всего открытого UDP-DNS, а не только запрещённых доменов. Обычные, ничем не примечательные домены тоже отвечает уже не тот резолвер, которому вы адресовали запрос.

Технически происходящее — это направленное перенаправление трафика по признаку содержимого. Оборудование на магистрали смотрит не только на порт назначения, но и на структуру полезной нагрузки: если внутри UDP-датаграммы опознан корректный DNS-запрос, адрес назначения подменяется на инфраструктуру НСДИ.

Отсюда несколько практических следствий, о которых стоит знать инженеру.

• Произвольный UDP-трафик на 53 порт не трогают. Перенаправление срабатывает именно на распознанный DNS. Значит, туннели, которые упаковывают трафик в свой формат, этой логикой не задеваются.
• Ответ приходит с подменённым адресом отправителя. В дампе вы видите «ответ от 8.8.8.8», хотя фактически отвечал другой узел. Обычной проверкой «а туда ли ушёл пакет» это не ловится — нужно сравнение UDP и TCP или анализ времени жизни пакета.
• Время жизни пакета выдаёт промежуточный узел. Отправляя запросы с искусственно заниженным TTL, видно, что отвечает не конечный резолвер, а устройство в нескольких переходах от вас. Позиция этого устройства зависит от провайдера и региона.
• Механизм не идеален. При быстрой серии одинаковых запросов иногда приходит смешанный результат: сначала «домен не существует», следом настоящий адрес. Именно это порождает у пользователей ощущение «работает через раз» и делает жалобу такой трудноуловимой.
• Статистика провайдера искажается. В потоковой телеметрии соединения выглядят как обращения к российской инфраструктуре, а не к Google или Cloudflare. Если вы строите отчёты по внешнему трафику, картинка изменится без всяких действий с вашей стороны.

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

Во время проверки мы наткнулись на площадку, где картина внешне была идентичной, а причина — совершенно другая. Сервер за роутером MikroTik вообще не получал ответов по UDP на порт 53 к публичным резолверам: чистый таймаут, при этом TCP работал.

Это оказалось локальное правило на периметре — когда-то настроенное намеренно, чтобы вся сеть ходила за именами только через корпоративный резолвер. Симптом для пользователя тот же самый, диагноз и лечение — разные.

Мораль простая: прежде чем списывать сбой на внешние обстоятельства, проверьте свой же периметр. Мы в таких случаях идём по трём шагам: сначала измеряем с самого сервера, затем с роутера, затем с внешней контрольной точки за пределами страны. Три замера дают однозначный ответ, где именно теряется или подменяется запрос — на машине, на периметре или на магистрали.

Такая же дисциплина полезна и в обычных инцидентах: три точки замера снимают спор «это провайдер» / «это ваш сервер» за пять минут вместо часа переписки.

Мы проверили гипотезу на собственных серверах — двух в Москве (площадка в ЦОД и хостинг клиента) и одном контрольном за пределами РФ.

Запрос по UDP с московского сервера:

$ dig youtube.com @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13207
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

Тот же запрос, но принудительно по TCP:

$ dig +tcp youtube.com @8.8.8.8
youtube.com.  300  IN  A  142.251.1.93
youtube.com.  300  IN  A  142.251.1.190

Контрольный сервер за границей отвечает нормально в обоих режимах — значит, дело не в самих Google и Cloudflare.

А теперь самое интересное. Берём заведомо не заблокированный домен example.com и сравниваем ответы одного и того же резолвера по UDP и по TCP:

UDP @8.8.8.8 : 8.47.69.0 , 8.6.112.0     TTL 29
TCP @8.8.8.8 : 8.47.69.6 , 8.6.112.6     TTL 260

Разные IP-адреса и разное время жизни записи от «одного и того же» сервера — это прямое доказательство: по UDP отвечает не Google. Ваш DNS-трафик обслуживает третья сторона, и это происходит для всех доменов, а не только для тех, что в реестре.

Заодно проверили, что осталось живым с российского адреса: порт 853 (DNS-over-TLS) к 1.1.1.1 открыт, запрос DNS-over-HTTPS к Cloudflare отвечает кодом 200. Обычный TCP-порт 53 тоже работает. То есть чинить есть чем.

Классическая картина обращения в поддержку выглядит так:

• «Сайт не открывается, а у коллеги открывается» — у коллеги другой DNS в настройках или включён VPN с собственным резолвером.
• «Работает через раз» — в системе прописано два DNS-сервера, и запросы уходят то на перехваченный публичный, то на корпоративный.
• «VPN включён, но сервис всё равно недоступен» — туннель поднят, а резолвинг имени происходит до входа в туннель, системным резолвером.
• «У бухгалтера не грузится обновление, у остальных всё нормально» — на его машине руками прописан 8.8.8.8 «чтобы быстрее было».

Ошибка NXDOMAIN для приложения означает «домена не существует» — это не таймаут и не отказ в доступе. Поэтому программы ведут себя странно: клиент 1С пишет про недоступный сервер лицензирования, браузер сразу показывает страницу поиска, почтовый клиент молча не проверяет ящик. Админ в этот момент проверяет фаервол, маршруты и провайдера — и ничего не находит, потому что проблема на слое имён.

Есть и вторая, менее очевидная сторона: подменённый ответ можно получить и для рабочего сервиса. Если ваш почтовый шлюз, платёжный API или сервер лицензий резолвится «не туда», вы получаете плавающие сбои, которые почти невозможно поймать по логам приложения.

Проверка, которую можно запустить на любой площадке — от роутера в офисе до сервера в ЦОД. Она сравнивает ответ по UDP и по TCP к одному резолверу:

for s in 8.8.8.8 1.1.1.1; do
  u=$(dig +short youtube.com @$s +time=2 +tries=1 | head -1)
  t=$(dig +short +tcp youtube.com @$s +time=2 +tries=1 | head -1)
  echo "$s UDP='$u' TCP='$t'"
done

Интерпретация проста: если по TCP приходит адрес, а по UDP пусто или NXDOMAIN — открытый DNS на этом канале перехватывается. В Windows аналог — nslookup youtube.com 8.8.8.8 и сравнение с nslookup -vc youtube.com 8.8.8.8.

Мы завели такую проверку отдельным элементом данных в системе мониторинга: расхождение UDP и TCP для контрольного домена превращается в понятный триггер «на площадке активен перехват DNS». Это снимает половину спорных обращений — видно сразу, инфраструктура виновата или канал.

Порядок действий отличается для офиса с роутером, для сети с контроллером домена и для серверов. Общий принцип один: открытого UDP-DNS наружу быть не должно.

1. Периметр: DNS-over-TLS на роутере

В KeeneticOS и в pfSense есть штатная поддержка DoT/DoH. Мы убираем из настроек «Серверы имён» прямые 8.8.8.8 и 1.1.1.1 и включаем шифрованный профиль. Клиенты в LAN продолжают спрашивать роутер обычным способом, а наружу запрос уходит уже внутри TLS — подменить его на магистрали нельзя.

2. Сеть с Active Directory

Рабочие станции обязаны спрашивать только контроллеры домена — это и так требование корректной работы AD, но на практике на половине машин мы находим «народный» 8.8.8.8 во второй строке. Убираем через DHCP и групповые политики, а форвардеры на самом DNS-сервере переводим на шифрованный или, как минимум, TCP-транспорт.

3. Серверы Linux

Ставим локальный кеширующий резолвер (unbound или dnsmasq) с upstream по DoT на порт 853. Быстрая заплатка до нормальной настройки — строка options use-vc в /etc/resolv.conf: она заставляет систему ходить за именами по TCP.

4. VPN-клиенты

Проверяем, что резолвинг идёт внутри туннеля, а не системным резолвером. Это самая частая причина жалоб «VPN включён, а не работает»: сам туннель исправен, но имя сайта клиент спросил у перехваченного публичного резолвера ещё до входа в туннель.

5. Мониторинг и health-проверки

Отдельно ревизуем собственные скрипты. Любая проверка доступности, которая внутри себя делает запрос к публичному DNS по UDP, теперь может врать — и вы получите ложные аварии на ровном месте. Переводим такие проверки на TCP или на внутренний резолвер.

Не надо менять один публичный резолвер на другой. Перехват срабатывает на признак DNS внутри пакета, а не на конкретный адрес назначения. Замена 8.8.8.8 на любой другой открытый резолвер по UDP ничего не изменит.

Не надо решать вопрос точечно на одной машине. Мы видели офисы, где «полечили» директору, а через неделю то же самое всплыло на кассе и в бухгалтерии. DNS — инфраструктурный сервис, править его нужно на периметре и в политике, иначе вы получите долгий хвост однотипных заявок.

Не стоит считать DoT/DoH вечным решением. Это работающий сегодня инструмент, а не гарантия навсегда. Поэтому мы закладываем в схему запасной вариант — собственный резолвер с возможностью быстро сменить транспорт и upstream, а не жёсткую привязку к одному публичному сервису.

И не надо считать, что раз «у нас всё открывается», вас это не касается. Подменяются ответы и для обычных доменов; последствия проявляются не как явная блокировка, а как редкие необъяснимые сбои приложений.

Для компании до 50 рабочих мест история практическая, а не политическая. Она означает три вещи.

Во-первых, выросла цена «настроек по умолчанию». Конфигурация, где рабочие станции и роутер ходят за именами к публичным резолверам открытым текстом, десять лет считалась нормальной и внезапно перестала быть рабочей.

Во-вторых, диагностика инцидентов стала дороже. Симптом «работает через раз» без внятной ошибки съедает часы поддержки, если на площадке нет метрики, которая показывает подмену DNS напрямую.

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

Мы такую проверку и перевод офиса на шифрованный DNS делаем в рамках обслуживания — по времени это обычно один визит и час-полтора работы на периметре плюс правка политик.

Это блокировка VPN?

Нет. Речь именно о перехвате запросов к системе доменных имён по протоколу UDP. Сам VPN-туннель при этом может работать нормально — но если имя сайта запрашивается мимо туннеля, пользователь всё равно получит подменённый ответ.

Почему по TCP всё работает?

Механизм перехвата на сегодня разбирает и перенаправляет только UDP-пакеты с DNS-запросом внутри. Запросы по TCP на порт 53 проходят до настоящего резолвера. Это удобно для диагностики, но полагаться на это как на постоянное решение не стоит.

Насколько сложно перевести офис на DoT/DoH?

На современном роутере это настройка в интерфейсе плюс уборка старых DNS-серверов из профиля раздачи адресов. В сети с контроллером домена добавляется правка групповых политик и форвардеров. Типичный офис до 50 мест закрывается за один визит.

Может ли перехват сломать 1С, почту или платёжные сервисы?

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

Как понять, что проблема именно в DNS, а не в провайдере?

Сравнить ответ на один и тот же домен по UDP и по TCP к одному резолверу. Если TCP отдаёт адрес, а UDP — пустоту или ответ «домен не существует», это перехват, а не потеря связи.