Во-первых, эта проблема существует уже почти два года. Пока не появился serverfault, я почти отказался от его решения, но теперь надежда возродилась!
Я установил сервер Windows 2003 в качестве контроллера домена и VPN-сервер в удаленном офисе. Я могу без проблем подключаться и работать через VPN из любого клиента Windows, который я пробовал, включая XP, Vista и Windows 7, по крайней мере из пяти разных сетей (корпоративная и домашняя, доменная и не только). от всех них.
Однако всякий раз, когда я подключаюсь от клиентов на мой в домашней сети соединение разрывается (беззвучно) через 3 минуты или меньше. Через некоторое время он в конечном итоге сообщит мне, что соединение разорвано, и попытается повторно набрать номер / повторно подключиться (если я настроил клиент таким образом). Если я снова подключусь, соединение восстановится и будет работать правильно, но снова тихо упадет, на этот раз после, казалось бы, более короткого периода времени.
Это не прерывистые капли. Это происходит каждый раз точно так же. Единственная переменная - как долго сохраняется соединение.
Неважно, какой тип трафика я отправляю. Я могу сидеть без дела, отправлять непрерывные пинги, RDP, передавать файлы и все это сразу - это не имеет значения. Результат всегда один и тот же. Подключился на несколько минут, потом тихая смерть.
Поскольку я сомневаюсь, что кто-то сталкивался с этой конкретной ситуацией, какие шаги я могу предпринять, чтобы устранить неполадки в моем исчезающем VPN?
В течение этого двухлетнего периода я сменил провайдеров (на обоих концах), добавил новый контроллер домена (моя сеть) и поменял маршрутизаторы (обе сети). Ничего из этого не повлияло.
Проблема воспроизводится на нескольких ПК с разными ОС, но только в моей сети.
Я подтвердил, что поведение не зависит от клиента, протестировав на устройстве, отличном от Windows. Я настроил VPN на своем iPhone и подключился через Wi-Fi по моей сети. Используя приложение под названием Scany, я постоянно проверял связь с сервером, пока соединение не разорвалось примерно через 2 минуты - такое же поведение я наблюдал на клиентах Windows. После этого я отключил Wi-Fi и VPN через AT&T 3G и постоянно пинговал без потерянных запросов в течение 11 минут. Этот тест адекватно изолировал проблему от моей сети.
Единственный стабильный компонент за два года - это мой контроллер домена, который обрабатывает WINS, а также действует как VPN-сервер для входящих подключений. Но исходящий трафик не должен проходить через мой DC, он идет прямо на брандмауэр / маршрутизатор, который подключен непосредственно к моему кабельному модему.
Был сделан запрос, чтобы я проверял, что мои маршруты не вызывают сбоев при установке VPN-соединения. Я посмотрел и не увидел ничего явно неправильного, но мой опыт настройки маршрута довольно ограничен, поэтому я публикую данные.
Диапазон класса C моей локальной сети - 192.168.1.255, диапазон класса C удаленной локальной сети - 192.168.10.255. Я также замаскировал публичный IP-адрес VPN-сервера (74.93.XXX.XXX).
>route print (VPN Disconnected)
===========================================================================
Interface List
17...00 ff 10 80 57 0c ......Juniper Network Connect Virtual Adapter
11...00 23 ae e6 bb 49 ......Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit
Ethernet NIC (NDIS 6.20)
1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.24 10
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
192.168.1.0 255.255.255.0 On-link 192.168.1.24 266
192.168.1.24 255.255.255.255 On-link 192.168.1.24 266
192.168.1.255 255.255.255.255 On-link 192.168.1.24 266
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 192.168.1.24 266
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 192.168.1.24 266
===========================================================================
Persistent Routes:
None
>route print (VPN Connected)
===========================================================================
Interface List
25...........................VPN Test
17...00 ff 10 80 57 0c ......Juniper Network Connect Virtual Adapter
11...00 23 ae e6 bb 49 ......Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit
Ethernet NIC (NDIS 6.20)
1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.24 10
74.93.XXX.XXX 255.255.255.255 192.168.1.1 192.168.1.24 11
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
192.168.1.0 255.255.255.0 On-link 192.168.1.24 266
192.168.1.24 255.255.255.255 On-link 192.168.1.24 266
192.168.1.255 255.255.255.255 On-link 192.168.1.24 266
192.168.10.0 255.255.255.0 192.168.10.134 192.168.10.134 11
192.168.10.134 255.255.255.255 On-link 192.168.10.134 266
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 192.168.1.24 266
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 192.168.1.24 266
255.255.255.255 255.255.255.255 On-link 192.168.10.134 266
===========================================================================
Persistent Routes:
None
Огромное спасибо @Warner и @William за их предложения. В конечном итоге именно ответ Уильяма привел меня к окончательному решению. Для всех, кто приходит на поиски, вот сделка.
После тонны возни, пытаясь изолировать проблему, я, наконец, сделал, как предложил Уильям, и открыл журналы брандмауэра. Не ожидая найти ничего интересного, я был удивлен, увидев эту строчку:
PPTP ALG отклонил пакет от xxxx до xxxx: 1723
Зная, что PPTP - это то, как настроен этот VPN, я немного искал ошибку. Оказывается, другие люди иметь видел это также. В частности, люди с моим точным роутером, D-Link DIR-655.
Решение, оказывается, простое.
В интерфейсе веб-администрирования маршрутизатора перейдите на вкладку «Дополнительно» и нажмите «Параметры брандмауэра» в левом меню. В разделе «КОНФИГУРАЦИЯ ШЛЮЗА УРОВНЯ ПРИЛОЖЕНИЯ (ALG)» снимите флажок для PPTP (при желании также снимите флажок IPsec, если ваш VPN использует этот протокол). Нажмите «Сохранить настройки» и попросите маршрутизатор перезагрузиться. Вуаля!
К сожалению, отключение этих параметров ALG означает, что некоторые расширенные функции маршрутизации не будут работать. Например, поддержка PPTP предназначена для того, чтобы несколько клиентов с NAT могли одновременно туннелировать к одному и тому же серверу VPN. Вероятно, это не сработает, если флажок снят. Однако, как и я, ваш VPN вообще не работает, когда поле является проверил, вы наверное не против.
Мне до сих пор неясно, почему я, кажется, вспоминаю, что раньше у меня была эта проблема с совершенно другим маршрутизатором, но я рад, что, тем не менее, он работает.
Предположительно, существует компонент трафика VPN, который требуется, но блокируется (например, брандмауэром) или теряется, вызывая отключение. Проверьте журналы брандмауэра, если они у вас есть на наличие отброшенных пакетов. Дважды проверьте правила, чтобы убедиться, что все необходимые порты и протоколы включены. Вы также можете выполнить непрерывный мониторинг маршрута на своей стороне, чтобы увидеть, не направлен ли трафик неправильно после подключения VPN-туннеля. Команда "route print" показывает эту информацию в Windows.
У меня была такая же ошибка с openwrt и luci, я подключался через vpn к моему серверу openvpn на моем маршрутизаторе. Соединение будет установлено, затем он продолжит перезагружать мой модем 3g и терять мое соединение, ответ был в брандмауэре (спасибо, что указали направление) и отредактировал соединение: 1194. Здесь у вас есть выбор, откуда исходило соединение vpn, и по умолчанию это было устройство, два других варианта, где LAN и WAN, так что для моей ситуации это был WAN, быстрое изменение и перезапуск, и отлично работает ..
Устранение основных неисправностей. Устраните оборудование. Интернет-соединение напрямую с ПК. Если воспроизводимый, другой ПК. Замените модем, попробуйте другого провайдера (сотовый модем). Продолжайте движение по линии до тех пор, пока не будет изолировано, а затем устраните неисправность оборудования, к которому она изолирована.