Windows VPN завжди відключається через <3 хвилини, тільки від моєї мережі


11

По-перше, ця проблема існує майже два роки. Поки не народився сервер за замовчуванням, я майже відмовився від вирішення цього питання - але тепер надія відродилася!

Я створив сервер Windows 2003 як контролер домену та сервер VPN у віддаленому офісі. Я маю змогу підключитися до VPN і працювати з кожним клієнтом Windows, який я пробував, включаючи XP, Vista та Windows 7 без проблем, як мінімум з п'яти різних мереж (корпоративної та домашньої, доменних та інших). Це прекрасно працює від усіх них.

Тим НЕ менше, всякий раз , коли я підключаю від клієнтів на моїй домашній мережі, з'єднання падає (тихо) через 3 хвилини або менше. Через деякий час, врешті-решт, це скаже мені, що з'єднання впало і спробу повторного набору / повторного підключення (якщо я налаштував клієнта таким чином.) Якщо я знову підключуюся, з'єднання відновиться і, здається, працює правильно, але знову мовчки впаде, цього разу після, здавалося б, коротшого періоду часу.

Це не переривчасті краплі. Це відбувається кожен раз, абсолютно однаково. Єдина змінна - це те, як довго збережеться з'єднання.

Не має значення, який тип трафіку я надсилаю. Я можу сидіти в режимі очікування, надсилати безперервні пінг-файли, RDP, передавати файли, і все це відразу - це не має значення. Результат завжди однаковий. Підключились на кілька хвилин, потім мовчазна смерть.

Оскільки я сумніваюся, що хтось стикався з такою точною ситуацією, які кроки я можу зробити, щоб усунути свою VPN, що ухиляється?


Додатковий фон

Протягом цього дворічного періоду я змінив Інтернет-провайдери (на обох кінцях), додав новий контролер домену (моя мережа) та змінив маршрутизатори (обидві мережі). Ні на що це не вплинуло.

Проблема може бути відтворена з декількох ПК, з різними ОС, але тільки з моєї мережі.

Я перевірив, що поведінка є агностичним клієнтом, тестуючи на пристрої, який не працює під Windows. Я налаштував VPN на своєму iPhone та підключився через wifi через свою мережу. Використовуючи додаток під назвою Scany, я постійно пінгував сервер до тих пір, поки з'єднання не впало приблизно через 2 хвилини - така сама поведінка, яку я спостерігав у клієнтів Windows. Згодом я відключив Wi-Fi та VPN-та над AT & Ts 3G і безперервно пінгував без втрачених запитів протягом 11 хвилин. Цей тест адекватно виділив проблему в моїй мережі.

Єдиний послідовний компонент протягом двох років - мій контролер домену, який обробляє WINS, а також виконує функції VPN-сервера для вхідних з'єднань. Але вихідний трафік не повинен проходити через мій постійний струм, він прямує до брандмауера / маршрутизатора, який підключений безпосередньо до мого кабельного модему.

Більше приміток

Був зроблений запит, щоб я перевірив, що мої маршрути не є фальшивими, коли встановлено з'єднання VPN. Я подивився і не бачу нічого очевидно неправильного, але мій досвід конфігурації маршруту досить обмежений, тому я публікую дані.

Діапазон класу С моєї локальної мережі - 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

Оскільки ви намагалися вирішити це раніше, чи можете ви повідомити нам те, що ви вже пробували, щоб ми не переосмислили речі, які досі не працювали для вас?
Зіфер

Більшість того, що я "пробував", стосувалось пошуку "Мережі" для пов'язаних з цим питань, що в кінцевому підсумку виявилося дуже мало. Одне питання, яке може бути або не бути актуальним, це те, що сервер VPN має деякі проблеми з налаштуванням. Наприклад, щоб спілкуватися з ним, коли VPN підключено, я повинен використовувати його IP, а не його ім'я (я зазвичай редагую файл хостів на кожному підключеному клієнті.) Також я завжди відключаю "Використовувати шлюз за замовчуванням" під час підключення до VPN, оскільки його маршрутизація RAS неправильно налаштована. Однак ці проблеми не викликали проблем під час підключення з будь-якої іншої мережі.
конопля

Відповіді:


8

Величезне дякую @Warner та @William за їх пропозиції. Зрештою, відповідь Вільяма привела мене до остаточної резолюції. Для всіх, хто приходить шукати, ось угода.

Після тонни возитися, намагаючись вирішити проблему, я нарешті зробив це, як запропонував Вільям, і підтягнув мої журнали брандмауера. Не сподіваючись знайти щось цікаве, я здивувався, побачивши цей рядок:

PPTP ALG відхилив пакет з xxxx до xxxx: 1723

Знаючи, що так налаштовано цей VPN, я здійснив пошук помилки. Виявляється, це бачили і інші люди . Зокрема, люди з моїм точним маршрутизатором , D-Link DIR-655.

Рішення, виявляється, просте.

