|
Странная работа PPTP на разных типах аплинков
Добрый день!
Столкнулся вот с такой проблемой: для подключения к корпоративной сети используется VPN по протоколу PPTP. Схема стандартная - сотрудник имея подключение к сети Интернет, подключается по VPN и имеет доступ к некоторому набору информационных ресурсов. Все бы хорошо, но заметили, что конкретно W7 туннель отрабатывает по разному в зависимости от того какое соединение обеспечивает доступ в Интернет - если используется GPRS/EDGE-модем, то все нормально, интерфейс поднимается, доступ к ресурсам есть. А вот в ситуациикогда соединение с Интернет высокоскоростное (Ethernet), то соединение устанавливается, но ничего тяжелее пингов по каналу не ходит. Изменение MTU в реестре на VPN-адаптере толку не дает, меняли в широких пределах от 576 до 1462. Версия W7 Корпоративная 64-разрядная. Какие будут предложения? |
frozer,
вся штука может быть в том, что какие у вас ходят пинги по IP или по мнемонике (www....ru) предполагаю, что по IP, так как в остальном нужно DNS. При подключение по VPN у вас создается канал только между вами и сервером VPN. Так же возможно стоит firewall который блокирует пакеты GRE тип 47, так же должен быть открыт порт 1723. |
хорошо, давайте по порядку. Первое сообщение было достаточно сумбурным.
1. Настройки сетевой среды при VPN подключении присваевается и IP адрес, назначаются DNS-серверы и DNS-суффикс. Разрешение имен работает как вручную (через nslookup на присвоенный DNS-сервер), так и при работе сервисов. Т.е. если мы имеем подключение по медленному (GPRS/EDGE) или быстрому (Ethernet) каналу, то пинг отрабатывает во всех трех случаях: ping 192.168.1.100 - ok ping www.inner.domain.tld ping www - т.е. разрешение имен, а соответственно и работа протокола GRE (про порт 1723 и так понятно - авторизацию проходим). Открываем IE (при VPN поверх медленного подключения), набираем 192.168.1.100 - открывается корп. портал, то же самое при VPN поверх быстрого подключения - не работает. 2. Программная среда На том же железе парой недель раньше стояла XP SP3 - VPN функционировал без проблем. На W7 последовательно выключали KAV и встроенный МСЭ - без изменений, не работает на быстром канале, тем более, что как показывает пример п.1 влияния этих компонентов можно не учитывать - на медленном канале работает вместе с ними. Перебор - "Общественное место"-"Работа"-"Дом" результата тоже не приносит. 3. Предположения и догадки Собственно, "танцы" с MTU и начали, имея опыт похожих разбирательств с роутерами на уровне филиальной сети (почти вся работает на VPN поверх Интернет разных провайдеров), где как раз и пришлось подкручивать размер MTU на туннельном интерфейсе Cisco. Тем более, что подобные симптомы возникают при настройке PPPoE и даже соответсвующая статья на "православном" сайте есть (http://support.microsoft.com/kb/283165/ ). |
frozer,
Танцуйте от таблицы маршрутов команда cmd>route print Возможно у вас фишка в том, что есть такой параметр как "Метрика" этот параметр имеет значения и чем он меньше тем приоритет его выше (это сказывается на маршруте), но есть коэффициент который зависит от скорости соединения. Цитата:
И ваш IP до подключения принадлежит сетки 192.168.1.x? Покажите таблицу маршрутов до подключения VPN и после подключения? |
подождите, Valiant. При чем здесь метрика? В обоих случаях (быстрого и медленного канала) пинги ходят нормально. Вы же не станете утверждать, что метрика интерфейса по разному будет влиять на ICMP и на TCP-протокол?
Что же до IP-адресов, то на интерфейсе смотрящем в И-нет - адресация не совпадает со 192.168.0.0/16. Понимаете ли, что если бы маршруты были некорректными, то никаких пингов (и уж тем более, разрешения имен) мы на VPN поверх быстрого канала не видели. |
Если я все правильно понял проблему, то
1. У вас при VPN подключении Цитата:
Сделайте cmd>route print 2.У вас Цитата:
Сделайте cmd>route print При данном соединении у вас пропишется новый IP от VPN и добавится деф маршрут, тем более у адресация не совпадает со 192.168.0.0/16. Вы говорили что у вас Цитата:
ping если в одной сети как на сетевой то вы их увидите. Или покажите route print чтоб не думалось. |
Valeant, давайте сначала. Если Вы настаиваете на проблеме с маршрутами, то пж-та привожу соответствующие выборки.
1. До установления VPN-соединения. вывод команды ipconfig /all Код:
Ethernet adapter inet:Код:
IPv4 таблица маршрутавывод команды ipconfig /all Код:
Адаптер PPP VPN-подключение:Код:
IPv4 таблица маршрутаКод:
C:\Users\i>ping 192.168.100.52Теперь, если открыть www.inner.domain.tld в браузере (я привожу браузер, как пример приложения осуществляющего обмен данными по TCP) - "время ожидания истекло". |
ваша сеть c такой маской 10.12.160.0 - 10.12.175.255
странно все это, по маршрутам все так, а вот по DNS нет, вся фишка в том что для приложения запрос к интернету (браузер) запрос на DNS пойдет не через тунель, а нормально от в вашей сетевой, а вот сама работа да через тунель: 1. {DNS, UDP, IP} источник 10.12.162.96 - к серверу DNS приемник 10.0.72.10 - DNS:QueryId {www.....} ответ {DNS, UDP, IP} источник сервер DNS 10.0.72.10 - приемник 10.12.162.96 - {IP - для www.....} 2. сворачиваем в тунель будет пакет {TCP, IP} источник 10.12.162.96 - к серверу VPN приемник 84.254.201.40 GRE ------ [Ipv4: источник 192.168.90.122, приемник {IP - для www..... Port=HTTP(80)] ответ по тунелю {TCP, IP} источник сервер VPN 84.254.201.40 - приемник 10.12.162.96 GRE ------ [Ipv4: источник {IP - для www..... Port=HTTP(80), приемник 192.168.90.122] 3. {HTTP, TCP, IP} источник 10.12.162.96 - к серверу VPN приемник 84.254.201.40 GRE ------ [Ipv4: источник 192.168.90.122, приемник {IP - для www..... Port=HTTP(80)] ---------------- [HTTP:Request, GET .....] и т.д. Если вы делаете nslookup то он у вас какой ip показывает? Так же pathping? И если добавить маршрут, что б до ваших 10.0.72.10 route -p add 10.0.0.0/255.0.0.0 10.12.160.1 |
Цитата:
Вопрос, как видите, совсем не в маршрутах. |
frozer,
Тут я с вами не соглашусь и поспорю 1 {DNS:60, UDP:59, IPv4:8} - IP-лок - IP-DNS - DNS:QueryId = 0xE3AB, QUERY (Standard query), Query for mail.ru of type Host Addr on class Internet 2 {DNS:60, UDP:59, IPv4:8} - IP-DNS - IP-лок - DNS:QueryId = 0xE3AB, QUERY (Standard query), Response - Success, [217.69.128.45, 217.69.128.41 ... ] 3 {TCP:58, IPv4:2, IPv4:11} - IP-serv-vpn - IP-лок - SrcPort=HTTP(80), DstPort=52593, PayloadLen=0, Seq=3102319310, Ack=3439881161, Win=65535 ( Negotiated scale factor 0x1 ) = 131070 --Gre: Protocol = PPP, Flags = ..KS....A....... Version 1 , Length = 0x41 , CallID = 0x2e2e ----Ipv4: IP-vpn-кл - 217.69.128.45, .... 4 {TCP:4, IPv4:3, IPv4:11} - IP-serv-vpn - IP-лок - SrcPort=HTTP(80), DstPort=52615, PayloadLen=0, Seq=3462097665, Ack=2005666816, Win=7974 (scale factor 0x0) = 7974 --Gre: Protocol = PPP, Flags = ..KS............ Version 1 , Length = 0x35 , CallID = 0x2e2e ----Ipv4: 217.69.128.54, IP-vpn-кл, .... и т.д. В 1 и 2 пакетах вообще тунеля нет и GRE тоже. |
Завтра поставлю анализатор пакетов, и посмотрю сам :-) уж не обессудьте.
Для чистоты эксперимента принес ноутбук с такой же Windows (7 Corp 64-bit) - PPTP работает при любом виде несущего подключения. |
| Время: 06:57. |
Время: 06:57.
© OSzone.net 2001-