PPTP vs L2TP vs OpenVPN vs SSTP

Автор оригинала: Pete Zaborszky
  • Перевод
Недавно я искал информацию об отличиях существующих VPN-технологий и наткнулся на эту статью. Здесь вкратце описаны преимущества и недостатки основных VPN, очень легко и доступно. Предлагаю сообществу перевод статьи.

VPN-провайдеры обычно предлагают на выбор несколько типов подключения, иногда как часть различных тарифных планов, а иногда в составе единого тарифного плана. Цель этой статьи – провести обзор доступных вариантов VPN и помочь понять основы используемых технологий.

Заметка про длину ключа шифрования


Грубо говоря, длина ключа, используемого при создании шифра, определяет, сколько времени потребуется для взлома с помощью прямого перебора. Шифры с более длинными ключами требуют значительно больше времени для перебора, чем более короткие («брутфорс» означает перебор всех возможных комбинаций, пока не будет найдена верная).

Сейчас почти невозможно найти VPN-шифрование с использованием ключа длиной менее 128 бит и все сложнее найти 256-битное шифрование в предлагаемых OpenVPN-решениях, ключи которых бывают даже 2048 бит. Но что означают эти цифры на практике, 256-битное шифрование действительно более безопасное, чем 128-битное?

Краткий ответ таков: при практическом применении – нет. Это правда, что взлом 256-битного ключа потребует в 2128 больше вычислительной мощности, чем взлом 128-битного ключа. Это означает, что потребуется 3.4х10^38 операций (количество комбинаций в 128-битном ключе) – подвиг для существующих компьютеров и даже в ближайшем будущем. Если бы мы применили самый быстрый суперкомпьютер (по данным 2011 года его скорость вычислений 10.51 петафлопс), нам потребовалось бы 1.02х10^18 (около 1 миллиарда) лет, чтобы взломать 128-битный AES-ключ путем перебора.

Так как на практике 128-битный шифр не может быть взломан путем перебора, было бы правильно говорить, что ключа такой длины более чем достаточно для большинства применений. Только настоящие параноики (например, чиновники в правительстве, имеющие дело со сверхсекретными документами, которые должны оставаться в тайне в течение следующих 100 или более лет) могут использовать 256-битное шифрование (правительство США, например, использует сертифицированный NIST 256-битный AES-шифр).

Так почему же все более часто встречаются VPN-провайдеры, предлагающие 256-битное шифрование (не говоря уже о 2048-битном)? Особенно если учесть, что использование шифрования с 256-битным или более длинным ключом требует больше вычислительных ресурсов. Ответ прост – маркетинг. Проще продать VPN-услуги с более длинным ключом шифрования.

Крупные корпорации и правительства могут испытывать потребность в дополнительной безопасности, обеспечиваемой длинными ключами, но для среднего домашнего пользователя VPN с ключом 128 бит более чем достаточно.

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

PPTP


Протокол туннелирования точка-точка (Point-to-Point Tunneling Protocol) – это протокол, изобретенный Microsoft для организации VPN через сети коммутируемого доступа. PPTP является стандартным протоколом для построения VPN уже на протяжении многих лет. Это только VPN-протокол и он опирается на различные методы аутентификации для обеспечения безопасности (наиболее часто используется MS-CHAP v.2). Доступен как стандартный протокол почти во всех операционных системах и устройствах, поддерживающих VPN, что позволяет использовать его без необходимости установки дополнительного программного обеспечения. PPTP остается популярным выбором как предприятий, так и VPN-провайдеров. Его преимущество также в том, что он использует меньше вычислительных ресурсов, следовательно обладает высокой скоростью работы.

Хотя PPTP обычно и используется со 128-битным шифрованием, в следующие несколько лет после включения этого протокола в состав Windows 95 OSR2 в 1999 году были найдены ряд уязвимостей. Наиболее серьезной из которых явилась уязвимость протокола аутентификации MS-CHAP v.2. Используя эту уязвимость, PPTP был взломан в течение 2 дней. И хотя компанией Microsoft была исправлена эта ошибка (за счет использования протокола аутентификации PEAP, а не MS-CHAP v.2), она сама рекомендовала к использованию в качестве VPN проколов L2TP или SSTP.

