Пользователь
192,1
рейтинг
11 августа 2015 в 00:03

Разработка → Особенности резолвера DNS в Windows 10 и DNS Leak

image

TL;DR: DNS-резолвер в Windows 10 отправляет запросы на все известные системе адреса DNS-серверов параллельно, привязывая запрос к интерфейсу, и использует тот ответ, который пришел быстрее. В случае, если вы используете DNS-сервер из локального сегмента, такое поведение позволяет вашему провайдеру или злоумышленнику с Wi-Fi-точкой подменять записи DNS, даже если вы используете VPN.

Современные версии Windows добавляют головные боли активным пользователям VPN. DNS-резолвер до Windows 7 включительно имел предсказуемое поведение, совершая запросы к DNS-серверам в порядке очереди и приоритета DNS-серверов, в общем-то, как и все остальные ОС. Это создавало так называемый DNS Leak (утечка DNS-запроса через внешний интерфейс при подключенном VPN) только в том случае, если DNS-сервер внутри VPN-туннеля не ответил вовремя, или ответил ошибкой, и, в целом, не являлось такой уж вопиющей проблемой.

Windows 8

С выходом Windows 8, Microsoft добавила весьма интересную функцию в DNS-резолвер, которая, как я могу судить по Google, осталась совершенно незамеченной: Smart Multi-Homed Name Resolution. Если эта функция включена (а она включена по умолчанию), ОС отправляет запросы на все известные ей DNS-серверы на всех сетевых интерфейсах параллельно, привязывая запрос к интерфейсу. Сделано это было, вероятно, для того, чтобы уменьшить время ожидания ответа от предпочитаемого DNS-сервера в случае, если он по каким-то причинам не может ответить в отведенный ему таймаут (1 секунда по умолчанию), и сразу, по истечении таймаута, отдать ответ от следующего по приоритету сервера. Таким образом, в Windows 8 и 8.1 все ваши DNS-запросы «утекают» через интернет-интерфейс, позволяя вашему провайдеру или владельцу Wi-Fi-точки просматривать, на какие сайты вы заходите, при условии, что ваша таблица маршрутизации позволяет запросы к DNS-серверу через интернет-интерфейс. Чаще всего такая ситуация возникает, если использовать DNS-сервер внутри локального сегмента, такие DNS поднимают 99% домашних роутеров.

Данную функциональность можно отключить, добавив в ветку реестра:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient
Параметр типа DWORD с названием:
DisableSmartNameResolution
и любым значением, отличным от нуля, что возвращало старое поведение резолвера.

Windows 10

Хоть Windows 8 и 8.1 отправляли все ваши запросы без вашего ведома через публичный интерфейс, совершить подмену DNS-ответа таким образом, чтобы перенаправить вас на поддельный сайт, было проблематично для злоумышленника, т.к. ОС бы использовала подмененный ответ только в том случае, если не удалось получить правильный ответ от предпочитаемого DNS-сервера, коим является сервер внутри шифрованного туннеля.
Все изменилось с приходом Windows 10. Теперь ОС не только отправляет запрос через все интерфейсы, но и использует тот ответ, который быстрее пришел, что позволяет практически всегда вашему провайдеру перенаправить вас на заглушку о запрещенном сайте или злоумышленнику на поддельный сайт. Более того, способ отключения Smart Multi-Homed Name Resolution, который работал в Windows 8.1, не работает на новой версии.
Единственный приемлемый (хоть и не самый надежный) способ решения проблемы — установить DNS на интернет-интерфейсе вне локального сегмента, например, всем известные 8.8.8.8, однако, он не поможет в случае с OpenVPN. Для OpenVPN единственным (и некрасивым) решением является временное отключение DNS на интернет-интерфейсе скриптами.

UPD: ранее в статье рекомендовалось использовать параметр redirect-gateway без def1 для OpenVPN. Оказывается, Windows возвращает маршрут по умолчанию от DHCP-сервера при каждом обновлении IP-адреса, и через какое-то время весь ваш трафик начинал бы ходить в обход VPN. На данный момент, красивого решения не существует.

