По нескольким пространствам стейтов - для генерализованного решения да, это полезно. Но задачи, их требующие, не столь часты, и даже в линуксе поддержка неймспейсов появилась очень недавно.
это проблемы линуха. почему это должно меня волновать? виртуальные файрволы в asa появились очень давно. не регулируемое поведение было вообще изначально, в pix. регулируемое появилось относительно недавно, но достаточно давно на самом деле, кажется даже раньше нэймспэйсов. и это с твоей колокольни они не часты -- это типичная задача в корпоративной среде. ну да, как ее можно увидеть не работая там? просто поверь мне.
И конкретно описанная задача лучше решается не несколькими пространствами, а security-обработчиком flow, который записывает интерфейсы на первых проходящих пакетах в регистры dynrule и сравнивает их далее на каждом проходящем
это криво. это будет плохо работать. особенно если у нас что-то типа {bge0,bge1,bge2}-{bge3,bge4,bge5}
Что касается одинаковых адресов в разных FIB - ну так для этого в ядре таки должны быть сконфигурены разные fib, например.
почему в ядре должны быть сконфигурированны сущности, по которым работает файрвол? разве для фильтрации транзитного tcp в ядре должны быть tcp сокеты? ну или stcp. файрволу не требуется поддержка ядра для этих действий. и я уже приводил пример -- файрвол может фильтровать трафик в транзитном GRE-туннеле, не терминируюя его на машине. точно так же можно фильтровать трафик в езернетовском транке, не терминируя и не заводя vlanы в ядре, просто поставив в режим бриджа и самостоятельно разбирая 802.1q заголовки. ну и с метками mpls та же история. зачем делать урезанную функциональность, если достаточно простыми и дешевыми средствами можно получить гораздо большую гибкость?
По переписке - ну, если большая часть уже изложена, это хорошо. Здесь ветки уж слишком разрослись, надо уточнить некоторые моменты здесь, а потом сухой остаток предварительного итога в новый пост вынести.
может я и не прав и мне не удалось многое до тебя до нести. но раз в неделю -- я уже непомню что сказал, что нет.
no subject
это проблемы линуха. почему это должно меня волновать? виртуальные файрволы в asa появились очень давно. не регулируемое поведение было вообще изначально, в pix. регулируемое появилось относительно недавно, но достаточно давно на самом деле, кажется даже раньше нэймспэйсов. и это с твоей колокольни они не часты -- это типичная задача в корпоративной среде. ну да, как ее можно увидеть не работая там? просто поверь мне.
это криво. это будет плохо работать. особенно если у нас что-то типа {bge0,bge1,bge2}-{bge3,bge4,bge5}
почему в ядре должны быть сконфигурированны сущности, по которым работает файрвол?
разве для фильтрации транзитного tcp в ядре должны быть tcp сокеты? ну или stcp.
файрволу не требуется поддержка ядра для этих действий.
и я уже приводил пример -- файрвол может фильтровать трафик в транзитном GRE-туннеле, не терминируюя его на машине. точно так же можно фильтровать трафик в езернетовском транке, не терминируя и не заводя vlanы в ядре, просто поставив в режим бриджа и самостоятельно разбирая 802.1q заголовки. ну и с метками mpls та же история. зачем делать урезанную функциональность, если достаточно простыми и дешевыми средствами можно получить гораздо большую гибкость?
может я и не прав и мне не удалось многое до тебя до нести. но раз в неделю -- я уже непомню что сказал, что нет.