Шлюза может и не быть. Если у провайдера вся "локальная" сеть живёт в 10.35.*.*, то и шлюз можно не выдавать. Так даже лучше - на клиентских ПК не будет маразма с двумя дефолт-шлюзами. VPN-сервер тоже естественно находится в этой же сети 10.35.*.* и доступен напрямую.

Да это уже получается от темы отхошли...............вопрос так и не закрыт, почему из винды все рабоатет (аутентификация CHAP без шифрации), а 824 не коннектится, выдает ошибку 200 (MSCHAP 691)

ytka, давай все-таки разберемся КТО выдает 691 ошибку: винда или Д-Линк? Это первое.

Второе. Все-таки у тебя MSCHAP или просто CHAP?

Третье. Со своим провайдером пробовал обсудить эту ситуацию или нет желания.

Попробуем решить этот регбус.

В Винде все работает когда стоит в настройках ТОЛЬКО CHAP.
Ошибку 691 выдает Длинк-834, в логах..............
выглядит это так
Monday April 25, 2005 02:35:53 MSCHAP1: E=691 R=0

Вот я и не пойму, причем МсЧАП (на который ругается длинк), если в винде все работает просто с CHAP

Вообще говоря, когда Д-Линк выдает ошибку, он так и пишет в логах, например "PPTP:error=-200".

А то, о чем ты говоришь может быть параметром запроса, а не сообщением об ошибке. Этого я не знаю.

Проблема может быть вот в чем: Д-Линк при соединении пытается сам определить протокол авторизации PPTP (тут где-то об этом писали) - руками это задать низя, а жаль. Как он определяет это - мне не известно. Могу предположить, что в плоть до перебора запросов к серверу, на какой откликниться.

Если сервер не правильно сконфигурен или криво написан, то вполне вероятно он может пытаться откликаться на MSCHAP'овское приветствие CHAPом. Или что-то в этом роде. Результат один - ошибка авторизации (Error=-200).

Может я, конечно, тут нанес пургу - тут может только ТехСаппорт сказать, или тот, кто дочитал до конца RFC по PPP, PPTP и их CHAP'ам. Я ни асилил - много букофф, мала время.

Боюсь, без логов со стороны сервера или перехвата траффика эту ситуацию не разрулить. Что хоть за ОСь или что за железяка стоит у провайдера в качестве сервера NAS (network access server)?

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

Достал кусок лога с сервака, как я понял там поддерживаются CHAP и MSCHAPv2, но 824 упорно пытается применить MSCHAPv1, почему непонятно нихрена. Смотрите лог.............

Dec 21 23:29:59 vpn0 mpd: [pptp266] LCP: rec'd Configure Request #1 link 0 (Req-Sent)
Dec 21 23:29:59 vpn0 mpd: MRU 1460
Dec 21 23:29:59 vpn0 mpd: MAGICNUM c8190000
Dec 21 23:29:59 vpn0 mpd: [pptp266] LCP: SendConfigAck #1
Dec 21 23:29:59 vpn0 mpd: MRU 1460
Dec 21 23:29:59 vpn0 mpd: MAGICNUM c8190000
Dec 21 23:29:59 vpn0 mpd: [pptp266] LCP: state change Req-Sent --> Ack-Sent
Dec 21 23:29:59 vpn0 mpd: [pptp266] LCP: rec'd Configure Reject #2 link 0 (Ack-Sent)
Dec 21 23:29:59 vpn0 mpd: PROTOCOMP
Dec 21 23:29:59 vpn0 mpd: MP MRRU 1600
Dec 21 23:29:59 vpn0 mpd: MP SHORTSEQ
Dec 21 23:29:59 vpn0 mpd: ENDPOINTDISC [802.1] 00 0e 0c 83 10 95
Dec 21 23:29:59 vpn0 mpd: [pptp266] LCP: SendConfigReq #3
Dec 21 23:29:59 vpn0 mpd: ACFCOMP
Dec 21 23:29:59 vpn0 mpd: MRU 1500
Dec 21 23:29:59 vpn0 mpd: MAGICNUM 8976b9f6
Dec 21 23:29:59 vpn0 mpd: AUTHPROTO CHAP MSOFT
Dec 21 23:29:59 vpn0 mpd: [pptp266] LCP: rec'd Configure Ack #3 link 0 (Ack-Sent)
Dec 21 23:29:59 vpn0 mpd: ACFCOMP
Dec 21 23:29:59 vpn0 mpd: MRU 1500
Dec 21 23:29:59 vpn0 mpd: MAGICNUM 8976b9f6
Dec 21 23:29:59 vpn0 mpd: AUTHPROTO CHAP MSOFT
Dec 21 23:29:59 vpn0 mpd: [pptp266] LCP: state change Ack-Sent --> Opened
Dec 21 23:29:59 vpn0 mpd: [pptp266] LCP: phase shift ESTABLISH --> AUTHENTICATE
Dec 21 23:29:59 vpn0 mpd: [pptp266] LCP: auth: peer wants nothing, I want CHAP
Dec 21 23:29:59 vpn0 mpd: [pptp266] CHAP: sending CHALLENGE
Dec 21 23:29:59 vpn0 mpd: [pptp266] LCP: LayerUp
Dec 21 23:29:59 vpn0 mpd: [pptp266] CHAP: rec'd RESPONSE #1
Dec 21 23:29:59 vpn0 mpd: Name: "usie0230171"
Dec 21 23:29:59 vpn0 mpd: [pptp266] RADIUS: using /etc/radius.conf
Dec 21 23:29:59 vpn0 mpd: [pptp266] RADIUS: RadiusAddServer Adding 10.35.0.10
Dec 21 23:29:59 vpn0 mpd: [pptp266] RADIUS: RadiusPutAuth: RADIUS_CHAP (MSOFTv1) peer name: usie0230171
Dec 21 23:29:59 vpn0 mpd: [pptp266] RADIUS: RadiusSendRequest: RAD_ACCESS_REJECT for user usie0230171
Dec 21 23:29:59 vpn0 mpd: [pptp266] RADIUS: RadiusGetParams: RAD_REPLY_MESSAGE: Authorization failed.
Dec 21 23:29:59 vpn0 mpd: [pptp266] CHAP: sending FAILURE
Dec 21 23:29:59 vpn0 mpd: [pptp266] LCP: authorization failed
Dec 21 23:29:59 vpn0 mpd: [pptp266] device: CLOSE event in state UP
Dec 21 23:29:59 vpn0 mpd: pptp7-0: clearing call
Dec 21 23:29:59 vpn0 mpd: pptp7-0: killing channel
Dec 21 23:29:59 vpn0 mpd: [pptp266] PPTP call terminated
Dec 21 23:29:59 vpn0 mpd: [pptp266] IFACE: Close event
Dec 21 23:29:59 vpn0 mpd: [pptp266] IPCP: Close event
Dec 21 23:29:59 vpn0 mpd: [pptp266] IPCP: state change Starting --> Initial
Dec 21 23:29:59 vpn0 mpd: [pptp266] IPCP: LayerFinish
Dec 21 23:29:59 vpn0 mpd: [pptp266] IFACE: Close event
Dec 21 23:29:59 vpn0 mpd: pptp7: closing connection with 10.35.31.39:65535

