Перейти к содержимому
Калькуляторы

Ошибка 868 при поднятии VPN под Windows Похоже, что только на Windows 7

Со вчерашнего вечера у клиентов массово стала появляться ошибка 868 при поднятии VPN (у нас pptp) под Windows.

Вот описание на мелкософте: http://answers.microsoft.com/ru-ru/windows/forum/windows_7-networking/%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0-868/44f940de-3f80-4f63-9be7-1c9548eab050

Ошибка 868: Удаленное подключение не удалось установить, поскольку не удалось разрешить имя сервера удаленного доступа

Об Ошибке:

Кардинальное решение - поставить другую сборку Win7

Данная ошибка возникает только в операционной системе "Windows 7".

Компанией Microsoft ещё не найдено решение этой проблемы.

Суть проблемы в том, что в некоторых "билдах"(сборках) данной операционной системы нестабильно работает dns-клиент.

 

Решение:

В некоторых случаях помогает сброс каталогов ( в коммандной строке ввести комманды: netsh int ip reset c:\log и netsh winsock reset ) и перезагрузка компьютера. Если же после этого подключение не восстановилось, то стоит задуматься об переустановке ОС.

 

Цитата

да в целом решение у всех сводится к двум вариантам:

1) перезапуск днс-клиента в службах

2) пропись ip вместо имени сервера.

а суть проблемы рисуется на пальцах:

если primary-dns сервер немножко нагружен, то ответ он даст не сразу, а с некоторой задержкой (ну предположим, в тяжелом случае, секунд через 15-20). в winXP dns-клиент жует этот таймаут спокойно, а win7 считает что если пакет не получен в течении 1-5 секунд - то dns не отвечает, при этом повторно он видимо не пробует запросить dns или запросить у secondary-dns.

покрайней мере "синтезировать" ошибку удалось именно так (подвесив на некоторое время тестовый dns).

так что как вариант можно попробовать разгрузить сервера (горизонтально масштабировать например) или же ждать обновления от microsoft.

DNS у нас не перегружен, да и клиентов всего 2-3 сотни.

 

решение проблемы:

1. Зайдите в меню Пуск - наберите в строке поиска cmd - в появившихся результатах поиска найдите программу Командная строка - нажмите на нее правой кнопкой мыши и выберите Запуск от имени администратора, в открывшемся окне наберите netsh int ip reset и нажмите Ввод, далее наберите ipconfig flushdns и нажмите Ввод.

2. Создайте VPN-подключение заново.

3. Проверьте, корректно ли указан шлюз и DNS-серверы в свойствах сетевого подключения.

4. В командной строке выполните команды ipconfig all и route print, результаты можете проверить с техподдержкой провайдера.

 

Похоже, что проявляется только под Windows 7, т.к. XP и аппаратные роутеры работают по-прежнему стабильно.

Какое-то обновление винды прошло что ли?

 

PS. Холивар на тему "pptp в топку" поддержан не будет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну что - нет мнений/решений?

Клиенты уже весь мозг выклевали с этой проблемой.

Рекомендация переставить винду большинство утешает слабо.

А вышеприведенные рецепты большинству ничего не дают, они твердят - "ведь работало же. сделайте нам так, чтобы все было как прежде!"

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы имеете ввиду, что кто-то поднял у себя WINS-сервер?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы имеете ввиду, что кто-то поднял у себя WINS-сервер?

Вполне может быть. Windows 7 любит вместо DNS спрашивать у WINS. Как вариант решения ошибки 868 вообще (подсказано когда-то sfstudio) - поднять у себя WINS и выдавать его адрес по DHCP.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У нас сетка маленькая, серые адреса клиентам (по которым они достукиваются до NAS-а) прописаны ручками. Так что не вариант.

Например у клиента прописано:

ip 192.168.10.31

mask 255.255.255.0

gw 192.168.10.1

dns 192.168.10.1

 

Если на Windows7 сделать arp -a , то сервер 192.168.10.1 и его MAC в таблице присутствуют. Но сервак все равно не пингуется. :(

Причем ТОЛЬКО ПОД WINDOWS 7!

Под XP/Vista все работает замечательно, все пингуется, инет бегает, никаких проблем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Причем связка mac-ip нашего сервака 192.168.10.1 была внесена в конфиг центрального свича.

Почему это повлияло только на Windows 7 - загадка.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

PS. Холивар на тему "pptp в топку" поддержан не будет.

 

Вот по этому и надо уходить от pptp к pppoe. На свичах фильтруется все лишнее и не нужно забивать себе голову о кривости роутеров, а так же оставлять клиентов без интернета по не понятной причине=)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

