Jump to content
Калькуляторы

Ошибка 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 в топку" поддержан не будет.

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

У нас сетка маленькая, серые адреса клиентам (по которым они достукиваются до 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 все работает замечательно, все пингуется, инет бегает, никаких проблем.

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

 

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

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

Share this post


Link to post
Share on other sites

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Решение:

1. vlan-per-customer

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Edited by GFORGX

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this