Плюсы:
  • клиент PPTP встроен почти во все операционные системы
  • очень прост в настройке
  • работает быстро

Минусы:
  • небезопасен (уязвимый протокол аутентификации MS-CHAP v.2 все еще много где используется)


L2TP и L2TP/IPsec


Протокол туннелирования 2 уровня (Layer 2 Tunnel Protocol) – это протокол VPN, который сам по себе не обеспечивает шифрование и конфиденциальность трафика, проходящего через него. По этой причине, как правило, используется протокол шифрования IPsec для обеспечения безопасности и конфиденциальности.

L2TP/IPsec встроен во все современные операционные системы и VPN-совместимые устройства, и так же легко может быть настроен как и PPTP (обычно используется тот же клиент). Проблемы могут возникнуть в том, что L2TP использует UDP-порт 500, который может быть заблокирован файрволлом, если вы находитесь за NAT. Поэтому может потребоваться дополнительная настройка роутера (переадресация портов). Кстати, протокол SSL, например, использует TCP-порт 443, чтобы быть неотличимым от обычного HTTPS-трафика.

Протокол IPsec на данный момент не имеет никаких серьезных уязвимостей и считается очень безопасным при использовании таких алгоритмов шифрования, как AES. Однако, поскольку он инкапсулирует данные дважды, это не так эффективно, как SSL-решения (например, OpenVPN или SSTP), и поэтому работает немного медленнее.

Плюсы:
  • очень безопасен
  • легко настраивается
  • доступен в современных операционных системах

Минусы:
  • работает медленнее, чем OpenVPN
  • может потребоваться дополнительная настройка роутера


OpenVPN


OpenVPN является достаточно новой технологией с открытым кодом, которая использует библиотеку OpenSSL и протоколы SSLv3/TLSv1, наряду с множеством других технологий для обеспечения надежного VPN-решения. Одним из его главных преимуществ является то, что OpenVPN очень гибок в настройках. Этот протокол может быть настроен на работу на любом порту, в том числе на 443 TCP-порту, что позволяет маскировать трафик внутри OpenVPN под обычный HTTPS (который использует, например, Gmail) и поэтому его трудно заблокировать.

Еще одним преимуществом OpenVPN является то, что используемые для шифрования библиотеки OpenSSL поддерживают множество криптографических алгоритмов (например, AES, Blowfish, 3DES, CAST-128, Camelia и другие). Наиболее распространенные алгоритмы, которые используют VPN-провайдеры – AES и Blowfish. AES является новой технологией, и хотя оба считаются безопасными, тот факт, что он имеет 128-битный размер блока, а не 64-битный как у Blowfish, означает, что он может работать с большими (более 1Гб) файлами лучше. Различия, однако, довольно незначительные. То, как быстро работает OpenVPN, зависит от выбранного алгоритма шифрования, но, как правило, работает быстрее, чем IPsec.

OpenVPN стал технологией №1 при использовании VPN, и хотя он изначально не поддерживается операционными системами, этот протокол широко поддерживается через стороннее программное обеспечение. Совсем недавно невозможно было использовать OpenVPN на iOS и Android без джейлбрейка и рута, а сейчас появились сторонние приложения, которые частично решили эту проблему.

С этим связана другая проблема OpenVPN – гибкость может сделать его неудобным в настройке. В частности, при использовании типовой программной реализации OpenVPN (например, стандартный открытый клиент OpenVPN под Windows) необходимо не только скачать и установить клиент, но и загрузить и установить дополнительные конфигурационные файлы. Многие VPN-провайдеры решают эту проблему путем использования преднастроенных VPN-клиентов.

Плюсы:
  • гибко настраивается
  • очень безопасен (зависит от выбранного алгоритма шифрования, но все они безопасны)
  • может работать сквозь файрволлы
  • может использовать широкий спектр алгоритмов шифрования

Минусы:
  • необходимо стороннее программное обеспечение
  • может быть неудобен в настройке
  • ограниченная поддержка портативными устройствами


SSTP