UPD2: Я написал плагин.
Влад @ValdikSS
карма
621,0
рейтинг 192,1
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (63)

  • +21
    Вроде бы хотели как лучше, а получилось как бы специально о_О
    • 0
      Да вот так и есть и проблема в том, что уже давно есть ПО, которое тоже умеет параллельно слать запросы на несколько серверов для ускорения, да и вообще представляет из себя навороченный, пусть и ориентированный на кэширование DNS, но решение при этом полностью настраиваемое, т. е. оно шлёт запросы не абы куда, а только на те адреса, которые прописаны в конфиге. Называется Acrylic DNS Proxy.
  • –4
    Использовать странные dns сервера в организации вообще не есть гуд. А для домашнего пользователя 8.8.8.8 вполне нормально.

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

    Сейчас стало логичнее. Хотя было бы лучше поведение dns клиента при ошибках настраивать гибче.
    • 0
      А для домашнего пользователя 8.8.8.8 вполне нормально.
      Я тоже так думал и довольно долго им пользовался, но очень часто разные сайты были недоступны — я грешил на сами сайты, пока вдруг несколько раз я не смог попасть на сайт Гугла, в то время как у всех остальных сайт Гугла был доступен. Сменил DNS на провайдерский, и проблемы исчезли. Возможно, 8.8.8.8 и 8.8.4.4 просто не справлялись с нагрузкой, не знаю.
      • 0
        Было такое, то перестает отвечать днс провайдера, то днс гугла, фигня какая то. То ли провайдер специально блочит днс гугла, то ли что, не знаю. Перешел на днс от яндекс. Проблема исчезла.
      • –4
        Google где-то писал, что эти адреса не для внешнего использования, они не рассчитаны на какую-либо нагрузку. А один из открытых проектов (dnsmasq?) использует их по умолчанию, поэтому нагрузка на них всегда есть.
        • +4
          Вообще то нет.
          Но фраза типа одна бабка сказало, это хорошо.

          developers.google.com/speed/public-dns

          Более старый вариант: web.archive.org/web/20110830223912/http://code.google.com/intl/ru/speed/public-dns/docs/intro.html

          geektimes.ru/post/77199

          Ну итд итп.

          В конце концов wikipedia

          ru.wikipedia.org/wiki/Google_Public_DNS

          Хотя, это еще тот источник знаний.
          • +1
            Да, я ошибся, речь вообще шла об ntp и о надёжности не гуглового сервиса. systemd по умолчанию использует серверы Google, народ обсуждал, на что бы переехать другое. Как оказалось, pool.ntp.org не рекомендуют ставить стандартным сервером — это меня удивило, а упоминание Google просто в голове отложилось.

            github.com/systemd/systemd/issues/437
      • +2
        Моя статистика показывает, что DNS сервера домашних мелких провайдеров глючат горазо чаще, чем гугловский.

        Кстати, не очень понял за что заминусовали. Я считаю, что если один DNS сервер вернул ошибку, это еще не повод, что сайта действительно нет, и во многих случаях я бы хотел больше управлять поведением днс клиентом.
        Он собственно и в Линукс себя также ведет — второй ДНС сервер опрашивает только в том случае, если первый ДНС не отвечает.

        В нескольких крупных компаниях (200+ тыс.человек), где необходимо разделать внутренние и внешние ресурсы, проблема ресолва парочки адресов решилась исключительно через hosts файл, что неудобно. А было бы можно настроить поведение при ошибке, можно было бы просто два DNS сервера разных указать.
  • +11
    Провайдеры могут подменять DNS, и подменяют. Не пользуйтесь DNS провайдеров — это, кажется, прописное.
    Ну и если ваше оборудование автоматом цепляется за любой вайфай без пароля с dhcp… При таком уровне безопасности утечка dns не самая критичная уязвимость имо.
    Так что в нормальной сети проблем не будет, кмк. А там где будут — там и без этого дыра на дыре.
    • 0
      Дело не в DNS провайдеров, и не в автоматическом подключении к сетям. Даже если вы дома на роутере настроили сторонние DNS, но этот же роутер поднимает кеширующий DNS (как это обычно бывает) на интерфейсе локальной сети, вы же не будете прописывать эти DNS еще и на компьютере, ведь от этого, во-первых, пострадает кеширование, да и вообще, какой смысл тогда настраивать на роутере, верно? И вы ожидаете, что все в порядке, подключаете VPN, и — бах — все ваши DNS-запросы идут не так, как вы ожидаете.

      Та же ситуация с Wi-Fi в кафе. Подключаетесь к Wi-Fi, используя DNS, предоставленный по DHCP, сразу подключаетесь по VPN и надеетесь, что все в порядке, а на деле, все ваши DNS-запросы могут быть подменены злоумышленником.
      • 0
        Ну вот с поднятием VPN через публичную сеть кафехи соглашусь.
    • +1
      Провайдеры могут подменять DNS, и подменяют. Не пользуйтесь DNS провайдеров — это, кажется, прописное.


      На самом деле, всё ещё хуже. Они не только запросы к себе подменяют, но и к любым другим. У нас например, провайдер нагло изменяет все ДНС пакеты в которых упомянуты запрещённые имена. Даже 8.8.8.8 тут не поможет. (Зато через VPN всё как надо)
      • 0
        Я называю это «перенаправление DNS»
        • +1
          по моему вы имели в виду это :)
          • 0
            Спасибо за классную тулзу! Подтвердил то, до чего долго докапывался самостоятельно
          • 0
            Эх, да.
      • 0
        Вот Билайн так точно делает. Какое-то время назад столкнулся с проблемой, что 8.8.8.8 и тот же самый через VPN возвращают абсолютно разные данные.
        • 0
          Мобильный МТС еще.
          • 0
            И есть ли какое-нибудь решение? Сгодится и технический вариант (юзабелен ли сейчас DNSCrypt на Linux?), и юридический (выдать дружных люлей за модификацию трафика, хотя вряд ли получится).
            А вообще провайдер должен быть трубой в пространство IP/IPv6. Всё остальное его не касается.
            • +1
              юзабелен ли сейчас DNSCrypt на Linux?
              Абсолютно.
    • +1
      Провайдеры могут подменять DNS, и подменяют.


      И не всегда это плохо.
      Перенаправить клиента, у которого отрицательный баланс, на страничку с информацией, ссылкой на личный кабинет и возможностью начисления обещанного платежа — вполне себе нормальное и более чем приемлемое, я считаю, использование этой возможности. Для «домашних» пользователей это проблемой не является.
      Впрочем, практически весь трафик можно перенаправить куда нужно.
  • 0
    Хотел сказать «поднимите локальный ресолвер и закройте iptables всем, кроме него доступ к dns», но понял, что не знаю как это всё называется в виндах.

    Алсо, в линуксах есть resolv.conf и nsswitch.conf, управляющие порядком ресолвинга. В виндах аналогичного нет?
    • +4
      Ну так в windows можно указать несколько ДНС, проблема же в другом. Оно тут и описана, что винда кладет болт на это и делает по своему.
      • 0
        У меня стойкое ощущение, что это всё таки баг 10, а не фича и настройку для отключения либо потеряли, либо изменили, но нормально не задокументировали.
    • 0
      Алсо, в линуксах есть resolv.conf и nsswitch.conf, управляющие порядком ресолвинга. В виндах аналогичного нет?
      nsswitch точно есть, и аналог resolv.conf через реестр можно сделать, но это все костыльно и неудобно, к сожалению.
      Понятное дело, что локальный резолвер решает проблему, но нужно всегда помнить о необходимости убирать DNS на других интерфейсах, т.к. в Windows они привязаны к интерфейсам.
    • 0
      то есть для линукса можно настроить nsswitch что-то типа:

      dns [NOTFOUND=continue] nis

      и если первый dns сервер из resolv.conf не нашел домен, оно будет запрашивать остальные по очереди?
      • 0
        Насколько я знаю, как раз строго нет, от чего страдают всякие любители «альтернативных DNS через vpn», когда хочется, чтобы «не нашёл один — спроси у другого».
        • 0
          Вот у нас похожая проблема.

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

          Единственное, что в статье действительно не описали что будет, если win10 делает запрос, и самый быстрый сервер отвечает отказом. Дождется ли оно ответа от других серверов, или сразу отлуп?
      • 0
        и если первый dns сервер из resolv.conf не нашел домен, оно будет запрашивать остальные по очереди?

        Нет. Если DNS не нашел запись, ломиться в nis. А DNS опрашиваются по очереди из resolv.conf. Если первый не ответил — идем ко второму. Но если первый сказал, что записи нет (именно ответил «фигвам», а не отвалился по таймауту), то дальше опрос не проводится.
  • 0
    ValdikSS правильно ли я понимаю, что на примере OpenVPN директива конфига:

    push "redirect-gateway def1 bypass-dhcp"

    тоже не решает проблему? И даже при добавлении принудительного:

    push "route 0.0.0.0 0.0.0.0"

    разумеется, что:

    push "dhcp-option DNS xxx"

    должен быть добавлен.

    проблема останется? То есть верно ли я понимаю, что суть бага в том, что резольвер напрямую привязывает адреса DNS к интерфейсам, при этом полностью игнорирует правила маршрутизации?
    • 0
      Упс, прочитал по диагонали пост, прошу прощения:
      Если вы используете OpenVPN, убедитесь, что он заменяет маршрут по умолчанию, а не добавляет два маршрута 0.0.0.0/1 и 128.0.0.0/1 (параметр redirect-gateway должен быть без def1), т.к. в этом случае Windows сможет привязать запрос к интерфейсу и успешно отправить его в незашифрованном виде.

      Ответ уже есть, ValdikSS благодарю.
      • 0
        Чья идея изначально — роутить только половину интернета? Вы вкурсе же, что 0.0.0.0/1 это не 0.0.0.0/0?
        • 0
          Почему половину-то? Добавляются два маршрута — 0.0.0.0/1 и 128.0.0.0/1, так что маршрутизируется весь интернет.
          • 0
            Ну да, но зачем два маршрута то добавлять? Я не про этот комментарий сейчас. Просто встречал много OpenVPN серверов и документаций где маршрут указывают 0.0.0.0/1, а потом страдают, что только половина работает.
            • 0
              Затем, что если в Windows добавить default route и удалить старый, то старый через какое-то время (во время следующего DHCP renew) опять появится, причем с метрикой ниже, и весь ваш трафик чудным образом пойдет не через VPN, а в обход. Больше причин, в общем-то, нет, наверное.

              И где вы такую документацию встречали, кстати? Обычно нигде не пишут добавлять маршруты вручную, а используют redirect-gateway def1, который как раз добавляет два маршрута.
    • +1
      Он не игнорирует правила маршрутизации, а делает bind к интерфейсу перед тем, как отправить запрос, поэтому если у вас есть маршрут через локальный интерфейс, который в обычной ситуации не используется (выше метрика, перекрывается более узкими сетями), то Windows сможет его использовать.
      Самое противное, что проблема проявляется на самой распространенной конфигурации: подключаемся к роутеру, роутер выдает DNS на свой IP-адрес, и из этого же диапазона нам выдается адрес по DHCP. Маршрут до DNS, естественно, никак не убрать, т.к адрес next hop и DNS совпадают.
  • +4
    >> было проблематично для злоумышленника, т.к. ОС бы использовала подмененный ответ только в том случае, если не удалось получить правильный ответ от предпочитаемого DNS-сервера
    Вот это раньше была безопасность т.е. стоит отвлечься основному DNS и на тебе дыра в безопасности. Если вы так беспокоитесь о безопасности, то у вас вообще не должны быть прописаны DNS, которым вы не доверяете.

    >> не может ответить в отведенный ему таймаут (1 секунда по умолчанию)
    2 секунды таймаут по умолчанию.

    >> Теперь ОС не только отправляет запрос через все интерфейсы, но и использует тот ответ, который быстрее пришел
    В описание к функции говорится, что если получено несколько ответов, то для определения ответа используется порядок сетевых привязок (network binding order).

    P.S. В групповых политиках настройка доступна здесь:
    Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn off smart multi-homed name resolution
    • 0
      2 секунды таймаут по умолчанию.
      Все же одна.
      If no response is received after 1 second, client queries the second DNS server of the list and at the same time queries again the first DNS server
      support.microsoft.com/en-us/kb/2834226

      В описание к функции говорится, что если получено несколько ответов, то для определения ответа используется порядок сетевых привязок (network binding order).
      Вот оно работает в Windows 8.1, но не работает в Windows 10, или у меня руки кривые.
      • 0
        >> Все же одна.
        Ох, ты. Там оказывается все много сложнее, чем казалось.

        >> но не работает в Windows 10, или у меня руки кривые.
        Описание взял из Windows 10.
      • 0
        Практически уверен, что это просто баг. Стоит попробовать зареквестить его, наверняка скажут, что поправят.
  • –1
    Наверное параноикам действительно есть за что переживать, а мне показалось что так даже лучше. Ведь раньше, когда было указано два DNS сервера и первый в ответ сообщал, что домен не существует, то второму запрос не отправлялся.

    И есть такие провайдеры, которые считают что нужно обязательно сделать свою доменную зону (доступную только из локальной сети и известную только DNS серверам провайдера), которые кроме того особо не заморачиваются с блокировками и фильтруют только по DNS, причём только на своих серверах. Соответственно для того, чтобы всё работало хорошо, первым DNS сервером указывается внешний (google public dns, например) сервер, а вторым уже DNS от провайдера. И если я правильно понимаю, то в десятке такая конфигурация будет работать корректно.
    • 0
      >Наверное параноикам действительно есть за что переживать, а мне показалось что так даже лучше. Ведь раньше, когда было указано два DNS сервера и первый в ответ сообщал, что домен не существует, то второму запрос не отправлялся.

      А чем сейчас лучше?
      Отправилось на все известные днс, самый быстрый ответил, что сайта нет и на другие запрос не отправляется ;)
      • 0
        Если это действительно так, то обидно, ибо других плюсов в данной фишке я не вижу.
  • –3
    Извиняюсь за оффтоп, но у меня вопрос:

    Обновил недавно Wireshark, и он перестал у меня сохранять последний фильтр захвата (Capture Filter), каждый раз сбрасывая его. Знатоки, не знаете, в чем может быть дело? На старой версии последний фильтр сам сохранялся как последний, без всяких пресетов и прочего. Дико бесит уже…
  • 0
    Не очень понимаю суть проблемы. Хотите гарантировать, что трафик DNS не уйдет никуда, кроме сервера, прописанного на туннельном интерфейсе — вместе с поднятием туннеля включайте на файрволе соответствующие правила (как вариант — временно убивайте DNS с других интерфейсов).
    • 0
      Я хотел предупредить людей о таком новом поведении. Если раньше утечки DNS случались относительно редко и в ожидаемых ситуациях, то сейчас они не только происходят постоянно, но и гарантированно позволяют злоумышленнику подменить ответ.
  • 0
    Добрый день!
    Хочу уточнить, вы на каком интерфейсе (-ах) собирали дамп пакетов?
    Только на стороне самого клиента?
    (само собой, надеюсь, при поднятом VPN-тоннеле?)

    Из поста не ясны условия тестирования и выявления данной фичи.
    Теме не менее, спасибо за информацию!
    • 0
      На стороне самого клиента, на обоих интерфейсах (Ethernet и VPN) сразу.
    • 0
      Но, вообще, это стало очевидно сразу — провайдер подменяет A-записи и перенаправляет на свою заглушку, которая не уходила даже при включенном VPN, хотя на предыдущих версиях Windows работало.
  • 0
    Теперь, кстати, другая проблема: Windows каждый раз добавляет default route от DHCP при обновлении lease, даже если OpenVPN его убирает, а метрика у него, как правило, ниже, и весь трафик через какое-то время начинает идти в обход VPN, так что мою рекомендацию по использованию redirect-gateway без def1 не нужно слушать, пост обновлен.
  • 0
    Проверил. Windows 10 Enterprise, свежеустановленная в виртуалке. 2 сетевых интерфейса, на каждом по паре разных DNS.

    По умолчанию — действительно, параллельная отправка запросов с обоих интерфейсов.
    Включил групповую политику Network\DNS Client\Turn off smart multi-homed name resolution (не забыть gpupdate и перезапуск службы dns client) — посылает только с одного.

    P.S.
    Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient] "DisableSmartNameResolution"=dword:00000001

    P.P.S. Для любителей хитрых настроек есть ещё NRPT.
    • 0
      Эх, к сожалению, я делал то же самое на Windows 10 Pro и Enterprise. У меня не отключается эта функция, хотя те же действия в Windows 8.1 приводят к отключению. Может, вы что-то еще дополнительно делаете, о чем умалчиваете, и о чем я не знаю в силу неиспользования Windows?
      • 0
        Вот же блин забавно — теперь у меня после всяких экспериментов с настройками тоже не работает. :( Ладно, будем копать…
        • 0
          Вероятнее всего это баг. В 10 уже много подобного нашли, гейзенбажье какое то. У меня вообще до сих пор SRP криво работает на релизе 10, в причинах пока так разобраться и не удалось.
  • 0
    Столкнулся с аналогичной проблемой сегодня на Windows 10…

    Не появилось ли нормального решения как отличить эту «умную» работу с DNS?

    Вообще это все выглядит очень забавно — неужели в Microsoft считают, что если клиент поднимает туннель, то он хочет, чтобы хоть какие-то данные ходили мимо него?? Что за бред вообще, в голове не укладывается.
    • 0
      Один добрый человек мне написал следующее на почту, но с OpenVPN это не работает:
      Add-VpnConnection -Name myvpn -ServerAddress "vpn.myorg.com" -PassThru
      Set-VpnConnection -Name myvpn -TunnelType pptp -AuthenticationMethod MSChapv2 -EncryptionLevel Required -RememberCredential $true -SplitTunneling $true -DnsSuffix "myorg.local" -PassThru
      Add-VpnConnectionRoute -ConnectionName myvpn -DestinationPrefix 10.100.0.0/16 -PassThru
      Get-VpnConnectionTrigger -ConnectionName myvpn | fl
      
      
      Add-VpnConnectionTriggerDnsConfiguration -ConnectionName myvpn -DnsSuffix myorg.local -PassThru
      #тут powershell ругается с ошибкой, я повторяю команду и она выполняется (внезапно)
      Set-VpnConnectionTriggerDnsConfiguration -ConnectionName myvpn -DnsSuffix myorg.local -DnsIPAddress 10.100.0.1, 10.100.0.2 -PassThru -Force
      Set-VpnConnectionTriggerDnsConfiguration -ConnectionName myvpn -DnsSuffixSearchList myorg.local -PassThru
      Add-VpnConnectionTriggerTrustedNetwork -ConnectionName myvpn -DnsSuffix myorg.local -PassThru
      Add-VpnConnectionTriggerApplication -ConnectionName myvpn -ApplicationID "%windir%\system32\mstsc.exe" -PassThru
      • 0
        Как в OpenVPN feature request делаются? :) Всего-то нужно запилить интегрированный vpn-провайдер для win8/win10.
        • 0
          О, а там плагинная система есть? Тогда конечно, это нужная фича. Нужно создать feature request на багтрекере, лучше с каким-нибудь денежным вознаграждением.
    • 0
      Вообще это все выглядит очень забавно — неужели в Microsoft считают, что если клиент поднимает туннель, то он хочет, чтобы хоть какие-то данные ходили мимо него??


      В Microsoft как раз по умолчанию считают ровно наоборот — если клиент поднимает туннель, все данные идут туда. При условии, разумеется, если вы используете интегрированный в винду клиент (причем в теории там могут быть VPN-провайдеры от разных вендоров, под восьмерку они и были, под десятку, вероятно, надо ставить из маркетплейса), ибо о поведении стороннего софта MS заботиться не может. Все грабли начинаются только тогда, когда вы хотите использовать split tunneling.
      • 0
        Это не проверенные сведения. При использовании встроенного клиента DNS запрос внутрь сети проходит только в начале подключения, спустя время начинается гонка, которая в большинстве случае приводит к тому, что либо внутри туннеля не хватает 1 секунды на возврат имени, либо ответ с другого интерфейса приходит быстрее. Поэтому в целом, проблема как есть, так и осталась и пользоваться этим нормально невозможно.
  • 0

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