Системе windows не удается найти имя узла с помощью dns

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

К такой ошибке могут привести проблемы со стороны интернет-провайдера или неверные настройки локальной сети. В статье мы расскажем, что делать в первую очередь, если вы столкнулись с ошибкой, и как исправить проблему отсутствия подключения. Инструкции в статье были созданы под Windows 10, но подойдут и для других версий операционной системы от Microsoft.

Не удается найти DNS-адрес сайта: что это?

DNS (Domain Name System) — система доменных имён, которая преобразует доменное имя в IP-адрес сервера, на котором находится сайт. Подробнее о принципах работы читайте в статье Что такое DNS простыми словами.

Информация о том, какой IP-адрес принадлежит конкретному доменному имени, хранится на DNS-сервере. Когда вы открываете сайт по доменному имени, браузер узнает IP-адрес сайта у DNS-сервера. Если сервер недоступен или работает неправильно, браузер не сможет узнать IP-адрес и открыть сайт. Вместо него вы увидите ошибку «Не удалось открыть эту страницу» или другую с похожим содержимым.

При ошибке «Не удается получить доступ к сайту» в панели задач на значке подключения будет отображаться уведомление в виде треугольника с восклицательным знаком внутри. При этом в браузере возникнет ошибка «Не удается найти DNS-адрес сайта» или «Не удалось найти IP-адрес сервера». Текст ошибки зависит от браузера. Пример ошибки в Chrome:

Почему появляется ошибка

Источник проблемы может находиться как на стороне сервера (провайдера), так и на стороне браузера (пользователя). Причины неполадок могут быть следующими:

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

Чтобы точно определить источник, в первую очередь продиагностируйте локальное устройство. Внесите корректировки в настройки с помощью инструкций ниже, а затем повторите подключение. Если это не поможет, значит проблема возникла на стороне провайдера.

Автоматическая диагностика неполадок

Для начала запустите диагностику неполадок. Для этого в панели задач кликните правой кнопкой мыши на значок Сеть и нажмите на Диагностика неполадок. Windows попытается исправить ошибки автоматически. На экране вы увидите результат диагностики:

Обнаруженные проблемы при диагностике

Если Windows не исправил ошибку автоматически, попробуйте действия ниже.

Перезагрузите компьютер и роутер

Перезагрузите ваш компьютер и роутер. В некоторых случаях это поможет. Чтобы выключить роутер, нажмите на соответствующую кнопку на задней панели. Не перепутайте с кнопкой сброса настроек, так как сбрасывать настройки до заводских не нужно. Если кнопка питания отсутствует, обесточьте роутер на 30-60 секунд, а затем снова включите.

Подключитесь к той же сети при помощи другого устройства и проверьте работу интернета. Если на нём тоже нет связи с ДНС сервером, значит проблема в настройках роутера или вовсе у интернет-провайдера.

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

ipconfig/flushdns

Готово, вы сбросили кэш. На экране вы увидите сообщение:

Укажите альтернативные DNS от Google

Если перезагрузка не помогла, поменяйте DNS-серверы, с которых ваш компьютер запрашивает информацию о соответствии доменного имени и IP-адреса. При стандартных настройках DNS-серверы предоставляет интернет-провайдер. Серверы провайдера могут быть недоступны из-за аварии или технических работ. В качестве альтернативы пропишите Google Public DNS, которые отличаются высокой надежностью и повышенной частотой обновления кэша. Пошаговая инструкция:

Проверьте работу службы DNS-клиент

Проверьте работу службы DNS-клиент — она должна быть запущена:

Отключите антивирус

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

Если вы уверены, что проблема подключения возникает из-за антивируса, проверьте его настройки. Во многих программах есть управление межсетевым экраном. В Avast это Брандмауэр, а в Kaspersky – Веб-контроль. Попробуйте отключить межсетевой экран или включить стандартные настройки доступа. Если у вас возникают сложности, найдите инструкцию на сайте вашего разработчика или на тематических форумах.

Проверьте настройки роутера

Перейдите к управлению маршрутизатором через браузер. Для этого введите IP-адрес админки в адресную строку:

• 192.168.0.1 или 192.168.1.1 — подойдёт для большинства маршрутизаторов,
• 192.168.31.1 — для маршрутизаторов Xiaomi.

При переходе на правильный IP откроется страница с авторизацией. Логин и пароль обычно есть на самом роутере или в договоре с провайдером.

В настройках найдите раздел Интернет или WAN и сверьте настройки подключения с теми, которые предоставил провайдер. Если эти настройки вам неизвестны, позвоните на горячую линию интернет-провайдера и попросите помощи с настройкой роутера.

Если вам помогли альтернативные DNS, а у вас несколько устройств, пропишите эти DNS в настройках роутера:

Все устройства, которые к нему подключены, будут автоматически использовать альтернативные серверы.

Заключение

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

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

Проблемы с разрешением имен и подключением на сервере маршрутов и удаленного доступа, который также выполняет DNS или WINS

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

Применяется к: Windows Server 2012 R2, Windows Server 2016
Исходный номер КБ: 292822

Симптомы

Компьютер под управлением Microsoft Windows 2000 Server или Microsoft Windows Server 2003 может иметь проблемы с подключением, если сервер настроен следующим образом:

После подключения удаленного компьютера к серверу маршрутов и удаленного доступа с помощью подключения к виртуальной частной сети (VPN) может возникать один или несколько следующих симптомов:

Если на сервере маршрутиза и удаленного доступа также работает сервер Microsoft Internet Security and Acceleration (ISA) Server 2000, вы не можете просматривать веб-страницы с клиентских компьютеров в локальной сети независимо от того, настроены ли компьютеры на использование веб-прокси или клиент межсетевого экрана (Майкрософт). Например, «Страница не может отображаться» может отображаться в веб-браузере с сообщением об ошибке «не удается найти сервер или DNS».

Если на сервере маршрутиза и удаленного доступа работает ISA Server 2000, а пользователь на клиентской компьютере выбирает обновление теперь в диалоговом окне Параметры брандмауэра, пользователь получает следующее сообщение об ошибке:

Сервер не отвечает, когда клиент запрашивает обновление.
Возможные причины:
-Сервер не является сервером ISA.
-Сервер не съехался.

При попытке с помощью сервера маршрутизов и удаленного доступа с локального компьютера с помощью имени NetBIOS сервера или полностью квалифицированного доменного имени (FQDN) компьютер пытается цитировать неправильный IP-адрес.

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

Вы не можете подключиться кhttp:// server_name/myconsole
веб-сайт на компьютере Small Business Server 2000.

На сервере маршрутов и удаленного доступа вы получаете сообщение о событии, аналогичное следующему:

Вы получаете сообщения об ошибках при попытке открыть файлы или сетевые диски на сервер маршрутивке и удаленном доступе.

