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

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

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

> SSTP

Насчет windows-only — частично. Клиенты есть и под линукс, и емнип, под мак. А вот с серверной частью все сильно грустно :(
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», но что-то не видно их пока.
1. Не велика потеря.
2. Это да…

И тем не менее уже хорошо, что он хоть есть.
Единственный sstp-клиент под мак и линукс не поддерживает EAP, который многие администраторы любят включать, и этот фичреквест похоже так и не собираются делать. Поэтому клиент тоже очень частично.
UFO landed and left these words here
OpenVPN работает на уровне приложений (7-й модели OSI, 4-й TCP/IP) реализуя свой протокол и инкапсулируя свои пакеты в TCP/UDP.
UFO landed and left these words here
Собственно, L2TP и связывают с IPSec, чтобы было шифрование на втором уровне.
в ipsec шифрование как было на третьем уровне, так и осталось. L2TP тут совершенно не причём.

image

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

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


Использование OpenVPN в его штатном UDP режиме вызывает намного меньший overhead, чем openvpn over tcp. Единственный плюс IPSec, который я для себя уяснил — меньшее потребление ресурсов. Что именно я пропустил?
UFO landed and left these words here
PPTP изобретён не Microsoft, а Cisco.
И действительно, лихо автор смешал длины ключей.
в вики про L2TP пишут обратное:

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

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

https

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


1) а ничего, что openvpn работает в userspace, а ipsec — в ядре?
2)и намного — это во сколько раз?
3)ничего не сказано про пагубность tcp over tcp и чудесах, которые начинаются при малейшем packetloss.
4)о какой версии l2tp идет речь в статье?
Я вам больше скажу, OpenVPN еще и не распараллеливается на процессоры.
никто не мешает делать несколько туннелей и делать бонд интерфейс
3) TCP meltdown, лосс/уменьшение пропускной способности должны быть существенными
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-соединения по таймауту.
прекрасно видел и ощущал на себе, когда использовал openvpn/vtund через отельный wifi в египте.
там были потери ~ 3-6% и при этом работать по ssh было невозможно(в лучшем случае всё жутко тормозило, в худшем — соединение «подвисало»).
А можно пару советов по выбору протокола для плохих каналов?
Часто приходится подключаться через мобильную сеть. Важен ли такой параметр как сжатие трафика?
У Openvpn есть comp-lzo, у IPSEC, насколько знаю сжатия нет нативного.

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

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

Т.е. LZO жмет хуже.
Я думаю стоит смотреть в сторону SSL-based: OpenVPN и SSTP, SSTP быстрее работает, но хуже переносит ухудшение качества связи.
UFO landed and left these words here
а мне кажется, что куда сильнее влияет на цифры надпись внизу «Hosted by» ;)
UFO landed and left these words here
UFO landed and left these words here
да, поэтому и спросил собственно. :(
У нас в компании все под виндой работают, поэтому нам было бы удобно :)
У нас в компании все под виндой работают, поэтому нам было бы удобно :)


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

Мы уже давно — «vendor lock-in», особенности бизнеса такие :(
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, и любые другие комбинации).
различные варианты eap

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

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

а можно пример именно двухфакторной аутентификации?
afaik, в eap можно либо/либо. т.е. либо сертификаты(в т.ч. на смарткарте), либо различные варианты пароля(plain/hash/challenge-response)
>One of the problems with RRAS is that out of the box there isn't a real method for using two factor authentication
Странно, что автор находит настройку IPSec «простой». Судя по разным статьям/howto и отзывам знакомых, которые его настраивали — и PPTP и OpenVPN настроить в разы проще. Хотя возможно автор имел в виду только клиентскую часть.
У IPSec нет никаких сложностей в настройке и на принимающей стороне. Если знать матчасть.

С другой стороны, изредка бывают странные провайдеры, у которых бывают странные глюки. К примеру: через минуту после поднятия SA начинают теряться ESP пакеты в количестве 100%, и так до переустановки SA (это из недавнего). Потери именно на сети оператора — это доказано. В какой-то момент проблема саморазрешилась. Провайдер, конечно, как всегда ничего не делал… Я к тому, что такие вещи простым телнетом на порт не протраблшутить, требуется больше телодвижений. Но все равно ничего страшного там нет. Обычно IPSec работает как часы.
У OpenVPN есть еще одна интересная функция, вытекающая из его гибкой конфигурации, это возможность работать через любой HTTTP Proxy.
Статья выглядит крайне поверхностной, содержит кучу ляпов (и многие уже их отметили: смешивание в кучу симметричных и асимметричных ключей, путаницу насчет GRE), упоминает только узкий круг решений: забыт популярный Cisco VPN (он, конечно, IPSec-based, но барахла на базе последнего выше крыши), скомкано описана поддержка в разных ОС. Например, не разделена поддержка в десктопных, серверных, мобильных ОС и firmware роутеров.
Ещё у openvpn есть фича мультиплексирования своих данных и https траффика на одном порту. Удобно, если надо отдавать https и vpn на 443, чтобы он был доступен из кафе или других мест с ограниченным интернетом.
Уважаемый переводчик. Вы когда, в следующий раз что-то переводите, пожалуйста, хоть чуть-чуть понимайте в теме перевода. Чтоб не переводить откровенный бред. Так как в данном случае результат Вашего труда по смыслу кроме как «упоротым» назвать сложно.
Only those users with full accounts are able to leave comments. Log in, please.