Протокол безопасного туннелирования сокетов (Secure Socket Tunneling Protocol) – был представлен Microsoft в Windows Vista SP1, и хотя он теперь доступен на Linux, RouterOS и SEIL, он по-прежнему используется в значительной степени только Windows-системами (есть очень маленький шанс, что он появится на Apple устройствах). SSTP использует SSL v.3 и, следовательно, предлагает аналогичные преимущества, что и OpenVPN (например, возможность использовать TCP-порт 443 для обхода NAT), а так как он интегрирован в Windows, он проще в использовании и более стабилен, чем OpenVPN.

Плюсы:
  • очень безопасен (зависит от алгоритма шифрования, обычно используется очень стойкий AES)
  • полностью интегрирован в Windows (начиная с Windows Vista SP1)
  • имеет поддержку Microsoft
  • может работать сквозь файрволлы

Минусы:
  • работает только в Windows-среде


Заключение


PPTP небезопасен (даже его создатели в Microsoft отказались от него), поэтому его использования следует избегать. В то время, как простота установки и кроссплатформенная совместимость являются привлекательными, L2TP/IPsec имеет те же преимущества и является более безопасным.

L2TP/IPsec является хорошим решением VPN, но не таким хорошим, как OpenVPN. Однако, для быстрой настройки VPN без необходимости установки дополнительного программного обеспечения остается лучшим решением, особенно для мобильных устройств, где поддержка OpenVPN по-прежнему на низком уровне.

OpenVPN является лучшим решением VPN несмотря на необходимость стороннего программного обеспечения во всех операционных системах. Это надежный, быстрый и безопасный протокол, хотя и требует немного больше усилий, чем другие протоколы.

SSTP предлагает большинство преимуществ OpenVPN, но только в среде Windows. Это означает, что он лучше интегрирован в ОС, но благодаря этому он слабо поддерживается VPN-провайдерами.

Большинство пользователей могут использовать OpenVPN на своих настольных компьютерах, возможно, дополнив его L2TP/IPsec на своих мобильных устройствах.
Поделиться публикацией