Если сервер маршрутирования и удаленного доступа также является контроллером домена, при попытке войти в сеть вы получите сообщения об ошибках.

Если сервер маршрутирования и удаленного доступа является контроллером домена, вы получаете сообщения об ошибках при попытке открыть общие файлы или сетевые диски на любой общий ресурс в сети. Например, компьютеры с microsoft Windows 2000 Professional или Microsoft Windows XP Professional получают сообщение об ошибке, аналогичное следующему:

Нет серверов Logon, доступных для обслуживания вашего запроса logon

Эта проблема обычно затрагивает компьютеры с сервером малого бизнеса, так как эта версия Windows Server часто является единственным сервером в сети. Однако эта проблема может затронуть Windows 2000-сервер или любой сервер на Windows Server 2003 и сервер удаленного доступа, работающий с DNS или службой WINS.

Причина

Когда удаленный компьютер подключается к серверу маршрутного и удаленного доступа с помощью набора или VPN-подключения, сервер создает адаптер протокола точки к точке для связи с удаленным компьютером. Затем сервер может зарегистрировать IP-адрес этого адаптера PPP в DNS или базе данных WINS.

Когда сервер маршрутивки и удаленного доступа регистрирует IP-адрес своего адаптера PPP в DNS или WINS, при попытке подключения к серверу на локальных компьютерах могут возникнуть ошибки. Вы получаете эти ошибки, так как серверы DNS или WINS могут возвращать IP-адрес адаптеров PPP на компьютеры, запрашивающий DNS или WINS для IP-адреса сервера. Затем компьютеры пытаются подключиться к IP-адресу адаптеров PPP. Из-за того, что локальные компьютеры не могут достичь адаптеров PPP, подключение не удается.

Решение

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

Чтобы устранить эту проблему, настройте сервер маршрутов и удаленного доступа, чтобы он не зарегистрировал IP-адрес адаптеров PPP в DNS или базе данных WINS. Для этого выполните следующие действия:

Настройка сервера маршрутов и удаленного доступа для публикации только IP-адреса локального сетевого адаптера в DNS

Выполните действия в этом разделе только в том случае, если на сервере маршрутики и удаленного доступа работает служба DNS. Если на сервере не работает служба DNS, перейдите к серверу Настройка маршрутного и удаленного доступа, чтобы зарегистрировать только IP-адрес локального сетевого адаптера в разделе WINS.

Добавление значений реестра PublishAddresses и RegisterDnsARecords для служб DNS и Netlogon

Выберите Начните, выберите Выполнить, введите regedit, а затем выберите ОК.

Найдите и выберите следующий подкай реестра: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSParameters

В меню Редактирование указать значение New, а затем выберите строковую ценность, чтобы добавить следующее значение реестра:

Имя значения: PublishAddresses
Тип данных: REG_SZ
Данные о значении: IP-адрес локального сетевого адаптера сервера. Если необходимо указать несколько IP-адресов, разделять адреса с пробелами.

Найдите и выберите следующий подкай реестра: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters

В меню Редактирование указать значение New, а затем выберите значение DWORD, чтобы добавить следующее значение реестра:

Имя значения: RegisterDnsARecords
Тип данных: REG_DWORD
Данные значения: 0

Закрой редактор реестра, а затем перезапустите службы DNS и Netlogon. Чтобы перезапустить службу, выберите Пуск, указать на программы или все программы, указать на административные средства, а затем выбрать службы. В консоли Services щелкните правой кнопкой мыши службу и выберите перезапуск.

Добавление записей A в DNS

Выполните эти действия только в том случае, если сервер маршрутивки и удаленного доступа является контроллером домена.

Выберите Начните, указать на программы или все программы, указать на административные средства, а затем выберите DNS.

В консоли DNS раздвигаем объект сервера, расширяем папку Зоны смотра вперед, а затем выберите папку для локального домена.

В меню Действия выберите Новый хост.

В текстовом поле IP-адреса введите IP-адрес локального сетевого адаптера сервера.

Оставьте поле Имя пустым, выберите Создать связанную запись PTR, а затем выберите Add Host.

Когда вы получаете «(так же, как родительская папка) не является допустимым имя хоста. Вы уверены, что хотите добавить эту запись? сообщение, выберите Да.

Если сервер является глобальным сервером каталогов, перейдите к шагу 7. Если сервер не является глобальным сервером каталогов, вам не нужно выполнить действия с 7 по 11. Чтобы определить, является ли сервер глобальным сервером каталогов, выполните следующие действия:

В папке Зоны forward Lookup в консоли DNS разложите папку для локального домена, разложите папку MSDCS и выберите папку GC.

В меню Действия выберите Новый хост.

В поле IP-адрес введите IP-адрес локального сетевого адаптера сервера.

Оставьте поле Имя пустым, выберите Создать связанную запись PTR, а затем выберите Add Host.

Когда вы получаете «(так же, как родительская папка) не является допустимым имя хоста. Вы уверены, что хотите добавить эту запись? сообщение, выберите Да.

Настройка сервера маршрутов и удаленного доступа для регистрации только IP-адреса локального сетевого адаптера в WINS

Выполните действия в этом разделе только в том случае, если на сервере маршрутов и удаленного доступа работает служба WINS. Кроме того, если на сервере работает сервер малого бизнеса 2000 SP1, сервер малого бизнеса 2000 SP1a или Windows Small Business Server 2003, вам не нужно завершать действия в этом разделе. По умолчанию эти версии сервера Windows настраиваются, чтобы предотвратить регистрацию IP-адреса адаптеров PPP в базе данных WINS.

Добавление значения реестра DisableNetbiosOverTcpip для службы маршрутизации и удаленного доступа

Значение реестра DisableNetbiosOverTcpip отключает протокол NetBIOS по TCP/IP (NetBT) для подключений к удаленному доступу. Таким образом, сервер не будет регистрировать адаптер PPP в базе данных WINS. Знайте, что при добавлении этого значения клиенты удаленного доступа не могут просматривать локализованную сеть через «Мои сетевые места» или «Сетевое соседство». Иногда это также может привести к неудаче подключения к удаленному доступу на компьютерах с более старыми версиями Windows. Например, подключение к удаленному доступу может быть неудачным на 98 компьютерах Microsoft Windows и на компьютерах microsoft Windows NT 4.0 Workstation. Альтернативу использованию реестра DisableNetbiosOverTcpip см. в разделе Обходное решение.

Если сервер работает Windows 2000 Server SP2 или более ранней версии, необходимо обновить сервер с помощью SP3 или SP4, чтобы значение реестра DisableNetbiosOverTcpip работало. Если не обновить сервер, служба маршрутинга и удаленного доступа не будет использовать это значение реестра, и проблема не будет устранена.

Выберите Начните, выберите Выполнить, введите regedit, а затем выберите ОК.

