Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 98
Автор очень ловко сравнивает длину ключей у симметричных алгоритмов(128, 256) и асимметричных (2048, 4096)
> PPTP
Тут еще нужно добавить, что PPTP использует протокол GRE, который в некоторых роутерах может быть либо заблокирован, либо они вообще могут не уметь его маршрутизировать (да, видел я и такое).
> SSTP
Насчет windows-only — частично. Клиенты есть и под линукс, и емнип, под мак. А вот с серверной частью все сильно грустно :(
Тут еще нужно добавить, что PPTP использует протокол GRE, который в некоторых роутерах может быть либо заблокирован, либо они вообще могут не уметь его маршрутизировать (да, видел я и такое).
> SSTP
Насчет windows-only — частично. Клиенты есть и под линукс, и емнип, под мак. А вот с серверной частью все сильно грустно :(
Есть сервак для SSTP и работает как минимум в Ubuntu unix.stackexchange.com/a/76487
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», но что-то не видно их пока.
2. А где же исходники? Лично мне как-то стремно ставить какой-то левый VPN-сервер, через который будет идти весь мой траффик. Там пишут, что «and aiming to release the source code of SoftEther VPN in middle of 2013 or earlier», но что-то не видно их пока.
Или статья старая, или автор что-то путает.
Ничего не написано про чистый IPSec, без L2TP. В режиме NAT-T он прекрасно работает за файрволами и шифрует пакеты на втором уровне. При этом скорость выше, а потребление ресурсов ниже, чем тот же OpenVPN, который работает на третьем уровне. Хорошие серверные сетевые карты поддерживают IPSec offload.
Использование OpenVPN в TCP-режиме вызывает значительный overhead, так как TCP пакеты инкапсулируются внутрь TCP. В таком режиме пропускная способность падает, потребление вычислительных ресурсов возрастает.
Так что если есть возможность выбирать, то надо ставить IPSec. Если есть потенциальная проблема с закрытыми портами, только тогда можно настраивать OpenVPN.
Для современных мобильных устройств поддержка OpenVPN на очень хорошем уровне. Например, штатный конфигурационный профиль Apple iOS может содержать OpenVPN payload, все прекрасно работает, проверено лично.
Про PPTP действительно лучше даже не думать при развертывании VPN инфраструктуры, слишком много неприятных нюансов.
Ничего не написано про чистый IPSec, без L2TP. В режиме NAT-T он прекрасно работает за файрволами и шифрует пакеты на втором уровне. При этом скорость выше, а потребление ресурсов ниже, чем тот же OpenVPN, который работает на третьем уровне. Хорошие серверные сетевые карты поддерживают IPSec offload.
Использование OpenVPN в TCP-режиме вызывает значительный overhead, так как TCP пакеты инкапсулируются внутрь TCP. В таком режиме пропускная способность падает, потребление вычислительных ресурсов возрастает.
Так что если есть возможность выбирать, то надо ставить IPSec. Если есть потенциальная проблема с закрытыми портами, только тогда можно настраивать OpenVPN.
Для современных мобильных устройств поддержка OpenVPN на очень хорошем уровне. Например, штатный конфигурационный профиль Apple iOS может содержать OpenVPN payload, все прекрасно работает, проверено лично.
Про PPTP действительно лучше даже не думать при развертывании VPN инфраструктуры, слишком много неприятных нюансов.
Использование OpenVPN в TCP-режиме вызывает значительный overhead, так как TCP пакеты инкапсулируются внутрь TCP. В таком режиме пропускная способность падает, потребление вычислительных ресурсов возрастает.
Так что если есть возможность выбирать, то надо ставить IPSec. Если есть потенциальная проблема с закрытыми портами, только тогда можно настраивать OpenVPN.
Использование OpenVPN в его штатном UDP режиме вызывает намного меньший overhead, чем openvpn over tcp. Единственный плюс IPSec, который я для себя уяснил — меньшее потребление ресурсов. Что именно я пропустил?
PPTP изобретён не Microsoft, а Cisco.
И действительно, лихо автор смешал длины ключей.
И действительно, лихо автор смешал длины ключей.
в вики про L2TP пишут обратное:
1996—1997 — конкуренция между протоколами L2F (Cisco) и PPTP (Microsoft)
1997 — соглашение между разработчиками о совместной разработке протокола L2TP
1999 — опубликован стандарт RFC 2661, описывающий протокол L2TP
Считается, что протокол L2TP вобрал в себя лучшие черты L2F и PPTP[1].
1996—1997 — конкуренция между протоколами L2F (Cisco) и PPTP (Microsoft)
1997 — соглашение между разработчиками о совместной разработке протокола L2TP
1999 — опубликован стандарт RFC 2661, описывающий протокол L2TP
Считается, что протокол L2TP вобрал в себя лучшие черты L2F и PPTP[1].
в PPTP есть еще протокол аутентификации PAP или это тот же PEAP?
Кстати, протокол SSL, например, использует TCP-порт 443, чтобы быть неотличимым от обычного HTTPS-трафика
Прекрасная фраза
Да уж, странная статья, может имелось ввиду, что при использовании OpenVPN в режиме TCP там где нет анализатора пакетов, а только разрешены определённые порты можно будет «замаскировать» OpenVPN сервер под HTTPS сайт. Конечно же это не имелось ввиду, однако об этом стоит упомянуть в этом топике :) К примеру при работе через корпоративный прокси очень часто OpenVPN в режиме TCP на 443 порту это единственный работающий механизм.
это какой такой анализатор пакетов расковыряет ssl (без вмешательства)?
Там таки разный формат handshake'а, который позволяет DPI отличить OpenVPN от SSL/TLS:
https
openvpn
действительно, мультиплексер себя выдаёт.
Вот с sstp такое у меня не получилось, я вижу SSL, и без расшифровки дальше понять, что внутри туннель не получается. Вроде всё правильно сделал.
Вот с sstp такое у меня не получилось, я вижу SSL, и без расшифровки дальше понять, что внутри туннель не получается. Вроде всё правильно сделал.
Эта проблема обходится с помощью мультиплексора sslh и openvpn c --port-share на 443 порту.
Примеры, приведенные мной — это openssl с опцией
Скорее всего, sslh работает также (у меня его нет в репозиториях сервера, чтобы проверить — он всё-таки ещё нестабильный).
port-share 127.0.0.1 443. Мультиплексор различает трафик точно также, как и dpi. Скорее всего, sslh работает также (у меня его нет в репозиториях сервера, чтобы проверить — он всё-таки ещё нестабильный).
из того как это работало на практике я могу сделать вывод что происходило вот что dpi видит коннект на 443 порт и пытается вклинится но от dpi в сеть уходит пакет с ssl handshake на него отвечает sslh и пробрасывает конект на https, получив «правильный» ответ dpi разрешает соединение. в рез-те и openvpn tcp/443 и даже ssh/443 работали
навернякак это сильно зависит от dpi «железки»
навернякак это сильно зависит от dpi «железки»
При выборе длины ключа стоит учесть и государственные правила. В России без ограничений можно использовать симметричные ключи длиной до 56 битвключительно, асимметричные — до 512. Дальше начинаются юридические заморочки.
*отредактировано
То ли перевод неок, то ли в статье действительно ничего по делу:
1) нет описания различия принципов встраивания в сетевой стек системы: PPP, TUN/TAP
2) «L2TP медленее OpenVPN» — не верю, хоть какое-то обоснование должно быть
3) OpenVPN сложен в настройке? Настройте SSTP. Нет, не клиентскую часть.
1) нет описания различия принципов встраивания в сетевой стек системы: PPP, TUN/TAP
2) «L2TP медленее OpenVPN» — не верю, хоть какое-то обоснование должно быть
3) OpenVPN сложен в настройке? Настройте SSTP. Нет, не клиентскую часть.
По второму пункту автор пишет так:
Однако, поскольку он [IPsec] инкапсулирует данные дважды, это не так эффективно, как SSL-решения (например, OpenVPN или SSTP), и поэтому работает немного медленнее.
Настройте SSTP. Нет, не клиентскую часть.
А в чем проблема? RRAS настраивается в несколько кликов без лазанья по конфигам.
одного RRAS'а недостаточно, где-то должен жить CA, должен быть сконфигурирован NAP, короче это так или иначе подтянет AD. Я понимаю, что большинство windows-сетей уже работают с AD, но, в данном случае, сравнивая с openvpn, настройка «с нуля» у openvpn несравнимо проще.
Авторизации по сертификатам в условиях не было :) А без неё не нужен ни AD, ни CA, точно не помню, но вроде даже без NPS можно обойтись.
На сколько мне известно SSTP не работает без серверного сертификата с FQDN в CN.
Его можно получить в доверенном CA (тот же StartCom) или сгенерировать самому в SelfSSL, OpenSSL, SelfCert и подобных утилитах.
А в чем проблема? RRAS настраивается в несколько кликов без лазанья по конфигам.
а теперь то же самое, но на cisco/juniper.
Поднимал в локалке сервера 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
www.barabanov.ru/arts/tcp/Tcp_over_tcp_is_not_so_bad-web.pdf
и проводившем эксперименты на канале с потерями.
Угу, интернет — идеальное средство связи, абсолютно lossless, с PFC для всех классов трафика из конца в конец :)
Конечно же TCP ведет себя как ягненок при отсутствии потерь и когда перегрузка канала фиксируется по всплеску задержки. А если поднять VPN через 3G или не очень хорошо ловящий wi-fi, с полпроцента потерь?
А при чем тут это? Основная мысль в том, что внутреннему тсп не будет шибко хуже, чем внешнему. Ну и миф собственно утверждает обратное (meltdown-эффект).
Очевидно, что потери в тсп, не связанные с перегрузкой гнобят тсп по полной. Но это уже совершенно другая тема. Мы вроде обсуждаем, что тсп через тсп ведет себя забавно.
Однако, поскольку он инкапсулирует данные дважды, это не так эффективно, как 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-соединения по таймауту.
Я лично проводил тесты на dummynet. Эффект есть, вплоть до ресета внутреннего tcp-соединения по таймауту.
прекрасно видел и ощущал на себе, когда использовал openvpn/vtund через отельный wifi в египте.
там были потери ~ 3-6% и при этом работать по ssh было невозможно(в лучшем случае всё жутко тормозило, в худшем — соединение «подвисало»).
там были потери ~ 3-6% и при этом работать по ssh было невозможно(в лучшем случае всё жутко тормозило, в худшем — соединение «подвисало»).
А можно пару советов по выбору протокола для плохих каналов?
Часто приходится подключаться через мобильную сеть. Важен ли такой параметр как сжатие трафика?
Часто приходится подключаться через мобильную сеть. Важен ли такой параметр как сжатие трафика?
У Openvpn есть comp-lzo, у IPSEC, насколько знаю сжатия нет нативного.
А в общем, через мобильную сеть будет работать и то и то. Мы в свое время поднимали Openvpn как раз для мобильных пользователей.
А в общем, через мобильную сеть будет работать и то и то. Мы в свое время поднимали Openvpn как раз для мобильных пользователей.
Я думаю стоит смотреть в сторону SSL-based: OpenVPN и SSTP, SSTP быстрее работает, но хуже переносит ухудшение качества связи.
>OpenVPN и SSTP, SSTP быстрее работает
в каком смысле?
в каком смысле?
в смысле байтов в секунду
Я провел полевой тест, чтобы опытным образом установить производительность IPSec и OpenVPN на отдельно взятом iPhone в определенной точке пространства :-)
Для начала на телефон были установлены три профиля: IPSec, OpenVPN UDP 1194 и OpenVPN TCP 443. Сервисы VPN запущены на одном сервере.
Затем последовательно подключался к VPN и проверял скорость. Вот результаты:
IPSec
OpenVPN UDP 1194
OpenVPN TCP 443
На Samsung Galaxy S4 скорость OpenVPN при аналогичном подключении значительно выше и упирается в пропускную способность LTE. Разницы между UDP и TCP практически нет. Видимо сильно влияет более производительный процессор, чем в iPhone 5.
Для начала на телефон были установлены три профиля: IPSec, OpenVPN UDP 1194 и OpenVPN TCP 443. Сервисы VPN запущены на одном сервере.
Затем последовательно подключался к VPN и проверял скорость. Вот результаты:
IPSec
OpenVPN UDP 1194
OpenVPN TCP 443
На Samsung Galaxy S4 скорость OpenVPN при аналогичном подключении значительно выше и упирается в пропускную способность LTE. Разницы между UDP и TCP практически нет. Видимо сильно влияет более производительный процессор, чем в iPhone 5.
а мне кажется, что куда сильнее влияет на цифры надпись внизу «Hosted by» ;)
Провел чистый тест, на фиксированный сервер.
IPSec
OpenVPN UDP
OpenVPN TCP
IPSec
Пинг: 40
Скорость: 19,11 Мбит/с
OpenVPN UDP
Пинг: 62
Скорость: 13,26 Мбит/с
OpenVPN TCP
Пинг: 75
Скорость: 10,64 Мбит/с
А sstp проверить нет возможности?
Нет, к сожалению. SSTP — это только для Windows, я же проверял на публичном коммерческом VPN сервисе с айфона. Публичные сервисы используют наиболее распространенные и кросс-платформенные решения, для лучшей поддержки и бОльшего охвата.
SSTP есть смысл развертывать для корпоративных нужд.
SSTP есть смысл развертывать для корпоративных нужд.
да, поэтому и спросил собственно. :(
У нас в компании все под виндой работают, поэтому нам было бы удобно :)
У нас в компании все под виндой работают, поэтому нам было бы удобно :)
У нас в компании все под виндой работают, поэтому нам было бы удобно :)
мне кажется, вы таким образом сами раскладываете себе кучу грабель в виде vendor lock-in.
ipsec — стандарт, в отличие от sstp. причём, в ipsec вы можете аутентификацию сделать как душе угодно(да хоть те же смарткарты) или двухфакторную аутентификацию.
А разве с sstp такие вещи провести нельзя?
Мы уже давно — «vendor lock-in», особенности бизнеса такие :(
Мы уже давно — «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, и любые другие комбинации).
причём, сервер аутентифицируется на этапе установления 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 — отстой, не универсально).
Ах да, это тоже обернется анальным рабством, полностью согласен :)
Странно, что автор находит настройку IPSec «простой». Судя по разным статьям/howto и отзывам знакомых, которые его настраивали — и PPTP и OpenVPN настроить в разы проще. Хотя возможно автор имел в виду только клиентскую часть.
У IPSec нет никаких сложностей в настройке и на принимающей стороне. Если знать матчасть.
С другой стороны, изредка бывают странные провайдеры, у которых бывают странные глюки. К примеру: через минуту после поднятия SA начинают теряться ESP пакеты в количестве 100%, и так до переустановки SA (это из недавнего). Потери именно на сети оператора — это доказано. В какой-то момент проблема саморазрешилась. Провайдер, конечно, как всегда ничего не делал… Я к тому, что такие вещи простым телнетом на порт не протраблшутить, требуется больше телодвижений. Но все равно ничего страшного там нет. Обычно IPSec работает как часы.
С другой стороны, изредка бывают странные провайдеры, у которых бывают странные глюки. К примеру: через минуту после поднятия SA начинают теряться ESP пакеты в количестве 100%, и так до переустановки SA (это из недавнего). Потери именно на сети оператора — это доказано. В какой-то момент проблема саморазрешилась. Провайдер, конечно, как всегда ничего не делал… Я к тому, что такие вещи простым телнетом на порт не протраблшутить, требуется больше телодвижений. Но все равно ничего страшного там нет. Обычно IPSec работает как часы.
У OpenVPN есть еще одна интересная функция, вытекающая из его гибкой конфигурации, это возможность работать через любой HTTTP Proxy.
Статья выглядит крайне поверхностной, содержит кучу ляпов (и многие уже их отметили: смешивание в кучу симметричных и асимметричных ключей, путаницу насчет GRE), упоминает только узкий круг решений: забыт популярный Cisco VPN (он, конечно, IPSec-based, но барахла на базе последнего выше крыши), скомкано описана поддержка в разных ОС. Например, не разделена поддержка в десктопных, серверных, мобильных ОС и firmware роутеров.
SSLv3, вроде же, поломали? en.wikipedia.org/wiki/Transport_Layer_Security#SSL_3.0
SSTP вроде уже есть на MikroTik RouterOS 6.x
Действительно есть и даже работает с версии 5.х
Ещё у openvpn есть фича мультиплексирования своих данных и https траффика на одном порту. Удобно, если надо отдавать https и vpn на 443, чтобы он был доступен из кафе или других мест с ограниченным интернетом.
Уважаемый переводчик. Вы когда, в следующий раз что-то переводите, пожалуйста, хоть чуть-чуть понимайте в теме перевода. Чтоб не переводить откровенный бред. Так как в данном случае результат Вашего труда по смыслу кроме как «упоротым» назвать сложно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PPTP vs L2TP vs OpenVPN vs SSTP