Comments 36
Как раз на работе танцую с бубном вокруг libreswan. Падает в кору, зараза!
Попробуйте strongSwan — пока проблем на простом L2TP IPSec не наблюдалось.
Ну, у меня 4 подключения, два IPsec, одно L2TP/IPsec, одно dial-in L2TP/IPsec, т.е. не «простой» сервер. Валится почему-то с руганью на одно из IPsec-подключений (одно и то же) с воплем OAKLEY_DES_CBC not supported, proposal refused, потом сегфолт. При этом вторая сторона вообще не настроена предлагать что-то отличное от AES256!

Вообще, я вначале посмотрю, как себя поведет libreswan из исходников, он по версии выше, чем пакет в репозитории, а переделать на strongswan можно будет следующим этапом.
Эксплуатирую strongswan в продакшне (L2TP/IPsec, IKEv1, IKEv2) — на сегодня это наиболее передовой форк FreeS/WAN. Я бы даже сказал, что вам в любом случае стоит развернуться в сторону его использования — кроме него сейчас ничего адекватного нет.
Очень похоже на статью по «продвижению своих решений». Не, оно конечно всё с открытым кодом, но тон какой-то маркетинговый.
Из собственного опыта хочу заметить, что OpenVPN это лучшее что случилось с технологиями VPN за последнее время, всё что было до — IPSEC, PPTP, L2TP оказалось громоздким, небезопасным и в целом ненадёжным. Сколько времени и нервов потрачено на попытки «подружить» между собой различные корпоративные «точки зрения» на реализацию IPSEC. Так что, если есть возможность от IPSEC уйти — лучше это сделать как можно раньше и никогда не оглядываться.
OpenConnect (он же в девичестве Cisco Anyconnect) — тоже не взлетел, можно сказать.
SSTP (так называемый SSL VPN) — это попытка бизнесов догнать и перегнать OpenVPN, тоже не получила массового распространения, из реализаций серверов/клиентов с открытым кодом есть только SoftEther, кстати о нём.
Почему-то автор не упомянул такое универсальное решение как SoftEther — L2TP, OpenVPN, SSTP сервер в одном флаконе, с общим интерфейсом, с удивительным количеством вариантов настройки, даже совместимый с SSTP клиентами последних версий Windows (там правда с сертификатом надо шаманить слегка, так что уже не совсем прозрачно получается).
Ну и безусловный лидер последних лет это OpenVPN.
IPSec — это один из протоколов который незавим для каждой из сторон (side-to-side vpn)
Причем как с серверной стороны (а именно центральный сервер здесь отсутствует как таковой, т.е. каждая сторона равноправна) так и со стороны оборудования (IPSec туннель можно настроить между оборудованием разных вендоров).
Считаю что в некоторых случаях он действительно может быть незаменим. Например, если вам необходимо настроить равноправный канал с какой-нибудь сторонней организацией — с большой долей вероятности это будет IPSec и чем его тут заменять непонятно.
Да ну. Каждый производитель демонстрирует свое «вИдение» этого стандарта — IKE такое-сякое, вдруг X-Auth, а может и нет, если не приведи господи транзит идёт через кого-то, он может и не захотеть пропускать всякую экзотику типа ESP — да ну к лешему такую независимость. То, что за десятки лет существования его воплотили во множество железяк, в отличии от всех остальных — это совсем другой разговор и чаще всего перевешивает все остальные недостатки — ваши сетевые протоколы заканчиваются на сетевых устройствах, а не вылазят на сервера.
Ну хорошо — от офиса к офису, в пределах одной организации (сетевые устройства одного производителя) — IPSEC имеет право на жизнь. Удалённый доступ ко офису для мобильных клиентов — я бы не связывался.
На данный момент наиболее разумно использовать IKEv2 по следующим причинам:
1. Обработка пакетов происходит в пространстве ядра, а не в юзерспейсе как у OpenVPN, что создаёт значительный отрыв в производительности.
2. Имеется встроенная поддержка NAT-Traversal и инкапсуляции IPsec в UDP, если это необходимо.
3. Как раз для мобильных клиентов в IKEv2 есть расширение MOBIKE, которое поддерживается всеми современными ОС и позволяет поддерживать подключение, переключаясь между разными физическими каналами.
1. На данный момент обработка пакетов в ядре это не преимущество, а недостаток — при глючной имплементации (а протокол сложный и накосячить там можно много где) есть шанс уронить всё, а запасы по производительности современных систем позволяют обрабатывать пакеты в юзерспейсе без особой потери производительности.
2. Ну да, возможно
3. Вот, не поленился пошел, глянул — из тройки freeswan, strongswan, libreswan, MOBIKE декларируется в явном виде только у strongswan, остальные может тоже умеют, но сильно это не выпячивают. Что там и как поддерживают клиенты, остаётся только гадать — опять же, протокол сложный и корректно его воспроизвести могут только большие и опытные команды разработчиков, для которых это — основной бизнес, те, которым для галочки и реализуют его достаточно куцым.
Тем более, как сама основа дизайна, 2х потоковые протоколы устарели, все остальные шифрованнные соединения как-то научились обходиться одним.
1. Это домыслы. IPsec — тунельный протокол и ему место только в ядре, как и PPP, GRE. Достижение предела по CPU в OpenVPN на «современном» устройстве — обычное дело. В этой статье рассказано, как ускоряли OpenVPN за счёт выноса шифрования на FPGA. В комментариях авторы упоминают (и я наблюдал такие же результаты), что примерно половина времени CPU приходится на всяческие перекладывания пакетов между юзерспейсом и сетью, то есть обусловлены исключительно конструкцией OpenVPN вне ядра.
3. Эта фича проверена на клиенте лично мной на клиенте в Mac OS, iOS, Android (StrongSwan). Ещё поддержка имеется в Windows, но её я не проверял.

