ПОИСК НЕИСПРАВНОСТЕЙ VPN WINDOWS 7, 8, 10 C ПРОТОКОЛОМ PPTP

ВАЖНО!

Перед началом поиска проблем убедитесь, что все галочки на страницах "Гостевой доступ", "Белый список", "Маршрут по умолчанию" в вашем персональном разделе системы сняты! Это поможет локализовать и исправить ошибку быстрее.

Помните, что настройки туннелей в системе VPNKI применяются при переподключении туннеля. Поэтому при изменении информации в личном кабинете системы всегда переподключайте все туннели в вашем аккаунте.

 

Шаг 1. Подключение

1.0.1. Если соединения нет, то первым делом проверьте, что ваш внешний IP адрес не заблокирован в нашей системе. Узнать свой белый IP адрес можно, например, задав в поиске Яндекса фразу "IP address". Запомните адрес, а потом посмотрите на перечень заблокированных IP адресов в нашей системе. Этот список можно найти на странице "Инструменты" - "Заблокированные IP адреса".

1.0.2. Проверьте, что в настройках VPN соединения Windows вы используете механизм аутентификации CHAP для соединения без шифрования и механизм MS-CHAPv2 для соединения с шифрованием.

1.1. Наиболее частой причиной невозможности установления соединения является нежелание вашего провайдера пропустить трафик протокола GRE. Этот протокол используется в соединении PPTP.
По состоянию на начало 2017 года, провайдеры, ограничивающие вас в соединениях, это, например, Yota и МГТС. Но эта ситуация не одинакова во всех частях их сетей.
В случае наличия проблемы с GRE соединение не устанавливается и таймаут на его установление истекает.

О том, как эта проблема выглядит в логах системы VPNKI читайте здесь. Раздел про PPTP и GRE.
Вылечить это можно только путем использования другого VPN протокола. Например L2TP, L2TP c шифрованием IPsec, OpenVPN, SSTP и WireGuard.

Если нет возможности изменить протокол, то можно поменять и провайдера. Хотя бы на время тестирования.

1.2. Следующая по частоте причина - ошибка в имени пользователя, пароле или адресе службы msk.vpnki.ru . Тут совет один - проверьте все еще раз. Если не уверены в пароле, то поставьте на период тестирования пароль 12345. Когда все заработает, то измените на нормальный.

1.3. Следующая причина - ваше соединение НЕ будет принято, если пользователь с таким именем уже подключен. В этом случае вы получите ошибку авторизации.
Если вы некорректно оборвали первое соединение (например, отвалился канал к провайдеру) и вы начали устранавливать его еще раз, то в этом случае наша система может вас не подключить. До того момента, пока не исчетет таймаут неактивности первой сессии.
В некоторых случаях этот таймаут может доходить до 5 минут. Такую ситуацию вы сможете обнаружить в логе "События авторизации" нашей системы.

1.4. Если вы все сделали верно, но соединение не устанавливается, то обратитесь к нам в форум.

Сформулируйте ситуацию, сообщите время/дату неуспешного подключения, тип используемого протокола, а также имя туннеля, чье соединение не установилось.

Результат этого шага - Соединение установлено.

Шаг 2. Подключение установлено, как мне проверить что я на верном пути?

2.1. После установления соединения ваше устройство автоматически получит адрес из сети 172.16.0.0/16.
После этого вы должны успешно пинговать адрес сервера VPNKI путем выполнения команды ping 172.16.0.1 на своем устройстве.
 
Если пинг не проходит, то убедитесь что новый интерфейс на вашей системе создался. Выполните команду ipconfig и убедитесь, что интерфейс pppX с адресом 172.16.x.x создался.

Затем проверьте настройки межсетевого экрана на предмет пропускания трафика протокола icmp для нового интерфейса pppX. Но на 90% там все нормально.