Комментарии 98

    +25
    Автор очень ловко сравнивает длину ключей у симметричных алгоритмов(128, 256) и асимметричных (2048, 4096)
      +4
      Да, я тоже прифигел слегка. Это может ввести в заблуждение не совсем опытных читателей, которые не знают, в чём разница, поэтому, ИМХО, нужно уточнить и добавить краткое сравнение.

      Хотя, мне кажется, что автор сам путает.
      +5
      > PPTP

      Тут еще нужно добавить, что PPTP использует протокол GRE, который в некоторых роутерах может быть либо заблокирован, либо они вообще могут не уметь его маршрутизировать (да, видел я и такое).

      > SSTP

      Насчет windows-only — частично. Клиенты есть и под линукс, и емнип, под мак. А вот с серверной частью все сильно грустно :(
        0
        Есть сервак для SSTP и работает как минимум в Ubuntu unix.stackexchange.com/a/76487
          +1
          1. there are couple of limitations with the free version (for example, cannot use external authentication, client certificates etc.)
          2. А где же исходники? Лично мне как-то стремно ставить какой-то левый VPN-сервер, через который будет идти весь мой траффик. Там пишут, что «and aiming to release the source code of SoftEther VPN in middle of 2013 or earlier», но что-то не видно их пока.
            0
            1. Не велика потеря.
            2. Это да…

            И тем не менее уже хорошо, что он хоть есть.
          0
          Единственный sstp-клиент под мак и линукс не поддерживает EAP, который многие администраторы любят включать, и этот фичреквест похоже так и не собираются делать. Поэтому клиент тоже очень частично.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            OpenVPN работает на уровне приложений (7-й модели OSI, 4-й TCP/IP) реализуя свой протокол и инкапсулируя свои пакеты в TCP/UDP.
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Собственно, L2TP и связывают с IPSec, чтобы было шифрование на втором уровне.
                  +1
                  в ipsec шифрование как было на третьем уровне, так и осталось. L2TP тут совершенно не причём.

                  image

                  а теперь еще с nat-t:

                  image
              0
              Использование OpenVPN в TCP-режиме вызывает значительный overhead, так как TCP пакеты инкапсулируются внутрь TCP. В таком режиме пропускная способность падает, потребление вычислительных ресурсов возрастает.
              Так что если есть возможность выбирать, то надо ставить IPSec. Если есть потенциальная проблема с закрытыми портами, только тогда можно настраивать OpenVPN.


              Использование OpenVPN в его штатном UDP режиме вызывает намного меньший overhead, чем openvpn over tcp. Единственный плюс IPSec, который я для себя уяснил — меньшее потребление ресурсов. Что именно я пропустил?
              • НЛО прилетело и опубликовало эту надпись здесь
              +2
              PPTP изобретён не Microsoft, а Cisco.
              И действительно, лихо автор смешал длины ключей.
                0
                в вики про L2TP пишут обратное:

                1996—1997 — конкуренция между протоколами L2F (Cisco) и PPTP (Microsoft)
                1997 — соглашение между разработчиками о совместной разработке протокола L2TP
                1999 — опубликован стандарт RFC 2661, описывающий протокол L2TP
                Считается, что протокол L2TP вобрал в себя лучшие черты L2F и PPTP[1].
                  0
                  в той же вики про pptp пишут следующее:
                  Cisco первой реализовала PPTP и позже лицензировала эту технологию корпорации Microsoft.
                0
                в PPTP есть еще протокол аутентификации PAP или это тот же PEAP?
                  +8
                  Кстати, протокол SSL, например, использует TCP-порт 443, чтобы быть неотличимым от обычного HTTPS-трафика

                  Прекрасная фраза
                    0
                    Да уж, странная статья, может имелось ввиду, что при использовании OpenVPN в режиме TCP там где нет анализатора пакетов, а только разрешены определённые порты можно будет «замаскировать» OpenVPN сервер под HTTPS сайт. Конечно же это не имелось ввиду, однако об этом стоит упомянуть в этом топике :) К примеру при работе через корпоративный прокси очень часто OpenVPN в режиме TCP на 443 порту это единственный работающий механизм.
                      0
                      это какой такой анализатор пакетов расковыряет ssl (без вмешательства)?
                        0
                        Там таки разный формат handshake'а, который позволяет DPI отличить OpenVPN от SSL/TLS:

                        https

                        openvpn
                          0
                          действительно, мультиплексер себя выдаёт.
                          Вот с sstp такое у меня не получилось, я вижу SSL, и без расшифровки дальше понять, что внутри туннель не получается. Вроде всё правильно сделал.
                            0
                            На другом порту пакеты openvpn выглядят аналогично. Т. е. openvpn — не классический TLS/SSL.

                            Пример нормального TLS/SSL — Cisco VPN. А раскидать по разным приложениям можно используя SNI (поле server_name в client_hello в TLS/SSL).
                            0
                            Эта проблема обходится с помощью мультиплексора sslh и openvpn c --port-share на 443 порту.
                              0
                              Примеры, приведенные мной — это openssl с опцией port-share 127.0.0.1 443. Мультиплексор различает трафик точно также, как и dpi.

                              Скорее всего, sslh работает также (у меня его нет в репозиториях сервера, чтобы проверить — он всё-таки ещё нестабильный).
                                0
                                из того как это работало на практике я могу сделать вывод что происходило вот что dpi видит коннект на 443 порт и пытается вклинится но от dpi в сеть уходит пакет с ssl handshake на него отвечает sslh и пробрасывает конект на https, получив «правильный» ответ dpi разрешает соединение. в рез-те и openvpn tcp/443 и даже ssh/443 работали

                                навернякак это сильно зависит от dpi «железки»
                                  0
                                  Это уже какой-то «активный» dpi, который светится попыткой подключения. В таком случае он может также делать попытки установить ssh и openvpn.

                                  В случае «пассивного» dpi, который только анализирует трафик, но не вмешивается в него различить эти три типа соединения не составляет труда.
                      0
                      При выборе длины ключа стоит учесть и государственные правила. В России без ограничений можно использовать симметричные ключи длиной до 56 битвключительно, асимметричные — до 512. Дальше начинаются юридические заморочки.
                        0
                        А как же ГОСТ 1024?
                          0
                          Хочешь ГОСТ — получай лицензию или ищи другие возможности её не получать, например использовать исключительно для внутренних нужд.
                        0
                        *отредактировано
                          0
                          То ли перевод неок, то ли в статье действительно ничего по делу:
                          1) нет описания различия принципов встраивания в сетевой стек системы: PPP, TUN/TAP
                          2) «L2TP медленее OpenVPN» — не верю, хоть какое-то обоснование должно быть
                          3) OpenVPN сложен в настройке? Настройте SSTP. Нет, не клиентскую часть.
                            0
                            По второму пункту автор пишет так:
                            Однако, поскольку он [IPsec] инкапсулирует данные дважды, это не так эффективно, как SSL-решения (например, OpenVPN или SSTP), и поэтому работает немного медленнее.
                              0
                              А вот SSL-решения не инкапсулируют дважды данные, при чем с б`ольшим оверхедом, да?
                              Статья такая статья(переводчик, не в твою сторону камень;)).
                              0
                              Настройте SSTP. Нет, не клиентскую часть.

                              А в чем проблема? RRAS настраивается в несколько кликов без лазанья по конфигам.
                                0
                                одного RRAS'а недостаточно, где-то должен жить CA, должен быть сконфигурирован NAP, короче это так или иначе подтянет AD. Я понимаю, что большинство windows-сетей уже работают с AD, но, в данном случае, сравнивая с openvpn, настройка «с нуля» у openvpn несравнимо проще.
                                  0
                                  Авторизации по сертификатам в условиях не было :) А без неё не нужен ни AD, ни CA, точно не помню, но вроде даже без NPS можно обойтись.
                                    0
                                    На сколько мне известно SSTP не работает без серверного сертификата с FQDN в CN.
                                      0
                                      Его можно получить в доверенном CA (тот же StartCom) или сгенерировать самому в SelfSSL, OpenSSL, SelfCert и подобных утилитах.
                                        0
                                        Нужно попробовать. MS, правда, всё же рекомендует вкорячить роль AD согласно их же гайду.
                                          0
                                          Они для всего его рекомендуют.
                                          Я поднимал SSTP на 2012 в Azure для доступа к американским ресурсам — всё прекрасно работало без домена. Причем их облако пока не занесли в чёрный список даже в Bing Rewards, в отличии от того же Амазона.
                                  0
                                  А в чем проблема? RRAS настраивается в несколько кликов без лазанья по конфигам.

                                  а теперь то же самое, но на cisco/juniper.
                                    0
                                    В ASDM есть мастер настройки RA VPN для AnyConnect. Уверен, у Juniper есть что-то подобное.
                                      +1
                                      с чего вы решили, что cisco anyconnect и sstp совместимы?
                                        0
                                        Я подумал, что вы спрашиваете про аналоги (SSL VPN) от других вендоров.
                                0
                                Поднимал в локалке сервера PPTP и L2TP под linux (pptpd и xl2tpd соответственно). В данном случае меня больше интересовала возможность NTLM или Kerberos аутентификации и большим плюсом было наличие клиента в windows из коробки. Но столкнулся с проблемой (как с pptpd, так и с xl2tpd) — иногда при передаче трафика рвется соединение (возникает какое-то «недопонимание» между клиентом и сервером). Нагуглить решение тогда так и не смог. Никто не сталкивался с таким поведением и, возможно, решением этой проблемы?
                                  +6
                                  OpenVPN стал технологией №1 при использовании VPN

                                  Ложь. IPSec намного популярнее. Даже без дополнительных инкапсуляций (GRE/L2TP/что угодно).
                                  L2TP использует UDP-порт 500

                                  Ложь. UDP 500 — это ISAKMP.
                                  То, как быстро работает OpenVPN, зависит от выбранного алгоритма шифрования, но, как правило, работает быстрее, чем IPsec.

                                  Самая ресурсоемкая операция — шифрование. Соответственно, при одинаковых алгоритмах шифрования скорости будут примерно одинаковые. Однако, IPSec заворачивается в UDP либо ESP, что снижает оверхеды. Т.е. победитель именно он.

                                  Про путаницу с длинами ключей разных алгоритмов уже говорили.

                                  AES128 совершенно безопасен на данный момент. Однако, в будущем могут появиться квантовые компьютеры, способные гипотетически снизить реальную длину ключа вдвое, а 64 бита — это кошмар. Потому и рекомендуют AES256 в качестве future-proof решения.
                                    0
                                    Однако, IPSec заворачивается в UDP либо ESP, что снижает оверхеды. Т.е. победитель именно он.


                                    Штатно openvpn заворачивается именно в UDP. С другой стороны, мне кажется, в линукскакая-то часть IPSec работает на уровне ядра, в отличие от openvpn, который в userspace. Вот тут и вылазит разница в потреблении ресурсов.

                                    А вообще статья упоротая в мясо. Ее критиковать бессмысленно.
                                      0
                                      Ну я скорее говорил про сетевые оверхеды. Удачи гонять к примеру VOIP внутри TCP по неидеальному каналу. TCP внутри TCP тоже может вести себя забавно.
                                        0
                                        Первое предложение моего ответа прочтите, пожалуйста. Штатный OpenVPN работает по UDP. tcp используется только для обхода заблокированных портов. Поэтому я и написал про оверхед с точки зрения ресурсов. Про сетевой оверхед и tcp разрабы openvpn даже в собственном мануале пишут, ссылаясь сюда.
                                          0
                                          А что будет с тсп через тсп? Вот тут утверждают, основываясь в том числе и на эксперименте — что почти ничего и обратное — миф, вброшенный не вполне адекватным товарисчем, запутавшимся в матчасти и проводившем эксперименты на канале с потерями.

                                          www.barabanov.ru/arts/tcp/Tcp_over_tcp_is_not_so_bad-web.pdf
                                            0
                                            и проводившем эксперименты на канале с потерями.

                                            Угу, интернет — идеальное средство связи, абсолютно lossless, с PFC для всех классов трафика из конца в конец :)

                                            Конечно же TCP ведет себя как ягненок при отсутствии потерь и когда перегрузка канала фиксируется по всплеску задержки. А если поднять VPN через 3G или не очень хорошо ловящий wi-fi, с полпроцента потерь?
                                              0
                                              А при чем тут это? Основная мысль в том, что внутреннему тсп не будет шибко хуже, чем внешнему. Ну и миф собственно утверждает обратное (meltdown-эффект).

                                                0
                                                Очевидно, что потери в тсп, не связанные с перегрузкой гнобят тсп по полной. Но это уже совершенно другая тема. Мы вроде обсуждаем, что тсп через тсп ведет себя забавно.
                                                  0
                                                  Ну мне что-то подсказывает, что при дропе одного пакета в случае TCPoTCP спад скорости передачи данных будет куда сильнее, чем в случае одного TCP.
                                        +1
                                        Однако, поскольку он инкапсулирует данные дважды, это не так эффективно, как SSL-решения (например, OpenVPN или SSTP), и поэтому работает немного медленнее.


                                        1) а ничего, что openvpn работает в userspace, а ipsec — в ядре?
                                        2)и намного — это во сколько раз?
                                        3)ничего не сказано про пагубность tcp over tcp и чудесах, которые начинаются при малейшем packetloss.
                                        4)о какой версии l2tp идет речь в статье?
                                          0
                                          Я вам больше скажу, OpenVPN еще и не распараллеливается на процессоры.
                                            0
                                            никто не мешает делать несколько туннелей и делать бонд интерфейс
                                            0
                                            3) TCP meltdown, лосс/уменьшение пропускной способности должны быть существенными
                                              0
                                              Вы сами этот эффект видели?

                                              www.barabanov.ru/arts/tcp/Tcp_over_tcp_is_not_so_bad-web.pdf
                                                0
                                                Understanding TCP over TCP: Effects of TCP Tunneling on End-to-End Throughput and Latency за авторством Osamu Honda and Hiroyuki Ohsaki and Makoto Imase and Mika Ishizuka and Junichi Murayama

                                                Я лично проводил тесты на dummynet. Эффект есть, вплоть до ресета внутреннего tcp-соединения по таймауту.
                                                  0
                                                  прекрасно видел и ощущал на себе, когда использовал openvpn/vtund через отельный wifi в египте.
                                                  там были потери ~ 3-6% и при этом работать по ssh было невозможно(в лучшем случае всё жутко тормозило, в худшем — соединение «подвисало»).
                                              0
                                              А можно пару советов по выбору протокола для плохих каналов?
                                              Часто приходится подключаться через мобильную сеть. Важен ли такой параметр как сжатие трафика?
                                                0
                                                У Openvpn есть comp-lzo, у IPSEC, насколько знаю сжатия нет нативного.

                                                А в общем, через мобильную сеть будет работать и то и то. Мы в свое время поднимали Openvpn как раз для мобильных пользователей.
                                                  0
                                                  у IPSEC, насколько знаю сжатия нет нативного.

                                                  Есть. В любой реализации, но не на любом железе.
                                                    0
                                                    а есть сравнительный анализ качества сжатия?
                                                    И всё же, в какую строну смотреть?
                                                      0
                                                      Там обычно классический LZS. Надо искать сравнение с LZO.
                                                        0
                                                        LZO functions very similarly to the LZSS algorithm but is optimized for speed rather than compression ratio.

                                                        Т.е. LZO жмет хуже.
                                                          0
                                                          разница в сжатии ничтожна
                                                    0
                                                    Я думаю стоит смотреть в сторону SSL-based: OpenVPN и SSTP, SSTP быстрее работает, но хуже переносит ухудшение качества связи.
                                                      0
                                                      >OpenVPN и SSTP, SSTP быстрее работает

                                                      в каком смысле?
                                                        0
                                                        в смысле байтов в секунду
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                            +3
                                                            а мне кажется, что куда сильнее влияет на цифры надпись внизу «Hosted by» ;)
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                0
                                                                А sstp проверить нет возможности?
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                    0
                                                                    да, поэтому и спросил собственно. :(
                                                                    У нас в компании все под виндой работают, поэтому нам было бы удобно :)
                                                                      0
                                                                      У нас в компании все под виндой работают, поэтому нам было бы удобно :)


                                                                      мне кажется, вы таким образом сами раскладываете себе кучу грабель в виде vendor lock-in.
                                                                      ipsec — стандарт, в отличие от sstp. причём, в ipsec вы можете аутентификацию сделать как душе угодно(да хоть те же смарткарты) или двухфакторную аутентификацию.
                                                                        0
                                                                        А разве с sstp такие вещи провести нельзя?

                                                                        Мы уже давно — «vendor lock-in», особенности бизнеса такие :(
                                                                          0
                                                                          sstp — это ppp over https + немного обвязки.
                                                                          причём, сервер аутентифицируется на этапе установления ssl-соединения. после этого запускается ppp, ну а там уже кто как хочет: различные варианты eap или же ms-chap(со всеми его болячками).

                                                                          т.е. в лучшем случае у вас будет всё на сертификатах, в худшем — пароли.

                                                                          А вообще, я не понимаю тяги msft к созданию велосипедов на базе ppp:

                                                                          1. сначала прикрутили шифрование к ppp(mppe), но оно оказалось слабым.
                                                                          2. потом решили гонять ppp внутри gre. так родился pptp.
                                                                          3. потом на пару с cisco у них родилась идея «а давайте всё как в pptp, но только внутри udp-пакетов?». так появился l2tp.
                                                                          4. потом вспомнили про шифрование. так появился l2tp/ipsec
                                                                          5. потом подумали что как-то плохо вся эта конструкция проходит через nat. придумали sstp.

                                                                          т.е. всё тот же трупик ppp, но к нему всё время пытаются какие-то архитектурные штуки приделать, чтобы оно работало в современных ip-сетях.

                                                                          лучше бы сделали у себя l2tpv3(с его pseudowire и прочими плюшками) + ipsec с nat-t.
                                                                          либо сделали на базе sctp: там и multihoming(можно через несколько интернет-каналов без костылей работать), и multistreaming(в рамках одного коннекта можно несколько потоков данных гонять) и границы сообщений(tcp — это просто поток байт: 2 вызова write() по 500 байт не гарантируют что 2 read() на той стороне вернут вам по 50 байт. это может быть и сразу 500, и 200 + 300, и любые другие комбинации).
                                                                            0
                                                                            различные варианты eap

                                                                            Собственно, это — ответ на «вы можете аутентификацию сделать как душе угодно».
                                                                            лучше бы сделали у себя...

                                                                            Anyconnect. Можно DTLS, можно IPSec, на крайняк можно хоть SSL/TLS (но серьезно, VPN поверх TCP — отстой, не универсально).
                                                                            Ах да, это тоже обернется анальным рабством, полностью согласен :)
                                                                              0
                                                                              >Собственно, это — ответ на «вы можете аутентификацию сделать как душе угодно».

                                                                              а можно пример именно двухфакторной аутентификации?
                                                                              afaik, в eap можно либо/либо. т.е. либо сертификаты(в т.ч. на смарткарте), либо различные варианты пароля(plain/hash/challenge-response)
                                                                                0
                                                                                www.google.ru/search?q=sstp+two+factor

                                                                                А EAP разный бывает.
                                                                                  0
                                                                                  >One of the problems with RRAS is that out of the box there isn't a real method for using two factor authentication
                                                                                    0
                                                                                    А что мешает поднять более приспособленный для этого UAG?
                                                      +2
                                                      Странно, что автор находит настройку IPSec «простой». Судя по разным статьям/howto и отзывам знакомых, которые его настраивали — и PPTP и OpenVPN настроить в разы проще. Хотя возможно автор имел в виду только клиентскую часть.
                                                        0
                                                        У IPSec нет никаких сложностей в настройке и на принимающей стороне. Если знать матчасть.

                                                        С другой стороны, изредка бывают странные провайдеры, у которых бывают странные глюки. К примеру: через минуту после поднятия SA начинают теряться ESP пакеты в количестве 100%, и так до переустановки SA (это из недавнего). Потери именно на сети оператора — это доказано. В какой-то момент проблема саморазрешилась. Провайдер, конечно, как всегда ничего не делал… Я к тому, что такие вещи простым телнетом на порт не протраблшутить, требуется больше телодвижений. Но все равно ничего страшного там нет. Обычно IPSec работает как часы.
                                                        0
                                                        У OpenVPN есть еще одна интересная функция, вытекающая из его гибкой конфигурации, это возможность работать через любой HTTTP Proxy.
                                                          0
                                                          а у SSTP?
                                                            0
                                                            Это фича есть у всех реализаций SSL VPN.
                                                            0
                                                            Статья выглядит крайне поверхностной, содержит кучу ляпов (и многие уже их отметили: смешивание в кучу симметричных и асимметричных ключей, путаницу насчет GRE), упоминает только узкий круг решений: забыт популярный Cisco VPN (он, конечно, IPSec-based, но барахла на базе последнего выше крыши), скомкано описана поддержка в разных ОС. Например, не разделена поддержка в десктопных, серверных, мобильных ОС и firmware роутеров.
                                                              0
                                                              SSLv3, вроде же, поломали? en.wikipedia.org/wiki/Transport_Layer_Security#SSL_3.0
                                                                0
                                                                SSTP вроде уже есть на MikroTik RouterOS 6.x
                                                                  0
                                                                  Действительно есть и даже работает с версии 5.х
                                                                  0
                                                                  Ещё у openvpn есть фича мультиплексирования своих данных и https траффика на одном порту. Удобно, если надо отдавать https и vpn на 443, чтобы он был доступен из кафе или других мест с ограниченным интернетом.
                                                                    +7
                                                                    Уважаемый переводчик. Вы когда, в следующий раз что-то переводите, пожалуйста, хоть чуть-чуть понимайте в теме перевода. Чтоб не переводить откровенный бред. Так как в данном случае результат Вашего труда по смыслу кроме как «упоротым» назвать сложно.

                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                    Самое читаемое