У інтерфейсі веб-адміністрування маршрутизатора перейдіть на вкладку Додатково та натисніть Налаштування брандмауера в меню зліва. У розділі з написом "КОНФІГУРАЦІЯ РІВНЯ ЗАЯВКИ ПРИМІЩЕННЯ (ALG) CONFIGURATION" зніміть прапорець для PPTP (необов'язково, також зніміть прапорець IPsec, якщо ваш VPN використовує цей протокол.) Клацніть "Зберегти налаштування" та скажіть маршрутизатору перезавантажитися. Вуаля!

На жаль, відключення цих параметрів ALG означає, що деякі розширені функції маршрутизації не працюватимуть. Наприклад, підтримка PPTP призначена для того, щоб дозволити декільком клієнтам NAT'd тунель на один і той же VPN-сервер одночасно. Це, ймовірно, не вийде, якщо поле очиститься. Однак, якщо, як я, ваша VPN не працює взагалі, коли прапорець встановлений , ви, мабуть, не проти.

Мені все ще незрозуміло, чому я, начебто, згадую, що раніше ця проблема була з абсолютно іншим маршрутизатором, але я щаслива, що вона працює.


У мене була подібна проблема, і що ви знаєте ... той самий маршрутизатор D-Link. Ваше рішення спрацювало. Дякую! Цікаво, що у мене ніколи не було проблем з моїм VPN, поки я не вставив пристрій Vonage VDV21-VD між кабельним модемом і моїм маршрутизатором D-Link.
статик

Які журнали брандмауера показують вам це повідомлення? Я припускаю, що не журнали брандмауера на вашому VPN-клієнті чи VPN-сервері.
Ян Бойд

@Ian: Ні, брандмауер - це сам DIR-655. Ось де знаходяться журнали (можна переглянути через їх веб-інтерфейс.)
конопля

1
Це вирішило і це питання для мене. Лише вгору: додаючи переадресацію порту, необхідну VPN.
червоний

2

Як здогадується, є компонент трафіку VPN, який необхідний, але його блокують (наприклад, на брандмауері) або втрачають і спричиняють випадання. Перевірте журнали брандмауера, чи є вони у вас для скинутих пакетів. Двічі перевірте правила, щоб забезпечити включення всіх необхідних портів та протоколів. Ви також можете зробити постійний моніторинг маршруту на своєму кінці, щоб побачити, чи трафік неправильно спрямований після появи тунелю VPN. Команда "Друк маршруту" відображає цю інформацію в Windows.


Це чудові пропозиції, Вільям. Дякую. Я повернуся зі своїми результатами.
конопля

Я розмістив свої маршрути як правки до питання.
конопля

Ця відповідь привела мене до остаточної резолюції, яку я окремо документував. Дякую за твою допомогу!
конопля

1

У мене була така ж помилка з openwrt і luci, я б підключився через vpn до мого сервера openvpn на моєму маршрутизаторі. Підключення буде встановлено, тоді він продовжуватиме перезапуск мого 3g модему та втрачає моє з'єднання, відповідь була в, брандмауер (дякую за вказівку напрямку) та редагувати з'єднання: 1194. Тут у вас є вибір, звідки надходило з'єднання vpn, і за замовчуванням це був пристрій, інші два варіанти, коли lan та wan, тому для моєї ситуації це було WAN, швидка зміна та перезапуск та працює чудово.


0

Основне усунення несправностей. Усуньте обладнання. Підключення до Інтернету безпосередньо до ПК. Якщо можна відтворити, інший ПК. Замініть модем, спробуйте різні провайдери (модем стільникового зв'язку). Продовжуйте рух по лінії до тих пір, поки не буде вирішено проблему, а потім усуньте несправності з обладнанням, від якого вона ізольована.


Дякуємо за пропозиції. У цьому напрямку, ось що я можу додати: За цей дворічний період я змінив Інтернет-провайдери (на обох кінцях), додав новий контролер домену (моя мережа) та змінив маршрутизатори (обидві мережі). Ні на що це не вплинуло. Підключення VPN-сервера безпосередньо до Інтернету не відбудеться навіть протягом декількох хвилин, тож цього немає. Проблема може бути відтворена з декількох ПК, з різними ОС, але тільки з моєї мережі. Однак це дало мені ідею спробувати його від клієнта, який не є Windows, що я спробую зараз.
конопля

Ваша робоча мережа вже поза сферою, як ви заявили самі, вона ізольована від вашої мережі. Це здається, що це ваше з'єднання або мережеве обладнання. Підключіть домашнє з'єднання безпосередньо до відомого робочого ПК проти VPN.
Warner

Я налаштував VPN на своєму iPhone та підключився через Wi-Fi через свою мережу. Використовуючи додаток під назвою Scany, я постійно пінгував сервер до тих пір, поки з'єднання не впало приблизно через 2 хвилини - така сама поведінка, яку я спостерігав у клієнтів Windows. Згодом я відключив Wi-Fi та VPN-та над AT & Ts 3G і безперервно передавав повідомлення без втрачених запитів протягом 7 хвилин (і рахував). Цей тест адекватно ізолює проблему в моїй мережі. Однак я вже робив це - тому він пропонує мало нової інформації, за винятком того, що поведінка є агностичною.
конопля

FYI - той пінг без проблем пробіг 11 хвилин, перш ніж я набрид і вбив його.
конопля

1
Вимкніть постійний струм. Чи проблема продовжується? Підключіть свою робочу станцію безпосередньо до Інтернету. Це продовжується? Яке обладнання було усунуто підключенням безпосередньо до Інтернету?
Уорнер
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.