PPTP в топку :) И это не холивар, хватит над хомячками туннелями издеваться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Вот по этому и надо уходить от pptp к pppoe. На свичах фильтруется все лишнее и не нужно забивать себе голову о кривости роутеров, а так же оставлять клиентов без интернета по не понятной причине=)

Где вы увидели что-то о кривости роутеров? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Вот по этому и надо уходить от pptp к pppoe. На свичах фильтруется все лишнее и не нужно забивать себе голову о кривости роутеров, а так же оставлять клиентов без интернета по не понятной причине=)

Где вы увидели что-то о кривости роутеров? :)

 

Пардон, там было про кривость админов=)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это кривость вашей сети, а не админа клиента. Любой юзер может подключить роутер лан портами в вашу сеть. Ваша задача защитить сеть :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не любой - со стороны физиков такая защита есть: прибит mac сервака на центральном свиче. А со стороны юриков я такого не ожидал. Впрочем, это проблема никак не связана с использованием pptp.

Больше на эту тему отвечать не буду, т.к. "холивар ..." и т.д. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не любой - со стороны физиков такая защита есть: прибит mac сервака на центральном свиче. А со стороны юриков я такого не ожидал.

А не на центральном? ;)

 

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

Ага, у Вас Ethernet дырявый ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всегда умиляла особенность новичков этого форума к таким постам. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Событие: в клиентском влане появляется ip адрес равный адресу шлюза, все клиенты в этом влане начинают испытывать проблемы с доступом.

Задача: превентивно предотвратить возможный сценарий.

Решение:

1. vlan-per-customer

2. Куча ACL по всему и вся на умном доступе.

 

Еще какие варианты? И что дает "прибит mac сервака на центральном свиче"? Центральный свитч всегда знает что ip=mac, а толку то, у пользователей же нет такого знания, поэтому на их who-has 192.168.1.10 вернется или настоящий или фейковый, т.е. это не защита, а самообман.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сталкивались с аналогичной проблемой. Сеть у нас "десятка" 10.xx.xx.xx, адреса пользователи получают от нашего DHCP. Ситуация с получением адреса 192.168.xx.xx отпадает. Потому как у пользователя наши адреса, наш шлюз наши DNS. Но все равно ошибка 868. Причем как появилась, так и пропала - внезапно. Было такое пару раз за год. Тоже голову ломали...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

IPoE и VLAN на клиента помоему идеальное решение для 200-300 (да и для 2-3к) клиентов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

IPoE и VLAN на клиента помоему идеальное решение для 200-300 (да и для 2-3к) клиентов.

Влан на клиента или свитч, главное без тунелей ИМХО.

Но если автор не МОЖЕТ отказаться от тунелей по какой то причине то нет смысла это советовать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как советчики строить сети без туннелей занимаются балансировкой нагрузки и повышением отказоустойчивости?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как советчики строить сети без туннелей занимаются балансировкой нагрузки и повышением отказоустойчивости?

У нас в качестве PE - свитчи агрегации. У Вас так часто свитчи агрегации из строя выходят, раз Вы об этом задумываетесь? :) Не вижу смысла в first hop redundancy.

Изменено пользователем GFORGX

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как советчики строить сети без туннелей занимаются балансировкой нагрузки и повышением отказоустойчивости?

 

Методами балансировки нагрузки и повышения отказоустойчивости.

Что за детские вопросы?

 

Само отсутствие терминирующей туннели железки уже повышает отказоустойчивость.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Само отсутствие терминирующей туннели железки уже повышает отказоустойчивость.

Более чем спорное утверждение, железка то, как правило, одна "за всё", что для IPoE, что для PPPoE.

В случае с тем же PPPoE, простое добавления ещё одной железки повышает и производительность и отказоустойчивость системы в целом.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Более чем спорное утверждение, железка то, как правило, одна "за всё", что для IPoE, что для PPPoE.

В случае с тем же PPPoE, простое добавления ещё одной железки повышает и производительность и отказоустойчивость системы в целом.

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

Вы хрень какую-то написали, даже комментировать не хочется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

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

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.