Найдите и выберите следующий подкай реестра: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesRemoteAccessParametersIP

В меню Редактирование указать значение New, а затем выберите значение DWORD, чтобы добавить следующее значение реестра:

Имя значения: DisableNetbiosOverTcpip
Тип данных: REG_DWORD
Данные значения: 1

Закрой редактор реестра, а затем перезапустите службу маршрутов и удаленного доступа. Чтобы перезапустить службу, выберите Пуск, указать на программы или все программы, указать на административные средства, а затем выбрать службы. В консоли Services щелкните правой кнопкой мыши службу и выберите перезапуск.

Очистка базы данных WINS

Обходной путь

В качестве обхода этой проблемы можно настроить подключения удаленного доступа к статическому пулу IP-адресов, который находится на другой подсети IP, чем на локальных компьютерах. В этом случае локальные компьютеры не будут пытаться подключиться к адаптеру PPP, если он регистрируется в DNS или WINS, так как адаптер PPP находится на другой подсети IP.

Чтобы указать статичный пул адресов в консоли маршрутизировать и удаленный доступ, щелкните правой кнопкой мыши ServerName, выберите Свойства, выберите вкладку IP, выберите пул статических адресов, а затем выберите Добавить. Добавьте диапазон, который не использует ту же подсеть IP, что и локальные компьютеры. Например, если локальные компьютеры используют подсеть 10.0.0.0, добавьте статический пул, использующий подсеть 172.168.0.0. Если на сервере маршрутизации и удаленного доступа работает ISA Server 2000, необходимо добавить эту подсеть в локализованную адресную таблицу. Этот сценарий наиболее распространен в small Business Server 2000.

Источник

История отношений Сони и Тоши, или не найден сетевой путь

Герои романа 2 ноутбука,
А)Sony Vaio SVE1512F1RW (далее Соня)
Б)TOSHIBA Satelite C860 (далее Тоша)

Соня была куплена сразу с Windows 8 Pro (OEM), которую в последствии обновили до 8.1
На Тоше тоже Win 8, которая тоже как-бы ОЕМ, вот только до 8.1 не обновляли.

Их подключили к WI-FI роутеру TP-LINK TD-W8961ND

И у Тоши и у Сони есть расшаренные папки:
Соня:

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

А вот у Тоши так невыходит. Хотя пинг он проводит прекрасно:

И видит Соню в сетевом окружении, но, как я уже говорил, зайти в неё не может, по причине «Не найдет сетевой путь». Что-то там у него не запускается, из-за чего теряется первый пакет у сони. Но кто знает, что это?

Подробнее об их отношениях, для тех кто может и хочет помочь, я расскажу ниже:
Домашнюю группу они не создавали (гражданский брак), так что связывает их только протокол TCP/IPv4 (TCP/IPv6 отключен)

Вот что они говорят нам об ipсonfig /all (ничего не вырезано и не перекодировано):
Соня:

Но возможно все дело в сервисах? Тут я могу сказать только то, что «Модуль поддержки NetBois через TCP/IP», или просто imhosts включен и выполняется у обоих. Об остальном судите сами, я прикрепил информацию о состоянии сервисов Сони (Sony_serv) и Тоши (Tosha_serv).

Я буду продолжать самостоятельно пытаться решить проблему, и буду писать сюда о результатах дальнейших попыток. Но и на вашу помощь я тоже очень рассчитываю!

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Вложения

Не найден сетевой путь
В сетке стоит машина на WIN XP SP3 там стоял прокси сервер, после выключения света на машине всё.

не найден сетевой путь
вин 7 на обоих компах оба пингуются брандмауэр отключен рабочая группа одинакова по вводу ай пи.

Не найден сетевой путь
Программа выводит список каталогов на удаленных компьютерах в сети. Имя компьютера берется из.

Кстати, сервис IKEEXT описывается вот как:
I

Psec IKE and AuthIP Service
Updated: January 9, 2008
Applies To: Windows Server 2008
The IKE and AuthIP IPsec Keying Modules (IKEEXT) service implements the Internet Key Exchange (IKE) and Authenticated Internet
Protocol (AuthIP) protocols. These keying modules support the authentication and key exchange features required by Internet Protocol security (IPsec).
Aspects

The following is a list of all aspects that are part of this managed entity:
Name Description IKE and AuthIP Service Initialization
The IKE and AuthIP IPsec Keying Modules (IKEEXT) service must be running for Internet Protocol security (IPsec) to provide authentication and encryption services. This service implements the Internet Key Exchange (IKE) and Authenticated Internet Protocol (AuthIP) protocols. These keying modules support the authentication and key exchange features required by Internet Protocol security (IPsec).
When appropriate auditing events are enabled (Enable IPsec and Windows Firewall Audit Events), Windows reports successes and failures in starting the service, or when the service stops operating due to a failure.

Источник

Windows может связаться с сервером разрешения имен но не удается найти имя узла

Этот форум закрыт. Спасибо за участие!

Лучший отвечающий

Вопрос

Система Windows 7 Домашняя расширенная x64. После удаления вируса не работает разрешение имен, т.е. по IP адресу сайты открываются, по имени нет. Например выполним команду ipconfig /displaydns:

Однако в кэше запись www.ru появилась:

1. netsh int ip reset и netsh winsock reset

2. Переустановка протокола TCP/IP

3. Переустановка драйверов сетевых адаптеров

Кстати, localhost тоже не пингуется. Пингуется 127.0.01

Вопрос: на каком этапе не работает разрешение имен?

Ответы

Аллилуйа! Лыжи действительно не ехали.

Воробей был успешно пристрелен из рогатки, описанной добрым человеком APuh здесь: http://forum.oszone.net/thread-178627-2.html

Моя ошибка была в том что я переустанавливал только протокол TCP/IP 4, а надо было вместе с 6 все грохать. После выполнения всех действий, описанных APuh, включая правку реестра, все заработало.

Все ответы

gpedit.msc наст.комп.>адм.шаблоны>сеть>dns клиент там все по умолчанию?

Хотя «редактор локальной групповой политики отсутствует в «домашних» редакциях Windows 7, а именно Начальная, Домашняя базовая и Домашняя расширенная», но кого это останавливало? 😉

Скриншот не удалось прикрепить, на что обратить внимание?

Вроде как все стандартно. все пункты «Not configured»

С AVZ тоже пробовал, именно этот совет по ссылке, забыл про это написать

sfc /scannow от админа в кмд выполните

Посмотрел в Network Monitor какой трафик ходит. Оказалось DNS запросы прекрасно уходят и возвращаются. Программы которые напрямую обращаются к DNS серверам работают, например прекрасно себя чувствует Skype. Кроме того, видно как при выполнении ping уходит запрос на DNS сервер от DNS-клиента и приходит ответ, только вот ping эту информацию не получает.

