Показать полную графическую версию : Странная работа 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
Возможно у вас фишка в том, что есть такой параметр как "Метрика" этот параметр имеет значения и чем он меньше тем приоритет его выше (это сказывается на маршруте), но есть коэффициент который зависит от скорости соединения.
Чтобы автоматизировать выбор наиболее быстрого маршрута используется 2-ступенчатая схема назначения метрики. Каждому сетевому интерфейсу присваивается своеобразный коэффициент.
Скорость в интерфейсе:
Скорость выше 200 Мбит/сек ------ коэффициент 10;
Скорость от 20 до 200 Мбит/сек -- коэффициент 20;
Скорость от 4 до 20 Мбит/сек ----- коэффициент 30;
Скорость от 0,5 до 4 Мбит/сек ---- коэффициент 40.
Далее после подключения по VPN вы получаете IP адрес от сервера VPN, он не такой как у вас был ранее.
И ваш IP до подключения принадлежит сетки 192.168.1.x?
Покажите таблицу маршрутов до подключения VPN и после подключения?
подождите, Valiant. При чем здесь метрика? В обоих случаях (быстрого и медленного канала) пинги ходят нормально. Вы же не станете утверждать, что метрика интерфейса по разному будет влиять на ICMP и на TCP-протокол?
Что же до IP-адресов, то на интерфейсе смотрящем в И-нет - адресация не совпадает со 192.168.0.0/16.
Понимаете ли, что если бы маршруты были некорректными, то никаких пингов (и уж тем более, разрешения имен) мы на VPN поверх быстрого канала не видели.
Если я все правильно понял проблему, то
1. У вас при VPN подключении
если мы имеем подключение по медленному (GPRS/EDGE)
ping 192.168.1.100 - ok
ping www.inner.domain.tld
ping www
Открываем IE (при VPN поверх медленного подключения), набираем 192.168.1.100 - открывается корп. портал
Все нормально, маршрут на 192.168.1.x у вас имеет приоритет выше чем медленный ваш GPRS/EDGE см. выше
Сделайте
cmd>route print
2.У вас
по Ethernet каналу, то пинг отрабатывает во всех трех случаях:
ping 192.168.1.100 - ok
ping www.inner.domain.tld
ping www
Открываем IE набираем 192.168.1.100 поверх быстрого подключения - не работает.
В данном случае VPN создаст маршрут у которого метрика будет выше вашего 192.168.1.100
Сделайте
cmd>route print
При данном соединении у вас пропишется новый IP от VPN и добавится деф маршрут, тем более у адресация не совпадает со 192.168.0.0/16.
Вы говорили что у вас
Открываем IE (при VPN поверх медленного подключения), набираем 192.168.1.100 - открывается корп. портал, то же самое при VPN поверх быстрого подключения - не работает.
ping www.inner.domain.tld - это ваш корпаративный
ping если в одной сети как на сетевой то вы их увидите.
Или покажите route print чтоб не думалось.
Valeant, давайте сначала. Если Вы настаиваете на проблеме с маршрутами, то пж-та привожу соответствующие выборки.
1. До установления VPN-соединения.
вывод команды ipconfig /all
Ethernet adapter inet:
DNS-суффикс подключения . . . . . : .
Описание. . . . . . . . . . . . . : Realtek RTL8139/810x Family Fast Ethernet
сетевой адаптер
Физический адрес. . . . . . . . . : 00-0C-46-B2-DB-5B
DHCP включен. . . . . . . . . . . : Да
Автонастройка включена. . . . . . : Да
IPv4-адрес. . . . . . . . . . . . : 10.12.162.96(Основной)
Маска подсети . . . . . . . . . . : 255.255.240.0
Аренда получена. . . . . . . . . . : 14 февраля 2010 г. 17:43:25
Срок аренды истекает. . . . . . . . . . : 14 февраля 2010 г. 22:39:22
Основной шлюз. . . . . . . . . : 10.12.160.1
DHCP-сервер. . . . . . . . . . . : 10.0.72.4
DNS-серверы. . . . . . . . . . . : 10.0.72.10
NetBios через TCP/IP. . . . . . . . : Включен
Вывод команды route print:
IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрик
0.0.0.0 0.0.0.0 10.12.160.1 10.12.162.96 20
10.12.160.0 255.255.240.0 On-link 10.12.162.96 276
10.12.162.96 255.255.255.255 On-link 10.12.162.96 276
10.12.175.255 255.255.255.255 On-link 10.12.162.96 276
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 10.12.162.96 276
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 10.12.162.96 276
===========================================================================
2. Устанавливаем VPN-подключение
вывод команды ipconfig /all
Адаптер PPP VPN-подключение:
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : VPN-подключение
Физический адрес. . . . . . . . . :
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
IPv4-адрес. . . . . . . . . . . . : 192.168.90.122(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.255
Основной шлюз. . . . . . . . . : 0.0.0.0
DNS-серверы. . . . . . . . . . . : 192.168.100.35
192.168.100.29
NetBios через TCP/IP. . . . . . . . : Включен
Вывод команды route print:
IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрик
0.0.0.0 0.0.0.0 10.12.160.1 10.12.162.96 4245
0.0.0.0 0.0.0.0 On-link 192.168.90.122 21
10.12.160.0 255.255.240.0 On-link 10.12.162.96 4501
10.12.162.96 255.255.255.255 On-link 10.12.162.96 4501
10.12.175.255 255.255.255.255 On-link 10.12.162.96 4501
84.254.201.40 255.255.255.255 10.12.160.1 10.12.162.96 4246
127.0.0.0 255.0.0.0 On-link 127.0.0.1 4531
127.0.0.1 255.255.255.255 On-link 127.0.0.1 4531
127.255.255.255 255.255.255.255 On-link 127.0.0.1 4531
192.168.90.122 255.255.255.255 On-link 192.168.90.122 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 4531
224.0.0.0 240.0.0.0 On-link 10.12.162.96 4502
224.0.0.0 240.0.0.0 On-link 192.168.90.122 21
255.255.255.255 255.255.255.255 On-link 127.0.0.1 4531
255.255.255.255 255.255.255.255 On-link 10.12.162.96 4501
255.255.255.255 255.255.255.255 On-link 192.168.90.122 276
===========================================================================
Проверяем VPN-канал:
C:\Users\i>ping 192.168.100.52
Обмен пакетами с 192.168.100.52 по с 32 байтами данных:
Ответ от 192.168.100.52: число байт=32 время=23мс TTL=127
Ответ от 192.168.100.52: число байт=32 время=22мс TTL=126
Ответ от 192.168.100.52: число байт=32 время=24мс TTL=126
Ответ от 192.168.100.52: число байт=32 время=22мс TTL=126
Статистика Ping для 192.168.100.52:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 22мсек, Максимальное = 24 мсек, Среднее = 22 мсек
C:\Users\i>ping www.inner.domain.tld
Обмен пакетами с www.inner.domain.tld [192.168.100.52] с 32 байтами данных:
Ответ от 192.168.100.52: число байт=32 время=24мс TTL=126
Ответ от 192.168.100.52: число байт=32 время=25мс TTL=127
Ответ от 192.168.100.52: число байт=32 время=22мс TTL=127
Ответ от 192.168.100.52: число байт=32 время=23мс TTL=127
Статистика Ping для 192.168.100.52:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 22мсек, Максимальное = 25 мсек, Среднее = 23 мсек
Вы можете видеть, что туннель работает, разрешение имен (а другими словами, доступ по порту 53 протокола UDP к DNS-серверу организации) тоже.
Теперь, если открыть 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
вся фишка в том что для приложения запрос к интернету (браузер) запрос на DNS пойдет не через тунель, а нормально от в вашей сетевой » - категорически не соглашусь. Запрос пойдет к DNS серверам указанным в свойствах VPN соединения.
Вопрос, как видите, совсем не в маршрутах.
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 работает при любом виде несущего подключения.
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.
Available in ZeroNet 1osznRoVratMCN3bFoFpR2pSV5c9z6sTC