Все, что написал бред, кто прочитал извиняюсь! Текила и все такое!

D-Link здесь похоже не причем. Мелкософт, впрочем, тоже! Судя по логам, ауцтентификацию пользователя выполняет RADIUS-сервер, который вообще не нашел пользователя с таким именем. Как вариант очень длинное имя пользователя. Но это так -фантазии...

Судя пол логам провайдера вас не авторизует именно РАДИУС провайдера. Притом он понимает то, что говорит устройство. Похоже провайдер кривовато настроил свой сервер доступа...

_________________
С уважением -- Александр Шебаронин.

С именеим все нормально, из винды логинит.
У меня есть вариант что может быть: на сервере 2 метода аутентификации - CHAP и MSCHAP, у точки то же есть CHAP MSCHAP но разница в том, что у прова мсчап версии 2, а у точки версии 1. Привилегии у точки логинится методом МСЧАП, а потом ЧАП. Может они договариваются о методе МСЧАП, при этом не учитывая что версии разные ?
Все таки хреново что нельзя в точке явно вручную указать какой метод использовать.

по поводу прова, там ипользуется NEtUp UTM, конфигурации там тривиальные, все уже есть тока подправить под свою сеть,поэтому думаю там особо не парилисьб при их настройке. Но фак таткой что там 2 метода, CHAP и MSCHAPv1, скорее всего ошибка не в длинке, потому что если сделаить такие же установки в винде (вфыставить протокол ЧАП и МСЧАПв1) то тоже никакого эффекта. Но все таки обиднео что нельзя выбрать протокол вручную Это все бы решило, хоть прошивку сам пиши ))))))))))))

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

_________________
С уважением -- Александр Шебаронин.

UTM сам чтоль поддерживает PPTP сессию? Ни в жизни не поверю, тем более на том зоопарке систем, на котором они работают. Это биллинговая система, а не сервер доступа. Так что смотреть надо ту операционку, на которой она стоит. Да и если сравнивать наших разработчиков и западных, то качество тестирования и отладки программы отнюдь не в нашу пользу. Сколько у нас фирм сертифицировано по ИСО 9001?

Кроме того, ИМХО, для нормальной поддержки MSCHAP'ов нужно заключать партнерское соглашение с Мелкософтом, чтобы получить всю техническую документацию. Печальный опыт многих фирм разработчиков показывает, что в открытом доступе не всегда лежит, как бы помягче сказать, полная информация. Есть у меня подозрение, что это один из вопросов, мешающий сделать Д-Линку соответствующее устройство с МСЧАП в.2, - отчисления за технологию пока не окупят прибыль от продажи.

А вот по поводу ручного выбора протокола - тут я соглашусь на все 100%. Нет никаких проблем оставить режим автоматического выбора, но добавить при этом режим ручного. Не знаю, как в других странах, но у нас многие провайдеры используют разнообразные серверы доступа: как хардварные, так и софтверные на базе и Винды и Юниксов. Протестировать же железо на всем этом зоопарке нереально даже Д-Линку. А при ручном режиме сразу все становится на свои места.

Ну остается тока ждать прошивок новых. может вставят возможность ручной настройки, если это можно прошивкой исправить. Или искать возможные неправильные настройки pptp

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

_________________
С уважением -- Александр Шебаронин.