sfc /scannow пишет что некоторые файлы не смог восстановить.

На 10.10.10.20 как с днс?

nslookup что говорит?

Да 10.10.10.20 как днс и как шлюз, это Windows 8.1 с расшаренным сетевым соединением, я думаю это роли не играет. Как DNS прописывал и 8.8.8.8, не помогает.

nslookup говорит что все нормально:

В тоже время ping говорит что все плохо:

С модемом Yota тоже самое.

Кстати, не работал DHCP клиент, пришлось восстанавливать. Может какая-то служба отвечает за передачу данных DNS программам? И она тоже не работает?

Работают только программы, которые не пользуются этой службой.

sfc /scannow пишет что некоторые файлы не смог восстановить.

Выполните sfc еще два-три раза, возможно восстановит!

После этого выложите cbs.log

Еще, попробуйте следующее:

Посмотрел в Network Monitor какой трафик ходит. Оказалось DNS запросы прекрасно уходят и возвращаются. Программы которые напрямую обращаются к DNS серверам работают, например прекрасно себя чувствует Skype. Кроме того, видно как при выполнении ping уходит запрос на DNS сервер от DNS-клиента и приходит ответ, только вот ping эту информацию не получает.

sfc /scannow пишет что некоторые файлы не смог восстановить.

попробуйте sfc после этих действий

Хочется все-таки разобраться что в Windows 7 отвечает за разрешение имен (где находятся настройки). Ведь если на нормальной системе отключить DNS-клиент, имена все-равно разрешаются, тот же ping прекрасно себе работает.

Источник

Устранение неполадок в пространстве имен распределенной файловой системы в Windows

В этой статье предоставляется решение для решения проблем с ошибками доступа к распределенной файловой системе (DFSN).

Применяется к: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ: 975440

Симптомы

На компьютере, который Windows XP или Window Server 2003, при попытке доступа к DFSN вы получаете следующее сообщение об ошибке:

\ недоступны. Возможно, у вас нет разрешения на использование этого сетевого ресурса. Обратитесь к администратору этого сервера, чтобы узнать, есть ли у вас разрешения на доступ.

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

В Windows Vista и более поздних версиях Windows вы можете получить одно из следующих сообщений об ошибке:

Windows не удается получить доступ\

Причина

Эта ошибка обычно возникает из-за того, что клиент DFSN не может завершить подключение к пути DFSN.

Подключение может привести к сбой по любой из следующих причин:

Решение

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

Подключение

В этой статье подключение относится к возможности клиента связаться с контроллером домена или сервером DFSN. Если клиент не может завершить сетевое подключение к контроллеру домена или серверу DFSN, запрос DFSN завершается сбой.

Для проверки подключения можно использовать следующие тесты.

Определите, удалось ли клиенту подключиться к контроллеру домена для получения сведений о домене с помощью DFSUtil.exe /spcinfo команды. Вывод этой команды описывает доверенные домены и их контроллеры домена, обнаруженные клиентом через запросы рефералов DFSN. Это называется кэш домена.

В следующем примере клиент обнаруживает доменное имя DNS и доменное имя contoso.com NetBIOS CONTOSO. Для доменного имени CONTOSO были определены два контроллера домена: 2003server2 и 2003server1. Если клиент получает доступ к имени DNS в запросе, записи contoso.com отображаются под contoso.com записью.

Записи, отмеченные звездочкой (*), были получены через службу Workstation. Остальные записи были получены через рефералы клиентом DFSN. Записи, отмеченные знаком плюс (+), являются контроллерами домена, которые в настоящее время используются клиентом. Дополнительные сведения о процессах рефералов см. в справочной ссылке How DFS Works.

Чтобы оценить возможность подключения, попробуйте простое сетевое подключение к активному контроллеру домена с помощью IP-адреса. Например, введите любой из следующих команд:

Успешное подключение перечисляет все акции, которые находятся в контроллере домена.

Если подключение успешно, определите, возвращается ли допустимая реферал DFSN клиенту после доступа к пространству имен. Это можно сделать, просмотрев кэш рефералов (также известный как кэш PKT) с помощью DFSUtil.exe /pktinfo команды.

Ниже приводится информация о ожидаемых записях в кэше рефералов клиента после того, как клиент получает доступ к пути DFSN. \contoso.comdfsrootlink Корень имеет две цели (rooterver1 и rooterver2). Ссылка имеет одну цель (fileserver).

Если вы не можете найти запись для нужного пространства имен, это свидетельствует о том, что контроллер домена не возвращал направление. Сбои службы DFSN обсуждаются позже в этой статье.

Если вы видите запись для пространства имен (то есть), запись доказывает, что клиент мог связаться с контроллером домена, но затем не достиг каких-либо целей пространства имен contoso.comdfsroot DFSN. Если ни один из перечисленных в списке объектов пространства имен не обозначен как ACTIVE, это означает, что все цели недоступны.

Попробуйте получить доступ к каждому серверу пространства имен с помощью IP-адресов. Для этого теста необходимо указать только IP-адрес сервера и не включать в него долю пространства имен (то есть, net view \192.168.1.11 но net view \192.168.1.11dfsroot не). В противном случае может быть непреднанно передан другой корневой сервер DFS. Если это произойдет, вы получите вводящие в заблуждение результаты. Обратите внимание на сообщения об ошибках, которые сообщаются во время этих действий.

Необходимо исследовать и устранять любые сбои контроллера домена или связи сервера пространства имен DFS. Дополнительные сведения о сетевых сведениях tCP/IP и устранении неполадок см. в технической справке TCP/IP.

Разрешение имен

Клиенты должны решить имя пространства имен DFS и всех серверов, на которые размещено пространство имен. Просмотрите выходные данные, ранее созданные dfsutil /pktinfo командами dfsutil /spcinfo и командами. Указанные имена серверов должны быть разрешены клиентом на IP-адреса.

Вы можете использовать следующие методы для проверки правильной функции разрешения имен.

ИМЕНА WINS и NetBIOS

Просмотрите следующие документы, чтобы устранить сбои WINS:

По умолчанию DFSN сохраняет имена NetBIOS для корневых серверов. DFSN также можно настроить для использования имен DNS для сред без серверов WINS. Дополнительные сведения см. в дополнительных сведениях о настройке DFS для использования полностью квалифицированных доменных имен в рефералах.

Вы можете просмотреть кэш разрешения DNS клиента для проверки разрешенных имен DNS. Для этого откройте командную подсказку и введите ipconfig /displaydns команду.

Рассмотрим приведенный ниже пример.

Windows Конфигурация IP

Просмотрите следующие документы, чтобы устранить ошибки DNS:

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

Дополнительные сведения о Microsoft Network Monitor 3 см. в дополнительных сведениях о сетевом мониторе 3.

