The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Доступен релиз OpenVPN 2.4.0

28.12.2016 09:48

После почти четырёх лет с момента публикации ветки 2.3 выпущен релиз OpenVPN 2.4.0, пакета для создания виртуальных частных сетей, позволяющего организовать шифрованное соединение между двумя клиентскими машинами или обеспечить работу централизованного VPN-сервера для одновременной работы нескольких клиентов. Код OpenVPN распространяется под лицензией GPLv2, готовые бинарные пакеты подготовлены для Debian, Ubuntu, CentOS, RHEL и Windows.

Из добавленных в новой версии улучшений можно отметить:

  • Добавлена возможность бесшовной смены IP-адреса и номера сетевого порта клиента без разрыва соединения VPN. В новой версии представлен новый протокол P_DATA_V2, в котором для идентификации клиента используется универсальный Peer-ID. При изменении IP-адреса/порта, но сохранении Peer-ID, серевер считает соединение мигрировавшим, проверяет HMAC и обновляет сетевые параметры клиента в своих внутренних структурах без повторного согласования соединения;
  • Реализована возможность использования режима блочного шифрования AEAD GCM, при котором шифруется лишь важная часть данных (остаются открыты IP-адреса, номера протоколов и прочие метаданные), но всё сообщение, включая открытые метаданные, аутентифицировано. По сравнению с CBC пакеты в формате AEAD привносят небольшие накладные расходы - при схеме AES-128-GCM дополнительно добавляется 20 байт на пакет вместо 30 байт для AES-128-CBC + HMAC-SHA1;
  • Добавлена поддержка протокола согласования ключей на основе эллиптических кривых ECDH (Elliptic Curve Diffie-Hellmann), позволяющего имея незащищённый канал связи получить двум сторонам общий секретный ключ для дальнейшего шифрования;
  • Включен по умолчанию механизм согласования шифров ("--cipher"), используемых для защиты канала передачи данных. Если клиент объявит о поддержке согласуемых параметров шифрования (NCP, Negotiable Crypto Parameters), то сервер выберет оптимальный шифр (по умолчанию AES-256-GCM) и предложит его клиенту. Управлять доступными для согласования шифрами можно через опции "--ncp-ciphers" и "--ncp-disable". В случае если на клиенте или сервере используется старая версия OpenVPN, то возможно ограниченное согласование, при котором система с OpenVPN 2.4 может выбрать шифр, используемый на стороне с более ранее версией OpenVPN. Например, клиент 2.4 с "--cipher BF-CBC" и "ncp-ciphers AES-256-GCM:AES-256-CBC" может подсоединиться как к серверу 2.3 с выбранным шифром BF-CBC в файле конфигурации, так и с AES-256-CBC;
  • Добавлена поддержка сжатия при помощи алгоритма LZ4 (ранее поддерживался только LZO) и возможность передачи параметров сжатия со стороны сервера;
  • Добавлена опция "--tls-crypt" для увеличения защиты конфиденциальных данных о соединении пользователя. Опция позволяет использовать заранее предопределённые статические ключи для шифрования пакетов с управляющей информацией;
  • Улучшена работа в окружениях, одновременно использующих IPv4 и IPv6. Например, при соединении с внешним хостом OpenVPN пытается соединиться перебирая все привязанные в DNS адреса IPv6 и IPv4. В настройки добавлена новая опция DNS6 для явного задания DNS-резолвера для IPv6. Настройки "proto udp" и "proto tcp" теперь охватывают как IPv4, так и IPv6. Для настройки только IPv4 добавлены новые опции "proto udp4" и "proto tcp4";
  • Добавлена опция pull-filter, позволяющая явно разрешить или запретить приём опций отправляемых сервером. Также добавлена опция push-remove для выборочного удаления опций из списка "push";
  • Добавлена опция "--auth-gen-token", при указании которой сервер сгенерирует случайный токен и предаст его клиенту без изменения модулей аутентификации. Режим полезен для реализации схем с одноразовыми паролями, позволяя организовать периодическое обновление ключей без необходимости ввода новых кодов OTP;
  • Значительно расширен графический интерфейс, встроенный в установочный пакет для Windows. В том числе обеспечена возможность запуска OpenVPN GUI в Windows без наличия привилегий администратора. Полностью переписана прослойка для запуска сервиса OpenVPN в Windows. В установщике OpenVPN 2.4 прекращена поддержка Windows XP;
  • Добавлена поддержка платформ Android (через VPNService API) и AIX (через устройство tap). Для macOS реализована возможность использования встроенного хранилища ключей;
  • Для работы со списками отзыва сертификатов (CRLs) вместо встроенной реализации задействованы возможности внешних библиотек (OpenSSL или mbed TLS);
  • Объявлен устаревшим режим "--key-method 1" и опция "--no-iv", их поддержка будет удалена в следующей ветке, как и поддержка ранее объявленных устаревшими опций "--compat-names" и "--no-name-remapping". Удалена опция "--tls-remote", объявленная устаревшей в прошлой ветке;

  1. Главная ссылка к новости (https://sourceforge.net/p/open...)
  2. OpenNews: Надёжность OpenVPN будет проверена в ходе аудита
  3. OpenNews: Представлен Sweet32, новый вид атаки на HTTPS и OpenVPN
  4. OpenNews: Выпуск OpenVPN 2.3.6, 2.2.3 и 2.0.11 с устранением уязвимости
  5. OpenNews: Опасная уязвимость в реализациях LZO/LZ4, затрагивающая ядро Linux, FFmpeg, OpenVPN и другие проекты
  6. OpenNews: Увидел свет OpenVPN 2.3.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/45777-openvpn
Ключевые слова: openvpn, vpn
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (111) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Аноним (-), 11:13, 28/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    интересно, производительность по сравнению с open any connect как? Кто-нибудь замерял?
     
     
  • 2.24, cmp (ok), 13:25, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А это что такое, впрочем, мне не интересно, линуха-линуха и через ssh нормально туннелится, а роутеры умеют gre, ipip и openvpn. gre у каждого свой, ipip бесполезен, так что выбор не велик.
     
     
  • 3.45, qwerty123 (??), 15:53, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >gre у каждого свой

    неправда, прекрасно стандартизован.


     
     
  • 4.81, cmp (ok), 04:38, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > неправда, прекрасно стандартизован.

    А я утверждал обратное? Нет.

    Я говорил о том, что сервер под разных клиентов gre поднять заморочно, а может и невозможно, так как стандартов много, а на софт-vpn легко, тока копии процесса по разным портам расскидать с разными настройками.


     
     
  • 5.87, zanswer (?), 12:46, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Можете чуть подробнее рассказать, что вы имеете ввиду под GRE у каждого свой? Не считая первое RFC, их всего два вида заголовков стандартизировали. Один причём исклюзиано для PPTP, а второй общепринятый, его все и используют.
     
     
  • 6.93, cmp (ok), 15:46, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Можете чуть подробнее рассказать, что вы имеете ввиду под GRE у каждого
    > свой? Не считая первое RFC, их всего два вида заголовков стандартизировали.
    > Один причём исклюзиано для PPTP, а второй общепринятый, его все и
    > используют.

    GRE, OSPF, BGP, STP, LLDP и наверняка еще столько же не вспомнил, протоколы и стандарты, которые у каждого вендора, со своими "плюшками" из-за которых частенько оно в кроссвендорных связках не работает или работает, но криво.

    Полгода назад, ковырял этот gre, уж не помню откуда куда, но на одном конце пакеры tcpdump показывает in-out, на другом показывает только out.

     
     
  • 7.94, zanswer (?), 15:53, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если честно, исключая LLDP, с ним плотно не работал, у названных протоколов проблем в реализации между вендорами не встречал. Под вендорами я имею ввиду, Cisco, Juniper и тд., D-Link, TP-Link и прочие ломают что угодно и когда угодно.
     
     
  • 8.118, cmp (ok), 10:00, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Повезло вам, а нам на циски денег не дают, лучшее из того, что есть - это хуавей... текст свёрнут, показать
     
     
  • 9.120, zanswer CCNA RS (?), 10:39, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я слышал много хорошего о Huawei, по отношению к другим Китайским брендам ... текст свёрнут, показать
     
     
  • 10.124, cmp (ok), 12:23, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В целом железо прекрасное, в 2 раза дешевле и в 2 раза производительнее циски ... текст свёрнут, показать
     
  • 8.127, Нечестивый (ok), 13:15, 31/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Со стороны Juniper проблем тоже ни видел и вряд ли будут, но вот Cisco очень люб... текст свёрнут, показать
     
  • 7.95, zanswer (?), 15:57, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если пакеты на одной из сторон не возвращаются, значит имеет место быть их потеря в транзите, например по причине асимметричной маршрутизации, при которой обратные пакеты уходят не туда.

    Возможно я вас не правильно понял, но не вижу тут причин винить GRE, если пакеты вообще не пришли на интерфейс.

     
     
  • 8.117, cmp (ok), 09:54, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    НА Интерфейс туннеля нет, а на интерфейс физический gre трафик сыпется ... текст свёрнут, показать
     
     
  • 9.121, zanswer CCNA RS (?), 10:42, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    С удовольствием бы сделал TSHOOT по данной теме, если трафик дошёл до физическог... текст свёрнут, показать
     
  • 3.49, ram_scan (?), 16:34, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Было время когда GRE грустно ходил через NAT на сохо железках. Лично я с той поры как-то в UDP верую больше.
     
     
  • 4.74, Аноно (?), 00:52, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    с тех пор что-то изменилось? GRE и сейчас грустно ходит через NAT
     
  • 4.80, cmp (ok), 04:26, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Было время когда GRE грустно ходил через NAT на сохо железках. Лично
    > я с той поры как-то в UDP верую больше.

    Даже сейчас есть железо через которое gre не натится, причем операторское.

     
     
  • 5.86, zanswer (?), 12:42, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Тому есть вполне простое объяснение, вытекающие из формата заголовка GRE, а делать ALG в масштабах операторских решений не всегда рентабельно вестимо.
     
     
  • 6.96, cmp (ok), 16:01, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Тому есть вполне простое объяснение, вытекающие из формата заголовка GRE, а делать
    > ALG в масштабах операторских решений не всегда рентабельно вестимо.

    Дело в том, что железка которая не умеет стоила 3 миллиона дервянных в 13-14 годах, сейчас она толи 5, толи 6 стоит, при этом вендор для решения проблемы предлагает поставить циску и ацлками завернуть на нее gre трафик, хотя проще было бы купить циску и использовать ее, в стойке их стоит 4 штуки, а для 20 миллионой покупки формат заголовка не оправдание, к счастью или сожалению это не единственная проблема железки, поэтому, аллилуя, их скоро заменят хуавеями, но тем не менее.

     
     
  • 7.98, zanswer (?), 16:17, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Cisco тоже не умеет делать ASIC accelerated NAT для GRE, насколько я знаю, поско... большой текст свёрнут, показать
     
  • 4.85, zanswer (?), 12:25, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    GRE без IPSec бесполезен, если же вы про PPTP GRE вариант, то он не актуален совершенно уже.
     
  • 4.91, zanswer (?), 13:37, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, насчёт UDP, есть вот такой draft, GRE-in-UDP: https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-19

    Но я бы всё равно GRE без IPSec использовать в рамках сети Internet в жизни бы не стал.

     
     
  • 5.133, Аноним (-), 00:20, 03/01/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Но я бы всё равно GRE без IPSec использовать в рамках сети
    > Internet в жизни бы не стал.

    Не в обиду, но все эти ваши ipsec и gre очень геморны в настройке, застревают на первом же фаере или нате, через прокси не жильцы в принципе и еще и безопасность достаточно хилая. В результате долботни много а толку мало. Вот народ и предпочел дружно сабжа. Он сделан для реального интернета и его неидеальностей. Так что это можно быстренько настроить и потом еще и работать будет. Без секаса с ипсеками и прочих gre.

     

  • 1.5, Аноним (-), 11:27, 28/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть хорошая статья по установке и настройке OpenVPN?
     
     
  • 2.7, Andrey Mitrofanov (?), 11:28, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +84 +/
    > Есть хорошая статья по установке и настройке OpenVPN?

    "Измена Родине" подойдёт?

     
     
  • 3.12, Аноним (-), 12:04, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    спасибо, поржал :) хотя на сегодня более актуальна ст. 280
     
     
  • 4.58, ZloySergant (ok), 17:54, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >спасибо, поржал :) хотя на сегодня более актуальна ст. 280

    282-я же, для опеннета, по крайней мере. После 130-й. :)

    P.S. Притянуто за уши, но и верхние - тоже не ангелы, а йумаристы. :)

     
  • 2.8, Аноним (-), 11:30, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Есть, а что?
     
  • 2.11, Аноним (-), 11:39, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    да и книги есть
    https://openvpn.net/index.php/open-source/books.html

    эта гуляет в нете ebook качества
    Beginning OpenVPN 2.0.9
    by Markus Feilner and Norbert Graf
    Publisher: Packt Publishing (December 2, 2009)

    а так вот неплохая статья
    http://bfy.tw/9A5u

     
  • 2.26, Аноним (-), 13:34, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    косвенно  https://bettercrypto.org/
     
  • 2.34, dep (?), 14:21, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    На Digitalocean все есть.

    https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-serv

     
  • 2.64, Аноним (-), 20:08, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нижняя палата РФ уже работает над этим. ))
     

  • 1.9, Аноним (-), 11:33, 28/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >Please note that OpenVPN 2.4 installers will not work on Windows XP.

    Плак-плак :(

     
     
  • 2.13, Аноним (-), 12:11, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    это диверсия !
     
     
  • 3.79, 404 not found (?), 04:24, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    с этим надо что-то делать
     

  • 1.14, VPN это сила (?), 12:32, 28/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    Я слышал, что есть какие-то системы, определяющие OpenVPN, вроде как провайдет может определить OpenVPN и порвать соединение. В том же Китае он не работает, и некоторые VPN-провайдеры предлагают проприетарные решения для обхода таких блокировок. Я слышал, что OpenVPN вроде-бы хочет предпринять что-то в этом направлении, чтобы была маскировка от таких "детекторов". Что известно об этом?
     
     
  • 2.16, Andrey Mitrofanov (?), 12:36, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Я слышал, что есть какие-то системы,
    >Я слышал, что OpenVPN вроде-бы хочет предпринять что-то в этом
    > направлении, чтобы была маскировка от таких "детекторов". Что известно об этом?

    https://duckduckgo.com/?q=openvpn+traffic+obfuscation

     
     
  • 3.17, VPN это сила (?), 12:40, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Спасибо, очень интересно.
     
  • 3.134, Аноним (-), 00:23, 03/01/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > https://duckduckgo.com/?q=openvpn+traffic+obfuscation

    Посадят тебя по твоей же статье. Хоть и за утку вместо спутника.

     
  • 2.62, sage (??), 19:29, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для этого как раз сделали опцию tls-crypt в новой версии.
     

  • 1.15, VPN это сила (?), 12:33, 28/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    > Добавлена возможность бесшовной смены IP-адреса и номера сетевого порта клиента без разрыва соединения VPN.

    Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть, или где-то еще?

     
     
  • 2.25, Меломан1 (?), 13:32, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не совсем понимаю в каких случаях это может пригодиться?
     
     
  • 3.35, Аноним (-), 14:23, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    GPRS
     
     
  • 4.37, Меломан1 (?), 14:51, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не актуально. Прокачиваться будет не более 33.6кбит/c. даже заголовки сообщений будут с трудом просачиваться на таком соединении.
     
     
  • 5.43, Клыкастый (ok), 15:51, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Прокачиваться будет не более 33.6кбит/c

    на IRC хватит

     
  • 3.47, Аноним (-), 16:29, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Например, чтобы не палиться перед ISP, постоянно переподключая VPN-соединение для смены IP.
     
  • 3.106, Аноним (-), 02:58, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Multi-Wan вариации(всех типов) и Multipath-TCP использование.
    в Ad-Hoc/Mesh сетях тоже обычное дело(а там и оборонные и помышленные среди них есть а не только меш потато и вские гипербореи).
     
  • 3.115, zanswer CCNA RS (?), 08:52, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вот авторы RFC4555 Mobility and Multihoming Protocol MOBIKE , дают исчерпывающи... большой текст свёрнут, показать
     
  • 3.135, Аноним (-), 00:30, 03/01/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не совсем понимаю в каких случаях это может пригодиться?

    В любых когда соединение нестабильное. Например беспроводка. Не круто, понимаешь, если все дружно отлипает только на том основании что реконект случился.

     
  • 2.29, cmp (ok), 13:38, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть,
    > или где-то еще?

    Чет не очень понимаю зачем, давеча поставил фалег лится на ноут с хранилища, смотрю скорость бе, воткнул провод, 1 строкой в shell перевесил ip на ethernet и ни ssh не порвалось, ни закачка.

    Хотя чисто из академического интереса можно запихивать vpn-интерфейсы в мост с stp, но  при сходимость кольца все равно потеряет данные, IP всегда теряет данные, он байдизайн ширину канала по потерям расчитывает, так-то.

     
     
  • 3.31, Меломан1 (?), 14:03, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ни хера не понял в твоих манипуляциях. Подробности, пожалуйста.
     
     
  • 4.36, Аноним (-), 14:48, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Это явно юный админ локалхоста говорит фразы продолжения которых не знает.
     
  • 4.77, cmp (ok), 03:30, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    brctl addif br0 tun0

    че непонятного

     
  • 3.42, Аноним (-), 15:18, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Добавлена возможность бесшовной смены IP-адреса и номера сетевого порта клиента без разрыва соединения VPN.
    > перевесил ip на ethernet и ни ssh не порвалось, ни закачка.

    В новости говорится что можно сменить IP или/и порт и соединение не прервётся.
    Я правильно понял что ты не менял ни IP ни порт и говоришь "У меня и так работает"?

     
     
  • 4.44, Клыкастый (ok), 15:53, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Я правильно понял что ты не менял ни IP ни порт и говоришь "У меня и так работает"?

    ты всё правильно понял, а гражданин суммирует часы и устриц.

     
     
  • 5.78, cmp (ok), 04:18, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > ты всё правильно понял, а гражданин суммирует часы и устриц.

    Устрицы в голове у тебя. ядро шлет пакеты на хост до которого нет маршрута, между удалением ip с одного интерфейса и навешиванием на другой, и должно бы возвращать - но_роут_ту_хост, но не возвращает же, покрайней мере сразу, значит переустановить соединение-туннель есть время, а уж ip и порт нового значения не имеют, при правильно отстроенных буфферах и таймаутах соединения в туннеле даже не поймут, что что-то произошло.

     
  • 3.88, zanswer (?), 13:05, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    IP рассчитывает ширину канала по потерям? Можете подробнее изложить свою мысль, что вы имеете ввиду?

    Для каких целей IP протоколу, который является stetaless протоколом, потребовалось рассчитывать ширину канала, да ещё и по потерям. Может быть вы имели ввиду TCP?

     
     
  • 4.97, cmp (ok), 16:10, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >  Может быть вы имели ввиду TCP?

    Определенно, но хотел включить UDP в множество, хотя зря, так как особенности реализации отдельного кое-чего на udp к делу отношения не имеют.

     
  • 3.89, zanswer (?), 13:10, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Речь я так понимаю идёт о том, что OpenVPN теперь может динамически в рамках одной сессии, менять tunnel source, что в прошлом приводило к разрыву сессии.

    Вы же я так понимаю tunnel source не меняли, а изменили только его положение (перенесли на другой интерфейс). Поэтому да, tunnel destiantion не заметил подмены, как вы сами правильно заметили при правильных размерах буфера и dead interval, сессия не будет потеряна.

     
     
  • 4.99, cmp (ok), 16:17, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >  сессия не будет потеряна.

    А какая ценность у этой сессии? я хотел обратить внимание на то, что при ее разрыве и скорой установки новой, соединения внутри туннеля при надлежащих параметрах не разорвуться.

     
     
  • 5.100, J.L. (?), 16:50, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>  сессия не будет потеряна.
    > А какая ценность у этой сессии? я хотел обратить внимание на то,
    > что при ее разрыве и скорой установки новой, соединения внутри туннеля
    > при надлежащих параметрах не разорвуться.

    а какие надлежащие параметры и требуют ли они установки с обоих сторон соединения внутри туннеля - и на клиенте (подконтрольном) и на сервере (неподконтрольном)
    (частенько рвётся впн и приходится клиентскую подтуннельную программу переподключать)
    и стоит ли мне задуматься над схемой "виртуальноеEth -> впнEth1+впнEth2(на разные сервера целевой подсети) -> целевой_сервер" ? (и как такое вообще делать?)

     
     
  • 6.104, cmp (ok), 00:38, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Как любил говорить один не_товарищь - открытия требую экспериментов.

    > виртуальноеEth -> впнEth1+впнEth2(на разные сервера целевой подсети) -> целевой_сервер

    Вообще не понял ничего, не благодарное дело гадать, но в большенстве случаев на сервера ходят или за сервисами или для управления, сервисы лучше предоставлять через единую точку входа, где их можно будет прикрыть фаерволом ежели чего, управления на серверах, вроде и так не плохо защищено, смысла его туннелировать нет, это я о ssh говорю, как там оно в виндах и макосях беспонятия.

     
     
  • 7.109, zanswer CCNA RS (?), 06:27, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    macOS не чем принципиально от любого другого Unix в этом отличаться не будет, такой же SSH и TLS.

    Windows, по крайней мере в свежих реинкарнациях охотно использует TLS (WS-Management Protocol), возможно и SSH можно использовать, поинтересуюсь у коллег.

     
  • 5.101, zanswer (?), 17:29, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    У меня конечно же нет ответа, который устроит всех, но давайте представим следую... большой текст свёрнут, показать
     
     
  • 6.105, cmp (ok), 01:19, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Это какбы его работа, которая выполняется ровно на столько, на сколько выделятся... большой текст свёрнут, показать
     
     
  • 7.107, zanswer CCNA RS (?), 05:42, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    MPLS L2 VPN через всю страну, это очень дорогое удовольствие в каждый филиал, ег... большой текст свёрнут, показать
     
     
  • 8.110, cmp (ok), 07:11, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен, но в большенстве случаев перед ИТ клиентов л2впн стоят другие задачи, ... большой текст свёрнут, показать
     
     
  • 9.111, zanswer CCNA RS (?), 07:31, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вы всё время замыкаетесь на L2 VPN, к тому же операторский, что не всегда возмож... большой текст свёрнут, показать
     
     
  • 10.116, cmp (ok), 09:38, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    OpenVPN TUN этот который p2p , путаю их все время с TAP, если да, то почему не с... большой текст свёрнут, показать
     
     
  • 11.119, zanswer CCNA RS (?), 10:30, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Выбор типа VPN, L2 L3 лежит в плоскости требований вашей сети, обычно L2 VPN исп... большой текст свёрнут, показать
     
     
  • 12.125, cmp (ok), 13:06, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если у вас так, то я за вас рад А у нас все сильно по-другому, и у остальных то... текст свёрнут, показать
     
  • 11.122, zanswer (?), 11:09, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что касается GRE, то у него компактный заголовок, он без каких либо проблем позв... текст свёрнут, показать
     
     
  • 12.123, zanswer CCNA RS (?), 11:23, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Странно, при размещении сообщения куда-то OpenVPN потерялся Я имел ввиду, что O... текст свёрнут, показать
     
  • 7.108, zanswer (?), 06:19, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Поясню насчёт кейсов, что я имел ввиду Первый кейс, классическая топология Hub-... большой текст свёрнут, показать
     
     
  • 8.112, cmp (ok), 07:55, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    не такие уж и разные, о безопасности вообще спорно, нормальные безопасники сами ... текст свёрнут, показать
     
     
  • 9.113, zanswer CCNA RS (?), 08:04, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Под требованиями безопасности я понимаю, не только обеспечение конфиденциальност... большой текст свёрнут, показать
     
  • 9.114, zanswer CCNA RS (?), 08:07, 30/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В общем и целом, проблема защиты от утечек конфиденциальной информации или атак ... текст свёрнут, показать
     
  • 2.59, бугага (?), 18:10, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть, или где-то еще?

    ipsec mobike https://tools.ietf.org/html/rfc4555

     

  • 1.18, Аноним (-), 12:54, 28/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Жаль что многопоточность так и не завезли.
     
     
  • 2.30, cmp (ok), 13:46, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Жаль что многопоточность так и не завезли.

    А на кой, если надо из in-буффера скопировать в out-buffer, у вас копирование файлов тоже многопоточное? дефрагментировать не надоело?

     
     
  • 3.32, Аноним (-), 14:04, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > дефрагментировать не надоело

    что делают виндопользователи на опеннете?

     
     
  • 4.40, Аноним (-), 15:11, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> дефрагментировать не надоело
    > что делают виндопользователи на опеннете?

    Ламерить не надоело?

     
  • 4.76, cmp (ok), 03:28, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    ext3? С разморозкой!
     

  • 1.27, Ilya Indigo (ok), 13:37, 28/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Не ed25519, не chacha20-poly1305.
    Как-то не очень секьюрно.
     
     
  • 2.136, Аноним (-), 14:45, 03/01/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не ed25519, не chacha20-poly1305.

    Ну тогда во: https://www.phoronix.com/scan.php?page=news_item&px=WireGuard-2016

    > Как-то не очень секьюрно.

    Это OpenSSL, детка. Секурно его настроить не сможет даже вон тот CCNA, судя по его постам. Туда же и ipsec'ов всяких.

     

  • 1.33, arrnorets (ok), 14:07, 28/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Многопоточности все еще не хватает :(


     
  • 1.38, Аноним (-), 15:04, 28/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >В том числе обеспечена возможность запуска OpenVPN GUI в Windows без наличия привилегий администратора.

    маршруты как будут добавляться? У них и раньше можно было запускать, только без маршрутов оказываешься после этого

     
     
  • 2.61, K.O. (?), 18:32, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно они допилили OpenVPN Service под виндой. Теперь OpenVPN GUI просто просит этот сервис запускать OpenVPN, а сервис работает с правами админа, а OpenVPN статусы читаются через management interface.
    Ваш K.O.
     
  • 2.68, Led (ok), 22:28, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У них и раньше можно было запускать, только без маршрутов оказываешься после этого

    Вендузятники должны страдать.

     

  • 1.39, анан (?), 15:09, 28/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Многопоточности все еще не хватает :(
     
  • 1.46, h31 (ok), 16:26, 28/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Добавлена возможность бесшовной смены IP-адреса
    > Реализована возможность использования режима блочного шифрования AEAD GCM
    > Добавлена поддержка протокола согласования ключей на основе эллиптических кривых ECDH

    Уже сто лет как есть в IPsec. Приятно, что OpenVPN догоняет.

     
     
  • 2.52, Аноним (-), 17:19, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Скажите честно вы ipsec вообще использовали ?
     
     
  • 3.69, Ктулху (?), 23:19, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Я использую уже несколько лет (Linux—[Linux|Android], если важно). Прекрасно работает. А что, должны быть какие-то сложности?
     
     
  • 4.82, Аноним (-), 11:15, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Админов локалхоста просят проходить мимо.
     
  • 3.73, h31 (ok), 00:01, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Да, постоянно пользуюсь. Настроил pcrypt (многопоточное шифрование) - вообще красота.
     
     
  • 4.83, Аноним (-), 11:16, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Авторизация конечно же psk ?
     
  • 2.71, obl (ok), 23:43, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Добавлена возможность бесшовной смены IP-адреса
    >> Реализована возможность использования режима блочного шифрования AEAD GCM
    >> Добавлена поддержка протокола согласования ключей на основе эллиптических кривых ECDH
    > Уже сто лет как есть в IPsec. Приятно, что OpenVPN догоняет.

    Тут и можно поспорить кто догоняет. Ipsec если бы был прост в настройке так же как опенвпн.. Но увы.

     
     
  • 3.84, Аноним (-), 11:18, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А уж как прекрасно у ipsec c межвендорной совместимостью, это просто праздник какой-то.
     
  • 3.103, zanswer (?), 18:42, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Всё относительно, Cisco EasyVPN Server (IPsec) + Cisco AnyConnect Client (IPsec), будет не сложнее OpenVPN, по крайней мере на клиентах, настройка сервера, тут повод сравнивать детально уже.
     
  • 2.90, zanswer (?), 13:28, 29/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Разве IPSec поддерживает динамические изменение IP адреса? IKE при этом сохранит имеющиеся SA? Можете дать ссылку на RFC, где описан данный механизм?
     
  • 2.137, Аноним (-), 14:58, 03/01/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Уже сто лет как есть в IPsec. Приятно, что OpenVPN догоняет.

    Догоняет что? Нормальная кривая это 25519. А нистовские кривые возможно с бэкдорами. И если вы поюзаете nist-овский ECDH завтра над вашей перепиской будет плакать все АНБ.

    А ipsec не надо догонять. Это встревает на ближайшем NAT. А сабж даже через прокси можно запустить, если это за каким-то надо.

     

  • 1.67, Аноним (-), 22:13, 28/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Интересно, а почему это --no-iv объявлена устаревшей?
     
     
  • 2.132, Аноним (-), 09:12, 02/01/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Интересно, а почему это --no-iv объявлена устаревшей?

    ну и за что минус? по существу вопроса сказать нечего?

     

  • 1.126, ALex_hha (ok), 00:18, 31/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А подскажет кто, можно ли настроить openvpn так, чтобы в зависимости от имени пользователя добавлять определенные правила iptables?

    Собственно, за openvpn есть 20 подсетей. Я выдаю пользователю роуты в нужные, через client config dir. Но нужно еще закрыть возможность самому явно прописать маршрут в подсеть, в которую у него не должно быть доступа. Или можно как то проще сделать?

     
     
  • 2.128, Аноним (-), 10:58, 01/01/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > можно ли настроить openvpn так, чтобы в зависимости от имени пользователя добавлять определенные правила iptables?

    можно

     
  • 2.138, анон (?), 09:50, 09/01/2017 [^] [^^] [^^^] [ответить]  
  • +/
    через ccd выдаешь фиксированный ip, и ограничиваешь ему доступ фаерволом
     

  • 1.129, demfloro (ok), 11:33, 01/01/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Реализована возможность использования режима блочного шифрования AEAD GCM, при котором шифруется лишь важная часть данных (остаются открыты IP-адреса, номера протоколов и прочие метаданные)

    Я не могу найти подтверждения в источнике о том, что эти метаданные остаются открытыми. Везде указано что благодаря AEAD не нужен отдельный хеш и поэтому оверхед меньше. Откуда информация?

     
  • 1.130, ALex_hha (ok), 23:36, 01/01/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > можно

    В какую сторону смотреть?

     
     
  • 2.131, Аноним (-), 09:10, 02/01/2017 [^] [^^] [^^^] [ответить]  
  • +/
    client-connect/client-disconnect/learn-address, $common_name например.
     

  • 1.139, Аноним (-), 19:46, 21/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Заявленный пакет для CentOS кто-нибудь видел?
     
  • 1.140, Аноним (-), 12:34, 15/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Доброго дня, Бояре:) Кто может просветить, каким оброзом опция tls-crypt в 2.4 поможет справиться с DPI ? Проверял может кто иль курил мануалы иноземные?
    Спасибо.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру