Итак, чтобы понять причины низкой скорости, предлагаю вначале рассмотреть простое соединение компьютера пользователя с Интернет (а именно с каким-либо сайтом) без канала VPN. Как происходит соединение? Думаете так?

Прямое соединение

Ничего подобного! На самом деле всё гораздо сложнее. Рассмотрим частный случай подключенного к Интернету компьютера в квартире какого-либо пользователя с использованием беспроводного канала.

Схематическое изображение сети

Компьютер общается с «внешним миром» отправляя данные и принимая их. Данные отправляются пакетами определённой длины. Если полная длина пакета, отправляемого компьютером больше, чем обозначенная в настройках сетевого интерфейса,  то пакет «разрезается» на две (или больше) части, причем все кроме последней имеют длину указанной величины. Этот параметр (длина пакета) называется MTU. Тоже самое происходит при приёме пакетов. Если пакет большей длины, чем установленная величина он будет разрезан и передан более, чем за одну отправку.
Итак, первым узлом, который получает пакеты от компьютера пользователя, является на данной схеме беспроводной маршрутизатор (A). Заметьте, мы не случайно изобразили его совместно с небольшим значком «кирпичная стена». Этот значок означает присутствие в устройстве файерволла или специального функционала, позволяющего управлять трафиком. В большинстве моделей современных беспроводных маршрутизаторов этот функционал имеется.
Затем пакеты уже по проводному каналу, предоставляемым провайдером уходят в сетевое оборудование этого самого провайдера (B, C). Тут следует также упомянуть, что оборудование провайдера может также содержать файерволл и прочий функционал для управления трафиком.
Так почему мы так акцентируемся на этом функционале? Да потому что он может влиять на прохождение определённых пакетов через оборудование, на котором расположен. Допустим, если на файерволле будут настройки, запрещающие соединение, например, по протоколу HTTP, то большинство сайтов просто не откроются.
Но функциональность файерволлов не ограничивается только возможностью запрета или разрешения прохождения трафика. Существует ещё возможность ограничения пропускной способности для пакетов определенного типа (это называют шейпированием). Шейпирование применяется для приоритезации трафика, чтобы «более важным» пакетам предоставлялся более широкий канал, а «менее важным» - то, что осталось от основного после занятия выделенной для важных пакетов полосы. Решение о том, какой трафик будет более важным в вашей сети, принимает вовсе не пользователь, а администратор этой сети. И какое решение он примет – это большой вопрос. Возможно он решит, что более важен трафик http (т.е. просмотр сайтов) и отдаст для него 95% пропускной способности интернет-канала. В таком случае для организации VPN останется всего 5% «ширины» канала и тут уж всё будет зависеть от того, насколько он у вас широкий. Естественно, что если у вас канал 0,5 мБ/сек – то тут и без шейпирования хорошего VPN вы не получите.
Далее, оборудование провайдера передаёт пакеты от вашего компьютера на коммутационное оборудование (D), которое, используя различные технологии, определяет по какому маршруту направить их. Тут тоже есть нюансы. Допустим, что на основном канале в данное время произошла авария. В таком случае оборудование провайдера перенаправит ваши пакеты в резервный канал (каждый уважающий себя провайдер имеет таковые), но резервный канал может иметь гораздо меньшую пропускную способность. И тут опять может иметь место шейпирование, ибо в аварийной ситуации приоретизация трафика играет гораздо большую роль, чем в повседневной работе.
Продолжим рассуждать о каналах. Вероятно, не нужно объяснять, что пропускная способность оптоволоконных линий в разы превышает скорость передачи данных в старых добрых «медных» сетях. В настоящее время, большинство магистральных каналов уже используют оптическую передачу данных. Но всё же остаются участки, которые работают на «старых» проводах. Причём «старых» здесь будет иметь не только смысл «старые добрые провода», но и тот, что провода реально старые. Они трескаются, лопается изоляция и иногда рвутся. Вот тут ещё один момент. Допустим, на определённом участке произошёл разрыв кабеля связи, по которому как раз и течёт «река» вашего трафика. Туда был отправлен специалист-монтажник, который (к сожалению) оказался довольно нерадивым и вместо того, чтобы произвести замену или грамотное восстановление целостности кабеля по всем правилам, просто взял зачистил и скрутил жилки кабеля в месте разрыва. Канал при этом, несомненно восстановиться, но качество его в таком случае будет значительно хуже. Такой болезнью (наличие скруток) страдал большой сегмент сети очень старого провайдера в нашем городе. Не исключено, что таковая может присутствовать и в ваших сетях.
Ну далее из магистральных каналов ваши пакеты будут переданы на оборудование провайдера (F), где опять же стоит управляющий трафиком механизм файерволлов и приоритезации, и только за тем уже на сам веб-сервер, где размещён интересующий вас сайт.
Итого 6 шагов в одну сторону и столько же в обратную (естественно, в обратном порядке)
1.    Соединение компьютера с домашним WiFi-роутером
2.    Соединение роутера с оборудованием провайдера
3.    Соединение оборудование провайдера с глобальными коммутационными узлами
4.    Выбор глобальными коммутационными узлами оптимального маршрута для передачи данных
5.    Передача данных к провайдеру назначения пакета.
6.    Передача данных от провайдера назначения к серверу.
Если вы более любознательны, вы можете сами посмотреть количество узлов, которое проходит ваш пакет на пути к какому-либо серверу. Допустим, мы хотим посмотреть сколько узлов в сети пройдёт пакет, отправленный к глобальному DNS-серверу Google. Для это открываем командную строку («Пуск» -> «Все программы» -> «Стандартные» -> «Командная строка») и вводим в консоли команду
tracert –d 8.8.8.8
(обратите внимание, что после служеюного слова «tracert» идёт пробел, затем –d без пробелов, затем снова пробел и IP-адрес интересующего нас узла). После нажатия ENTER в выводе вы увидите все узлы, которые проходит пакет. На самом деле узлов может быть больше, потому что оборудование, передающее ваш пакет. Может быть настроено соответствующим образом, чтобы скрывать некоторые из них. Но от этого суть передачи пакетов сильно не меняется.
Заметьте, что первым в списке будет идти ваш домашний маршрутизатор (ну или корпоративный маршрутизатор, если вы будете экспериментировать на рабочем месте).
Сразу замечу, что описанная выше команда используется в операционной системе Windows, при работе в другой системе команда будет другой.
Мы рассмотрели частный случай канала без участия VPN. А что же происходит при создании VPN-канала?
А происходит следующее. В вышеописанную схему включается ещё и сервер VPN. Естественно со всем коммутационным оборудованием на пути к нему. Но включение VPN-сервера это ещё не всё. Дело в том, что VPN-канал не может быть создан без Интернет-канала. Ведь для того, чтобы связаться с сервером VPN ваш компьютер будет использовать интернет. Схематично это можно объяснить на предыдущей схеме, если в качестве цели вместо web-сервера указать сервер VPN. Т.е. на качество соединения с сервером будет огромное влияние оказывать качество используемого вами интернет-канала. Поскольку VPN-канал строиться в рамках интернет-канала, то он не может быть «более широким»,  чем канал предоставленный вашим провайдером. Часть трафика в ваших каналах будет использована собственно для организации канала VPN и по разным данным она составляет до 25%. Ещё часть трафика (уже в рамках самого VPN-канала) может быть использована для организации шифрования. Эта величина тоже варьирует в рамках до 25% общего трафика. Итак, согласно расчётов в самом медленном варианте VPN скорость канала будет равна половине ширины интернет-канала.
Ваш компьютер, проходит тебе самые 6 шагов, как и в первом примере, для организации самого VPN-канала. Происходит соединение, становление VPN-канала и…
А попробуйте теперь ввести вышеописанную команду и посмотреть вывод. Заметили разницу? А дело в том, что (при определённых настройках VPN-соединения) вашим главным маршрутизатором становиться сервер VPN (и вы видите его адрес первым в выводе tracert). Что же произошло? Почему пропали из вывода tracert все узлы на пути к серверу VPN? Сервер – штука неподвижная и переместиться по ближе к вам он не мог. А дело в том, что создался VPN-канал. Теперь все пакеты, идущие от вашего компьютера направляются только к серверу VPN (естественно через всё коммутационное оборудование, оно никуда не пропало, просто теперь не отображается, оно же расположено за пределами VPN-канала, в котором теперь находитесь вы), а уже от сервера VPN дальше (в зависимости от того. куда именно направлялся ваш пакет). В реальности теперь опять можно провести аналогию со схемой без VPN, но только теперь сервер VPN нужно поставить не на место web-сервера, а на место клиентского компьютера. Далее всё точно также как и в случае соединения вашего компьютера с веб-сервером, только теперь с веб-сервером соединяется сервер VPN.
Тут есть пара важных моментов. В зависимости от типа соединения с VPN-сервером и применяемой для этого технологии скорость этого соединения может быть различной. Так, например, если для соединения с сервером используется протокол UDP, то скорость соединения будет выше в виду особенностей данного протокола. Второй момент связан с использованием шифрования трафика в самом канале. Да, шифрование, это, конечно, очень хорошо, потому что не позволит сторонним личностям просмотреть какие ресурсы в интернет вы посещаете. Однако, процесс шифрования и дешифрования будет использовать аппаратные ресурсы, причём как сервера VPN, так и вашего компьютера. Естественно, при этом снизиться общая работоспособность канала VPN.

