arni

Все еще допиливаем, uspe-client переписываем на python для лучшей интеграции с разными биллингами/API !

Да, допиливаем новую версию и потому пока что билды делаем по запросу от клиентов. Новая документация будет уже на новом сайте, запустим вместе со следующей версией софта!

Примеров добавим, но со следующих версий - там как раз много изменений будет по CLI и фичам.

Пока что мы делаем багфиксы, 17.2 будет со следующей порцией исправлений. У нас много изменений для следующего мажорного релиза с кластеризацией и нового cli, поэтому промежуточные версии сейчас не готовим.

Здравствуйте! 1) Перехват зашифрованного трафика пока не планируется. Маски поддерживаются, редирект через tproxy на ваш squid или что-то подобное. Если все пойдет через squid то и все списки там все равно удобнее держать. 2) Предел всегда очень зависит от конфигурации файрвола, и пока скриптов и железа хватает - не думаю, что от миграции будет выигрыш. Разве что в плане удобства :) 3) да, но без SLA и в порядке приоритетов 4) логов соединений нет, но тот же netflow можете собирать теми же средствами

Здравствуйте! 1. да, ограничений нет 2. к сожалению, пока нет 3. Достаточно, если контактный е-майл будет с домена компании и это не почтовый хостинг :) Наверняка у вас требования не только в NAT 1:1, так что дайте знать если будут какие-либо вопросы, постараюсь помочь!

Да, конечно! Новые версии пока не выпускаем, так как нужно обновить все API сразу и на пол пути релиза не выйдет :/ Для уточнения - трафик общий 6 Гиг или 6Гиг в каждую сторону (т.е. 12 в сумме)? Во втором случае топовый I7 будет очень близок к своим возможностям, и лучше такой трафик вместе с NATом все же разделить на два сервера. Дольше хватит, да и надежнее (всегда можно без перебоев их обновить/заменить). Как ни странно, но shared кэш I7 работает эффективнее, чем большее количество ядер и per-core кэш в E5. Да и цена на E5 сильно грустнее.

Выпущена alpha1 версии 16.8. В CG-NAT сделано много изменений : Улучшена система блокировок Поддержка нескольких Nat-пулов для каждой сессии (раньше поддерживался только один) Возможность блэклистинга публичных портов (не выдаются клиентам) Публичные порты 0-1024 не используются в NAT Поддержка дополнительных слотов для сессии Ключи от 16.2 будут совместимы и с 16.8, заменять лицензии не нужно! Качать тут : http://www.uplink-spe.com/downloads/alpha_builds/uplink-spe_16.8alpha1_centos7-3.10.0-327.22.2.el7.x86_64.tar.gz Поскольку в Ubuntu ядро 4.4 пока еще не стабильно, работаем пока что с Centos. Настройка NAT такая же как и в 16.2 - так что старая документация актуальна и для 16.8. Настройка блэклистинга и дополнительных слотов будет в следующей альфе, тогда же и подготовим отдельную документацию для новой версии.

Если подходить к этой задаче, как к DPI, то наш софт не особо подходит : наш DPI - state-less, соответственно разделять потоки не умеет. для правильной приоритезации нужны именно потоки, как в conntrack например. Так что для ваших требований нужны скорее iptables+conntrack+l7-filter или SCE

Да, новые версии считаем по мажорной версии. По суппорту - 1295 евро в год. В Белоруссии пока у нас партнеров нет, но скидки те же, что и для России.

Пока не планировали. А какая именно приоритезация нужна? В пределах сессии или глобально? Мы сейчас обрабатываем пакет сразу как он приходит - пропускаем его или дропаем. Если не надо добавлять пакеты в очередь, то принять решение пропустить пакет или дропнуть на основе приоритета вполне можно. Вопрос только как лучше написать такой функционал и как сделать, чтобы было удобно с ним работать ;)

Тогда все проще :) делаете проверку ACL и разрешайте пакет до того, как будет SNAT. В обратную сторону нат не будет применятся, так как DST адрес будет внутренним и все будет бегать как надо ;)

Про DHCP вот тут : http://www.uplink-spe.com/docs/16.2/#dhcp Дело в том, что DHCP у нас пока только на QinQ/.1Q интерфейсах работает, поэтому немного запрятано :) А для того, чтобы исключить серый IP из SNAT - лучше всего разбить сеть на префиксы и добавлять только те, в которых все адреса нужно натить. Как вариант, можно сделать ACL и фильтровать в каждом профиле, но так по-моему криво :)

Выпустили обновление - 16.2.1 Изменения : исправлен баг с отображением каунтера записей в map-ах полисеры и профили теперь создаются динамически (теперь можно создавать до 64K профилей и полисеров без нужды устанавливать max_profiles при заргрузке) собрали под более свежее ядро Критичных исправлений нет, так что обновление не обязательное. Качать тут : http://www.uplink-spe.com/downloads/uplink-spe_16.2.1_ubuntu1604-4.4.0-16-generic.tar.gz

1. У сессии может быть только один профиль и один полисер. Поэтому - да, скорость можно задать только в заранее созданном полисере. К сожалению пока поддерживаются только глобальные профили и полисеры, создавать на основе данных радиуса - очень затратно по ресурсам и будет сильно бить по производительности (по нашим тестам падение где-то на уровне 40%). Поэтому пока не развиваем такой функционал. 2. Раздельного аккаунтинга на данный момент нет, но статистика собирается в каждой сессии по каждому action-у в профиле и полисере. Изменений не много, так что в одно из следующих обновлений добавим