Andrei Опубликовано 27 октября, 2011 · Жалоба Со вчерашнего вечера у клиентов массово стала появляться ошибка 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 в топку" поддержан не будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 28 октября, 2011 · Жалоба Ну что - нет мнений/решений? Клиенты уже весь мозг выклевали с этой проблемой. Рекомендация переставить винду большинство утешает слабо. А вышеприведенные рецепты большинству ничего не дают, они твердят - "ведь работало же. сделайте нам так, чтобы все было как прежде!" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 28 октября, 2011 · Жалоба У вас там WINS не завелся часом? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 28 октября, 2011 · Жалоба Вы имеете ввиду, что кто-то поднял у себя WINS-сервер? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 28 октября, 2011 · Жалоба Вы имеете ввиду, что кто-то поднял у себя WINS-сервер? Вполне может быть. Windows 7 любит вместо DNS спрашивать у WINS. Как вариант решения ошибки 868 вообще (подсказано когда-то sfstudio) - поднять у себя WINS и выдавать его адрес по DHCP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 28 октября, 2011 · Жалоба У нас сетка маленькая, серые адреса клиентам (по которым они достукиваются до 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 все работает замечательно, все пингуется, инет бегает, никаких проблем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 28 октября, 2011 · Жалоба Все оказалось проще: админ одного из клиентов так ловко подключил свою сетку через роутер, что его локалка стала светиться наружу, в т.ч. и LAN-адрес их сетки, который тоже был 192.168.10.1. Вычислили по таблицам мак-адресов на свичах, благо они управляемые. Причем связка mac-ip нашего сервака 192.168.10.1 была внесена в конфиг центрального свича. Почему это повлияло только на Windows 7 - загадка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 28 октября, 2011 · Жалоба PS. Холивар на тему "pptp в топку" поддержан не будет. Вот по этому и надо уходить от pptp к pppoe. На свичах фильтруется все лишнее и не нужно забивать себе голову о кривости роутеров, а так же оставлять клиентов без интернета по не понятной причине=) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 28 октября, 2011 · Жалоба PPTP в топку :) И это не холивар, хватит над хомячками туннелями издеваться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 29 октября, 2011 · Жалоба Вот по этому и надо уходить от pptp к pppoe. На свичах фильтруется все лишнее и не нужно забивать себе голову о кривости роутеров, а так же оставлять клиентов без интернета по не понятной причине=) Где вы увидели что-то о кривости роутеров? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 29 октября, 2011 · Жалоба Вот по этому и надо уходить от pptp к pppoe. На свичах фильтруется все лишнее и не нужно забивать себе голову о кривости роутеров, а так же оставлять клиентов без интернета по не понятной причине=) Где вы увидели что-то о кривости роутеров? :) Пардон, там было про кривость админов=) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 29 октября, 2011 · Жалоба Причем кривость была у админа клиента. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 29 октября, 2011 · Жалоба Это кривость вашей сети, а не админа клиента. Любой юзер может подключить роутер лан портами в вашу сеть. Ваша задача защитить сеть :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 31 октября, 2011 · Жалоба Не любой - со стороны физиков такая защита есть: прибит mac сервака на центральном свиче. А со стороны юриков я такого не ожидал. Впрочем, это проблема никак не связана с использованием pptp. Больше на эту тему отвечать не буду, т.к. "холивар ..." и т.д. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 31 октября, 2011 · Жалоба Не любой - со стороны физиков такая защита есть: прибит mac сервака на центральном свиче. А со стороны юриков я такого не ожидал. А не на центральном? ;) Впрочем, это проблема никак не связана с использованием pptp. Ага, у Вас Ethernet дырявый ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 31 октября, 2011 · Жалоба Всегда умиляла особенность новичков этого форума к таким постам. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 31 октября, 2011 · Жалоба На самом деле это интересный вопрос. Событие: в клиентском влане появляется ip адрес равный адресу шлюза, все клиенты в этом влане начинают испытывать проблемы с доступом. Задача: превентивно предотвратить возможный сценарий. Решение: 1. vlan-per-customer 2. Куча ACL по всему и вся на умном доступе. Еще какие варианты? И что дает "прибит mac сервака на центральном свиче"? Центральный свитч всегда знает что ip=mac, а толку то, у пользователей же нет такого знания, поэтому на их who-has 192.168.1.10 вернется или настоящий или фейковый, т.е. это не защита, а самообман. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gods33 Опубликовано 31 октября, 2011 · Жалоба Сталкивались с аналогичной проблемой. Сеть у нас "десятка" 10.xx.xx.xx, адреса пользователи получают от нашего DHCP. Ситуация с получением адреса 192.168.xx.xx отпадает. Потому как у пользователя наши адреса, наш шлюз наши DNS. Но все равно ошибка 868. Причем как появилась, так и пропала - внезапно. Было такое пару раз за год. Тоже голову ломали... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RussTlt Опубликовано 31 октября, 2011 · Жалоба IPoE и VLAN на клиента помоему идеальное решение для 200-300 (да и для 2-3к) клиентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 31 октября, 2011 · Жалоба IPoE и VLAN на клиента помоему идеальное решение для 200-300 (да и для 2-3к) клиентов. Влан на клиента или свитч, главное без тунелей ИМХО. Но если автор не МОЖЕТ отказаться от тунелей по какой то причине то нет смысла это советовать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 31 октября, 2011 · Жалоба А как советчики строить сети без туннелей занимаются балансировкой нагрузки и повышением отказоустойчивости? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 31 октября, 2011 (изменено) · Жалоба А как советчики строить сети без туннелей занимаются балансировкой нагрузки и повышением отказоустойчивости? У нас в качестве PE - свитчи агрегации. У Вас так часто свитчи агрегации из строя выходят, раз Вы об этом задумываетесь? :) Не вижу смысла в first hop redundancy. Изменено 31 октября, 2011 пользователем GFORGX Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 31 октября, 2011 · Жалоба А как советчики строить сети без туннелей занимаются балансировкой нагрузки и повышением отказоустойчивости? Методами балансировки нагрузки и повышения отказоустойчивости. Что за детские вопросы? Само отсутствие терминирующей туннели железки уже повышает отказоустойчивость. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 31 октября, 2011 · Жалоба Само отсутствие терминирующей туннели железки уже повышает отказоустойчивость. Более чем спорное утверждение, железка то, как правило, одна "за всё", что для IPoE, что для PPPoE. В случае с тем же PPPoE, простое добавления ещё одной железки повышает и производительность и отказоустойчивость системы в целом. В случае с IPoE, так не выйдет, придётся что-то городить для увязки железок между собой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 31 октября, 2011 · Жалоба Более чем спорное утверждение, железка то, как правило, одна "за всё", что для IPoE, что для PPPoE. В случае с тем же PPPoE, простое добавления ещё одной железки повышает и производительность и отказоустойчивость системы в целом. В случае с IPoE, так не выйдет, придётся что-то городить для увязки железок между собой. Вы хрень какую-то написали, даже комментировать не хочется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...