Схематическое изображение VPN

Посмотрите на схему выше. В реальности трафик проходит весь путь до сервера VPN (A, B, C, D), далее в сетевое оборудование провайдера (без обозначений), где расположен VPN, «говорит» серверу VPN куда он (трафик) именно он должен быть доставлен, а сервер VPN, вновь через всё оборудование своего провайдера, перенаправляет трафик в глобальную сеть к искомому серверу, опять же через всё оборудование.
Снова попробуем пошагово рассмотреть путь трафика с участитем VPN:
1.    Соединение компьютера с домашним WiFi-роутером
2.    Соединение роутера с оборудованием провайдера
3.    Соединение оборудование провайдера с глобальными коммутационными узлами
4.    Выбор глобальными коммутационными узлами оптимального маршрута для передачи данных к серверу VPN
5.    Передача данных к провайдеру сервера VPN.
6.    Передача данных от провайдера назначения к серверу VPN.
7.    Передача данных от сервера VPN к своему провайдеру (уже путь к пункту назначения пакета).
8.    Передача данных из сети провайдера в глобальные сети.
9.    Выбор маршрута в глобальных сетях до провайдера сервера назначения и передача трафика.
10.    Передача пакетов от провайдера сервера назначения до самого сервера.
Итого 10 шагов в одну сторону и также 10 шагов в обратную.
А теперь предположим, что сервер VPN находиться, например, в другой стране. Как вы думаете, увеличиться ли количество узлов, которые должен пройти пакет? Конечно увеличиться. Ведь на пути к серверу пакетам придётся пройти гораздо большее количество коммутационного оборудования. Естественно, что если для просмотра ресурса, расположенного в вашей стране вы будете использовать иностранный VPN, то количество таких узлов увеличиться примерно в 2 раза (ведь путь от VPN-сервера к искомому ресурсу пройдёт примерно тот же маршрут только в обратном порядке).
Итак, подведём итоги. Так от чего же всё-таки зависит качество VPN?
В первую очередь от качества самого интернет-канала. На плохом канале не стоит ожидать хороших результатов скорости VPN. Очень большую роль играет настройка вашего оборудования, а именно параметра MTU сетевых интерфейсов, а также разнообразных фильтров и брандмауэров в самом маршрутизаторе. Также играет роль наличие шифрования в канале. В большинстве случаев протокол PPTP требует наличия шифрования, а протокол L2TP – не требует. Также скорость передачи в VPN-канале очень зависит от местоположения интересующего вас ресурса, решение просматривать, например, российские сайты, через американский VPN не является оптимальным. Конечно, скорость интернет-канала также зависит от мощности сервера, но зачастую эта зависимость ничтожна.
Так что же делать, если скорость соединения в VPN-канале вас не удовлетворяет? Можно ли её увеличить? Об этом в следующей статье.