2.2. Пинг адреса 172.16.0.1 проходит, но не сразу.
Это нормальная ситуация. В течение 10-12 секунд после установления соединения система VPNKI ожидает запрос от вашего устройства на получение данных по протоколу DHCP. Такая длительность обусловлена подключением клиентов по низкоскоростным каналам и поэтому мы вынуждены ждать.
Если запрос DHCP не приходит, то маршрутизация вашего трафика начнется через 12 секунд. Если запрос DHCP получен и обработан, то трафик пойдет без задержек.

Результат этого шага - команда ping 172.16.0.1 выполняется успешно.

Шаг 3. Подключение установлено, пинг адреса 172.16.0.1 успешен, что дальше?

Дальнейшие действия связаны с наличием маршрутной информации. Дело в том, что после подключения, адрес сервера VPNKI - 172.16.0.1 является адресом, напрямую подключенным к вашему устройству по каналу точка-точка. По этой причине ваше устройство "знает" об этом адресе и успешно пингует его.
Однако, на этом этапе, ваше устройство не обладает информацией о других адресах вашей сети VPNKI. Первым шагом будет являться "обучение" вашего устройства новому маршруту к сети VPNKI 172.16.0.0/16 .
Именно в этой логической сети находятся все ваши прочие туннели.
Для достижения цели обучения вашего устройства используются два метода:

• получение этого маршрута на ваше устройства от сервера по протоколу DHCP.
• прописывание статического маршрута в ручном режиме в командной строке Windows.
  
  

Если вы настраивали все по инструкции на сайте (с использованием протокола DHCP), то после установления соединения ваше устройство получит информацию о маршруте к сети 172.16.0.0/16

Эта сеть должна быть доступна через адрес сервера VPNKI - 172.16.0.1 .
Проверить это можно выполнив команду route print. В ее длинном выводе вы должны обнаружить следующую строку:

Сетевой адрес   Маска            Адрес шлюза    Интерфейс
172.16.0.0      255.255.0.0      172.16.0.1     172.16.x.x - выданный вам адрес

Если по какой-то причине данная строка не появилась то это означает, что протокол DHCP не отработал и маршрутная информация о сети 172.16.0.0/16 не получена.

В такой ситуации вы сможете выполнить пинг сервера 172.16.0.1, но не сможете выполнить пинг адреса другого туннеля в сети VPNKI. В этом случае имеет смысл разобраться в причине или добавить статический маршрут в ручном режиме.
В качестве обходного маневра вы можете прописать маршрут к сети 172.16.0.0/16 выполнив команду (с правами администратора!)
route add 172.16.0.0 mask 255.255.0.0 172.16.0.1

После этого вы должны успешно выполнить пинг своего "другого устройства", подключенного к сети VPNKI по его адресу 172.16.x.x. Выполните команду ping 172.16.x.x .


Однако обращаем внимание:

- второе устройство также должно содержать в своей таблице маршрутов путь к сети 172.16.0.0/16. Только в этом случае ваше устройство в другом туннеле будет знать куда отправять ответы на пинг.

- на втором вашем устройстве межсетевой экран не должен блокировать ответы на пакеты icmp. Проверить принципиальную возможность ответов устройства на пакеты утилиты ping вы можете с нашей страницы "Инструменты", указав адрес устройства. Если вы уверены, что устройство настроено правильно, но пинги с этой страницы не проходят, то смотрите настройки своего устройства относящиеся к протоколу icmp.

Результат этого шага - наличие маршрута к сети 172.16.0.0/16 в таблице маршрутов Windows устройства. И успешный пинг вашего второго устройства по адресу 172.16.x.x.

Шаг 4. Пинг моего другого устройства по адресу 172.16.x.x успешен, а как выполнить пинг другого устройства по его внутреннему адресу 192.168.x.x?

