openvpn и AES-256-GCM

Та же проблема. Есть решение?

Это удивительно, у Mikrotik крайне медленное развитие, через пару лет он исчезнет с рынка. Есть ли какое-то надежное решение для VPN с клиентами Windows?

Итак, что вы предлагаете для реализации надёжной и простой VPN-системы для пользователей Windows?

С L2tp/Ipsec у меня проблема: когда два человека с одного и того же IP пытаются подключиться, одного из них через какое-то время выбрасывает. Я почитаю об этом. Спасибо.

AES 256-CBC шифр считается недостаточно надёжным? При использовании L2TP/IPsec у меня возникает проблема: когда два человека пытаются подключиться с одного IP, одного из них через некоторое время выбрасывает. @sindy объяснил, почему так происходит… Вот ссылка на разъяснение: http://forum.mikrotik.com/t/multiple-road-warrior-l2tp-ipsec-clients-behind-nat-solved/118206/1. Однако, судя по всему, это уже исправлено… *) l2tp — исправлено создание нескольких туннелей с одного удалённого IP (введено в версии v6.47); https://mikrotik.com/download/changelogs. Так что, какая у тебя версия ROS?

Это так, но всё равно работает…

Для тех, кто хочет получить действительно техническую информацию по этой проблеме, эта статья хорошо объясняет вопрос с AES-CBC. «Если уж совсем нет выбора и нужно использовать CBC, то всё ещё можно обеспечить безопасность, вычисляя код аутентификации сообщения (MAC) на основе шифротекста и IV — это можно сделать с помощью популярного алгоритма HMAC.» Чистый OpenVPN-сервер умеет добавлять дополнительный уровень защиты с помощью HMAC через опцию конфигурации tls-auth. Большинство других реализаций OpenVPN тоже это поддерживают. К сожалению, когда Mikrotik якобы написал свою собственную реализацию OpenVPN, они не реализовали множество функций (PUSH options — один из самых заметных пробелов). tls-auth — ещё одна из таких функций, и из-за этого, как описано в статье выше, VPN-туннель, зашифрованный AES-CBC без защиты HMAC, уязвим для атак. Думаю, OpenVPN правильно отказался от AES-CBC, ведь большинство используют то, что проще, а не то, что правильнее, по разным причинам. Будет интересно посмотреть, добавит ли Mikrotik альтернативные шифры, например AES-GCM, в свою реализацию OpenVPN в ближайшее время, и исправит ли другие баги OpenVPN (например, чтобы при ошибке аутентификации сервер возвращал событие AUTH_FAILED, а не NETWORK_EOF_ERROR, чтобы клиент понимал, что данные учётки неверны…).

Нет. Нужно добавить поддержку AES-256-GCM, AES-128-GCM и CHACHA20-POLY1305, совместимых со стандартной реализацией OpenVPN. Для меня это большая проблема.