Развернутое тестирование помогло, не без боли, выявить ряд проблем в генерируемых политиках и спрятанных ошибках. Актуальная версия 0.9.4.
Добавил генерацию маскардинга.
!!! Если вы используете рекурсивные проверки маршрутов, к примеру для dualwan, то обязательно разрешите пинги от руотера в интернет. Без этого у вас интернет быстро пропадет.
Вот я не смог прийти к однозначному мнению на это счёт.
Скрипт может быть адаптирован под IPv6, да и не у всех на IPv4 должен быть NAT (хотя сколько таких осталось)?
И если уж добавлять то, что не связано с фильтрацией (уже есть немного), то что ещё добавить?
И конечно объем тестирования скрипта пока довольно мал, будьте внимательны при использовании ;)
Да, маскардинг данным скриптом не создается совсем.
Когда я об этом думал, я так и не решил, стоит ли его делать, потому и не сделал.
Если можете хорошо обосновать, нужно ли это делать, то я добавлю в скрипт, благо это не сложно.
А тут вопрос. Скрипт делает каркас, в любое место которого можно вставить свою цепочку или правило. Если все дропать как вы предлагаете, то это не решит ничего кроме добавления большого числа правил, которые по сути не нужны и создаст лишню работу при кастомизации.
Обработка правил идет до тех пор, пока пакет не терминируется на любом правиле типа ACCEPT, REJECT, DROP. И если в вашем фильтре нет терминирующего корневого правила, к примеру в цепочке forwad (для транзитного трафика), то действие для него будет accept. Для любой не корневой цепочки, если в ней нет больше правил для обработки, и пакет не подошел, срабатывает действие return, и обработка продолжается со следующего правила от jump.
На скрине пояснение для forward:
17 — прыгаем в дебри фильтрации, если пакет там не «застрял», то он всплывет и попадет на 19 — ое правило.
Я не пробовал, но вроде решения на nvidia grid это могут. Вот только как то оно подозрительно дешёвого выходит, одна видюха как б/у сервер прошлого поколения, а Софт как два таких сервера… Поэтому сижу на теплой ламповой оффлайн ручной миграции…
Прекрасно работает ускорение с применением карточки на подобие quadro k620. При этом ускорение в RDHS начинает работать с 2012 сервера, а 2008r2 его не умеет (только для дочерних виртуалок). Вместо quadro неплохо работали и другие карточки с поддержкой аппаратного ускорения h264. И в такой комбинации 2008r2 уже фаворитом не будет. В «серверах» из десктопов, без видюхи я выжимал те-же 8-10 сессий на 2008r2 относительно комфортных, с переходом на 2016 и добавлением видяхи с ОЗУ (тут они конечно кушают больше), смог получить комфортных до 15 сессий, при этом видео крутилось очень мягко.
У меня рецепт чуть другой, но вполне эффективен. Порт 5060 (и любой без шифрования SIP) открыт только с ip провайдеров. Это спасает от совсем тупой долбежки, но и создаёт трудности тоже. Не шифрованный SIP разрешён только во внутренней сети (соответственно за VPN тоже). Для тех, кому не нужен VPN, а VOIP нужен, те работают только через SIP TLS, который прикрыт fail2ban. В таком режиме активность на брут учеток практически нет (жалкие два адреса за месяц).
Тут прикол в том, что все узлы указаны по IP, но кто-то все равно делает lookup на все (даже IP).
Решением в моем случае может быть такое: настроить локальный DNS кэш (dnsmasq или unbound), тогда отвал любого из DNS не будет заметен в принципе. Особеность установки FreePBX из коробки в том, что его надо прикручивать дополнительно.
Тут habr.com/post/331544 есть скрипт который учитывает состояние гонки при работе DHCP cllient, да еще его можно использовать и без DHCP для формирования маршрутов.
По сути, там нечего писать. Порты объединяются мостом. Если чип поддерживает аппаратную разгрузку, то интерфейсы получать статус H. Если делать несколько мостов, а группа коммутации только одна, то тот, что с большим числом интерфейсов становится "мастером" с аппаратной разгрузкой, остальные софтовые.
Добавил генерацию маскардинга.
!!! Если вы используете рекурсивные проверки маршрутов, к примеру для dualwan, то обязательно разрешите пинги от руотера в интернет. Без этого у вас интернет быстро пропадет.
Скрипт может быть адаптирован под IPv6, да и не у всех на IPv4 должен быть NAT (хотя сколько таких осталось)?
И если уж добавлять то, что не связано с фильтрацией (уже есть немного), то что ещё добавить?
И конечно объем тестирования скрипта пока довольно мал, будьте внимательны при использовании ;)
Когда я об этом думал, я так и не решил, стоит ли его делать, потому и не сделал.
Если можете хорошо обосновать, нужно ли это делать, то я добавлю в скрипт, благо это не сложно.
На скрине пояснение для forward:
17 — прыгаем в дебри фильтрации, если пакет там не «застрял», то он всплывет и попадет на 19 — ое правило.
Предложите вариант конфигурации, я её сгенерирую, ниже для текущей конфигурации.
Я не пробовал, но вроде решения на nvidia grid это могут. Вот только как то оно подозрительно дешёвого выходит, одна видюха как б/у сервер прошлого поколения, а Софт как два таких сервера… Поэтому сижу на теплой ламповой оффлайн ручной миграции…
Чистый, или про проброс видяхи в виртуалку. Тут главное чтобы винда её увидила вместе с дровами.
Решением в моем случае может быть такое: настроить локальный DNS кэш (dnsmasq или unbound), тогда отвал любого из DNS не будет заметен в принципе. Особеность установки FreePBX из коробки в том, что его надо прикручивать дополнительно.
Тогда фразу в статье стоит изменить. А то создалось впичатление, что вы не знали про ThinProvision, а вопрос был в поддержке кластеризации.
По сути, там нечего писать. Порты объединяются мостом. Если чип поддерживает аппаратную разгрузку, то интерфейсы получать статус H. Если делать несколько мостов, а группа коммутации только одна, то тот, что с большим числом интерфейсов становится "мастером" с аппаратной разгрузкой, остальные софтовые.