Дальше начинается действие, ради которого все и затевалось - получение одним устройством c ОС Windows доступа к внутренней сети, расположенной за устройством (маршрутизатором) в вашем другом туннеле. Эти действия связаны с наличием маршрутной информации о сети "за" маршуртизатором и почти аналогичны предыдущему шагу, но с некоторыми отличиями. Теперь нам необходимо не только обучить ваш Windows "знанию" о сети 172.16.0.0/16 . Это было выполнено на предыдущем шаге. Теперт надо дать ему информацию о сети, расположенной "за" маршрутизатором вашего второго туннеля.

Прежде чем приступить к этому шагу вы должны убедиться в том, что сеть "за" вашим маршрутизатором НЕ пересекается с сетью, в которую подключена ваша Windows машина. То есть, если ваш Windows находится в сети 192.168.0.0/24 (например дом) и такая же сеть 192.168.0.0/24 расположена за вторым устройством (например дача), то такая конфигурация будет некорректной и из нее есть два выхода:

- перенастроить одну из сетей на другую схему адресации, например 192.168.1.0/24

- осуществить трансляцию портов на вашем втором устройстве в адрес, полученный от сети vpnki 172.16.x.x . Эту конфигурацию мы не будем рассматривать в рамках настоящего документа.

Итак, если вы имеете разные сети, то теперь нам необходимо сообщить вашему Windows устройству о наличии сети, например 192.168.1.0/24, расположенной за ваш вторым туннелем. Для этого вам необходимо на вашей персональной странице настроек VPNKI, для второго вашего туннеля (например дача) отметить галочкой то, что вы настраиваете маршуртизатор и за ним расположена сеть 192.168.1.0/24. Примененная на этой странице настройка добавит эту сеть в протокол DHCP и передаст в ваше Windows устройство при следующем подключении.

Проверить это вы сможете выполнив команду route print. В ее длинном выводе вы должны обнаружить следующую строку:

Сетевой адрес       Маска            Адрес шлюза         Интерфейс
192.168.1.0          255.255.255.0    on-link             172.16.x.x - выданный вам адрес

Если по какой-то причине данная строка не появилась это означает, что протокол DHCP не отработал и маршрутная информация не получена. В этом случае имеет смысл разобраться в причине или добавить статический маршрут в ручном режиме.
В качестве обходного маневра вы можете прописать маршрут к сети 192.168.1.0/24 выполнив команду (с правами администратора!)
route add 192.168.1.0 mask 255.255.255.0 172.16.0.1

После этого вы должны успешно выполнить пинг своего "другого устройства", подключенного к сети vpnki по его внутреннему адресу (например 192.168.1.1), выполнив команду ping 192.168.1.1

Однако обращаем внимание:

- на то, что второе устройство (маршрутизатор) должно содержать в своей таблце маршрутов путь к сети 172.16.0.0/16 для отправки ответов на ваш пинг.

- на втором вашем устройстве (маршрутизаторе) межсетевой экране не должен блокировать ответы на пакеты icmp .

Результат этого шага - наличие маршрута к сети 192.168.1.0/24 в таблице маршрутов Windows устройства и успешный пинг вашего второго устройства по внутреннему адресу 192.168.1.x.

PS: В целях борьбы с зависшими сессиями мы принудительно отключаем пользовательские туннели с протоколами PPTP, L2TP, L2TP/IPsec, IKEv2/IPsec, SSTP через 24 часа после установления соединения. При правильной настройке соединения должны автоматически переустановиться.

ДОПОЛНИТЕЛЬНО ПО ТЕМЕ:

• Ознакомьтесь с настройками и работой нашей услуги "Публикация URL". Она поможет вам организовать удаленный доступ по протоколам http и https к своим ресурсам.

• Озанакомьтесь с работой и настройками нашей услуги "Проброс TCP порта". Она поможет вам опубликовать в сети Интернет TCP порт вашего устройства.

• Ознакомьтесь с настройками и приниципами работы услуги "Доступ через HTTP и SOCKS5 прокси". Она даст вам возможность удаленного доступа через прокси.