Это радует. Форум, сайт и даты релизов ещё полгода тому назад оставляли другое ощущение.

Вот эту штуку ещё забыли: www.zerotier.com Пользуюсь, очень радует. Грубо говоря, создаёшь свой виртуальный Ethernet-сегмент, раздаёшь IP всем компам, телефонам и зубочисткам и радуешься. Это P2P (mesh) VPN-решение, сервер нужен только для координации.

Есть вариант получше — NeoRouter Free, свой сервер в бесплатной версии, никаких привязок к кому-либо, пользуюсь активно и перманентно с 2009 года.

Спасибо, выглядит очень многообещающе, надо будет попробовать заменить свой «аварийный вариант» с PPTP на этот, тем более есть клиенты под основные платформы.
Почитал документацию — миленько, но бедненько.
Без исходников, внешней аутентификации нет, не буду время тратить, под мои задачи не подходит.
А мне Pritunl нравится, очень простой и лаконичный GUI для OpenVPN:

image
kvaps, не подскажешь удалось ли изменить серверный конфиг на каждый тунель? насколько понял конфиг единый и генерируется при создании сервера и его никак не изменить, потому как даже при остановке сервера тунель удалятся, имея парк ip телефонов с устаревшим openvpn клиентом вынужден был отключить опцию topology subnet чтобы и телефоны и клиенты работали, но есть проблема с мобильными ios android клиентами, не хотят работать с topology net30, а в целом проект отличный все удобно

Лучшее VPN решение это то, которое Роскомнадзор сможет заблокировать в последнюю очередь. А об это в статье ни слова.

Оценивать VPN исключительно с точки зрения его прокси-возможностей это то же самое, как оценивать веб-сервер (например nginx) исключительно с точки зрения возможности запустить на нём веб-анонимайзер типа anonymouse.org. И новости с законами (о которых я, естественно, в курсе) тут ни при чём.

И зачем вы оцениваете VPN с точки зрения его прокси-возможностей? Тем более что никаких прокси-возможностей у VPN нет вообще.

cryptostorm.is?
Исландский, децентрализованный и очень толковый. Деанон-сервисы даже не понимают, что вы сидите с VPN (если конечно, позаботились о тайм-зоне и замкнули WebRTC).
в чём разница между VPN и VPS

Я один прочитал: В чем разница между свёклой и борщом?
> Algo поддерживает только IKEv3 с единственной подсистемой шифрования.
IKEv2.

Так это же тупо рекламный пост для VyprVPN?
Автор описывает несколько простых истин про впн, создавая слабенькое ощущение то что это настоящая статья, а потом в открытую рекламирует один из сотен подобных сервисов, тратя на это весомую часть всей статьи! Либо автор один из владельцев этого сервиса, либо просто зарабатывает на рефералах!

Only those users with full accounts are able to leave comments. Log in, please.