Дополнительные сведения о сетевом трафике, который наблюдается между клиентом и средой DFS на основе домена, см. в руб. Как работает DFS.

Дополнительные сведения о DNS и WINS см. в дополнительных сведениях о технологиях разрешения имен.

DFS и конфигурация системы

Даже если подключение и разрешение имен работают правильно, проблемы с конфигурацией DFS могут привести к ошибке клиента. DFS использует данные конфигурации DFS, правильно настроенные параметры службы и конфигурацию сайта Active Directory.

Во-первых, убедитесь, что служба DFS запущена на всех контроллерах домена и на пространстве имен DFS/корневых серверах. Если служба запущена во всех расположениях, убедитесь, что ошибки, связанные с DFS, не сообщаются в журналах событий системы серверов.

Если администратор вносит изменения в пространство имен на основе домена, это изменение производится в мастере эмулятора контроллера основного домена (PDC). Контроллеры домена и корневые серверы DFS периодически опове- Если PDC недоступен или включен режим корневой масштабируемости, задержки репликации Active Directory и сбои могут помешать серверам выдавать правильные рефералы. Дополнительные сведения о режиме корневой масштабируемости см. в обзоре размера DFS Рекомендации.

Один из методов оценки состояния репликации — опрос состояния последней попытки репликации входящие для каждого контроллера домена. Для этого запустите команду repadmin.exe. Необходимый синтаксис для этой команды:

repadmin /showrepl * DN_of_domain

В этой команде * представлены все запрашиваемые контроллеры домена, а DN_of_domain — отличительное имя домена, например dc=contoso,dc=com.

Просмотрите состояние и время последней успешной репликации, чтобы убедиться, что изменения конфигурации DFSN достигли всех контроллеров домена. Необходимо изучить все сбои, которые сообщаются о входящие репликации в DC.

Проблемы конфигурации DFSN также могут препятствовать доступу к пространству имен. Одним из распространенных сценариев, в котором это происходит, является клиент, который принадлежит сайту, который не содержит имен или целей папки. Если пространство имен настроено для выдачи целевых адресов рефералов только на сайте клиента (вариант insite), DFSN не предоставит направление. Чтобы оценить, настроен ли insite параметр в пространстве имен, откройте командную подсказку и введите dfsutil /path:\contoso.comdfs /insite /display команду.

Кроме того, проблемы с конфигурацией сайтов Active Directory могут помешать серверам DFSN правильно определять клиентский сайт. Поэтому при настройке insite эти проблемы могут привести к сбоям в передаче. Служба DFSN передает клиента на сайт, анализируя исходный IP-адрес запроса клиента на направление. Служба DFS также передает каждый корневой целевой сервер на сайт, разрешая имя целевого сервера на IP-адрес. Чтобы оценить, может ли контроллер домена или корневой сервер DFS определить правильный сайт системы, запустите либо следующие команды локально на контроллерах домена и на сервере пространства имен DFS:

Источник

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

В статье разберем причины возникновения ошибки и опишем способы решения проблемы.

Что означает DNS-сервер недоступен

Если у вас есть проблемы с DNS, понимание того, как работают DNS-серверы, может помочь в устранении неполадок.

У сайта есть имя (домен) и номер (IP-адрес). Имя — это то, что пользователи вводят в браузере для доступа к сайту, например, nic.ru. К этому доменному имени привязан IP-адрес, который сообщает браузеру о местонахождении сайта. IP-адрес состоит из чисел, например, IP-адрес сайта RU-CENTER — 31.177.80.04.

Задача DNS-сервера — связать имя с номером. При вводе домена сайта в поисковую строку браузер запрашивает у DNS-сервера его IP-адрес. DNS-сервер ищет совпадения между доменом и IP-адресом. Когда совпадение обнаружено, в браузере открывается запрашиваемый сайт. В блоге RU-CENTER есть подробная статья о том, что такое DNS.

Если DNS-сервер недоступен, браузер не может получить IP-адрес сайта, поэтому он выдает ошибку.

Почему браузеру не удается найти ip-адрес сервера

Причина возникновения ошибки, из-за которой не удается найти dns-адрес, может быть как на стороне провайдера, так и на стороне пользователя.

Среди причин возникновения ошибки выделяют:

• Сбой сетевых настроек роутера;
• Проблемы с оборудованием у провайдера;
• Технические работы у провайдера;
• Работа антивируса;
• Проблемы с компьютером у пользователя;
• Неполадки в работе браузера;
• Неверно прописаны DNS-серверы для домена на сайте.

Если проблема связана с антивирусом, браузером или роутером, вы можете решить ее без посторонней помощи. Если проблема связана с вашим интернет-провайдером или DNS-сервером, ее решение займет немного больше времени.

Диагностика сети в Windows

Проверить, есть ли проблемы с подключением к интернету, можно в Windows, запустив «Диагностику неполадок». Для этого найдите внизу панели задач значок «Сеть». Нажмите на него правой кнопкой мыши и выберете «Диагностика неполадок».

Будет запущена проверка, результат которой вы увидите в окне «Диагностика сетей Windows»:

Если после диагностики автоматически исправить ошибки не удалось, то стоит попробовать другие способы устранения ошибки. О них мы написали ниже.

Ошибка «DNS-сервер не отвечает»: как исправить

Если диагностика неполадок не помогла, а ошибка все еще наблюдается, то посмотрите следующие способы решить проблему:

Способ 1. Перезагрузите компьютер и роутер

Рекомендуем попробовать самые простые, но эффективные методы: перезагрузку компьютера и роутера. Возможно, эти действия дадут результат.

Для перезагрузки роутера найдите на задней панели устройства кнопку и нажмите ее. Подождите, пока все индикаторы выключатся, а затем включите роутер снова.

Если к Wi-Fi-сети подключено несколько устройств, то проверьте, работает ли интернет на этих устройствах. Можно попробовать отключить роутер и подключить сетевой кабель напрямую к компьютеру.

Способ 2. Временно отключите антивирус

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

Способ 3. Зайдите на сайт через другой браузер

Ошибка может возникать из-за самого браузера. Если вы используете Firefox, попробуйте использовать Яндекс.Браузер или Safari для доступа в интернет. Если проблема устранена с помощью другого браузера, возможно, вам нужно обновить версию того браузера, на котором появлялась ошибка.

Способ 4. Очистите кэш браузера

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

Способ 5. Очистите кэш DNS в Windows

Для этого вам нужно в строке поиска Windows ввести cmd и правой кнопкой мыши кликнуть по найденной программе, выбрав «Запуск от имени администратора».

В открывшимся окне нужно ввести по очереди команды:

• ipconfig /flushdns
• ipconfig /registerdns
• ipconfig /renew
• ipconfig /release

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

Способ 6. Перезапустите службу DNS-клиент в Windows

