Я использую VPN для подключения к работе. Я привык слушать потоковую музыку, когда нахожусь в офисе, но когда я делаю это через VPN, соединение обрывается. Так что ничего страшного, я просто не буду использовать потоковую музыку, когда я использую VPN.
Но у меня только что была встреча с офисом по Skype, и я потерял VPN. Итак, теперь это мешает мне, и я хочу это исправить. Есть идеи, где мне искать?
Я запускаю Server 2008 на ноутбуке, использую беспроводное соединение в моем доме для приличного, надежного соединения DSL. Я использую встроенный в Windows VPN-клиент.
обновление: со стороны офиса VPN находится на брандмауэре DLink - это PPTP с 128-битным шифрованием MPPE.
обновление: я полагаю, это связано с проблемой задержки DPC, которая, кажется, преследует многие ноутбуки на рынке. Я все еще не решил проблему. В моем случае я использую Dell Studio XPS 16, который является одним из ноутбуков с этой проблемой. Я надеюсь, что в конце концов найду правильное сочетание драйверов для решения проблемы.
Я столкнулся с подобными проблемами при использовании подключения Windows VPN к нашему главному офису и обнаружил следующее.
Обязательно ограничивайте восходящий (и, возможно, нисходящий) трафик для любых интенсивно используемых систем в вашей сети. Мой выделенный торрент-ящик настроен так, что он не съедает всю мою трубу и не вызывает проблем. Даже при включенном QOS для определения приоритета трафика VPN он имеет тенденцию падать, если я насыщаю канал и увеличиваю задержку, с которой соединение должно иметь дело. Соединения PPTP vpn довольно привередливы, когда дело доходит до задержки, они, как правило, ОЧЕНЬ быстро обрываются.
Я также заметил в вашем вопросе, что вы сказали, что транслируете музыку через VPN-соединение? Знаете ли вы, что по умолчанию подключения Windows VPN настроены на отправку всего трафика через удаленный шлюз по умолчанию? Это сделано для того, чтобы вы могли маршрутизировать через VPN в другие сети, которые могут не находиться в той же подсети, что и ваше соединение. Вы можете легко обойти это, отключив «использовать шлюз по умолчанию в удаленной сети» здесь: Свойства соединения -> Вкладка «Сеть» -> Свойства TCP / IP -> Кнопка «Дополнительно» -> Вкладка «Общие»
После проверки это будет отправлять только трафик, предназначенный для удаленной подсети, через ваше VPN-соединение, позволяя вашей потоковой музыке выходить из вашего локального сетевого соединения без инцидентов. Я считаю это чрезвычайно полезным, когда вы пытаетесь просматривать веб-страницы во время работы в удаленной сети, вы получаете локальную скорость для всего, кроме удаленной локальной сети.
ПРИМЕЧАНИЕ: если ваше устройство сервера pptp назначает IP-адреса вашей клиентской системе, которая находится в отдельной подсети, чем сеть, к которой вы пытаетесь добраться, вам, возможно, придется обойти это.
Пример: Сетевой адрес LAN на удаленном сайте: 192.168.0.0/24 Сетевой адрес LAN у вас дома: 172.16.7.0/24 Подсеть VPN, назначенная клиентам на маршрутизаторе при подключении: 192.168.254.0/24
Таким образом сервер Windows обрабатывает VPN-соединения, когда вы используете RRAS для размещения VPN-соединений, и я видел, как маршрутизаторы обрабатывают соединения таким образом.
Обходной путь: вам нужно будет либо вручную запустить команду маршрута, чтобы добавить запись в таблицу маршрутизации после подключения к VPN, команда будет выглядеть примерно так: route ADD network_to_reach MASK subnet_mask gateway_ip_of_vpn_connection (возможно) route add 192.168.0.0 MASK 255.255 .255.0 192.168.254.1
Это сообщит вашей машине, что она должна использовать маршрутизатор 192.168.254.1 для доступа к любой системе в сети 192.168.0.0/24. Системы внутри сети будут использовать маршрутизатор, на котором установлено соединение, в качестве шлюза по умолчанию, поэтому им не нужно будет указывать, как вернуться в вашу систему.
Это можно автоматизировать и добавить к VPN-соединению. Вот как мы управляем и разворачиваем клиентов в нашем офисе, и это работает ОЧЕНЬ хорошо. Вы можете использовать Microsoft CMAK (пакет администрирования диспетчера подключений) для создания «коннектоида» VPN, который содержит инструкции по автоматизации, включая маршруты для добавления, сценарии для запуска на разных этапах процесса подключения и отключения, а также некоторые другие полезности, которых я никогда не касался. .
Надеюсь, это решит ваши проблемы и поможет вам подключиться к VPN во время прослушивания ваших мелодий, а также поможет некоторым другим достичь состояния VPN ZEN.
Скорее всего, у вас есть первопричина: как маршрутизируется трафик.
Например, прослушивание потоковой музыки не должно быть проблемой - потому что это НЕ должно проходить через VPN.
Точно так же я бы поспорил, если вы используете обычный видеоклиент для своих конференций, такой как Skype, тогда вам все равно не нужен этот трафик, проходящий через VPN. Очевидно, это может не применяться, если вы подключаетесь к видеомосту за корпоративным брандмауэром.
Если вы используете клиент Windows VPN, существует простой способ отправлять не-VPN трафик через локальный шлюз. Если вы используете сторонний клиент, вам нужно будет обратиться к его документации.
Что вы можете захотеть рассмотреть, так это размер пакета. Потоковая передача и скайп наверняка будут генерировать некоторые большие пакеты, а vpn иногда не работает с большими пакетами, поскольку они добавляют свои заголовки и иногда превышают MTU.
Быстрый взлом - это понизить MTU на вашем клиенте до низкого значения (~ 1000 Б). Это быстро поможет вам определить, действительно ли проблема в размере пакета.
Если я правильно помню, MTU устанавливается в реестре под Windows ...
Насколько быстро у вас соединение (обычная ожидаемая скорость, а не скорость заголовка «до») и с какой скоростью идет потоковая передача звука?
Возможно, дополнительный трафик задерживает пакеты и ответы VPN, которые клиент VNOP рассматривает как разрыв соединения. При современной настройке (то есть без коммутируемого доступа) я бы не ожидал, что одного входящего аудиопотока будет достаточно, чтобы заполнить ваш нисходящий поток до точки, где затронут другой трафик, но если у вас есть соединение с очень небольшой восходящей скоростью, исходящий Данных Skype может быть достаточно, чтобы вызвать измеримые задержки.
Если проблема связана с проблемами задержки, вызванными другим трафиком, вы можете попробовать две вещи: посмотреть, есть ли какие-либо настройки тайм-аута в VPN-клиенте, которые вы можете изменить и которые в настоящее время очень низкие, и / или попробуйте формирование трафика ваш конец (хотя это поможет только в том случае, если полоса пропускания восходящего потока насыщена, а не нисходящего, поскольку вы не можете напрямую управлять нисходящим потоком).
Вероятно, лучше использовать одни и те же инструменты с обеих сторон. Например, вы упомянули, что запускаете VPN-сервер на DLink, я бы сказал, попробуйте VPN-клиент, предоставленный Dlink, и посмотрите, станет ли он лучше. Или включите RRAS на своем сервере Server 2008 и подключитесь к нему, используя соединение Windows VPN, и посмотрите, имеет ли это значение.
Некоторое время назад у нас была такая проблема с одним из продуктов VPN, которые мы использовали. Он был нетерпим к прибытию пакетов вне очереди и завершал сеанс VPN, когда это происходило. В то время в работе использовалась пара связанных T1, что приводило к некоторым проблемам с нарушением порядка для ряда протоколов. TCP якобы терпим к этому, но не все протоколы, использующие TCP.
Возможно, вы захотите изучить маршрутизатор с QoS, чтобы VPN-соединение получило приоритет над другими пакетами.
Другая вещь, которая может быть причиной (как упоминалось другими), - это проверка вашей пропускной способности восходящего потока. Обычно пропускная способность нисходящего потока довольно высока, но восходящий поток ограничен (256 КБ или 356 КБ). Возможно, вы захотите изменить свой тарифный план широкополосного доступа, если восходящий поток действительно невелик.
-JFV
Соединение PPTP действительно два соединения, контрольное соединение и соединение для передачи данных. Это само по себе проблема маршрутизаторов и особенно межсетевых экранов.
Ухудшение (и продвижение) размеров пакетов является частью протокола, поэтому я не понимаю, как это может быть проблемой, если у вас нет действительно паршивой линии - потому что тогда размер вашего пакета может упасть до 1, и ваш исходящий поток будет уменьшен к плохой скорости аналогового модема из-за накладных расходов протокола.
Но что немного хуже, если управляющее соединение получает пакеты не по порядку, все VPN-соединение разрывается. Или контрольное соединение «переполнено» соединением для передачи данных, что приводит к тайм-ауту и, следовательно, к разрыву всего VPN-соединения.
Вы упоминаете Skype, и, насколько мне известно, Skype использует максимальную пропускную способность для обеспечения плавного изображения и хорошего звука. Даже звуковые соединения Skype используют до 16 кбайт / с, что соответствует примерно 128 кбит / с, поэтому, если ваш восходящий поток ADSL даже близок к этому, это может быть проблемой, особенно с учетом того, что вы можете добавить накладные расходы протокола для своего VPN-соединения. Видео еще больше усугубляет эти проблемы с пропускной способностью.
Поэтому, если у вас есть возможность реализовать QoS на вашей линии ADSL (т. Е. Ваш маршрутизатор поддерживает его), установите высокий приоритет для порта 1723 TCP (который является вашим управляющим соединением), прямо под ICMP. Это могло бы помочь.
Несколько вещей для начала:
1) Какой конец сбрасывает соединение? При включенном VPN запускайте эхо-запросы в обоих направлениях и выполняйте захват пакетов на обоих концах, в идеале как зашифрованного, так и незашифрованного трафика. Сделайте так, чтобы он потерпел неудачу, и посмотрите, что произойдет; вы, вероятно, обнаружите, что один конец отправляет пакеты, а другой конец либо молча сбрасывает их на пол, либо активно их отклоняет.
2) Начните упрощать вещи и пробуйте снова на каждом этапе; удалите беспроводную связь и подключите ее непосредственно к маршрутизатору. Обойдите маршрутизатор и подключите его напрямую к модему. Сделайте то же самое на другом конце. Вы можете определить некоторые формы проблем с NAT, удалив маршрутизаторы из уравнения и поместив свой общедоступный IP-адрес непосредственно в конечный комплект; количество сетевого оборудования с NAT или ALG ошибок поражает.
3) Проверьте журналы событий VPN и журналы брандмауэра, чтобы узнать, дают ли они какое-либо представление о том, почему туннель VPN умирает. Как минимум, они должны регистрировать сбой и, в идеале, причину.
4) Попробуйте другой компьютер, попробуйте другую ОС. Посмотрите, сможете ли вы найти комбинацию, которая работает.
Как только вы найдете неисправное оборудование, вы можете продолжить поиск и устранение неисправностей; вам может потребоваться обновить прошивку устройства, добавить несколько записей NAT / переадресации портов или настроить набор правил брандмауэра. Если это относится к машине, может потребоваться перестройка или сброс сетевого стека (некоторые приложения Broadband Optimiser могут ужасно нарушить конфигурацию сетевого стека, а другие приложения, которые внедряются в сетевой стек, могут искажать пакеты).
Если проблема связана с недостаточной пропускной способностью, то, вероятно, проблема заключается в пропускной способности восходящего потока (при условии, что вы используете асинхронное соединение).
Голос будет использоваться где-то в диапазоне от 4 Кбайт / сек до 11 Кбайт / сек в восходящем потоке, когда вы говорите. Прослушивание музыки само по себе является противоположным направлением, поэтому не должно ни на что влиять. Вы случайно не используете Spotfire для прослушивания музыки или что-то еще, что работает в одноранговой сети, и, таким образом, используете все ваши апстримы?
Я сомневаюсь, что это ваша проблема, но на это стоит обратить внимание. Я управляю несколькими концентраторами vpn серии Cisco VPN3000, и из-за криптографии, которую они выполняют, они гораздо больше ограничены процессором, чем полосой пропускания. Несмотря на то, что соединение установлено на 100 Мбит / с (и у него более чем достаточно пропускной способности интернета для его насыщения, большое спасибо, задержка устройства значительно увеличивается, и устройство начинает отбрасывать пакеты. Возможно, устройство, которое вы упомянули, обрабатывает проблемы с пропускной способностью / ЦП из-за разрыва соединений, а не из-за ухудшения работы.