я тут пытался задавать тупые вопросы, в других ветках
потому что мне нужно реализовать довльно сложную схему "заворота" трафика на основе dfl-800, но у меня не хватает знаний, и даже если я получаю ответы, то через пол шага затык
я тут смотрю не я один такой
с английским у меня плохо, инструкцию читаю, но сложно это все идет у меня
поэтому я решил - конкретно, потихонечку разобраться, поделившись своим пониманием принципов действия и приложением их к своим задачам, чтоб меня поправили если что, и задавать уже вопросы более грамотно
надесь что тему не удалят, я буду потихоньку добавлять

итак, ключевое слово в начале главы Static Routing это NetDefendOS
это я так понимаю это операционка которая стоит на маршрутизаторе
написано что она поддерживает альтернативные таблицы, но об этом потом

механизм маршрутизации NetDefendOS отличается от от того что используется в большинстве роутеров, где каждый пакет направляется без контекста, другими словами forwarding is stateless (вот тут я не понял), и таблица маршрутизации сканируется для каждого пакета принятого на роутер

в NetDefendOS пакеты forwarded with state-awareness,
вот эти два термина:
forwarding is stateless
forwarded with state-awareness
я бы хотел чтоб мне пояснили

в NetDefendOS когда IP пакет принимается на любой интерфейс, в первую очередь просматривается таблица соединений (status-connections), есть ли уже открытое соединение, к которому пакет принадлежит, если такое соединение есть, то просматривать таблицумаршрутизации смысла нет, это гораздо более эффективно, чем традиционный просмотр таблицы маршрутизации и одна из причин быстрой работы NetDefendOS

если соединение не найдено, то просматривается таблица маршрутизации (status-routes), важно понять что таким образом поиск маршрута будет выполнен прежде, чем сработают различные rules
как результат - интерфейс назначения известен уже в то время, когда NetDefendOS решает пропустить этот пакет или нет

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

как я понял механизм выбора таблицы работает так:

1 перед тем как сработают PBR, интерфейс назначения для входящего пакета должен быть определен в основной таблице - main table

2 ищется routing rule у которого - source/destination interface/network as well as service такие-же как у входящего пакета, если PBR Rule не найдено, то используется main table

3 когда корректная таблица найдена, срабатывают Access Rules, проверяется разрешение доступа между IP источника и интерфейсом назначения, если такого правила не найдено, то в лог идет Default access rule log error message

4 на этом шаге используется выбранная routing table, выбирается маршрут в соответсти с выбранным методом - ordering (об этом ниже)

To implement virtual systems, the Only ordering option should be used. - этой фразы ваще не понял даже с переводчиком, имеются ввиду какие-то автомтически создаваемые альт таблицы?

5 срабатывают IP rule, и еще написано что то про SAT, я так понял, нет не понял (что то про то что сначала сработает маршрут в таблице, потом SAT, но actual route будет выполнен для altered address. причем когда будет отработан маршрут, правило будет считаться выполненым - это типа для того, что бы все правила отрабатывали по реальному (нетранслированному) интерфейсу назначения - поправтье если напутал)

6 если правила допускают, то новое соединение устанавливается и NetDefendOS state table (ставит таблицу?) и направляет пакет по этому соединению

The Ordering parameter

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

Default - сначала выполняется поиск в main table, если подходящего маршрута нет, или найден маршрут default (с назначением all-nets), то выполняется маршрут в альтернативной таблице, если в альтернативаной таблице подходящего маршрута нет, то выполняется default в main table

First -сначала смотрится alternate table, потом main, маршрут default будет использован в альт таблице (если он там есть)

Only - маршрут ищется только в альтернативной таблице

первые два варианта позволяют сочетать главную и альт таблицы если нужный маршрут есть в обоих

дальше написано крупными БУКВАМИ - НИКОГДА НЕ УДАЛЯЙТЕ МАРШРУТ ALL-NETS ИЗ MAIN TABLE - будет конкретный dropped
типа все сервисы которых нет в routing rules - отпадут, я так понял

что то я не увидел описание параметров
return table
forward table

forward - таблица первоначального просмотра
return - таблица на которую осуществляется возврат после просмотра forward таблицы

_________________
2хDFL-210

теперь значит о своих задачах:
была у меня сеть с выходом в инет через биллинг (комп с 2-мя сетевухами - nat, www.lan2net.ru, куплено официально)

сейчас значит появился второй провайдер, и появился dfl-800
мне нужно подключить второго провайдера и оставить биллинг (в качестве шлюза в сети должен быть dfl-800, потому что есть еще задача управления vlan-ми)

я понимаю так:
1 локальный трафик приходит на интерфейс lan или vlan-1, при помощи PBR уходит на биллинг
2 с биллинга приходит на DMZ или vlan-2
3 c DMZ или vlan-2 идет во внешний мир через wan1, wan2

такое возможно?

и вообще сейчас у меня многие клиенты сидят на биллинге - эта задача может стать стандартной

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

если я поставлю шлюзом по умолчанию комп с биллингом (т.е. поставлю биллинг с натом между лок сетью и dfl-800) - это ограничит какой-либо функционал dfl? например управление vlan-ми лок сети?

в общем я что-то не могу сообразить как сделать красиво, биллинг в схему - лок сеть-dfl800-два провайдера, никак не укладывается

Самый "простой и красивый" вариант, настроить proxy сервер через который будет ходить весь трафик.

ну да, я примерно так и понял, в следующем проекте так и сделаю

Настроить так, чтоб просто указывать в приложениях работать через PROXY.