Вы можете попробовать перезапустить службу DNS-клиент. Для этого вам нужно нажать на клавиатуре клавиши Windows + R. В открывшимся окне введите services.msc и нажмите «ОК».

Появится окно «Службы». В списке вам нужно найти службу DNS-клиент, кликнуть правой кнопкой мыши и выбрать команду «Обновить».

После обновления службы DNS-клиент проверьте, появляется ли ошибка «DNS-сервер недоступен».

Также вы можете перейти в «Свойства» и проверить, корректно ли работает DNS-клиент Windows.

В «Типе запуска» должно стоять «Автоматически», а в «Состоянии» — «Работает». В этом случае параметры указаны верно.

Способ 7. Измените DNS-серверы вручную через настройки Windows

Если вы столкнулись с проблемой недоступности DNS, вы можете попробовать изменить DNS-серверы вручную. В качестве альтернативы можно использовать DNS-серверы Google. Подробная инструкция, как поменять DNS-серверы, представлена ниже.

В панели задач найдите значок «Сеть», кликнете правой кнопкой мыши и выберите «Центр управления сетями и общим доступом»:

Перейдите в «Изменение параметров адаптера»:

Правой кнопкой мыши нажимаем на активную сеть и выбираем «Свойства»:

В появившемся окне выделяем пункт «Протокол Интернета версии 4 (TCP/IPv4)» и нажимаем «Свойства»:

Выбираем пункт «Использовать следующие адреса DNS-серверов». Теперь введите:

Предпочитаемый DNS-сервер: 8.8.8.8

Альтернативный DNS-сервер: 8.8.4.4

После этого нажимаем «ОК».

Посмотрите, помогли ли изменения восстановить подключение к интернету.

Что делать, если не получилось исправить ошибку

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

Заключение

В статье разобрали, что значит ошибка «DNS-сервер не отвечает», что делать, если сайт не работает из-за этой ошибки. Мы показали различные способы решения этой проблемы. Надеемся, что они вам помогли.

При попытке загрузить файл, найденный в центре загрузок Microsoft, который начинается, например, с http://download.microsoft.com/download/6/8/7/(some_GUID)/(some_file_name.ext), я получаю тайм-аут с «Internet Explorer не может отобразить веб-страницу».

Больше информации говорит:

Интернет-соединение было потеряно.
Сайт временно недоступен. Сервер доменных имен (DNS) недоступен. Сервер доменных имен (DNS) не имеет списка для домена веб-сайта. Если это HTTPS (безопасный) адрес, нажмите «Сервис», выберите «Свойства обозревателя», нажмите «Дополнительно» и убедитесь, что в разделе «Безопасность» включены протоколы SSL и TLS.

Диагностика проблем с подключением говорит:

Windows не может найти имя хоста «download.microsoft.com», используя DNS

Терпите меня, пока я расширяю проблему: все началось, когда я пытался загрузить режим Windows XP для моей машины с Windows 7. Я пошел на сайт виртуального ПК, затем через Windows Genuine Advantage, который подтвердил, что все в порядке, но когда он перенаправляет, чтобы получить файл просто тайм-аут с вышеуказанной ошибкой.
(NB: я также пробовал использовать последние версии Chrome и Firefox, но без использования из-за материала Genuine Advantage, поэтому решил придерживаться IE).

Я за модемным маршрутизатором ADSL2+, подключающимся по беспроводной сети (ноутбук Win 7 Pro); поэтому я переключаюсь на рабочий стол, подключенный через Ethernet (Vista Business), и результат тот же; начинаю думать, что сайт download.microsoft.com не работает. Поэтому я делаю перерыв на чтение EDNS, очистку кеша, файла hosts и т.д.

Повторите попытку через час на машине с Win 7, но по-прежнему нет; поэтому я отключаю брандмауэр Win 7 (программное обеспечение), и вот, я могу подключиться и получить любые файлы с download.microsoft.com; (… хорошо, у нас есть межсетевой экран Micro $ 0ft, запрещающий доступ к веб-сайту Micro $ 0ft, не удивительно, что мои автообновления продолжали давать сбой, но это уже другая история).

Но я все еще не рад, что рабочий стол, подключенный через Ethernet, все еще не может попасть на download.microsoft.com, хотя я отключил все брандмауэры, защитников, антивирус и т.д. Что такого особенного / специфического в URL-адресе download.microsoft .com, любой другой сайт в порядке, включая www.microsoft.com.

Любой сетевой гуру знает, что ДЕЙСТВИТЕЛЬНО происходит, и как я могу подключить рабочий стол?

Ping download.microsoft.com -> Запрос Ping не может найти хост download.microsoft.com. Пожалуйста, проверьте имя и попробуйте снова.

Пинг google.com или даже www.microsoft.com работает дает мне IP-адрес.

NB: На беспроводном ноутбуке работает ping download.microsoft.com, я получаю xxxx.ms.akamai.net [202.7.177.33].

Windows не может получить доступ к компьютеру в локальной сети

При попытке подключиться с одного компьютера на Windows к другому, можно увидеть сообщение типа «Windows не может получить доступ к // *имя_компьютера*», который находится в локальной сети. Ошибка часто возникает на Windows 7 и 10, но может также появляться на 8 и других, менее популярных версиях системы.

Навигация по статье:

Виды проблемы и коды ошибок

Ошибка о проблемах подключения Windows к локальной сети иногда появляется на Windows 7 после установки одного из официальных пакетов обновлений системы. В конце окна в этом случае приводится код ошибки — 0×80070035. Чаще всего проблема банальна и вызвана неправильными настройками системы на компьютере (или на одном из компьютеров), из-за чего и возникают все проблемы с созданием локального подключения.

Сообщение с кодом ошибки может выглядеть по-разному:

1. Windows не может получить доступ к компьютеру в локальной сети Windows (7, 8, 10, XP).
2. Разрешение на доступ к «имя_компьютера» отсутствует. Обратитесь к сетевому администратору для получения доступа.
3. Windows не может получить доступ к компьютеру в сети (в локальной или домашней сети, к компьютеру, сетевому диску).
4. Windows не может получить доступ к компьютеру. Проверьте правильность написания данного имени.

Коды ошибок, которые могут появляться после сообщения: 0×80070035, 0x80004005, 0x8007004b, 0x800704b3. Осталось разобраться, что означает каждая ошибка и как избавиться от проблемы.

Ошибка 0×80070035 «Не найден сетевой путь»

Наиболее распространенная ошибка, говорящая о том, что Windows банально на нашла путь, по которому можно установить соединение. Для решения проблемы следует выполнить несколько простых инструкций.

Проверка настроек общего доступа:

1. Нажать правой кнопкой мыши по локальному диску, к которому не удается подключиться.
2. Выбрать пункт «Свойства», в открывшемся окне перейти на вкладку «Доступ».
3. Нажать «Расширенная настройка», поставить галочку около «Открыть общий доступ к этой папке».
4. Убедиться, что в поле «Имя общего ресурса» указан именно тот локальный диск, к которому требуется подключиться.

Если ошибка продолжает появляться, следует попробовать настроить cовместное использование IP-адреса компьютера. Это может помочь обойти ошибку и настроить подключение напрямую, используя IP-адрес ресурса.

Для этого требуется:

1. Нажать «Пуск», в поиске вбить cmd и найти командную строку.
2. Нажать правой кнопкой мыши по найденному приложению и запустить командную строку от имени администратора.
3. Ввести в поле командной строки «ipconfig /all» (без кавычек), нажать Enter.
4. В появившемся поле найти IPv4-адрес компьютера. Он выглядит типа 192.168.X.X.
5. Нажать сочетание клавиш Win+R.
6. В появившемся окне «Выполнить» ввести IP и локальный диск в формате //192.168.1.1/F (где F — имя локального диска).

Если опять ничего не получилось, и Windows все равно не удается установить соединение, имеет смысл проверить правильность работы диспетчера устройств.

Настройка работы диспетчера устройств:

1. Нажать сочетание клавиш Win+R.
2. Ввести в поле devmgmt.msc и нажать «ОК», чтобы войти в диспетчер устройств.
3. В открывшемся окне в верхнем меню нажать вкладку «Вид».
4. В выпадающем меню поставить галочку напротив пункта «Показать скрытые устройства».
5. В списке всех устройств найти и нажать на список «Сетевые адаптеры».

Появившийся список драйверов следует рассмотреть подробно. Устаревшие и неиспользуемые сетевые драйвера могут конфликтовать с новым ПО Windows, особенно после некоторых патчей безопасности. Для устранения проблемы подключения следует удалить все старые и неиспользуемые драйвера, а затем перезагрузить компьютер. Система должна автоматически установить новую версию ПО. Во избежание удаления нужных файлов, имеющиеся драйвера для отображаемых устройств можно обновить вручную.

Исправление ошибок с правами аккаунта

Иногда Windows не может получить доступ к другому компьютеру в локальной сети по вполне банальным причинам. Ошибки с кодами 0×80070035, 0x80004005, 0x8007004b, 0x800704b3 и иными уведомления вполне могут вызываться этими причинами, поэтому следует проверить их отсутствие.

1. Права доступа не установлены для пользователя, с которого выполняется попытка подключения. Следует убедиться, что у подключаемого пользователя есть права администратора. Аккаунт администратора должен быть добавлен в список разрешенных пользователей.
2. В диалоговом окне «Безопасность Windows» установлены разные пароли. Следует изучить инструкцию по созданию и раздаче локальной сети и исправить найденные ошибки.
3. Пользователь не является владельцем файлов и папок, которые пытается раздать в локальной сети.

Для того, чтобы стать владельцем папки или файла нужно:

1. Нажать на файле или папке правой кнопкой мыши.
2. Выбрать пункт «Свойства».
3. Перейти во вкладки «Безопасность» — «Дополнительно» — «Владелец».
4. Добавить нужную учетную запись в разрешения.

Помимо этого, нужно будет предоставить добавленной учетной записи полный доступ. Это делается во вкладке «Свойства» — «Безопасность» — «Изменить» — «Добавить». Только после этих действий нужно давать той или иной папке или файлам доступ в локальной сети. Ошибка должна исчезнуть, и Windows без проблем установит подключение.

Решение ошибки «Windows не может получить доступ к \имя ПК»

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

1. Нажать правой кнопкой мыши по папке.
2. Выбрать в подменю пункт «Общий доступ».
3. Перейти в раздел «Конкретные пользователи».
4. В появившемся окне нажать на треугольную стрелочку возле кнопки «Добавить» и выбрать того пользователя, для которого требуется предоставить доступ. Если пользователи в списке не отображаются, нужно выбрать пункт «Все».

Для добавленного пользователя можно установить уровень доступа: чтение или чтение и запись. После этого нужно нажать на кнопку «Общий доступ» и, если там не появляется никаких ошибок или уведомлений, нажать кнопку «Готово». Способ помогает на Windows 7 и более новых. В XP интерфейс может называться немного иначе, однако принцип исправления ошибок остается тот же.

3 thoughts on “ Windows не может получить доступ к компьютеру в локальной сети ”

Ничего не помогло. К слову еще нужно проверить все ли необходимые службы работают и не внесены ли изменения в Локальную политику безопасности. Пришлось создать пользователя и включить доступ по паролю. Win7 SP1 prof. К слову в сети еще 4 таких компа, на них все нормально.

Здравствуйте, спасибо за статью.
Я на даче использую свою собственную систему управления на основе RaspberryPi и вот такой способ удаленного доступа к ней — **ссылка на сторонний сайт — vpnki.ru**
Это тоже VPN, но не для доступа в Интернет, а для объединения моих устройств в единую сеть.
У меня это единственный вариант, потому что белого IP нет, а соединение снаружи закрыто провайдером, хотя ddns работает, но толку никакого.
Насчет скорости не проверял, но мою камеру нормально показывает на смартфоне. Удаленное управление тоже вполне быстро работает.
Вдруг кому-то поможет.

один компьютер коннектился к вай фаю через 5ггц, а второй через 2.4.
проблему решило подключение обоих компов на соединение 2.4
вот так по тупому))

Источник

История отношений Сони и Тоши, или не найден сетевой путь

Герои романа 2 ноутбука,
А)Sony Vaio SVE1512F1RW (далее Соня)
Б)TOSHIBA Satelite C860 (далее Тоша)

Соня была куплена сразу с Windows 8 Pro (OEM), которую в последствии обновили до 8.1
На Тоше тоже Win 8, которая тоже как-бы ОЕМ, вот только до 8.1 не обновляли.

Их подключили к WI-FI роутеру TP-LINK TD-W8961ND

И у Тоши и у Сони есть расшаренные папки:
Соня:

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

А вот у Тоши так невыходит. Хотя пинг он проводит прекрасно:

И видит Соню в сетевом окружении, но, как я уже говорил, зайти в неё не может, по причине «Не найдет сетевой путь». Что-то там у него не запускается, из-за чего теряется первый пакет у сони. Но кто знает, что это?

Подробнее об их отношениях, для тех кто может и хочет помочь, я расскажу ниже:
Домашнюю группу они не создавали (гражданский брак), так что связывает их только протокол TCP/IPv4 (TCP/IPv6 отключен)

Вот что они говорят нам об ipсonfig /all (ничего не вырезано и не перекодировано):
Соня:

К вопросу о возможных препятствиях:
Оба принимают антивирусы, Соня предпочитает 360TS, в Тоше хватает Windows Defender-а (Защитник Windows). Соня переставала принимать 360ый, но это не помогло.
Оба состоят в одной рабочей группе MSHOME, хотя тут есть одни интересный момент — У Сони, в её редакции винды 8.1 — отключена возможность работы в домене.

Но возможно все дело в сервисах? Тут я могу сказать только то, что «Модуль поддержки NetBois через TCP/IP», или просто imhosts включен и выполняется у обоих. Об остальном судите сами, я прикрепил информацию о состоянии сервисов Сони (Sony_serv) и Тоши (Tosha_serv).

Я буду продолжать самостоятельно пытаться решить проблему, и буду писать сюда о результатах дальнейших попыток. Но и на вашу помощь я тоже очень рассчитываю!

Вложения

Не найден сетевой путь
В сетке стоит машина на WIN XP SP3 там стоял прокси сервер, после выключения света на машине всё.

не найден сетевой путь
вин 7 на обоих компах оба пингуются брандмауэр отключен рабочая группа одинакова по вводу ай пи.

Не найден сетевой путь код ошибки 0x80070035
проблема возникла неизвестно когда есть камп есть модем dlink 2640 с wifi есть мобила с вайфай .

Не найден сетевой путь
Программа выводит список каталогов на удаленных компьютерах в сети. Имя компьютера берется из.

Всмысле пигнуется-ли?
—-
Спустя пару минут попробовал зайти с Тоши на Соню ещё раз (чтобы снова запустить средство диагностики) и, что странно, у меня запросили логин и пароль для входа! Я ввел логин и пароль, под которым захожу на Соню, и подключение совершилось, вижу папки Сони.
Но, какого черта? Посмотрел настройки Сони — парольная защита по прежнему отключена. Скажем так, проблему решили частично, каждый раз вводить логин и пароль вариант, но не лучший.

Кстати, сервис IKEEXT описывается вот как:
I

Psec IKE and AuthIP Service
Updated: January 9, 2008
Applies To: Windows Server 2008
The IKE and AuthIP IPsec Keying Modules (IKEEXT) service implements the Internet Key Exchange (IKE) and Authenticated Internet
Protocol (AuthIP) protocols. These keying modules support the authentication and key exchange features required by Internet Protocol security (IPsec).
Aspects

The following is a list of all aspects that are part of this managed entity:
Name Description IKE and AuthIP Service Initialization
The IKE and AuthIP IPsec Keying Modules (IKEEXT) service must be running for Internet Protocol security (IPsec) to provide authentication and encryption services. This service implements the Internet Key Exchange (IKE) and Authenticated Internet Protocol (AuthIP) protocols. These keying modules support the authentication and key exchange features required by Internet Protocol security (IPsec).
When appropriate auditing events are enabled (Enable IPsec and Windows Firewall Audit Events), Windows reports successes and failures in starting the service, or when the service stops operating due to a failure.

Источник

Windows может связаться с сервером разрешения имен но не удается найти имя узла

Вопрос

Система Windows 7 Домашняя расширенная x64. После удаления вируса не работает разрешение имен, т.е. по IP адресу сайты открываются, по имени нет. Например выполним команду ipconfig /displaydns:

Однако в кэше запись www.ru появилась:

1. netsh int ip reset и netsh winsock reset

2. Переустановка протокола TCP/IP

3. Переустановка драйверов сетевых адаптеров

Кстати, localhost тоже не пингуется. Пингуется 127.0.01

Вопрос: на каком этапе не работает разрешение имен?

Ответы

Аллилуйа! Лыжи действительно не ехали.

Воробей был успешно пристрелен из рогатки, описанной добрым человеком APuh здесь: http://forum.oszone.net/thread-178627-2.html

Моя ошибка была в том что я переустанавливал только протокол TCP/IP 4, а надо было вместе с 6 все грохать. После выполнения всех действий, описанных APuh, включая правку реестра, все заработало.

• Предложено в качестве ответа Dmitriy Vereshchak Microsoft contingent staff, Moderator 11 июня 2014 г. 8:12
• Помечено в качестве ответа Dmitriy Vereshchak Microsoft contingent staff, Moderator 11 июня 2014 г. 8:12

Все ответы

gpedit.msc наст.комп.>адм.шаблоны>сеть>dns клиент там все по умолчанию?

Хотя «редактор локальной групповой политики отсутствует в «домашних» редакциях Windows 7, а именно Начальная, Домашняя базовая и Домашняя расширенная», но кого это останавливало? 😉

Скриншот не удалось прикрепить, на что обратить внимание?

Вроде как все стандартно. все пункты «Not configured»

С AVZ тоже пробовал, именно этот совет по ссылке, забыл про это написать

sfc /scannow от админа в кмд выполните

Посмотрел в Network Monitor какой трафик ходит. Оказалось DNS запросы прекрасно уходят и возвращаются. Программы которые напрямую обращаются к DNS серверам работают, например прекрасно себя чувствует Skype. Кроме того, видно как при выполнении ping уходит запрос на DNS сервер от DNS-клиента и приходит ответ, только вот ping эту информацию не получает.

sfc /scannow пишет что некоторые файлы не смог восстановить.

На 10.10.10.20 как с днс?

nslookup что говорит?

Да 10.10.10.20 как днс и как шлюз, это Windows 8.1 с расшаренным сетевым соединением, я думаю это роли не играет. Как DNS прописывал и 8.8.8.8, не помогает.

nslookup говорит что все нормально:

В тоже время ping говорит что все плохо:

С модемом Yota тоже самое.

Кстати, не работал DHCP клиент, пришлось восстанавливать. Может какая-то служба отвечает за передачу данных DNS программам? И она тоже не работает?

Работают только программы, которые не пользуются этой службой.

sfc /scannow пишет что некоторые файлы не смог восстановить.

Выполните sfc еще два-три раза, возможно восстановит!

После этого выложите cbs.log

Еще, попробуйте следующее:

Посмотрел в Network Monitor какой трафик ходит. Оказалось DNS запросы прекрасно уходят и возвращаются. Программы которые напрямую обращаются к DNS серверам работают, например прекрасно себя чувствует Skype. Кроме того, видно как при выполнении ping уходит запрос на DNS сервер от DNS-клиента и приходит ответ, только вот ping эту информацию не получает.

sfc /scannow пишет что некоторые файлы не смог восстановить.

попробуйте sfc после этих действий

Хочется все-таки разобраться что в Windows 7 отвечает за разрешение имен (где находятся настройки). Ведь если на нормальной системе отключить DNS-клиент, имена все-равно разрешаются, тот же ping прекрасно себе работает.

В моем же случае такое впечатление что система даже не пытается разрешить имя, порядок проверки ведь какой — локальное имя, файл hosts, DNS, NetBt. Но, даже если прописать соответствие в hosts имя не разрешается, т.е. проверка просто не производится. Почему?

Источник