Le ecureuil
-
Постов
11 544 -
Зарегистрирован
-
Посещение
-
Победитель дней
678
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Le ecureuil
-
В usr лежит неправильный ip6tables, нужный вам лежит в /opt/usr.
-
Укажите полный путь к правильному ip6tables и настройте PATH.
-
Делайте VLAN поверх GE1, а не GE1/0. И все будет хорошо. -
Еще не забудьте, что у вас подсеть назначения - /20, а не /24, как у вас.
-
DNS-у вообще все равно на ACL, а вот транзитный трафик весь уйдет вникуда.
-
Один раз после загрузки такое может произойти, если во время TLS-хэндшейка произошла синхронизация часов на Keenetic. Однако потом должно работать нормально.
-
Настраивать нужно так: - разрешаем исходящий https на 109.207.0.0/20 - разрешаем исходящий http на 109.207.0.0/20 - запрещаем все остальное
-
Поставьте все последние обновления на Windows и все будет хорошо.
-
L3. Полный аналог PPTP с точки зрения энкапсуляции.
-
Померяйте, похвалитесь нам)
-
В теории может и норм, но на практике я бы посмотрел на такое. Имхо пинг и джиттер сделают такой канал невменяемым.
-
Я же говорю, что там даже без шифрования ускорение максимум до 70 - 100 Мбит/с. С шифрованием обязательно добавляйте overhead на копирование в ядро / обратно, причем пакетики у openvpn мелкие и эффективность тоже будет низкая. В итоге получаем выйгрыш процентов в 20-30, проделав большую работу. Смысл на текущих процессорах виден слабо. Для нормального результата с криптоускорителем нужны пакеты в 1400 (а желательно вообще в 10К - вот там можно и 800 Мбит достичь в теории). А OpenVPN сильно дробит пакеты на блоки перед шифрованием. Скорее добавим поддержку OpenSSL 1.1 с Chacha20/Poly1305, она программно очень неплохо работает.
-
Попытаюсь настроить, может дам какие советы по тюнингу, чтобы хоть еле-еле, но устойчиво работало.
-
Маршрутизация - только через туннели, чистый ipsec построен на принципе политик, и совсем не поддерживает маршрутизацию.
-
В 23-44 strongswan обнаруживает, что пора бы инициировать rekey самому, но так как настроен этого не делать, то тупо удаляет устаревшие SA и отправляет об этом отчет другой стороне без инициирования rekey (а новые SA уже есть от rekey в 23-32, потому это происходит безболезненно). Весь rekey и вся реаутентификация управляются полностью пожеланиями инициатора.
-
Пробуйте, сообщайте о наблюдениях.
-
Для ccd на устройствах с storage-разделом можете попробовать использовать его. Он располагается по адресу /storage Использование USB-drive неразумно, поскольку порядок поднятия интерфейсов и монтирования дисков не связан, и у вас будут рандомные глюки.
-
Серверная сторона настроена так, чтобы не инициировать rekey сама, но отвечает на него.
-
Какой именно счетчик? Счетчик CHILD_SA в {X}? Так он и не должен.
-
Понятие "сервер" и "клиент" в IPsec немного неверное, обе стороны вообще говоря равноправны. Скорее их нужно называть "инициатор" и "ответчик". Именно поэтому в IKEv1 мы не можем сказать, к какому именно соединению пришел ответный IKE-пакет, и это определяется перебором с небольшой эвристикой, которая не всегда правильно (и не всегда может из-за недостатка информации) срабатывает.
-
Попробуйте поиграться с tx-burst на WifiMaster0 и WifiMaster1, потому что показометр от спидтеста очень своеобразен и не всегда показывает истину:
-
Потолок на 7628 - 70 Мбит/с (это когда шифрование и хэш равны NULL, openvpn только переклеиванием заголовков занимается). Не сильно-то и разгуляешься. На 7621 наверное в такой синтетике можно выжать 100 Мбит/с. В таких условиях блок шифрования применять смысла нет, потому что ускорение с условных 30 до условных 40 Мбит/с (а выше 70 не прыгнешь даже в теории - см. выше + overhead на копирование в ядро/обратно) - очень жидко для столь большого объема работы. Потому все полностью программно. Если нужна максимальная скорость с шифрованием - тогда нужно выбирать BF-CBC/MD5 или AES-GCM - по тестам они самые лучшие.
-
>> crypto map VPNL2TPIPsecServer no l2tp-server nat
-
Такой вариант пока никак, без вариантов.
