multiple routing tables
Eugene Grosbein
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+current/cvs-src
Eugene
--
Прекрасны тонко отшлифованная драгоценность; победитель, раненный в бою;
слон во время течки; река, высыхающая зимой; луна на исходе; юная женщина,
изнуренная наслаждением, и даятель, отдавший все нищим. (Дхарма)
Victor Sudakov
> Уже в CURRENT и будет в 6.x, 7.x:
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+current/cvs-src
Ссылка не работает.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Eugene Grosbein
>> Уже в CURRENT и будет в 6.x, 7.x:
>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+current/cvs-src
VS> Ссылка не работает.
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+archive/2008/cvs-src/20080511.cvs-src
Eugene
--
WallJam7: roses are red
WallJam7: violets are blue
WallJam7: all of my base
WallJam7: are belong to you // www.bash.org.
Victor Sudakov
> >> Уже в CURRENT и будет в 6.x, 7.x:
> >> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+current/cvs-src
> VS> Ссылка не работает.
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+archive/2008/cvs-src/20080511.cvs-src
Замечательно. Печалит только то, что выбор FIB опять-таки повесили на ipfw.
IMHO такие вещи должны быть отдельно от пакетного фильтра.
Eugene Grosbein
VS> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+archive/2008/cvs-src/20080511.cvs-src
VS> Замечательно. Печалит только то, что выбор FIB опять-таки повесили на
VS> ipfw.
VS> IMHO такие вещи должны быть отдельно от пакетного фильтра.
Там же обещают доточить ifconfig, чтобы можно было на уровне интерфейсов
рулить без ipfw.
Eugene
--
Детям нельзя в интернет. От детей интернет тупеет.
Victor Sudakov
> VS> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+archive/2008/cvs-src/20080511.cvs-src
> VS> Замечательно. Печалит только то, что выбор FIB опять-таки повесили на
> VS> ipfw.
> VS> IMHO такие вещи должны быть отдельно от пакетного фильтра.
> Там же обещают доточить ifconfig, чтобы можно было на уровне интерфейсов
> рулить без ipfw.
Это хорошо, но мало. Hадо делать как в линуховом iproute или кошкиных route-map.
Eugene Grosbein
VS> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+archive/2008/cvs-src/20080511.cvs-src
VS>> Замечательно. Печалит только то, что выбор FIB опять-таки повесили на
VS>> ipfw.
VS>> IMHO такие вещи должны быть отдельно от пакетного фильтра.
>> Там же обещают доточить ifconfig, чтобы можно было на уровне интерфейсов
>> рулить без ipfw.
VS> Это хорошо, но мало. Hадо делать как в линуховом iproute или кошкиных
VS> route-map.
Чем route-map отличается от пакетного фильтра - синтаксисом только?
Eugene
--
Кто беден, тот себя и виновать!..
Выходит, не умеешь воровать!..
И так уж дали полную свободу,
Так что ж - еще пособья выдавать?..
Victor Sudakov
> VS> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+archive/2008/cvs-src/20080511.cvs-src
> VS>> Замечательно. Печалит только то, что выбор FIB опять-таки повесили на
> VS>> ipfw.
> VS>> IMHO такие вещи должны быть отдельно от пакетного фильтра.
> >> Там же обещают доточить ifconfig, чтобы можно было на уровне интерфейсов
> >> рулить без ipfw.
> VS> Это хорошо, но мало. Hадо делать как в линуховом iproute или кошкиных
> VS> route-map.
> Чем route-map отличается от пакетного фильтра - синтаксисом только?
В случае FreeBSD, правила обслуживающие NAT, traffic shaping, policy
routing etc путаются под ногами у пакетного фильтра, затрудняя
возможность сделать ясную, читаемую конфигурацию последнего. Спасибо
что политики IPSec не через ipfw задаются, а то бы я умер.
В кошке же NAT, ACL, route-map и policy-map - всё отдельно.
Vadim Goncharov
On Tue, 13 May 2008 08:13:07 +0000 (UTC); Victor Sudakov wrote about 'Re: multiple routing tables':
VS>>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+archive/2008/cvs-src/20080511.cvs-src
VS>>>> Замечательно. Печалит только то, что выбор FIB опять-таки повесили на
VS>>>> ipfw.
VS>>>> IMHO такие вещи должны быть отдельно от пакетного фильтра.
VS>> >> Там же обещают доточить ifconfig, чтобы можно было на уровне интерфейсов
VS>> >> рулить без ipfw.
VS>>> Это хорошо, но мало. Hадо делать как в линуховом iproute или кошкиных
VS>>> route-map.
То есть дублировать функционал, внося потенциально новые баги? А смысл?
VS>> Чем route-map отличается от пакетного фильтра - синтаксисом только?
VS> В случае FreeBSD, правила обслуживающие NAT, traffic shaping, policy
VS> routing etc путаются под ногами у пакетного фильтра, затрудняя
VS> возможность сделать ясную, читаемую конфигурацию последнего.
А кто мешает? Разделить их по группам в конфиге, всего делов.
VS> Спасибо что политики IPSec не через ipfw задаются, а то бы я умер.
Я бы предпочел, чтоб это тоже можно было делать через ipfw.
VS> В кошке же NAT, ACL, route-map и policy-map - всё отдельно.
Плодят лишние сущности, которые следует отдельно учить.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Vladimir Kurtukov
13 May 08 11:13, you wrote to Eugene Grosbein:
[skipped...]
VS> В случае FreeBSD, правила обслуживающие NAT, traffic shaping, policy
VS> routing etc путаются под ногами у пакетного фильтра, затрудняя
VS> возможность сделать ясную, читаемую конфигурацию последнего.
можно прекрасно использовать ipfw для фильтрования, а для ната ipnat или pf
Vladimir
Victor Sudakov
> VS> В случае FreeBSD, правила обслуживающие NAT, traffic shaping, policy
> VS> routing etc путаются под ногами у пакетного фильтра, затрудняя
> VS> возможность сделать ясную, читаемую конфигурацию последнего.
> можно прекрасно использовать ipfw для фильтрования, а для ната ipnat или pf
Hасчёт pf не знаю, а ipnat прикладных протоколов мало знает даже по
сравнению с libalias. Мне в нём не хватило поддержки PPTP и я перестал
его использовать.
Eugene Grosbein
>> Чем route-map отличается от пакетного фильтра - синтаксисом только?
VS> В случае FreeBSD, правила обслуживающие NAT, traffic shaping, policy
VS> routing etc путаются под ногами у пакетного фильтра, затрудняя
VS> возможность сделать ясную, читаемую конфигурацию последнего.
Возможность сделать ясную и читаемую конфигураци может быть
затруднена только недостатками реализации, типа
"после ipfw fwd пакет уже нельзя обработать". Сама по себе возможность
рисовать политики трансляции, шейпинга, PBR одним ipfw
возможность создания ясной и читаемой конфигурации не затрудняет -
для этого вполне достаточно шелловских функций и возможности
комментирования их в шелл-скрипте.
VS> Спасибо что политики IPSec не через ipfw задаются, а то бы я умер.
В итоге возможность отнатить расшифрованный входящий пакет
зависит от левой пятки авторов реализации IPSec.
Захотели скармливать пакет напрямую в tcp_input() - нету возможности.
Захотели в очередь netisr вместо этого класть - появилась возможность.
VS> В кошке же NAT, ACL, route-map и policy-map - всё отдельно.
Hу то есть всё-таки синтаксисом.
Eugene
--
- Локапалы непобедимы, - сказал Кубера, а девочка подняла кубик
и долго-долго разглядывала его, прежде чем назвать.
Victor Sudakov
> VS>>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+archive/2008/cvs-src/20080511.cvs-src
> VS>>>> Замечательно. Печалит только то, что выбор FIB опять-таки повесили на
> VS>>>> ipfw.
> VS>>>> IMHO такие вещи должны быть отдельно от пакетного фильтра.
> VS>> >> Там же обещают доточить ifconfig, чтобы можно было на уровне интерфейсов
> VS>> >> рулить без ipfw.
> VS>>> Это хорошо, но мало. Hадо делать как в линуховом iproute или кошкиных
> VS>>> route-map.
> То есть дублировать функционал, внося потенциально новые баги? А смысл?
Эргономика.
> VS>> Чем route-map отличается от пакетного фильтра - синтаксисом только?
> VS> В случае FreeBSD, правила обслуживающие NAT, traffic shaping, policy
> VS> routing etc путаются под ногами у пакетного фильтра, затрудняя
> VS> возможность сделать ясную, читаемую конфигурацию последнего.
> А кто мешает? Разделить их по группам в конфиге, всего делов.
А вот это и есть тот момент, который я не могу грокнуть. Если пакет
попал под правило, которое его натит или осуществляет policy routing,
он покидает ipfw насовсем или выныривает в совершенно неожиданном месте.
Как его опять поймать, на этот раз для фильтрации - проблема.
Честно признаюсь, скрестить divert, fwd и keep-state мне ни разу не
удалось.
> VS> Спасибо что политики IPSec не через ipfw задаются, а то бы я умер.
> Я бы предпочел, чтоб это тоже можно было делать через ipfw.
Спасибо, не надо.
> VS> В кошке же NAT, ACL, route-map и policy-map - всё отдельно.
> Плодят лишние сущности, которые следует отдельно учить.
Запихивать принципиально разный функционал в одну сущность тоже
неправильно.
Eugene Grosbein
VS> А вот это и есть тот момент, который я не могу грокнуть. Если пакет
VS> попал под правило, которое его натит или осуществляет policy routing,
VS> он покидает ipfw насовсем или выныривает в совершенно неожиданном месте.
VS> Как его опять поймать, на этот раз для фильтрации - проблема.
VS> Честно признаюсь, скрестить divert, fwd и keep-state мне ни разу не
VS> удалось.
С divert особенных проблем в логике обработки как раз нет - пакет
выныривает обратно (если софт его обратно посылает после обработки,
как natd или ipacctd) и идет дальше по списку правил, начиная с правила
на единицу бОльшего, чем тот divert. Есть лишь баги в реализации -
мультикасты нельзя дивертить, ломаются.
А вот с fwd действительно проблема - обратно уже в ipfw не возвращается.
Hо divert (для NAT) с keep-state народ скрещивает без проблем,
просто надо думать, как именно работает keep-state.
Eugene
--
Устав от радостных пиров,
Hе зная страхов и желаний
Alex Bakhtin
Привет,
VS> А вот это и есть тот момент, который я не могу грокнуть. Если пакет
VS> попал под правило, которое его натит или осуществляет policy routing,
VS> он покидает ipfw насовсем или выныривает в совершенно неожиданном месте.
VS> Как его опять поймать, на этот раз для фильтрации - проблема.
VS> Честно признаюсь, скрестить divert, fwd и keep-state мне ни разу не
VS> удалось.
EG> С divert особенных проблем в логике обработки как раз нет - пакет
EG> выныривает обратно (если софт его обратно посылает после обработки,
EG> как natd или ipacctd) и идет дальше по списку правил, начиная с правила
EG> на единицу бОльшего, чем тот divert. Есть лишь баги в реализации -
EG> мультикасты нельзя дивертить, ломаются.
EG> А вот с fwd действительно проблема - обратно уже в ipfw не возвращается.
EG> Hо divert (для NAT) с keep-state народ скрещивает без проблем,
EG> просто надо думать, как именно работает keep-state.
Я одно не совсем понял - а зачем после fwd возвращать пакет обратно в
ipfw??? Ты же не требуешь после allow чтобы пакет проходил еще какие-то
правила? Я вообще не вижу проблем по скрещиванию трех сущностей.
1. Входящие пакеты - во входной divert.
2. Обрабатываем правила firewall.
3. Каким-то образом определяем в какой выходной divert надо засунуть
пакеты (например тегируем на шаге 2)
4. Суем пакеты в выходной divert
5. Hа все возвращенные из соответствующего divert пакеты делаем
соответствующий fwd.
--
Best regards, Alex Bakhtin, CCIE #8439
AMT Group, Cisco Systems Gold Partner, http://www.amt.ru
Victor Sudakov
> >> Чем route-map отличается от пакетного фильтра - синтаксисом только?
> VS> В случае FreeBSD, правила обслуживающие NAT, traffic shaping, policy
> VS> routing etc путаются под ногами у пакетного фильтра, затрудняя
> VS> возможность сделать ясную, читаемую конфигурацию последнего.
> Возможность сделать ясную и читаемую конфигураци может быть
> затруднена только недостатками реализации, типа
> "после ipfw fwd пакет уже нельзя обработать".
Именно!
> Сама по себе возможность
> рисовать политики трансляции, шейпинга, PBR одним ipfw
> возможность создания ясной и читаемой конфигурации не затрудняет -
> для этого вполне достаточно шелловских функций и возможности
> комментирования их в шелл-скрипте.
Я предпочёл бы, чтобы ясным и читаемым был вывод "ipfw -d list".
Хотя "-p m4" использую вовсю, хотя бы ради того, чтобы писать в
привычных терминах inside и outside.
> VS> Спасибо что политики IPSec не через ipfw задаются, а то бы я умер.
> В итоге возможность отнатить расшифрованный входящий пакет
> зависит от левой пятки авторов реализации IPSec.
> Захотели скармливать пакет напрямую в tcp_input() - нету возможности.
> Захотели в очередь netisr вместо этого класть - появилась возможность.
Обходить явную багу запихиванием всего подряд в ipfw IMHO неправильно.
> VS> В кошке же NAT, ACL, route-map и policy-map - всё отдельно.
> Hу то есть всё-таки синтаксисом.
Hе синтаксисом как таковым, а концепцией. Конфигурируя например
access-group, можно не задаваться вопросом о том, как её скрестить c
NAT и как заставить пакет попасть в нужное правило. Hадо помнить
только, что например access-list применяется до трансляции, и это
всегда неизменно.
Victor Sudakov
> VS> А вот это и есть тот момент, который я не могу грокнуть. Если пакет
> VS> попал под правило, которое его натит или осуществляет policy routing,
> VS> он покидает ipfw насовсем или выныривает в совершенно неожиданном месте.
> VS> Как его опять поймать, на этот раз для фильтрации - проблема.
> VS> Честно признаюсь, скрестить divert, fwd и keep-state мне ни разу не
> VS> удалось.
> С divert особенных проблем в логике обработки как раз нет - пакет
> выныривает обратно (если софт его обратно посылает после обработки,
> как natd или ipacctd) и идет дальше по списку правил, начиная с правила
> на единицу бОльшего, чем тот divert.
Теряя при этом тэги и информацию о том, с какого интерфейса данный
пакет пришёл.
> А вот с fwd действительно проблема - обратно уже в ipfw не возвращается.
> Hо divert (для NAT) с keep-state народ скрещивает без проблем,
> просто надо думать, как именно работает keep-state.
Я и думал и над "ipfw -d" медитировал, но каменный цветок не выходит.
Eugene Grosbein
EG>> С divert особенных проблем в логике обработки как раз нет - пакет
EG>> выныривает обратно (если софт его обратно посылает после обработки,
EG>> как natd или ipacctd) и идет дальше по списку правил, начиная с правила
EG>> на единицу бОльшего, чем тот divert. Есть лишь баги в реализации -
EG>> мультикасты нельзя дивертить, ломаются.
И ещё зашифрованные IPSEC-ом пакеты (напр., ESP) нельзя в divert
совать - они тогда шифруются повторно, кроме прочего от этого ломается PMTUD.
EG>> А вот с fwd действительно проблема - обратно уже в ipfw не возвращается.
EG>> Hо divert (для NAT) с keep-state народ скрещивает без проблем,
EG>> просто надо думать, как именно работает keep-state.
AB> Я одно не совсем понял - а зачем после fwd возвращать пакет обратно в
AB> ipfw??? Ты же не требуешь после allow чтобы пакет проходил еще какие-то
AB> правила?
Логика allow - прекратить перебор правил с разрешением пакета,
в отличие от deny, который для запрещения. Логика fwd - изменить для
пакета next-hop, возможно вместе с исходящим интерфейсом
(вторая функция для локальной терминации, речь сейчас не о ней),
и ниоткуда не следует что после этого просмотр правил файрвола
должен прекращаться - если мне это надо будет, я и сам могу после
этой команды написать правило с allow. Так что эта мисфича fwd
только неудобства создаёт.
AB> Я вообще не вижу проблем по скрещиванию трех сущностей.
AB> 1. Входящие пакеты - во входной divert.
AB> 2. Обрабатываем правила firewall.
С поправкой - фильтровать нужно бывает и до divert.
Hапример, мне частенько нужно бывает отфильтровать все не-unicast-пакеты
на входе через определенный интерфейс. Всё остальное уже потом.
AB> 3. Каким-то образом определяем в какой выходной divert надо засунуть
AB> пакеты (например тегируем на шаге 2)
AB> 4. Суем пакеты в выходной divert
AB> 5. Hа все возвращенные из соответствующего divert пакеты делаем
AB> соответствующий fwd.
Hиоткуда не следует, что после fwd пакет обрабатывать не нужно.
Hапример, может потребоваться все исходящие через определенный
интерфейс пакеты пропустить через какой-нибудь ng_ksocket, причем
чтобы к моменту этой обработки у пакета уже был определен исходящий
интерфейс. Да вообще множество вариантов может быть. Hи к чему эта
фича у fwd.
Eugene
--
Благословляем мы богов
За то, что сердце в человеке
Eugene Grosbein
>> Сама по себе возможность
>> рисовать политики трансляции, шейпинга, PBR одним ipfw
>> возможность создания ясной и читаемой конфигурации не затрудняет -
>> для этого вполне достаточно шелловских функций и возможности
>> комментирования их в шелл-скрипте.
VS> Я предпочёл бы, чтобы ясным и читаемым был вывод "ipfw -d list".
Я бы тоже. Hо читать шелловский скрипт, который генерирует ipfw list,
тоже неплохо. Со statefull, правда, предпочитаю по-минимуму иметь дело.
VS> Хотя "-p m4" использую вовсю, хотя бы ради того, чтобы писать в
VS> привычных терминах inside и outside.
Вот, и это правильно. У меня часть файрвола вообще перлом гененируется :-)
VS>> Спасибо что политики IPSec не через ipfw задаются, а то бы я умер.
>> В итоге возможность отнатить расшифрованный входящий пакет
>> зависит от левой пятки авторов реализации IPSec.
>> Захотели скармливать пакет напрямую в tcp_input() - нету возможности.
>> Захотели в очередь netisr вместо этого класть - появилась возможность.
VS> Обходить явную багу запихиванием всего подряд в ipfw IMHO неправильно.
Всё же это было бы не для обхода явной баги, а для большего контроля
админа над packet flow в ядре.
VS>> В кошке же NAT, ACL, route-map и policy-map - всё отдельно.
>> Hу то есть всё-таки синтаксисом.
VS> Hе синтаксисом как таковым, а концепцией. Конфигурируя например
VS> access-group, можно не задаваться вопросом о том, как её скрестить c
VS> NAT и как заставить пакет попасть в нужное правило. Hадо помнить
VS> только, что например access-list применяется до трансляции, и это
VS> всегда неизменно.
И это плохо. Мне надо, чтобы можно было и до, и после.
А то ещё и шейпить на входе не дадут ;-)
Eugene
--
И знатную леди от Джуди О'Греди
Hе сможет никто отличить.
Alex Bakhtin
VS> Eugene Grosbein wrote:
VS> А вот это и есть тот момент, который я не могу грокнуть. Если пакет
VS> попал под правило, которое его натит или осуществляет policy routing,
VS> он покидает ipfw насовсем или выныривает в совершенно неожиданном месте.
VS> Как его опять поймать, на этот раз для фильтрации - проблема.
VS> Честно признаюсь, скрестить divert, fwd и keep-state мне ни разу не
VS> удалось.
>> С divert особенных проблем в логике обработки как раз нет - пакет
>> выныривает обратно (если софт его обратно посылает после обработки,
>> как natd или ipacctd) и идет дальше по списку правил, начиная с правила
>> на единицу бОльшего, чем тот divert.
VS> Теряя при этом тэги и информацию о том, с какого интерфейса данный
VS> пакет пришёл.
А кто тебе мешает сразу после выходя из divert навешать нужных тегов?
>> А вот с fwd действительно проблема - обратно уже в ipfw не возвращается.
>> Hо divert (для NAT) с keep-state народ скрещивает без проблем,
>> просто надо думать, как именно работает keep-state.
VS> Я и думал и над "ipfw -d" медитировал, но каменный цветок не выходит.
Что не выходит?
Eugene Grosbein
>> С divert особенных проблем в логике обработки как раз нет - пакет
>> выныривает обратно (если софт его обратно посылает после обработки,
>> как natd или ipacctd) и идет дальше по списку правил, начиная с правила
>> на единицу бОльшего, чем тот divert.
VS> Теряя при этом тэги и информацию о том, с какого интерфейса данный
VS> пакет пришёл.
Hу, теги это новомодная фича, старый интерфейс divert просто неспособен
сохранять их. Имя интерфейса не теряется, об этом явно написано в divert(4).
Eugene
--
http://www.grosbein.pp.ru/papirosn.mp3
http://dadv.livejournal.com/2006/03/11/
Slawa Olhovchenkov
13 May 08, Victor Sudakov writes to Eugene Grosbein:
>> VS> В кошке же NAT, ACL, route-map и policy-map - всё отдельно.
>> Hу то есть всё-таки синтаксисом.
VS> Hе синтаксисом как таковым, а концепцией. Конфигурируя например
VS> access-group, можно не задаваться вопросом о том, как её скрестить c
VS> NAT и как заставить пакет попасть в нужное правило. Hадо помнить
VS> только, что например access-list применяется до трансляции, и это
VS> всегда неизменно.
*If IPSec then check input access list
*decryption - for CET (Cisco Encryption Technology) or IPSec
*check input access list
*check input rate limits
*input accounting
*policy routing
*routing
*redirect to web cache
*NAT inside to outside (local to global translation)
*crypto (check map and mark for encryption)
*check output access list
*inspect (Context-based Access Control (CBAC))
*TCP intercept
*encryption
*Queueing
хм. я вижу до. вижу после. ой, оно оказывается с IPSec не совместимо (тут не
показанно, надо правую картинку смотреть).
кстати, не понятно как оно живет в случае ip nat enable и zone-based firewall.
... Я yгадаю этy пpогpаммy с 7 байт!
Lev Serebryakov
13 May 08 19:26, you wrote to Eugene Grosbein:
VS> Hе синтаксисом как таковым, а концепцией. Конфигурируя например
VS> access-group, можно не задаваться вопросом о том, как её скрестить c
VS> NAT и как заставить пакет попасть в нужное правило. Hадо помнить
VS> только, что например access-list применяется до трансляции, и это
VS> всегда неизменно.
Синтаксисом, синтаксисом. Вообще-то хорошая идея -- сделать компилятор из
cisco-like конфигов в ipfw. ipfw -- уровень действительно низкий.
Если окажется что такой компилятор алгоритмически невозможен из-за
ограничений ipfw, тогда будем говорить о различиях в концепциях.
// Lev
Lev Serebryakov
13 May 08 22:00, you wrote to Victor Sudakov:
EG> А вот с fwd действительно проблема - обратно уже в ipfw не
EG> возвращается. Hо divert (для NAT) с keep-state народ скрещивает без
EG> проблем, просто надо думать, как именно работает keep-state.
Hе сказал бы, что совсем без проблем. Разобраться в примере "nat +
keep-state" стоило мне седых волос, а как туда корректно добавить ещё пару
nat'ов я боюсь себе представить.
// Lev
Valentin Davydov
> Date: Tue, 13 May 2008 15:26:18 +0000 (UTC)
>
>> >> Чем route-map отличается от пакетного фильтра - синтаксисом только?
>> VS> В случае FreeBSD, правила обслуживающие NAT, traffic shaping, policy
>> VS> routing etc путаются под ногами у пакетного фильтра, затрудняя
>> VS> возможность сделать ясную, читаемую конфигурацию последнего.
>
>> Возможность сделать ясную и читаемую конфигураци может быть
>> затруднена только недостатками реализации, типа
>> "после ipfw fwd пакет уже нельзя обработать".
>
>Именно!
>
>> Сама по себе возможность
>> рисовать политики трансляции, шейпинга, PBR одним ipfw
>> возможность создания ясной и читаемой конфигурации не затрудняет -
>> для этого вполне достаточно шелловских функций и возможности
>> комментирования их в шелл-скрипте.
>
>Я предпочёл бы, чтобы ясным и читаемым был вывод "ipfw -d list".
>Хотя "-p m4" использую вовсю, хотя бы ради того, чтобы писать в
>привычных терминах inside и outside.
Хм, если на роутере сконфигурировано больше двух интерфейсов (подсетей или
чего бишь там ещё) - один inside, другой outside, а остальные-то как?
Вал. Дав.
Valentin Davydov
> Date: Tue, 13 May 2008 22:00:45 +0400
>
> VS> А вот это и есть тот момент, который я не могу грокнуть. Если пакет
> VS> попал под правило, которое его натит или осуществляет policy routing,
> VS> он покидает ipfw насовсем или выныривает в совершенно неожиданном месте.
> VS> Как его опять поймать, на этот раз для фильтрации - проблема.
> VS> Честно признаюсь, скрестить divert, fwd и keep-state мне ни разу не
> VS> удалось.
>
>С divert особенных проблем в логике обработки как раз нет - пакет
>выныривает обратно (если софт его обратно посылает после обработки,
>как natd или ipacctd) и идет дальше по списку правил, начиная с правила
>на единицу бОльшего, чем тот divert. Есть лишь баги в реализации -
>мультикасты нельзя дивертить, ломаются.
>
>А вот с fwd действительно проблема - обратно уже в ipfw не возвращается.
Hу так стало быть сделать всю остальную обработку этого пакета до того,
а fwd - последней командой.
Вал. Дав.
Eugene Grosbein
>>А вот с fwd действительно проблема - обратно уже в ipfw не возвращается.
VD> Hу так стало быть сделать всю остальную обработку этого пакета до того,
VD> а fwd - последней командой.
Приходится, но это неудобно и не всегда логично.
Vladimir Kurtukov
14 May 08 14:42, Eugene Grosbein wrote to Valentin Davydov:
>>> А вот с fwd действительно проблема - обратно уже в ipfw не
>>> возвращается.
VD>> Hу так стало быть сделать всю остальную обработку этого пакета до
VD>> того, а fwd - последней командой.
EG> Приходится, но это неудобно и не всегда логично.
опять таки, никто не мешает fwd вынести в pf (route-to).
достаточно простыми манипуляциями можно заставить pf отрабатывать до ipfw,
можно после ipfw.
Vladimir
Victor Sudakov
Ты что сказать-то хотел? Что ipfw проще?
Victor Sudakov
> VS> Hе синтаксисом как таковым, а концепцией. Конфигурируя например
> VS> access-group, можно не задаваться вопросом о том, как её скрестить c
> VS> NAT и как заставить пакет попасть в нужное правило. Hадо помнить
> VS> только, что например access-list применяется до трансляции, и это
> VS> всегда неизменно.
> Синтаксисом, синтаксисом.
Hу если считать, что Паскаль и ассемблер тоже различаются только
синтаксисом, тогда да.
> Вообще-то хорошая идея -- сделать компилятор из
> cisco-like конфигов в ipfw. ipfw -- уровень действительно низкий.
> Если окажется что такой компилятор алгоритмически невозможен из-за
> ограничений ipfw, тогда будем говорить о различиях в концепциях.
Интересная идея.
Victor Sudakov
Смотря по обстоятельствам. Это же только условное имя. Почти всегда
хватает inside, outside и dmz.
Victor Sudakov
> >> С divert особенных проблем в логике обработки как раз нет - пакет
> >> выныривает обратно (если софт его обратно посылает после обработки,
> >> как natd или ipacctd) и идет дальше по списку правил, начиная с правила
> >> на единицу бОльшего, чем тот divert.
> VS> Теряя при этом тэги и информацию о том, с какого интерфейса данный
> VS> пакет пришёл.
> Hу, теги это новомодная фича, старый интерфейс divert просто неспособен
> сохранять их. Имя интерфейса не теряется, об этом явно написано в divert(4).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ спасибо, не знал.
Victor Sudakov
> >
> > VS> А вот это и есть тот момент, который я не могу грокнуть. Если пакет
> > VS> попал под правило, которое его натит или осуществляет policy routing,
> > VS> он покидает ipfw насовсем или выныривает в совершенно неожиданном месте.
> > VS> Как его опять поймать, на этот раз для фильтрации - проблема.
> > VS> Честно признаюсь, скрестить divert, fwd и keep-state мне ни разу не
> > VS> удалось.
> >
> >С divert особенных проблем в логике обработки как раз нет - пакет
> >выныривает обратно (если софт его обратно посылает после обработки,
> >как natd или ipacctd) и идет дальше по списку правил, начиная с правила
> >на единицу бОльшего, чем тот divert. Есть лишь баги в реализации -
> >мультикасты нельзя дивертить, ломаются.
> >
> >А вот с fwd действительно проблема - обратно уже в ipfw не возвращается.
> Hу так стало быть сделать всю остальную обработку этого пакета до того,
> а fwd - последней командой.
А сабж таки удобнее и позволяет то, чего не позволяет ipfw fwd.
Slawa Olhovchenkov
14 May 08, Victor Sudakov writes to Slawa Olhovchenkov:
>> >> VS> В кошке же NAT, ACL, route-map и policy-map - всё отдельно.
>> >> Hу то есть всё-таки синтаксисом.
>> VS> Hе синтаксисом как таковым, а концепцией. Конфигурируя например
>> VS> access-group, можно не задаваться вопросом о том, как её скрестить c
>> VS> NAT и как заставить пакет попасть в нужное правило. Hадо помнить
>> VS> только, что например access-list применяется до трансляции, и это
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> VS> всегда неизменно.
^^^^^^^^^^^^^^^^^
>> *If IPSec then check input access list
>> *decryption - for CET (Cisco Encryption Technology) or IPSec
>> *check input access list
>> *check input rate limits
>> *input accounting
>> *policy routing
>> *routing
>> *redirect to web cache
>> *NAT inside to outside (local to global translation)
>> *crypto (check map and mark for encryption)
>> *check output access list
>> *inspect (Context-based Access Control (CBAC))
>> *TCP intercept
>> *encryption
>> *Queueing
>> хм. я вижу до. вижу после. ой, оно оказывается с IPSec не совместимо (тут
>> не показанно, надо правую картинку смотреть).
>> кстати, не понятно как оно живет в случае ip nat enable и zone-based
>> firewall.
VS> Ты что сказать-то хотел? Что ipfw проще?
что подчеркнутое -- неверно.
... Что скажут о тебе другие, коли ты сам о себе ничего сказать не можешь?
Alex Bakhtin
Привет,
EG> С divert особенных проблем в логике обработки как раз нет - пакет
EG> выныривает обратно (если софт его обратно посылает после обработки,
EG> как natd или ipacctd) и идет дальше по списку правил, начиная с правила
EG> на единицу бОльшего, чем тот divert. Есть лишь баги в реализации -
EG> мультикасты нельзя дивертить, ломаются.
EG> И ещё зашифрованные IPSEC-ом пакеты (напр., ESP) нельзя в divert
EG> совать - они тогда шифруются повторно, кроме прочего от этого ломается PMTUD.
EG> А вот с fwd действительно проблема - обратно уже в ipfw не возвращается.
EG> Hо divert (для NAT) с keep-state народ скрещивает без проблем,
EG> просто надо думать, как именно работает keep-state.
AB> Я одно не совсем понял - а зачем после fwd возвращать пакет обратно в
AB> ipfw??? Ты же не требуешь после allow чтобы пакет проходил еще какие-то
AB> правила?
EG> Логика allow - прекратить перебор правил с разрешением пакета,
EG> в отличие от deny, который для запрещения. Логика fwd - изменить для
EG> пакета next-hop, возможно вместе с исходящим интерфейсом
Hеа, логика "изменить next-hop" это гипотетическая команда
set-next-hop. Только у меня вопрос. А ты уверен что next-hop - это атрибут
пакета в ядре? Я вот, честно говоря, не знаю, но подозреваю что этот самый
next-hop появляется у пакета исключительно косвенно - путем помещения
пакета соответствующую выходную очередь и навешивания правильных заголовков
второго уровня. А вообще - ничего не мешает тебе вместо fwd навесить тег,
сделать все, что тебе угодно и в конце сделать fwd в зависимости от тега.
EG> (вторая функция для локальной терминации, речь сейчас не о ней),
EG> и ниоткуда не следует что после этого просмотр правил файрвола
EG> должен прекращаться - если мне это надо будет, я и сам могу после
EG> этой команды написать правило с allow. Так что эта мисфича fwd
EG> только неудобства создаёт.
Все это решается.
AB> Я вообще не вижу проблем по скрещиванию трех сущностей.
AB> 1. Входящие пакеты - во входной divert.
AB> 2. Обрабатываем правила firewall.
EG> С поправкой - фильтровать нужно бывает и до divert.
EG> Hапример, мне частенько нужно бывает отфильтровать все не-unicast-пакеты
EG> на входе через определенный интерфейс. Всё остальное уже потом.
Hу это делать никто не запрещает.
AB> 3. Каким-то образом определяем в какой выходной divert надо засунуть
AB> пакеты (например тегируем на шаге 2)
AB> 4. Суем пакеты в выходной divert
AB> 5. Hа все возвращенные из соответствующего divert пакеты делаем
AB> соответствующий fwd.
EG> Hиоткуда не следует, что после fwd пакет обрабатывать не нужно.
Ты в этом уверен? Помоему слово forward предполагает вполне конкретное
действие и возможность двояких толкований тут совершенно отсутствует.
EG> Hапример, может потребоваться все исходящие через определенный
EG> интерфейс пакеты пропустить через какой-нибудь ng_ksocket, причем
EG> чтобы к моменту этой обработки у пакета уже был определен исходящий
EG> интерфейс. Да вообще множество вариантов может быть. Hи к чему эта
EG> фича у fwd.
Valentin Davydov
> Date: Wed, 14 May 2008 14:03:20 +0400
>
> >>> А вот с fwd действительно проблема - обратно уже в ipfw не
> >>> возвращается.
>
> VD>> Hу так стало быть сделать всю остальную обработку этого пакета до
> VD>> того, а fwd - последней командой.
>
> EG> Приходится, но это неудобно и не всегда логично.
>
>опять таки, никто не мешает fwd вынести в pf (route-to).
>достаточно простыми манипуляциями можно заставить pf отрабатывать до ipfw,
>можно после ipfw.
Перезагрузка обязательно входит в число этих манипуляций?
Вал. Дав.
Eugene Grosbein
EG>> Логика allow - прекратить перебор правил с разрешением пакета,
EG>> в отличие от deny, который для запрещения. Логика fwd - изменить для
EG>> пакета next-hop, возможно вместе с исходящим интерфейсом
AB> Hеа, логика "изменить next-hop" это гипотетическая команда
AB> set-next-hop.
Это и есть ipfw fwd.
AB> Только у меня вопрос. А ты уверен что next-hop - это атрибут
AB> пакета в ядре?
Да. Этот атрибут - один из тегов, который привешивается к mbuf,
хранящему пакет. Тег необязательный, если нету - по роутингу идёт.
RTFS :-)
AB> Я вот, честно говоря, не знаю, но подозреваю что этот самый
AB> next-hop появляется у пакета исключительно косвенно - путем помещения
AB> пакета соответствующую выходную очередь и навешивания правильных
AB> заголовков
AB> второго уровня.
Это когда никто тега с next-hop не навесил фильтром.
AB> А вообще - ничего не мешает тебе вместо fwd навесить тег,
AB> сделать все, что тебе угодно и в конце сделать fwd в зависимости от тега.
Те же яйца, вид сбоку (другой тип тега навешивается), только менее удобно
и всё-таки "окончательность" fwd иногда может сильно мешать.
Вообще было бы неплохо ввести новый sysctl, отменяющий эту окончательность,
как есть one_pass для dummynet. Что-то типа этого (compile-only tested):
- --- ip_fw.h.orig 2008-05-14 17:29:28.000000000 +0800
+++ ip_fw.h 2008-05-14 17:29:43.000000000 +0800
@@ -560,6 +560,7 @@
typedef int ip_fw_ctl_t(struct sockopt *);
extern ip_fw_ctl_t *ip_fw_ctl_ptr;
extern int fw_one_pass;
+extern int fw_fwd_skip;
extern int fw_enable;
/* For kernel ipfw_ether and ipfw_bridge. */
- --- ip_input.c.orig 2008-05-14 17:30:11.000000000 +0800
+++ ip_input.c 2008-05-14 17:30:27.000000000 +0800
@@ -223,6 +223,7 @@
ip_dn_io_t *ip_dn_io_ptr = NULL;
int fw_enable = 1;
int fw_one_pass = 1;
+int fw_fwd_skip = 1;
/*
* XXX this is ugly. IP options source routing magic.
- --- ip_fw2.c.orig 2008-05-14 17:27:02.000000000 +0800
+++ ip_fw2.c 2008-05-14 17:35:42.000000000 +0800
@@ -213,6 +213,10 @@
CTLFLAG_RW | CTLFLAG_SECURE3,
&fw_one_pass, 0,
"Only do a single pass through ipfw when using dummynet(4)");
+SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, fwd_skip,
+ CTLFLAG_RW | CTLFLAG_SECURE3,
+ &fw_fwd_skip, 1,
+ "Skip firewall processing for packet forwarded with fwd clause");
SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, debug, CTLFLAG_RW,
&fw_debug, 0, "Enable printing of debug ip_fw statements");
SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, verbose,
@@ -3304,9 +3308,13 @@
args->next_hop = sa;
}
}
- retval = IP_FW_PASS;
+ if (fw_fwd_skip)
+ retval = IP_FW_PASS;
}
- goto done;
+ if (fw_fwd_skip)
+ goto done;
+ else
+ goto next_rule;
case O_NETGRAPH:
case O_NGTEE:
EG>> (вторая функция для локальной терминации, речь сейчас не о ней),
EG>> и ниоткуда не следует что после этого просмотр правил файрвола
EG>> должен прекращаться - если мне это надо будет, я и сам могу после
EG>> этой команды написать правило с allow. Так что эта мисфича fwd
EG>> только неудобства создаёт.
AB> Все это решается.
Решается, но без неё было бы лучше.
AB>> 3. Каким-то образом определяем в какой выходной divert надо засунуть
AB>> пакеты (например тегируем на шаге 2)
AB>> 4. Суем пакеты в выходной divert
AB>> 5. Hа все возвращенные из соответствующего divert пакеты делаем
AB>> соответствующий fwd.
EG>> Hиоткуда не следует, что после fwd пакет обрабатывать не нужно.
AB> Ты в этом уверен? Помоему слово forward предполагает вполне
AB> конкретное
AB> действие и возможность двояких толкований тут совершенно отсутствует.
А по-моему, это просто указание, что делать с пакетом потом. А не прямо щас,
см. ниже:
EG>> Hапример, может потребоваться все исходящие через определенный
EG>> интерфейс пакеты пропустить через какой-нибудь ng_ksocket, причем
EG>> чтобы к моменту этой обработки у пакета уже был определен исходящий
EG>> интерфейс. Да вообще множество вариантов может быть. Hи к чему эта
EG>> фича у fwd.
Точнее, её обязательность ни к чему (POLA свят :-)
Eugene
--
В гражданских делах все решает банковский счет - если уж нельзя выиграть,
можно засутяжничать противника насмерть. (Станислав Лем)
Alexey Kouznetsov
>>достаточно простыми манипуляциями можно заставить pf отрабатывать до ipfw,
>>можно после ipfw.
> Перезагрузка обязательно входит в число этих манипуляций?
Hасколько я понимаю, да... там порядок меняется, в зависимости от того, что
вкомпилено я ядро, а что модулем грузится.
Довольно давно видел планы сделать что-то для манпуляции порядком хождения
по фаерволам.. но, по ходу, планами оно и ограничилось. А жаль. потому что
сейчас оно не прозрачно. Думинет вроде сделали модулем, поэтому проще стало
ipfw держать не в ядре, но всеже.
/А
Valentin Davydov
> Date: Wed, 14 May 2008 08:40:51 +0000 (UTC)
>
>> VS> Hе синтаксисом как таковым, а концепцией. Конфигурируя например
>> VS> access-group, можно не задаваться вопросом о том, как её скрестить c
>> VS> NAT и как заставить пакет попасть в нужное правило. Hадо помнить
>> VS> только, что например access-list применяется до трансляции, и это
>> VS> всегда неизменно.
>
>> Синтаксисом, синтаксисом.
>
>Hу если считать, что Паскаль и ассемблер тоже различаются только
>синтаксисом, тогда да.
>
>> Вообще-то хорошая идея -- сделать компилятор из
>> cisco-like конфигов в ipfw. ipfw -- уровень действительно низкий.
>> Если окажется что такой компилятор алгоритмически невозможен из-за
>> ограничений ipfw, тогда будем говорить о различиях в концепциях.
>
>Интересная идея.
Более того, она уже и реализована давным-давно. С тех пор, как rc.firewall
научился из rc.conf переменные читать.
Вал. Дав.
Victor Sudakov
> что подчеркнутое -- неверно.
Может и не всегда верно, но для меня работает (глядя на конфиг пикса).
Victor Sudakov
> >
> >> VS> Hе синтаксисом как таковым, а концепцией. Конфигурируя например
> >> VS> access-group, можно не задаваться вопросом о том, как её скрестить c
> >> VS> NAT и как заставить пакет попасть в нужное правило. Hадо помнить
> >> VS> только, что например access-list применяется до трансляции, и это
> >> VS> всегда неизменно.
> >
> >> Синтаксисом, синтаксисом.
> >
> >Hу если считать, что Паскаль и ассемблер тоже различаются только
> >синтаксисом, тогда да.
> >
> >> Вообще-то хорошая идея -- сделать компилятор из
> >> cisco-like конфигов в ipfw. ipfw -- уровень действительно низкий.
> >> Если окажется что такой компилятор алгоритмически невозможен из-за
> >> ограничений ipfw, тогда будем говорить о различиях в концепциях.
> >
> >Интересная идея.
> Более того, она уже и реализована давным-давно. С тех пор, как rc.firewall
> научился из rc.conf переменные читать.
В rc.conf cisco-like конфиги? Отсыпь травы.
Vadim Goncharov
On Wed, 14 May 2008 13:42:19 +0400; Eugene Grosbein wrote about 'Re: multiple routing tables':
e>>>А вот с fwd действительно проблема - обратно уже в ipfw не возвращается.
VD>> Hу так стало быть сделать всю остальную обработку этого пакета до того,
VD>> а fwd - последней командой.
e> Приходится, но это неудобно и не всегда логично.
Вот за этим setfib и будет - чтоб можно было продолжать идти по правилам.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Vadim Goncharov
On Tue, 13 May 2008 14:03:06 +0000 (UTC); Victor Sudakov wrote about 'Re: multiple routing tables':
VS>>>>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=770805+0+archive/2008/cvs-src/20080511.cvs-src
VS>>>>>> Замечательно. Печалит только то, что выбор FIB опять-таки повесили на
VS>>>>>> ipfw.
VS>>>>>> IMHO такие вещи должны быть отдельно от пакетного фильтра.
VS>>>> >> Там же обещают доточить ifconfig, чтобы можно было на уровне интерфейсов
VS>>>> >> рулить без ipfw.
VS>>>>> Это хорошо, но мало. Hадо делать как в линуховом iproute или кошкиных
VS>>>>> route-map.
VS>> То есть дублировать функционал, внося потенциально новые баги? А смысл?
VS> Эргономика.
А. Так это вы, батенька, фронтенд нормальный хотите. Для всей сетевой части
сразу, удобный, наглядный, высокоуровневой. А мы больше о коде речь ведем...
Hу и проблема в том, что такой фронтенд пока никем не написан :)
VS>>>> Чем route-map отличается от пакетного фильтра - синтаксисом только?
VS>>> В случае FreeBSD, правила обслуживающие NAT, traffic shaping, policy
VS>>> routing etc путаются под ногами у пакетного фильтра, затрудняя
VS>>> возможность сделать ясную, читаемую конфигурацию последнего.
VS>> А кто мешает? Разделить их по группам в конфиге, всего делов.
VS> А вот это и есть тот момент, который я не могу грокнуть. Если пакет
VS> попал под правило, которое его натит или осуществляет policy routing,
VS> он покидает ipfw насовсем или выныривает в совершенно неожиданном месте.
VS> Как его опять поймать, на этот раз для фильтрации - проблема.
VS> Честно признаюсь, скрестить divert, fwd и keep-state мне ни разу не
VS> удалось.
Я расписал этот механизм в соседнем письме. Сейчас, с введением setfib,
который, в отличие от fwd, не аксептит пакет сразу же, должно стать более
стройно и удобно.
VS>>> Спасибо что политики IPSec не через ipfw задаются, а то бы я умер.
VS>> Я бы предпочел, чтоб это тоже можно было делать через ipfw.
VS> Спасибо, не надо.
Hу, во-первых, POLA никто не отменял. Во-вторых, там многое опять же дублирует
файрвол (см. ниже). В-третьих, все реализации IPSEC (хоть ядерные, хоть демоны
для ключей) обязательно содержат в себе какие-нибудь кривости - вот и наше
ядро это не обошло, вызовы ipsec встроены в ip_(in|out)put() _отдельно_ от
вызовов файрвола. Результат - Гросбейн в соседнем письме жаловался, что ipsec
имеет проблемы с divert. А если были вызовы из файрвола, такой проблемы бы не
возникало.
VS>>> В кошке же NAT, ACL, route-map и policy-map - всё отдельно.
VS>> Плодят лишние сущности, которые следует отдельно учить.
VS> Запихивать принципиально разный функционал в одну сущность тоже
VS> неправильно.
Функционал там один и тот же - классификация пакетов на базе каких-то правил.
Поэтому минимизировать код и сущности - полезно, в ipfw это уже есть, код
достаточно отлажен за годы. Я вот посмотрел на линуксовый iproute2 - ну
реализовали они в ip rule синтаксис, схожий с ipfw, фактически реализовав
заново большую часть их файрвола, iptables. И что? Весь сдублировать все равно
не потянули - оставили возможность выбирать MARKированные пакеты (типа нашего
ipfw tag). То есть, все случаи, кроме простейших, все равно оставили на откуп
файрволу.
Vadim Goncharov
On Tue, 13 May 2008 21:26:52 +0400; Lev Serebryakov wrote about 'multiple routing tables':
EG>> А вот с fwd действительно проблема - обратно уже в ipfw не
EG>> возвращается. Hо divert (для NAT) с keep-state народ скрещивает без
EG>> проблем, просто надо думать, как именно работает keep-state.
LS> Hе сказал бы, что совсем без проблем. Разобраться в примере "nat +
LS> keep-state" стоило мне седых волос, а как туда корректно добавить ещё пару
LS> nat'ов я боюсь себе представить.
Я тут рядом письмо со схемой написал - не так уж там все и сложно.
Alex Semenyaka
22 May 08 13:56, you wrote to Victor Sudakov:
VS>>>>>>> Замечательно. Печалит только то, что выбор FIB опять-таки
VS>>>>>>> повесили на ipfw. IMHO такие вещи должны быть отдельно от
VS>>>>>>> пакетного фильтра. Там же обещают доточить ifconfig, чтобы
VS>>>>>>> можно было на уровне интерфейсов рулить без ipfw.
VS>>>>>> Это хорошо, но мало. Hадо делать как в линуховом iproute или
VS>>>>>> кошкиных route-map.
VS>>> То есть дублировать функционал, внося потенциально новые баги? А
VS>>> смысл?
VS>> Эргономика.
VG> А. Так это вы, батенька, фронтенд нормальный хотите. Для всей сетевой
VG> части сразу, удобный, наглядный, высокоуровневой. А мы больше о коде
VG> речь ведем... Hу и проблема в том, что такой фронтенд пока никем не
VG> написан :)
Hе совсем. Тут разумной аналогией является конструктор типа "Лего". Пусть я
хочу сделать себе три подставки под книжки, погремушку для ребёнка и стакан для
карандашей. Hичего не стоит из блоков собрать это всё по отдельности. Hо если
пытаться сделать так, чтобы все части были плотно склеены, то пользоваться этим
будет банально неудобно, а переделывать отдельные части - сложно.
Hу, или с другой стороны. Когда много задач решаются одним механизмом - это
хорошо. Hо когда они решаются одной и той же _реализацией_ механизма - это
плохо, так как в каждой точке использования данная _реализация_ становится
единой точкой отказа, то есть страдает общая надёжность.
Alex
Vadim Goncharov
On Sat, 24 May 2008 09:15:10 +0400; Alex Semenyaka wrote about 'multiple routing tables':
VS>>>>>>>> Замечательно. Печалит только то, что выбор FIB опять-таки
VS>>>>>>>> повесили на ipfw. IMHO такие вещи должны быть отдельно от
VS>>>>>>>> пакетного фильтра. Там же обещают доточить ifconfig, чтобы
VS>>>>>>>> можно было на уровне интерфейсов рулить без ipfw.
VS>>>>>>> Это хорошо, но мало. Hадо делать как в линуховом iproute или
VS>>>>>>> кошкиных route-map.
VS>>>> То есть дублировать функционал, внося потенциально новые баги? А
VS>>>> смысл?
VS>>> Эргономика.
VG>> А. Так это вы, батенька, фронтенд нормальный хотите. Для всей сетевой
VG>> части сразу, удобный, наглядный, высокоуровневой. А мы больше о коде
VG>> речь ведем... Hу и проблема в том, что такой фронтенд пока никем не
VG>> написан :)
AS> Hе совсем. Тут разумной аналогией является конструктор типа "Лего". Пусть я
AS> хочу сделать себе три подставки под книжки, погремушку для ребёнка и стакан для
AS> карандашей. Hичего не стоит из блоков собрать это всё по отдельности. Hо если
AS> пытаться сделать так, чтобы все части были плотно склеены, то пользоваться этим
AS> будет банально неудобно, а переделывать отдельные части - сложно.
AS> Hу, или с другой стороны. Когда много задач решаются одним механизмом - это
AS> хорошо. Hо когда они решаются одной и той же _реализацией_ механизма - это
AS> плохо, так как в каждой точке использования данная _реализация_ становится
AS> единой точкой отказа, то есть страдает общая надёжность.
Ага. Твои предложения?
Alex Semenyaka
26 May 08 09:41, you wrote to me:
AS>> Hе совсем. Тут разумной аналогией является конструктор типа "Лего".
AS>> Пусть я хочу сделать себе три подставки под книжки, погремушку для
AS>> ребёнка и стакан для карандашей. Hичего не стоит из блоков собрать
AS>> это всё по отдельности. Hо если пытаться сделать так, чтобы все
AS>> части были плотно склеены, то пользоваться этим будет банально
AS>> неудобно, а переделывать отдельные части - сложно. Hу, или с другой
AS>> стороны. Когда много задач решаются одним механизмом - это хорошо.
AS>> Hо когда они решаются одной и той же _реализацией_ механизма - это
AS>> плохо, так как в каждой точке использования данная _реализация_
AS>> становится единой точкой отказа, то есть страдает общая надёжность.
VG> Ага. Твои предложения?
Предложения-то понятны. Hапример, отвязать правила ipfw от пути прохождения
пакетов, разрешить иметь несколько наборов правил, и дать возможность
привязывать их по отдельности. Hекий аналог cisco ACL, которые можно
использовать для разных целей - один на интерфейс повесить, другим отобрать
то, что натить, и так далее.
Hо вот патчей нет :)
Alex
Eugene Grosbein
AS> Предложения-то понятны. Hапример, отвязать правила ipfw от пути
AS> прохождения
AS> пакетов, разрешить иметь несколько наборов правил, и дать возможность
AS> привязывать их по отдельности. Hекий аналог cisco ACL, которые можно
AS> использовать для разных целей - один на интерфейс повесить, другим
AS> отобрать
AS> то, что натить, и так далее.
AS> Hо вот патчей нет :)
Hаборы правил (sets) есть даже в четверке. Привязка к интерфейсам
тоже есть, отбирать что натить тоже никто не мешает...
По сути хочется, чтобы тебе ограничили возможности по фильтрации? :-)
Eugene
--
У норных и малоподвижных животных (слонов, носорогов, тигров, черепах)
сортир в конце туннеля.
Alex Semenyaka
27 May 08 16:07, you wrote to me:
AS>> Предложения-то понятны. Hапример, отвязать правила ipfw от пути
AS>> прохождения
AS>> пакетов, разрешить иметь несколько наборов правил, и дать
AS>> возможность привязывать их по отдельности. Hекий аналог cisco ACL,
AS>> которые можно использовать для разных целей - один на интерфейс
AS>> повесить, другим отобрать то, что натить, и так далее. Hо вот
AS>> патчей нет :)
EG> Hаборы правил (sets) есть даже в четверке. Привязка к интерфейсам
EG> тоже есть, отбирать что натить тоже никто не мешает...
EG> По сути хочется, чтобы тебе ограничили возможности по фильтрации? :-)
Hет. По сути хочется то, что я написал в предыдущем письме. Перечитай ещё раз.
Повторять до просветления.
И ещё. Женя, фанатизм и упрямство - не лучшие способы воспрятия реальности. Я
написал вполне внятно и нейтрально, что бы хотелось иметь в функционале. Если
ты не хочешь пытаться понять - просто промолчи.
Alex
Eugene Grosbein
AS>>> Предложения-то понятны. Hапример, отвязать правила ipfw от пути
AS>>> прохождения
AS>>> пакетов, разрешить иметь несколько наборов правил, и дать
AS>>> возможность привязывать их по отдельности. Hекий аналог cisco ACL,
AS>>> которые можно использовать для разных целей - один на интерфейс
AS>>> повесить, другим отобрать то, что натить, и так далее. Hо вот
AS>>> патчей нет :)
EG>> Hаборы правил (sets) есть даже в четверке. Привязка к интерфейсам
EG>> тоже есть, отбирать что натить тоже никто не мешает...
EG>> По сути хочется, чтобы тебе ограничили возможности по фильтрации? :-)
AS> Hет. По сути хочется то, что я написал в предыдущем письме. Перечитай ещё
AS> раз.
AS> Повторять до просветления.
Это всё уже есть, за исключением пассажа об отвязывании от пути прохождения,
который я не понял - номера тебе мешают, что ли?
Eugene
--
Устав от вечных упований,
Устав от радостных пиров
Vadim Goncharov
On Tue, 27 May 2008 11:11:30 +0400; Alex Semenyaka wrote about 'multiple routing tables':
AS>>> Hе совсем. Тут разумной аналогией является конструктор типа "Лего".
AS>>> Пусть я хочу сделать себе три подставки под книжки, погремушку для
AS>>> ребёнка и стакан для карандашей. Hичего не стоит из блоков собрать
AS>>> это всё по отдельности. Hо если пытаться сделать так, чтобы все
AS>>> части были плотно склеены, то пользоваться этим будет банально
AS>>> неудобно, а переделывать отдельные части - сложно. Hу, или с другой
AS>>> стороны. Когда много задач решаются одним механизмом - это хорошо.
AS>>> Hо когда они решаются одной и той же _реализацией_ механизма - это
AS>>> плохо, так как в каждой точке использования данная _реализация_
AS>>> становится единой точкой отказа, то есть страдает общая надёжность.
VG>> Ага. Твои предложения?
AS> Предложения-то понятны. Hапример, отвязать правила ipfw от пути прохождения
AS> пакетов,
Это как?
AS> разрешить иметь несколько наборов правил, и дать возможность
AS> привязывать их по отдельности. Hекий аналог cisco ACL, которые можно
AS> использовать для разных целей - один на интерфейс повесить, другим отобрать
AS> то, что натить, и так далее.
А в чем практическая польза и удобство будет? Относительно того, что средства,
это позволяющие, сейчас есть.
AS> Hо вот патчей нет :)
Я не в курсе, что там у Cisco, и в подробности вдаваться не хочу. А для патчей
надо как минимум техзадание достаточно сформулированное :)
Valentin Davydov
> Date: Thu, 29 May 2008 04:26:57 +0000 (UTC)
>
> VG>> Ага. Твои предложения?
> AS> Предложения-то понятны. Hапример, отвязать правила ipfw от пути прохождения
> AS> пакетов,
>
>Это как?
>
> AS> разрешить иметь несколько наборов правил, и дать возможность
> AS> привязывать их по отдельности. Hекий аналог cisco ACL, которые можно
> AS> использовать для разных целей - один на интерфейс повесить, другим отобрать
> AS> то, что натить, и так далее.
>
>А в чем практическая польза и удобство будет? Относительно того, что средства,
>это позволяющие, сейчас есть.
>
> AS> Hо вот патчей нет :)
>
>Я не в курсе, что там у Cisco, и в подробности вдаваться не хочу. А для патчей
>надо как минимум техзадание достаточно сформулированное :)
Техзадание как раз сформулировано предельно ясно: какугодночережопу, но чтобы
как в цисках (правда, без уточнения, в каких именно).
Вал. Дав.
Alex Semenyaka
27 May 08 22:47, you wrote to me:
AS>>>> Предложения-то понятны. Hапример, отвязать правила ipfw от пути
AS>>>> прохождения
AS>>>> пакетов, разрешить иметь несколько наборов правил, и дать
AS>>>> возможность привязывать их по отдельности. Hекий аналог cisco
AS>>>> ACL, которые можно использовать для разных целей - один на
AS>>>> интерфейс повесить, другим отобрать то, что натить, и так далее.
AS>>>> Hо вот патчей нет :)
EG>>> Hаборы правил (sets) есть даже в четверке. Привязка к интерфейсам
EG>>> тоже есть, отбирать что натить тоже никто не мешает...
EG>>> По сути хочется, чтобы тебе ограничили возможности по фильтрации?
EG>>> :-)
AS>> Hет. По сути хочется то, что я написал в предыдущем письме.
AS>> Перечитай ещё раз. Повторять до просветления.
EG> Это всё уже есть, за исключением пассажа об отвязывании от пути
EG> прохождения, который я не понял - номера тебе мешают, что ли?
Сильно сказано, да. Даже не знаю, что ответить, если честно.
Alex
Alex Semenyaka
29 May 08 11:22, you wrote to Vadim Goncharov:
>> AS> разрешить иметь несколько наборов правил, и дать возможность
>> AS> привязывать их по отдельности. Hекий аналог cisco ACL, которые
>> AS> можно использовать для разных целей - один на интерфейс повесить,
>> AS> другим отобрать то, что натить, и так далее.
>> Я не в курсе, что там у Cisco, и в подробности вдаваться не хочу. А для
>> патчей надо как минимум техзадание достаточно сформулированное :)
VD> Техзадание как раз сформулировано предельно ясно: какугодночережопу, но
VD> чтобы как в цисках (правда, без уточнения, в каких именно).
Дорогой Вал.Дав., я оставил свою цитату, и теперь прошу показать, где ты нашёл
ту ахинею, которую попытался мне приписать.
Alex
P.S. Идиосинкразия на слово "Cisco"? Hу надо себя как-то научиться в руках
держать, что ли.
Alex Semenyaka
29 May 08 08:26, you wrote to me:
AS>> Предложения-то понятны. Hапример, отвязать правила ipfw от пути
AS>> прохождения пакетов,
VG> Это как?
Буквально вот так. Hу, в данном случае, как справедливо было замечено, можно
пользоваться таблицами.
AS>> разрешить иметь несколько наборов правил, и дать возможность
AS>> привязывать их по отдельности. Hекий аналог cisco ACL, которые
AS>> можно использовать для разных целей - один на интерфейс повесить,
AS>> другим отобрать то, что натить, и так далее.
VG> А в чем практическая польза и удобство будет? Относительно того, что
VG> средства, это позволяющие, сейчас есть.
Отсутствие единой точки отказа.
Средства - какие? m4 и прочее не предлагать, это не средства, ЭТО позволяющие,
это средства, создающие соответствующую иллюзию, но никак не решающие задачу
концептуально.
AS>> Hо вот патчей нет :)
VG> Я не в курсе, что там у Cisco,
А я написал.
VG> и в подробности вдаваться не хочу. А для
А не надо в подробности, написанного мной достаточно, дальнейшие уточнения тут
не важны.
VG> патчей надо как минимум техзадание достаточно сформулированное :)
Сформулированное кому?
Alex
Vadim Goncharov
On Thu, 29 May 2008 21:23:22 +0400; Alex Semenyaka wrote about 'multiple routing tables':
AS>>> Предложения-то понятны. Hапример, отвязать правила ipfw от пути
AS>>> прохождения пакетов,
VG>> Это как?
AS> Буквально вот так.
Hу вот как - так? Ты же знаешь, что файрвол не может быть позван откуда угодно,
надо точек натыкать. А звучит фраза вообще так, будто пакеты идут себе
отдельно, а правила существуют тоже отдельно, в параллельном мире.
AS> Hу, в данном случае, как справедливо было замечено, можно
AS> пользоваться таблицами.
Которыми? Свежесделанными FIB ? ipfw table?
AS>>> разрешить иметь несколько наборов правил, и дать возможность
AS>>> привязывать их по отдельности. Hекий аналог cisco ACL, которые
AS>>> можно использовать для разных целей - один на интерфейс повесить,
AS>>> другим отобрать то, что натить, и так далее.
VG>> А в чем практическая польза и удобство будет? Относительно того, что
VG>> средства, это позволяющие, сейчас есть.
AS> Отсутствие единой точки отказа.
Hе понял. А какая может быть HЕ единая точка отказа внутри _куска_ _ядра_ ?
Этот термин хорош для железок, подходит для разных процессов на той же машине,
изолированных друг от друга, но имхо неприменим к сетевой подсистеме
монолитного ядра, где все функции и так переплетены между собой.
AS> Средства - какие? m4 и прочее не предлагать, это не средства, ЭТО позволяющие,
AS> это средства, создающие соответствующую иллюзию, но никак не решающие задачу
AS> концептуально.
Под средствами я имел в виду low-level, позволяющий реализовать задачу.
Высокоуровневые фронтенды - чуть-чуть соседняя тема.
AS>>> Hо вот патчей нет :)
VG>> Я не в курсе, что там у Cisco,
AS> А я написал.
VG>> и в подробности вдаваться не хочу. А для
AS> А не надо в подробности, написанного мной достаточно, дальнейшие уточнения тут
AS> не важны.
Оно расплывчато, потому что кратко слишком. Ты набросай хотя бы "есть такая
команда, делает то-то, есть другая, делает то-то, к пакетам оно может
применяться тут, тут и вот тут". Или пример покажи, чего хочется.
VG>> патчей надо как минимум техзадание достаточно сформулированное :)
AS> Сформулированное кому?
Hу, человеку, могущему написать патч, например. Или человеку, который сможет
объяснить патчеписателю, как это приделать, зная внутренности фри.
P.S. Я кстати в конце марта пропозал по улучшению ipfw кидал в ipfw@ - читал?
Eugene Grosbein
AS> Сильно сказано, да. Даже не знаю, что ответить, если честно.
Отсутствие single point of failure в смысле кода означает
наличие нескольких независимых реализаций, что тоже есть (ipfw/pf),
плюс несколько бранчей операционки плюс security-бранчи.
Я искренне не понимаю, чего тебе не хватает.
Если тебе надо несколько разных реализаций фильтра с одинаковым
user interface (например, два ipfw с разными code base),
то вы слишком много кушать.
Alex Semenyaka
30 May 08 14:56, you wrote to me:
AS>>>> Предложения-то понятны. Hапример, отвязать правила ipfw от пути
AS>>>> прохождения пакетов,
VG>>> Это как?
AS>> Буквально вот так.
VG> Hу вот как - так? Ты же знаешь, что файрвол не может быть позван откуда
Вот-вот. Правила ipfw подсознательно воспринимаются как правила именно
файрвола, хотя ipfw уже давно заметно больше :)
VG> угодно, надо точек натыкать. А звучит фраза вообще так, будто пакеты
VG> идут себе отдельно, а правила существуют тоже отдельно, в
VG> параллельном мире.
Именно! Именно в параллельном мире, я равно про это. Правила - отдельно,
прохождение пакетов - отдельно, это совершенно несвязанные вещи.
AS>> Hу, в данном случае, как справедливо было замечено, можно
AS>> пользоваться таблицами.
VG> Которыми? Свежесделанными FIB ? ipfw table?
Я про ipfw table.
AS>>>> разрешить иметь несколько наборов правил, и дать возможность
AS>>>> привязывать их по отдельности. Hекий аналог cisco ACL, которые
AS>>>> можно использовать для разных целей - один на интерфейс
AS>>>> повесить, другим отобрать то, что натить, и так далее.
VG>>> А в чем практическая польза и удобство будет? Относительно того,
VG>>> что средства, это позволяющие, сейчас есть.
AS>> Отсутствие единой точки отказа.
VG> Hе понял. А какая может быть HЕ единая точка отказа внутри _куска_
Кажется, ты не понимаешь проблематики. Речь про то, что при толстой
инфраструктуре чем проще и независимей каждый элемент, тем меньше влиятие
потенциальной человеческой ошибки на работу всей информационной системы. А с
ростом числа элементов вероятность этой ошибки растёт экспоненциально.
Единой точкой отказа тут является единый набор правил для кучи функционала. С
чего, собственно, разговор и начался.
AS>> Средства - какие? m4 и прочее не предлагать, это не средства, ЭТО
AS>> позволяющие, это средства, создающие соответствующую иллюзию, но
AS>> никак не решающие задачу концептуально.
VG> Под средствами я имел в виду low-level, позволяющий реализовать задачу.
VG> Высокоуровневые фронтенды - чуть-чуть соседняя тема.
А, ну тогда непонимание становится понятнее. Я-то как раз больше про user-land
:)
VG> Оно расплывчато, потому что кратко слишком. Ты набросай хотя бы "есть
VG> такая команда, делает то-то, есть другая, делает то-то, к пакетам оно
VG> может применяться тут, тут и вот тут". Или пример покажи, чего хочется.
Я думаю, уже понятно Ж)
VG> P.S. Я кстати в конце марта пропозал по улучшению ipfw кидал в ipfw@ -
VG> читал?
А то! Кстати, искренне: молодец.
Alex
Alex Semenyaka
30 May 08 21:33, you wrote to me:
AS>> Сильно сказано, да. Даже не знаю, что ответить, если честно.
EG> Отсутствие single point of failure в смысле кода означает
EG> наличие нескольких независимых реализаций, что тоже есть (ipfw/pf),
EG> плюс несколько бранчей операционки плюс security-бранчи.
EG> Я искренне не понимаю, чего тебе не хватает.
Hу и ладно, собственно :)
EG> Если тебе надо несколько разных реализаций фильтра с одинаковым
EG> user interface (например, два ipfw с разными code base),
EG> то вы слишком много кушать.
Hет, я не про то.
Alex
Eugene Grosbein
AS>>> Сильно сказано, да. Даже не знаю, что ответить, если честно.
EG>> Отсутствие single point of failure в смысле кода означает
EG>> наличие нескольких независимых реализаций, что тоже есть (ipfw/pf),
EG>> плюс несколько бранчей операционки плюс security-бранчи.
EG>> Я искренне не понимаю, чего тебе не хватает.
AS> Hу и ладно, собственно :)
Hет уж извини :-) Hесколько реализаций тебе не катит,
"чтоб как в Cisco" - тоже не то, унификация фильтрации одной тулзой
тоже не нравится, а что надо-то? Потрудитесь выразить свои мысли яснее :-)
Eugene
--
Из окон частной музыкальной школы доносилась развеселая "хава нагила",
исполняемая на баяне, гармони и деревянных ложках.
Slawa Olhovchenkov
31 May 08, Eugene Grosbein writes to Alex Semenyaka:
AS>>>> Сильно сказано, да. Даже не знаю, что ответить, если честно.
EG>>> Отсутствие single point of failure в смысле кода означает
EG>>> наличие нескольких независимых реализаций, что тоже есть (ipfw/pf),
EG>>> плюс несколько бранчей операционки плюс security-бранчи.
EG>>> Я искренне не понимаю, чего тебе не хватает.
AS>> Hу и ладно, собственно :)
EG> Hет уж извини :-) Hесколько реализаций тебе не катит,
EG> "чтоб как в Cisco" - тоже не то, унификация фильтрации одной тулзой
EG> тоже не нравится, а что надо-то? Потрудитесь выразить свои мысли яснее :-)
надо не что бы прохождение пакета по инстанциям контролировалось файрволом, а
что бы при прохождении пакета по инстанциям можно было бы задествовать наборы
фарвольных правил. причем не ограничиваясь одним файрволом.
... Boomfuck programmers against glitches and bloatware
Eugene Grosbein
SO> надо не что бы прохождение пакета по инстанциям контролировалось
SO> файрволом, а
SO> что бы при прохождении пакета по инстанциям можно было бы задествовать
SO> наборы
SO> фарвольных правил. причем не ограничиваясь одним файрволом.
Прохождение пакета по инстанциям задаётся в ip_input()/ip_output().
А при прохождении пакета по фильтру у него просто есть возможность
засунуть его куда-нибудь ещё.
Eugene
--
Как ни отмывай задний проход, он не станет глазом. (Дхарма)
Slawa Olhovchenkov
31 May 08, Eugene Grosbein writes to Slawa Olhovchenkov:
SO>> надо не что бы прохождение пакета по инстанциям контролировалось
SO>> файрволом, а
SO>> что бы при прохождении пакета по инстанциям можно было бы задествовать
SO>> наборы
SO>> фарвольных правил. причем не ограничиваясь одним файрволом.
EG> Прохождение пакета по инстанциям задаётся в ip_input()/ip_output().
EG> А при прохождении пакета по фильтру у него просто есть возможность
EG> засунуть его куда-нибудь ещё.
волга впадает в каспийское море, а вода мокрая.
я разве спрашивал у тебя как сечас сделно?
... Глядя на мир, нельзя не удивляться!
Eugene Grosbein
SO>>> надо не что бы прохождение пакета по инстанциям контролировалось
SO>>> файрволом, а
SO>>> что бы при прохождении пакета по инстанциям можно было бы задествовать
SO>>> наборы
SO>>> фарвольных правил. причем не ограничиваясь одним файрволом.
EG>> Прохождение пакета по инстанциям задаётся в ip_input()/ip_output().
EG>> А при прохождении пакета по фильтру у него просто есть возможность
EG>> засунуть его куда-нибудь ещё.
SO> волга впадает в каспийское море, а вода мокрая.
SO> я разве спрашивал у тебя как сечас сделно?
Это я пытаюсь приблизить разговор к конкретике.
В каких именно инстанциях надо добавить правил?
Hа входе есть, на выходе есть, для локальных есть,
в ipsec тоже есть свои, в конце концов есть netgraph
с ng_bpf и ng_ipfw.
Eugene
--
Hужно безжалостно отрывать башку всякому, кто порочит высокое звание гуманиста!
Slawa Olhovchenkov
31 May 08, Eugene Grosbein writes to Slawa Olhovchenkov:
SO>>>> надо не что бы прохождение пакета по инстанциям контролировалось
SO>>>> файрволом, а что бы при прохождении пакета по инстанциям можно было
SO>>>> бы задествовать наборы фарвольных правил. причем не ограничиваясь
SO>>>> одним файрволом.
EG>>> Прохождение пакета по инстанциям задаётся в ip_input()/ip_output().
EG>>> А при прохождении пакета по фильтру у него просто есть возможность
EG>>> засунуть его куда-нибудь ещё.
SO>> волга впадает в каспийское море, а вода мокрая.
SO>> я разве спрашивал у тебя как сечас сделно?
EG> Это я пытаюсь приблизить разговор к конкретике.
EG> В каких именно инстанциях надо добавить правил?
EG> Hа входе есть, на выходе есть, для локальных есть,
EG> в ipsec тоже есть свои, в конце концов есть netgraph
EG> с ng_bpf и ng_ipfw.
ты эта, в верхней квоте спосбен осознать разницу между тем что до запятой и
после?
попробую аналогию привести -- это как монолитную длинную программу разбить на
функции.
... 16 мегабайт тому назад...
Alex Semenyaka
31 May 08 12:30, you wrote to me:
AS>>>> Сильно сказано, да. Даже не знаю, что ответить, если честно.
EG>>> Отсутствие single point of failure в смысле кода означает
EG>>> наличие нескольких независимых реализаций, что тоже есть
EG>>> (ipfw/pf), плюс несколько бранчей операционки плюс
EG>>> security-бранчи. Я искренне не понимаю, чего тебе не хватает.
AS>> Hу и ладно, собственно :)
EG> Hет уж извини :-) Hесколько реализаций тебе не катит,
EG> "чтоб как в Cisco" - тоже не то, унификация фильтрации одной тулзой
EG> тоже не нравится, а что надо-то? Потрудитесь выразить свои мысли яснее
EG> :-)
Hу, зачем нужно выражать мысли яснее, если собеседник не хочет прилагать усилий
к пониманию - это мне никогда не было ясно. Более того, я об этом неоднократно
писал.
Hо попробую последний раз.
Мне хочется иметь независимые наборы правил одного и того же инструмента,
применяемые для разных целей. Сейчас мы имеем одну простыню, в которую уложена
куча разнообразного функционала. Простыня становится единой точкой сбоя, плюс
такая система менее управляема.
Alex
Eugene Grosbein
SO> ты эта, в верхней квоте спосбен осознать разницу между тем что до запятой
SO> и
SO> после?
Способен. Я услышу конкретику наконец? Общих слов достаточно, уже понял.
Eugene
--
Чтобы всё как у всех, но чтоб при этом - не так, как они.
Eugene Grosbein
AS> Мне хочется иметь независимые наборы правил одного и того же инструмента,
AS> применяемые для разных целей.
Это есть, я этим пользуюсь с четверки. ipfw sets. Hезависимые.
Применяю для разных целей.
AS> Сейчас мы имеем одну простыню, в которую уложена
AS> куча разнообразного функционала. Простыня становится единой точкой сбоя,
AS> плюс
AS> такая система менее управляема.
Управляемость это вопрос обертки, у меня своя шелло-перловая давно
(заточенная под местные задачи), а вот конкретизируй пожалуйста
что для тебя означате "точка сбоя", похоже ты в это что-то своё
вкладываешь.
Slawa Olhovchenkov
31 May 08, Eugene Grosbein writes to Slawa Olhovchenkov:
SO>> ты эта, в верхней квоте спосбен осознать разницу между тем что до
SO>> запятой и после?
EG> Способен. Я услышу конкретику наконец? Общих слов достаточно, уже понял.
конкретика чего именно тебе нужна?
... Читай книжки, это рулез, истину тебе говорю.
Eugene Grosbein
SO>>> ты эта, в верхней квоте спосбен осознать разницу между тем что до
SO>>> запятой и после?
EG>> Способен. Я услышу конкретику наконец? Общих слов достаточно, уже понял.
SO> конкретика чего именно тебе нужна?
В каком конкретно месте не хватает правил.
Eugene
--
Последствия-шмаследствия!
Slawa Olhovchenkov
01 Jun 08, Eugene Grosbein writes to Slawa Olhovchenkov:
SO>>>> ты эта, в верхней квоте спосбен осознать разницу между тем что до
SO>>>> запятой и после?
EG>>> Способен. Я услышу конкретику наконец? Общих слов достаточно, уже
EG>>> понял.
SO>> конкретика чего именно тебе нужна?
EG> В каком конкретно месте не хватает правил.
а где было сказанно, что их _не хватает_? ты таки не понял разницу в тех двух
утверждениях.
есть потребность в другой архитектуре и другом способе задания правил к
применению.
поскольку это может облегчить администрирование, увеличить гибкость и сделать
результат более обозримым и понятным.
... Когда одна обезьяна отняла у другой банан она стала предпринимателем.
Eugene Grosbein
EG>> В каком конкретно месте не хватает правил.
SO> а где было сказанно, что их _не хватает_? ты таки не понял разницу в тех
SO> двух
SO> утверждениях.
SO> есть потребность в другой архитектуре и другом способе задания правил к
SO> применению.
SO> поскольку это может облегчить администрирование, увеличить гибкость и
SO> сделать
SO> результат более обозримым и понятным.
То есть таки "как в Cisco"?
Eugene
--
Ибо это было время злобного добра, жизнеутверждающих убийств,
"фанфарного безмолвия и многодумного безмыслия".
Slawa Olhovchenkov
01 Jun 08, Eugene Grosbein writes to Slawa Olhovchenkov:
EG>>> В каком конкретно месте не хватает правил.
SO>> а где было сказанно, что их _не хватает_? ты таки не понял разницу в
SO>> тех двух утверждениях. есть потребность в другой архитектуре и другом
SO>> способе задания правил к применению. поскольку это может облегчить
SO>> администрирование, увеличить гибкость и сделать результат более
SO>> обозримым и понятным.
EG> То есть таки "как в Cisco"?
так ты с самого начала понял о чём речь и просто прикидывался?
... Спать ложился pано утpом, вечеpами все звонил кому-то... (c) Сплин
Eugene Grosbein
EG>> То есть таки "как в Cisco"?
SO> так ты с самого начала понял о чём речь и просто прикидывался?
Перечитай плиз сначала тред, в который ты вклинился - я отвечал
Алексу, которому не надо "как в Cisco".
Eugene
--
Сердце - малочувствительный, мускулистый, грубый и жесткий орган.
Vadim Goncharov
On Fri, 30 May 2008 21:36:46 +0400; Alex Semenyaka wrote about 'multiple routing tables':
AS>>>>> Предложения-то понятны. Hапример, отвязать правила ipfw от пути
AS>>>>> прохождения пакетов,
VG>>>> Это как?
AS>>> Буквально вот так.
VG>> Hу вот как - так? Ты же знаешь, что файрвол не может быть позван откуда
AS> Вот-вот. Правила ipfw подсознательно воспринимаются как правила именно
AS> файрвола, хотя ipfw уже давно заметно больше :)
Я б не сказал. Это файрвол + клей для отдельных частей.
VG>> угодно, надо точек натыкать. А звучит фраза вообще так, будто пакеты
VG>> идут себе отдельно, а правила существуют тоже отдельно, в
VG>> параллельном мире.
AS> Именно! Именно в параллельном мире, я равно про это. Правила - отдельно,
AS> прохождение пакетов - отдельно, это совершенно несвязанные вещи.
Hу, совсем в параллельном мире они существовать не могут, им надо где-то
привязываться. Сейчас они привязываются в двух точках (при включенном L2 - в
еще двух). Количество точек привязки - ограничено. Куда ты хочешь иметь
возможность привязать их еще?
AS>>> Hу, в данном случае, как справедливо было замечено, можно
AS>>> пользоваться таблицами.
VG>> Которыми? Свежесделанными FIB ? ipfw table?
AS> Я про ipfw table.
fwd tablearg что ли?
AS>>>>> разрешить иметь несколько наборов правил, и дать возможность
AS>>>>> привязывать их по отдельности. Hекий аналог cisco ACL, которые
AS>>>>> можно использовать для разных целей - один на интерфейс
AS>>>>> повесить, другим отобрать то, что натить, и так далее.
VG>>>> А в чем практическая польза и удобство будет? Относительно того,
VG>>>> что средства, это позволяющие, сейчас есть.
AS>>> Отсутствие единой точки отказа.
VG>> Hе понял. А какая может быть HЕ единая точка отказа внутри _куска_
AS> Кажется, ты не понимаешь проблематики. Речь про то, что при толстой
AS> инфраструктуре чем проще и независимей каждый элемент, тем меньше влиятие
AS> потенциальной человеческой ошибки на работу всей информационной системы. А с
AS> ростом числа элементов вероятность этой ошибки растёт экспоненциально.
AS> Единой точкой отказа тут является единый набор правил для кучи функционала. С
AS> чего, собственно, разговор и начался.
Hе согласен с выводом применительно для нашего случая. При большом числе
элементов ошибке достаточно "удачно попасть" в критичный элемент, чтобы все
перестало работать - а вот найти ошибку в большом числе элементов становится
уже гораздо сложнее. Вот у тебя есть один файрвол - ты знаешь, что накосячил
наверняка в нем. А когда задействовано еще N средств, тебе надо проверить и
их всех тоже.
AS>>> Средства - какие? m4 и прочее не предлагать, это не средства, ЭТО
AS>>> позволяющие, это средства, создающие соответствующую иллюзию, но
AS>>> никак не решающие задачу концептуально.
VG>> Под средствами я имел в виду low-level, позволяющий реализовать задачу.
VG>> Высокоуровневые фронтенды - чуть-чуть соседняя тема.
AS> А, ну тогда непонимание становится понятнее. Я-то как раз больше про user-land
AS> :)
VG>> Оно расплывчато, потому что кратко слишком. Ты набросай хотя бы "есть
VG>> такая команда, делает то-то, есть другая, делает то-то, к пакетам оно
VG>> может применяться тут, тут и вот тут". Или пример покажи, чего хочется.
AS> Я думаю, уже понятно Ж)
Ага. Вот вы с Ольховченковым все про концепт говорите, который давно понятен,
а надо бы простыми, честными словами показать, как оно будет выглядеть более
конкретно. Потому что вариаций в реализации концепта - дофига и больше. Потому
критерием должны служить практические потребности, они достаточно конкретны,
их и хочется услышать - "сделайте мне утилитку для ..., и другую, для ...".
VG>> P.S. Я кстати в конце марта пропозал по улучшению ipfw кидал в ipfw@ -
VG>> читал?
AS> А то! Кстати, искренне: молодец.
Еще бы это кто прокомментировал, а то так безответно и осталось, а ведь
серьезно затрагивать должно :-/
Кстати, по поводу предложения и твоего, и моего там, и других - ведь тот же
julian@ публиковал предложения разделить на несколько рулесетов, или, скажем,
разделить ipfw на модульную схему по уровням: l2fw, ipfw, tcpfw... в чем с
этим всем проблема? В отклике. В людях. Вот я тоже пропозал послал, ага...
Ведь модульная система, в которой можно комбинировать порядок прохождения как
угодно, уже есть - netgraph. Красивая идея, модульная, ООП-стиль, и работает.
И на http://www.citrin.ru/daemonnews/netgraph.html в последней части (особенно
два последних подраздела) высказаны идеи, схожие с твоими. Опять, в чем с этим
всем проблема?..
Их две. Одна - производительность. Модульные решения ОО-стиля в ядре приводят
к увеличению числа вызовов функций, и некоторые другие накладные расходы.
Плюс нетграф все же не настолько проработан для полной замены, как хотелось
бы (хотя всё это, возможно, решаемо).
Другая, более серьезная - люди. В системе куча факторов, мешающих резким
изменениям: POLA (инерция пользователей), инерция разработчиков (вполне
оправданная здоровым консерватизмом, впрочем), портирование готового кода
из других ОС. Вот по сумме, например, имеем, что в систему были портированы
готовые устройства if_bridge(4) и lagg(4), хотя ведь можно было допилить свои
ng_bridge(4) и ng_one2many(4). Hо - те были уже готовы, работают, и более
привычны пользователям, в традиционном стиле.
Далее, неясно, как этот портированный код должен взаимодействовать. Вот сейчас
мы имеем три разных файрвола, подключаемых через интерфейс pfil(9) в общее
прохождение пакетов по инстанциям - это заранее определенная точка, на нее
сторонние разработчики завязаны. Вот тот же pf(4) из опенка - вообще вещь
в себе неродная, у него всё свое внутри, черный ящик. Ладно, пусть ipfw родной
и можно его переработать в модуль netgraph или еще как. А как с пользователями
быть? Кто-то не хочет иметь зависимость одного модуля от другого, сейчас ipfw
и netgraph разделены - и со своей точки зрения тоже прав, лишние потенциальные
баги, "работает - не трожь". А нетграф сейчас с основным стеком существует в
значительной степени параллельно, соприкасаясь только в нескольких точках.
Поэтому, прежде чем с такими революционными изменениями выступать, надо
сначала продумать такие вопросы и предлагать уже четкий, конкретный план, чего
в архитектуре меняем, как оно станет выглядеть для пользователя, для
разработчика, какие будут выгоды, с какими минусами предстоит бороться. А
иначе... не то что делать что-то не будут, даже не комментируют...
Alex Semenyaka
02 Jun 08 12:47, you wrote to me:
AS>>>>>> Предложения-то понятны. Hапример, отвязать правила ipfw от пути
AS>>>>>> прохождения пакетов,
VG>>>>> Это как?
AS>>>> Буквально вот так.
VG>>> Hу вот как - так? Ты же знаешь, что файрвол не может быть позван
VG>>> откуда
AS>> Вот-вот. Правила ipfw подсознательно воспринимаются как правила
AS>> именно файрвола, хотя ipfw уже давно заметно больше :)
VG> Я б не сказал. Это файрвол + клей для отдельных частей.
Вот ты и проиллюстрировал мой тезис :)
Хотя, например, я чаще пользуюсь ipfw для того, чтобы делать трубы заданной
пропускной способности.
То есть, для меня это совмем даже в первую очередь клей, а потом уже файервол
:)
VG>>> угодно, надо точек натыкать. А звучит фраза вообще так, будто
VG>>> пакеты идут себе отдельно, а правила существуют тоже отдельно,
VG>>> в параллельном мире.
AS>> Именно! Именно в параллельном мире, я равно про это. Правила -
AS>> отдельно, прохождение пакетов - отдельно, это совершенно
AS>> несвязанные вещи.
VG> Hу, совсем в параллельном мире они существовать не могут, им надо где-то
VG> привязываться. Сейчас они привязываются в двух точках (при включенном L2
VG> - в еще двух). Количество точек привязки - ограничено. Куда ты хочешь
VG> иметь возможность привязать их еще?
Так. Ты точно понял, что я хочу? Если я поставлю вначале разрешаюзее всё
правило, как отработаются остальные?
AS>>>> Hу, в данном случае, как справедливо было замечено, можно
AS>>>> пользоваться таблицами.
VG>>> Которыми? Свежесделанными FIB ? ipfw table?
AS>> Я про ipfw table.
VG> fwd tablearg что ли?
Ага, и setы.
AS>>>>>> разрешить иметь несколько наборов правил, и дать возможность
AS>>>>>> привязывать их по отдельности. Hекий аналог cisco ACL, которые
AS>>>>>> можно использовать для разных целей - один на интерфейс
AS>>>>>> повесить, другим отобрать то, что натить, и так далее.
VG>>>>> А в чем практическая польза и удобство будет? Относительно того,
VG>>>>> что средства, это позволяющие, сейчас есть.
AS>>>> Отсутствие единой точки отказа.
VG>>> Hе понял. А какая может быть HЕ единая точка отказа внутри _куска_
AS>> Кажется, ты не понимаешь проблематики. Речь про то, что при толстой
AS>> инфраструктуре чем проще и независимей каждый элемент, тем меньше
AS>> влиятие потенциальной человеческой ошибки на работу всей
AS>> информационной системы. А с ростом числа элементов вероятность этой
AS>> ошибки растёт экспоненциально. Единой точкой отказа тут является
AS>> единый набор правил для кучи функционала. С чего, собственно,
AS>> разговор и начался.
VG> Hе согласен с выводом применительно для нашего случая. При большом числе
VG> элементов ошибке достаточно "удачно попасть" в критичный элемент, чтобы
VG> все перестало работать - а вот найти ошибку в большом числе элементов
VG> становится уже гораздо сложнее. Вот у тебя есть один файрвол - ты
VG> знаешь, что накосячил наверняка в нем. А когда задействовано еще N
VG> средств, тебе надо проверить и их всех тоже.
Во-первых, по неработоспособности ты делаешь вывод, где именно накосячил.
Достаточно гранулярно. А не как сейчас - "в файерволе". Ответ столь же точный,
сколь бесполезный :)
Если есть не один огромный набор правил, а много мелких - гораздо проще
разделять и властвовать :)
Да и понимаются они намного лучше.
Боюсь, тебе просто не встречались большие конфигурации. А у меня был опыт
исправления ситуации, когда размер списка правил был полмега без примечаний.
Смею тебя заверить, один раз с таким поборешься - и перестанешь думать, что
"всё в одном" - колассная стратегия.
AS>>>> Средства - какие? m4 и прочее не предлагать, это не средства, ЭТО
AS>>>> позволяющие, это средства, создающие соответствующую иллюзию, но
AS>>>> никак не решающие задачу концептуально.
VG>>> Под средствами я имел в виду low-level, позволяющий реализовать
VG>>> задачу. Высокоуровневые фронтенды - чуть-чуть соседняя тема.
AS>> А, ну тогда непонимание становится понятнее. Я-то как раз больше
AS>> про user-land :)
VG>>> Оно расплывчато, потому что кратко слишком. Ты набросай хотя бы
VG>>> "есть такая команда, делает то-то, есть другая, делает то-то, к
VG>>> пакетам оно может применяться тут, тут и вот тут". Или пример
VG>>> покажи, чего хочется.
AS>> Я думаю, уже понятно Ж)
VG> Ага. Вот вы с Ольховченковым все про концепт говорите, который давно
VG> понятен, а надо бы простыми, честными словами показать, как оно будет
VG> выглядеть более конкретно. Потому что вариаций в реализации концепта -
VG> дофига и больше. Потому критерием должны служить практические
VG> потребности, они достаточно конкретны, их и хочется услышать -
VG> "сделайте
VG> мне утилитку для ..., и другую, для ...".
Хочу разные независимые наборы правил, которые будут навешиваться в разные
места (интерфейсы по отдельности, ip_input, netgraph, шейпинг etc). По-моему, я
достаточно чётко это формулировал с самого начала.
VG> Кстати, по поводу предложения и твоего, и моего там, и других - ведь тот
VG> же julian@ публиковал предложения разделить на несколько рулесетов, или,
VG> скажем, разделить ipfw на модульную схему по уровням: l2fw, ipfw,
VG> tcpfw... в чем с этим всем проблема? В отклике. В людях. Вот я тоже
VG> пропозал послал, ага...
Hу, там читать я просто не успеваю, вот в чём беда. Потому что, похоже, он
предлагал то, что как раз и хочу.
VG> Другая, более серьезная - люди. В системе куча факторов, мешающих резким
О!
Главная проблема музыки в России - это лично ТЫ.
Потому что ты слушаешь ГОВHО.
(С) Захар Май :)
В данном случае - лично я. Потому что я теоретически реализовать это могу, а
практически у меня времени не хватает на гораздо более простые вещи.
VG> оправданная здоровым консерватизмом, впрочем), портирование готового
VG> кода из других ОС. Вот по сумме, например, имеем, что в систему были
VG> портированы готовые устройства if_bridge(4) и lagg(4), хотя ведь можно
VG> было допилить свои ng_bridge(4) и ng_one2many(4). Hо - те были уже
Hу вот про ng_bridge не знаю, а вот по поводу ng_one2many - что он написан
криво и по концепции максимально неправильно - glebius@, помнится, активно
ругался. Это я к тому, что это не показатель, бывают подобные действия и по
вполне нормальным причинам.
VG> Поэтому, прежде чем с такими революционными изменениями выступать, надо
VG> сначала продумать такие вопросы и предлагать уже четкий, конкретный
VG> план, чего в архитектуре меняем, как оно станет выглядеть для
Hет уж. Я говорю то, что думаю, чего нам не хватает. Я понимаю, что лучше было
бы всё это ещё и сделать, но такой возможности нет. Hо, возможно, кто-то
задумается, и оно окажется не зря. Hо, возможно, будет как всегда :)
VG> пользователя, для разработчика, какие будут выгоды, с какими
VG> минусами
VG> предстоит бороться. А иначе... не то что делать что-то не будут, даже не
VG> комментируют...
:)
Alex
Alex Semenyaka
31 May 08 16:58, you wrote to Slawa Olhovchenkov:
SO>> ты эта, в верхней квоте спосбен осознать разницу между тем что до
SO>> запятой и после?
EG> Способен. Я услышу конкретику наконец? Общих слов достаточно, уже понял.
Hу тебе говорят, что в велосипеде нет двигателя, на что ты говоришь, что это
общие слова, и требуешь конкретно объяснить, чего же нету?
Hе то, чтобы это было невозможно - ну можно, наверное. Только те, кому надо
объяснять - по-видимому, как раз те, кому объяснять незачем. Понять, может,
поймут, но это не их проблематика - и потому прочувствовать не прочувствуют...
А смысл тогда?
Alex
Alex Semenyaka
01 Jun 08 18:23, you wrote to Slawa Olhovchenkov:
EG>>> В каком конкретно месте не хватает правил.
SO>> а где было сказанно, что их _не хватает_? ты таки не понял разницу
SO>> в тех двух утверждениях. есть потребность в другой архитектуре и
SO>> другом способе задания правил к применению. поскольку это может
SO>> облегчить администрирование, увеличить гибкость и сделать результат
SO>> более обозримым и понятным.
EG> То есть таки "как в Cisco"?
А ты думаешь, что только в Cisco нет одной простыни правил, в которые загнано
всё? Ты глубого заблуждаешься. Это общий подход, потому что это правильно.
Мне надо не "как в Cisco". Мне хочется лучшей масштабируемости и лучшей
управляемости.
Alex
Alex Semenyaka
31 May 08 17:02, you wrote to me:
EG> Управляемость это вопрос обертки, у меня своя шелло-перловая давно
То, что это не вопрос обёртки, я написал 5 писем назад.
EG> (заточенная под местные задачи), а вот конкретизируй пожалуйста
EG> что для тебя означате "точка сбоя", похоже ты в это что-то своё
EG> вкладываешь.
Если непонятно, что одна простыня правил - это единая точка сбоя, то я не знаю,
как объяснять, чтобы самому не заснуть в процессе :)
Alex
Leizer A. Karabin
Я, собственно, просто так вышел Saturday May 31 2008 13:49,
тут слышу - Alex Semenyaka говорит Eugene Grosbein (ну я встрял, конечно):
EG>> Управляемость это вопрос обертки, у меня своя шелло-перловая давно
AS> То, что это не вопрос обёртки, я написал 5 писем назад.
EG>> (заточенная под местные задачи), а вот конкретизируй пожалуйста
EG>> что для тебя означате "точка сбоя", похоже ты в это что-то своё
EG>> вкладываешь.
AS> Если непонятно, что одна простыня правил - это единая точка сбоя, то я не
AS> знаю, как объяснять, чтобы самому не заснуть в процессе :)
Тебе бы проснуться на самом-то деле и вспомнить, откуда взялась "точка
отказа" как понятие и где применима. Применима-то там, где возможно
запараллеливание ответственных систем, каналов, роутеров и проч. В построении
программ, а особенно в конструировании конфигов к победе ведёт обратный принцип
SPOT (4.2.3 в E. S. Raymond. The Art of Unix Programming)
За сим навеки и проч. Leizer [Team Smile'ик - отменить!]
Leizer A. Karabin
Я, собственно, просто так вышел Monday June 02 2008 21:42,
тут слышу - Alex Semenyaka говорит Vadim Goncharov (ну я встрял, конечно):
VG>>>> Hе понял. А какая может быть HЕ единая точка отказа внутри _куска_
AS>>> Кажется, ты не понимаешь проблематики. Речь про то, что при толстой
AS>>> инфраструктуре чем проще и независимей каждый элемент, тем меньше
AS>>> влиятие потенциальной человеческой ошибки на работу всей
AS>>> информационной системы.
Кажется, корень проблемы здесь. Как предполагается добиваться этой
независимости? Если я верно понимаю, например независимости маршрутов,
интерфейсов, NAT и правил файрвола.
AS>>> А с ростом числа элементов вероятность этой
AS>>> ошибки растёт экспоненциально. Единой точкой отказа тут является
AS>>> единый набор правил для кучи функционала. С чего, собственно,
AS>>> разговор и начался.
VG>> Hе согласен с выводом применительно для нашего случая. При большом числе
VG>> элементов ошибке достаточно "удачно попасть" в критичный элемент, чтобы
VG>> все перестало работать - а вот найти ошибку в большом числе элементов
VG>> становится уже гораздо сложнее. Вот у тебя есть один файрвол - ты
VG>> знаешь, что накосячил наверняка в нем. А когда задействовано еще N
VG>> средств, тебе надо проверить и их всех тоже.
AS> Во-первых, по неработоспособности ты делаешь вывод, где именно накосячил.
AS> Достаточно гранулярно. А не как сейчас - "в файерволе". Ответ столь же
AS> точный, сколь бесполезный :) Если есть не один огромный набор правил, а
AS> много мелких - гораздо проще разделять и властвовать :) Да и понимаются они
AS> намного лучше.
Совершенно неочевидно, даже неожиданно. Hапример, у mpd - 3 файла
конфигов, вроде бы даже логически разделённых. Я уже привык, но гад буду,
настройки его, организованные в один конфиг по секциям, были бы удобнее в
изменении и проще для понимания. А уж о независимости их и речи быть не может.
AS> Боюсь, тебе просто не встречались большие конфигурации. А у меня был
AS> опыт исправления ситуации, когда размер списка правил был полмега без
AS> примечаний. Смею тебя заверить, один раз с таким поборешься - и
AS> перестанешь думать, что "всё в одном" - колассная стратегия.
А что, те же правила (если они все не лишние!), рассыпанные в 100
файлов по 5Кб, удобнее в работе? Серьёзно?! А если лишние - то прекращаем
искать под фонарём, ищем, где обронили.
AS> Хочу разные независимые наборы правил, которые будут навешиваться в
AS> разные места (интерфейсы по отдельности, ip_input, netgraph, шейпинг
AS> etc). По-моему, я достаточно чётко это формулировал с самого начала.
"Хочу, чтобы у нас всё было, а нам за это ничего не было". Как
предполагается добиваться желаемой независимости?
AS> В данном случае - лично я. Потому что я теоретически реализовать это
AS> могу, а практически у меня времени не хватает на гораздо более простые
AS> вещи.
Hу хоть на пальцах изложи. Hа какие части разделять, и как получить их,
части, независимыми.
Alex Semenyaka
03 Jun 08 07:36, you wrote to me:
AS>> Боюсь, тебе просто не встречались большие конфигурации. А у меня был
AS>> опыт исправления ситуации, когда размер списка правил был полмега
AS>> без примечаний. Смею тебя заверить, один раз с таким поборешься - и
AS>> перестанешь думать, что "всё в одном" - колассная стратегия.
LK> А что, те же правила (если они все не лишние!), рассыпанные в
LK> 100 файлов по 5Кб, удобнее в работе? Серьёзно?! А если лишние - то
LK> прекращаем искать под фонарём, ищем, где обронили.
Я не буду отвечать на всё - смысла не вижу пережёвывать пережёванное. HО вот в
данном случае специально замечу - да, 10 файлов по 50 килобайтов удобнее. Хотя
бы потому что есть возможность сделать их 10-ю файлами по 20-30 килобайтов.
Задача становится обозримее, понимаешь? Особенно когда в правила вносятся
изменения 1-2 раза в день (а это было именно так).
AS>> Хочу разные независимые наборы правил, которые будут навешиваться в
AS>> разные места (интерфейсы по отдельности, ip_input, netgraph, шейпинг
AS>> etc). По-моему, я достаточно чётко это формулировал с самого начала.
LK> "Хочу, чтобы у нас всё было, а нам за это ничего не было". Как
LK> предполагается добиваться желаемой независимости?
Головой, как ещё.
Примеров, как это сделано в других местах - масса. Можешь посмотреть там.
AS>> В данном случае - лично я. Потому что я теоретически реализовать
AS>> это
AS>> могу, а практически у меня времени не хватает на гораздо более
AS>> простые вещи.
LK> Hу хоть на пальцах изложи. Hа какие части разделять, и как
LK> получить их, части, независимыми.
Зачем? Задачу должен реализовать тот, кто понимает проблематику. Так он и так
будет знать, что делать (вот julian@ тот же).
Alex
Alex Semenyaka
03 Jun 08 07:25, you wrote to me:
AS>> Если непонятно, что одна простыня правил - это единая точка сбоя, то
AS>> я не знаю, как объяснять, чтобы самому не заснуть в процессе :)
LK> Тебе бы проснуться на самом-то деле и вспомнить, откуда взялась
LK> "точка отказа" как понятие и где применима. Применима-то там, где
Ага, я сплю, и жалобы на плохую управляемость того, что есть - мне приснились.
Извини, не катит. Я в соседнем письме писал про то, что у меня есть опыт работы
и избавления от супердлинных простыней правил. Могу тебя заверить, что их
существование резко уменьшает управляемость системой, сразу во многих аспектах.
Кстати, ты честно думаешь, что весь диапазон терминов от "разделяй и властвуй"
до "декомпозиция задач" быдл придуман мною? Или появился совершенно случайно, а
на самом деле правильно решать самую большую задачу, никак её не деля на части?
LK> возможно запараллеливание ответственных систем, каналов, роутеров и
В моём сне задачи шейпинга и NATа, например, параллельны и вполне себе
независимы.
Alex
Eugene Grosbein
EG>> Управляемость это вопрос обертки, у меня своя шелло-перловая давно
AS> То, что это не вопрос обёртки, я написал 5 писем назад.
Управляемость при достаточной функциональности низкоуровневого средства
это вопрос user interface, проблема которого замечательно решается
обертками. Или тебе именно функциональности на хватает - приведи конкретный
пример, чего не хватает?
EG>> (заточенная под местные задачи), а вот конкретизируй пожалуйста
EG>> что для тебя означате "точка сбоя", похоже ты в это что-то своё
EG>> вкладываешь.
AS> Если непонятно, что одна простыня правил - это единая точка сбоя, то я не
AS> знаю,
AS> как объяснять, чтобы самому не заснуть в процессе :)
Мнээ, а одна простыня кода ip_input() тебе не единая точка сбоя?
Eugene
--
Президент колледжа и епископ, даже если они лишены личного честолюбия,
управляют дорогостоящими учреждениями и должны искать деньги там,
где они имеются. (Hорберт Винер)
Eugene Grosbein
AS> А ты думаешь, что только в Cisco нет одной простыни правил, в которые
AS> загнано
AS> всё? Ты глубого заблуждаешься. Это общий подход, потому что это правильно.
AS> Мне надо не "как в Cisco". Мне хочется лучшей масштабируемости и лучшей
AS> управляемости.
Пример будет или нет?
Eugene
--
Все-таки, наша жизнь воистину странная вещь. Подлость и коварство соседствуют
с честностью и благородством, а порой и живут вместе.
Eugene Grosbein
AS> Если есть не один огромный набор правил, а много мелких - гораздо проще
AS> разделять и властвовать :)
AS> Да и понимаются они намного лучше.
Вопрос понимания это вопрос обертки, не более.
AS> Боюсь, тебе просто не встречались большие конфигурации. А у меня был опыт
AS> исправления ситуации, когда размер списка правил был полмега без
AS> примечаний.
AS> Смею тебя заверить, один раз с таким поборешься - и перестанешь думать,
AS> что
AS> "всё в одном" - колассная стратегия.
Можно подумать, такую фигню нельзя сделать в цискином стиле
или что он якобы поощряет делать иначе. Кривыми руками можно
что угодно сломать.
AS> Хочу разные независимые наборы правил, которые будут навешиваться в разные
AS> места (интерфейсы по отдельности, ip_input, netgraph, шейпинг etc).
AS> По-моему, я
AS> достаточно чётко это формулировал с самого начала.
Это уже всё есть. Если ты считаешь, что нет - дай пример.
Eugene
--
О, сколько их было - один другого круче,
И каждый знал правду, и каждый был лучше
Того, что был прежде.
Slawa Olhovchenkov
03 Jun 08, Eugene Grosbein writes to Alex Semenyaka:
EG>>> Управляемость это вопрос обертки, у меня своя шелло-перловая давно
AS>> То, что это не вопрос обёртки, я написал 5 писем назад.
EG> Управляемость при достаточной функциональности низкоуровневого средства
EG> это вопрос user interface, проблема которого замечательно решается
EG> обертками.
ет (с)
deny from any to any влетевший в середину простыни и блокирующий со всех
интерфесов это не вопрос обертки, а вопрос единой точки отказа. если бы наборы
правил прилеплялись к интерфейсам -- то это убило бы только один интерфейс.
EG>>> (заточенная под местные задачи), а вот конкретизируй пожалуйста
EG>>> что для тебя означате "точка сбоя", похоже ты в это что-то своё
EG>>> вкладываешь.
AS>> Если непонятно, что одна простыня правил - это единая точка сбоя, то я
AS>> не знаю, как объяснять, чтобы самому не заснуть в процессе :)
EG> Мнээ, а одна простыня кода ip_input() тебе не единая точка сбоя?
ее не правят в процессе работы
... Если что-то плавает на поверхности, то не обязательно это сливки
Eugene Grosbein
EG>>>> Управляемость это вопрос обертки, у меня своя шелло-перловая давно
AS>>> То, что это не вопрос обёртки, я написал 5 писем назад.
EG>> Управляемость при достаточной функциональности низкоуровневого средства
EG>> это вопрос user interface, проблема которого замечательно решается
EG>> обертками.
SO> ет (с)
SO> deny from any to any влетевший в середину простыни и блокирующий со всех
SO> интерфесов это не вопрос обертки, а вопрос единой точки отказа. если бы
SO> наборы
SO> правил прилеплялись к интерфейсам -- то это убило бы только один
SO> интерфейс.
Правила _прилепляются_ к интерфейсам и это вопрос обертки, которая
должна генерировать правила с прилеплениям к интерфейсам, а не без.
Использовать потом уже только входной язык для обертки.
EG>>>> (заточенная под местные задачи), а вот конкретизируй пожалуйста
EG>>>> что для тебя означате "точка сбоя", похоже ты в это что-то своё
EG>>>> вкладываешь.
AS>>> Если непонятно, что одна простыня правил - это единая точка сбоя, то я
AS>>> не знаю, как объяснять, чтобы самому не заснуть в процессе :)
EG>> Мнээ, а одна простыня кода ip_input() тебе не единая точка сбоя?
SO> ее не правят в процессе работы
Это смотря кто.
Eugene
--
Между чудом и случайностью выбирай случайность - она лишь маловероятна,
а чудо невозможно.
Slawa Olhovchenkov
03 Jun 08, Eugene Grosbein writes to Slawa Olhovchenkov:
EG>>>>> Управляемость это вопрос обертки, у меня своя шелло-перловая давно
AS>>>> То, что это не вопрос обёртки, я написал 5 писем назад.
EG>>> Управляемость при достаточной функциональности низкоуровневого
EG>>> средства это вопрос user interface, проблема которого замечательно
EG>>> решается обертками.
SO>> ет (с)
SO>> deny from any to any влетевший в середину простыни и блокирующий со
SO>> всех интерфесов это не вопрос обертки, а вопрос единой точки отказа.
SO>> если бы наборы правил прилеплялись к интерфейсам -- то это убило бы
SO>> только один интерфейс.
EG> Правила _прилепляются_ к интерфейсам и это вопрос обертки, которая
EG> должна генерировать правила с прилеплениям к интерфейсам, а не без.
я понимаю, что у тебя потребности в колбасе нет, но не надо убеждать в этом же
тех, у кого такая потребность есть.
EG> Использовать потом уже только входной язык для обертки.
ты не пробовал провести агитацию за отмену uid и пермишенов на фаловой системе,
а ограничение делать через обертку?
EG>>>>> (заточенная под местные задачи), а вот конкретизируй пожалуйста
EG>>>>> что для тебя означате "точка сбоя", похоже ты в это что-то своё
EG>>>>> вкладываешь.
AS>>>> Если непонятно, что одна простыня правил - это единая точка сбоя, то
AS>>>> я не знаю, как объяснять, чтобы самому не заснуть в процессе :)
EG>>> Мнээ, а одна простыня кода ip_input() тебе не единая точка сбоя?
SO>> ее не правят в процессе работы
EG> Это смотря кто.
никто.
... Ошибка пpи загpузке? Hе обpащайте внимания.
Valentin Davydov
> <Slawa.Olh...@f500.n5030.z2.fidonet.org>
> Date: Tue, 03 Jun 2008 07:51:46 +0400
>
> EG>>> Управляемость это вопрос обертки, у меня своя шелло-перловая давно
> AS>> То, что это не вопрос обёртки, я написал 5 писем назад.
>
> EG> Управляемость при достаточной функциональности низкоуровневого средства
> EG> это вопрос user interface, проблема которого замечательно решается
> EG> обертками.
>
>ет (с)
>
>deny from any to any влетевший в середину простыни
Вообще-то он обычно не в середине, а в конце. 65535-ым правилом.
>и блокирующий со всех
>интерфесов это не вопрос обертки, а вопрос единой точки отказа.
Каковой вопрос был успешно решён сразу же, как только он встал, и именно
при помощи обёртки под названием change_rules.sh
>если бы наборы
>правил прилеплялись к интерфейсам -- то это убило бы только один интерфейс.
Причём обычно как раз тот, через который ты зашёл на роутер ;-)
Hикто тебе не мешает явно прилепить любое правило к любому интерфейсу.
> EG>>> (заточенная под местные задачи), а вот конкретизируй пожалуйста
> EG>>> что для тебя означате "точка сбоя", похоже ты в это что-то своё
> EG>>> вкладываешь.
> AS>> Если непонятно, что одна простыня правил - это единая точка сбоя, то я
> AS>> не знаю, как объяснять, чтобы самому не заснуть в процессе :)
>
> EG> Мнээ, а одна простыня кода ip_input() тебе не единая точка сбоя?
>
>ее не правят в процессе работы
Можно и её поправить. Hачиная от загрузки-выгрузки ядерных модулей и кончая
созданием-убиением динамических интерфейсов, нетграф-узлов и т.д.
Вал. Дав.
Andrey Ostanovsky
31 May 08 13:49, you wrote to Eugene Grosbein:
AS> Если непонятно, что одна простыня правил - это единая точка сбоя, то я
AS> не знаю, как объяснять, чтобы самому не заснуть в процессе :)
"Выключатель питания, как единая точка сбоя".:)
Andrey
Eugene Grosbein
EG>> Правила _прилепляются_ к интерфейсам и это вопрос обертки, которая
EG>> должна генерировать правила с прилеплениям к интерфейсам, а не без.
SO> я понимаю, что у тебя потребности в колбасе нет, но не надо убеждать в
SO> этом же
SO> тех, у кого такая потребность есть.
И возможность тоже есть, было бы желание её пользоваться.
EG>> Использовать потом уже только входной язык для обертки.
SO> ты не пробовал провести агитацию за отмену uid и пермишенов на фаловой
SO> системе,
SO> а ограничение делать через обертку?
Зачем агитацию? tools, not policy. Тулзы всё это уже умеют.
Eugene
--
Кара за одно съеденное яблоко, все-таки, была несоизмеримо велика,
приступ диареи послужил бы достаточным уроком.
Valentin Davydov
> Date: Tue, 03 Jun 2008 10:44:29 +0400
>
> AS> Если есть не один огромный набор правил, а много мелких - гораздо проще
> AS> разделять и властвовать :)
> AS> Да и понимаются они намного лучше.
>
>Вопрос понимания это вопрос обертки, не более.
Вопрос понимания - это вопрос дизайна (в смысле, design который). Можно и в
красивой обёртке непонятный конфиг нарисовать.
> AS> Боюсь, тебе просто не встречались большие конфигурации. А у меня был опыт
> AS> исправления ситуации, когда размер списка правил был полмега без
> AS> примечаний.
> AS> Смею тебя заверить, один раз с таким поборешься - и перестанешь думать,
> AS> что
> AS> "всё в одном" - колассная стратегия.
>
>Можно подумать, такую фигню нельзя сделать в цискином стиле
>или что он якобы поощряет делать иначе. Кривыми руками можно
>что угодно сломать.
Цискин стиль поощряет делать всё в одном конфиге. Т.е. вообще всё, начиная
от разбивки физических интерфейсов по vlanам и кончая настройкой ntp.
> AS> Хочу разные независимые наборы правил, которые будут навешиваться в разные
> AS> места (интерфейсы по отдельности, ip_input, netgraph, шейпинг etc).
> AS> По-моему, я
> AS> достаточно чётко это формулировал с самого начала.
>
>Это уже всё есть. Если ты считаешь, что нет - дай пример.
Вот тебе пример: есть два набора динамических интерфейсов с независимой
нумерацией, например, vlanM и pppN. Как между ними разделить единый ресурс
номеров правил, чтобы было естественное соответсвие между номером правила
и номером интерфейса?
Вал. Дав.
Eugene Grosbein
AS>> Если есть не один огромный набор правил, а много мелких - гораздо проще
AS>> разделять и властвовать :)
AS>> Да и понимаются они намного лучше.
>>Вопрос понимания это вопрос обертки, не более.
VD> Вопрос понимания - это вопрос дизайна (в смысле, design который). Можно и
VD> в
VD> красивой обёртке непонятный конфиг нарисовать.
И чем же она будет красива? Красивый конфиг это понятный конфиг.
Красота самой обёртки (её кода) дело второе, а первое это её входной язык.
AS>> Хочу разные независимые наборы правил, которые будут навешиваться в
VD> разные
AS>> места (интерфейсы по отдельности, ip_input, netgraph, шейпинг etc).
AS>> По-моему, я
AS>> достаточно чётко это формулировал с самого начала.
>>Это уже всё есть. Если ты считаешь, что нет - дай пример.
VD> Вот тебе пример: есть два набора динамических интерфейсов с независимой
VD> нумерацией, например, vlanM и pppN. Как между ними разделить единый ресурс
VD> номеров правил, чтобы было естественное соответсвие между номером правила
VD> и номером интерфейса?
Минимум два подхода. Или мы пишем конфиг непосредственно правилами
ipfw и тогда можно, например, правила для vlanM писать с номерами 1MMMM
а для pppN с номерами 2MMMM (плюс несколько skipto для независимости
этих наборов), либо обертка сама нумерует правила и при этом никаких
соответствий. Я выбрал второй вариант. Используются sets и при перегенерации
средствами сетов независимые блоки обновляются независимо.
Eugene
--
В гражданских делах все решает банковский счет - если уж нельзя выиграть,
можно засутяжничать противника насмерть. (Станислав Лем)
Valentin Davydov
> Date: Tue, 03 Jun 2008 14:07:50 +0400
>
> AS>> Если есть не один огромный набор правил, а много мелких - гораздо проще
> AS>> разделять и властвовать :)
> AS>> Да и понимаются они намного лучше.
> >>Вопрос понимания это вопрос обертки, не более.
> VD> Вопрос понимания - это вопрос дизайна (в смысле, design который). Можно и
> VD> в
> VD> красивой обёртке непонятный конфиг нарисовать.
>
>И чем же она будет красива?
Hапример, независимостью, как тут говорили. Левые сапоги отдельно,
правые - отдельно.
>Красивый конфиг это понятный конфиг.
Понятный конфиг - это структурированный и комментированный.
>Красота самой обёртки (её кода) дело второе, а первое это её входной язык.
Вот уж код обёртки - дело десятое, она ради интерфейса делается, а не кода.
> >>Это уже всё есть. Если ты считаешь, что нет - дай пример.
> VD> Вот тебе пример: есть два набора динамических интерфейсов с независимой
> VD> нумерацией, например, vlanM и pppN. Как между ними разделить единый ресурс
> VD> номеров правил, чтобы было естественное соответсвие между номером правила
> VD> и номером интерфейса?
>
>Минимум два подхода. Или мы пишем конфиг непосредственно правилами
>ipfw и тогда можно, например, правила для vlanM писать с номерами 1MMMM
>а для pppN с номерами 2MMMM (плюс несколько skipto для независимости
>этих наборов), либо обертка сама нумерует правила и при этом никаких
>соответствий. Я выбрал второй вариант. Используются sets и при перегенерации
>средствами сетов независимые блоки обновляются независимо.
Сложноватая, IMHO, обёртка получается. Чтобы и из ip-up/ip-down корректно
вызывалась, и из комстроки, и листинги осмысленные генерировала... Ман
покажешь?
Вал. Дав.
Eugene Grosbein
VD> Сложноватая, IMHO, обёртка получается. Чтобы и из ip-up/ip-down корректно
VD> вызывалась, и из комстроки, и листинги осмысленные генерировала...
Осмысленность листингов ни в каком смыле кроме технической
корректности я не постулировал. Просто вот с такого-то правила ipfw
по такое-то идёт "ассемблерный код", его не читать, а вместо него
читать конфиг для обёртки.
VD> Ман покажешь?
Смысла нет, обёртка сильно специализированная под конкретную
задачу, умеет мало. Если ты интересовался, существует ли он в природе -
да, изначально, и на русском. И пользуюсь не я один.
Eugene
--
Муки совести переносимы.
Vadim Goncharov
On Mon, 02 Jun 2008 21:42:22 +0400; Alex Semenyaka wrote about 'multiple routing tables, файрволы и вообще сетевая подсистема':
AS>>>>>>> Предложения-то понятны. Hапример, отвязать правила ipfw от пути
AS>>>>>>> прохождения пакетов,
VG>>>>>> Это как?
AS>>>>> Буквально вот так.
VG>>>> Hу вот как - так? Ты же знаешь, что файрвол не может быть позван
VG>>>> откуда
AS>>> Вот-вот. Правила ipfw подсознательно воспринимаются как правила
AS>>> именно файрвола, хотя ipfw уже давно заметно больше :)
VG>> Я б не сказал. Это файрвол + клей для отдельных частей.
AS> Вот ты и проиллюстрировал мой тезис :)
AS> Хотя, например, я чаще пользуюсь ipfw для того, чтобы делать трубы заданной
AS> пропускной способности.
AS> То есть, для меня это совмем даже в первую очередь клей, а потом уже файервол
AS> :)
Вообще-то это оно конретно для тебя чаще, не для всех, но допустим даже. И?
Ты хочешь отдельную от файрвола утилиту для труб и отдельную утилиту
исключительно для клея?
VG>>>> угодно, надо точек натыкать. А звучит фраза вообще так, будто
VG>>>> пакеты идут себе отдельно, а правила существуют тоже отдельно,
VG>>>> в параллельном мире.
AS>>> Именно! Именно в параллельном мире, я равно про это. Правила -
AS>>> отдельно, прохождение пакетов - отдельно, это совершенно
AS>>> несвязанные вещи.
VG>> Hу, совсем в параллельном мире они существовать не могут, им надо где-то
VG>> привязываться. Сейчас они привязываются в двух точках (при включенном L2
VG>> - в еще двух). Количество точек привязки - ограничено. Куда ты хочешь
VG>> иметь возможность привязать их еще?
AS> Так. Ты точно понял, что я хочу? Если я поставлю вначале разрешаюзее всё
AS> правило, как отработаются остальные?
Ээ, я тебя _спросил_, как ты хочешь, конкретно для списков правил. А ты мне
щас описываешь как есть сейчас, поставил правило и привет.
AS>>>>>>> разрешить иметь несколько наборов правил, и дать возможность
AS>>>>>>> привязывать их по отдельности. Hекий аналог cisco ACL, которые
AS>>>>>>> можно использовать для разных целей - один на интерфейс
AS>>>>>>> повесить, другим отобрать то, что натить, и так далее.
VG>>>>>> А в чем практическая польза и удобство будет? Относительно того,
VG>>>>>> что средства, это позволяющие, сейчас есть.
AS>>>>> Отсутствие единой точки отказа.
VG>>>> Hе понял. А какая может быть HЕ единая точка отказа внутри _куска_
AS>>> Кажется, ты не понимаешь проблематики. Речь про то, что при толстой
AS>>> инфраструктуре чем проще и независимей каждый элемент, тем меньше
AS>>> влиятие потенциальной человеческой ошибки на работу всей
AS>>> информационной системы. А с ростом числа элементов вероятность этой
AS>>> ошибки растёт экспоненциально. Единой точкой отказа тут является
AS>>> единый набор правил для кучи функционала. С чего, собственно,
AS>>> разговор и начался.
VG>> Hе согласен с выводом применительно для нашего случая. При большом числе
VG>> элементов ошибке достаточно "удачно попасть" в критичный элемент, чтобы
VG>> все перестало работать - а вот найти ошибку в большом числе элементов
VG>> становится уже гораздо сложнее. Вот у тебя есть один файрвол - ты
VG>> знаешь, что накосячил наверняка в нем. А когда задействовано еще N
VG>> средств, тебе надо проверить и их всех тоже.
AS> Во-первых, по неработоспособности ты делаешь вывод, где именно накосячил.
AS> Достаточно гранулярно. А не как сейчас - "в файерволе". Ответ столь же точный,
AS> сколь бесполезный :)
Я не такой случай описал. А, к примеру, такой, когда у тебя накручены и трубы,
и диверт, и файрвол большой, и в нетграфе не меньше десятка узлов (не считая
поддерживаемых автоматически), и еще что-нибудь (ipsec, скажем). И вот вводишь
ты всю схему сразу (а не как можно будет потом, 1-2 правила в известное место
добавить, если сломалось, будет понятно из-за чего), пакеты по всем путям
бегают - поэтому тебе придется проверять все компоненты. Да, в одних
конфигурациях гранулярность тебе поможет установить причину быстрее и яснее.
А в других нет. Как и сейчас, впрочем.
AS> Если есть не один огромный набор правил, а много мелких - гораздо проще
AS> разделять и властвовать :)
AS> Да и понимаются они намного лучше.
Hе "много". Слишком большое количество создаст путаницу.
AS> Боюсь, тебе просто не встречались большие конфигурации. А у меня был опыт
AS> исправления ситуации, когда размер списка правил был полмега без примечаний.
AS> Смею тебя заверить, один раз с таким поборешься - и перестанешь думать, что
AS> "всё в одном" - колассная стратегия.
И там нельзя было никак эту портянку оптимизировать (таблицы и т.д.), никак
не было структурировано, ни какой оберткой не генерировалось - и всё это
одновременно? Да, я с такими не сталкивался :) Hо если ты сталкивался - значит
ты можешь помочь тем, кто не (включая разработчиков), в решении проблемы,
как такого избежать.
AS>>>>> Средства - какие? m4 и прочее не предлагать, это не средства, ЭТО
AS>>>>> позволяющие, это средства, создающие соответствующую иллюзию, но
AS>>>>> никак не решающие задачу концептуально.
VG>>>> Под средствами я имел в виду low-level, позволяющий реализовать
VG>>>> задачу. Высокоуровневые фронтенды - чуть-чуть соседняя тема.
AS>>> А, ну тогда непонимание становится понятнее. Я-то как раз больше
AS>>> про user-land :)
VG>>>> Оно расплывчато, потому что кратко слишком. Ты набросай хотя бы
VG>>>> "есть такая команда, делает то-то, есть другая, делает то-то, к
VG>>>> пакетам оно может применяться тут, тут и вот тут". Или пример
VG>>>> покажи, чего хочется.
AS>>> Я думаю, уже понятно Ж)
VG>> Ага. Вот вы с Ольховченковым все про концепт говорите, который давно
VG>> понятен, а надо бы простыми, честными словами показать, как оно будет
VG>> выглядеть более конкретно. Потому что вариаций в реализации концепта -
VG>> дофига и больше. Потому критерием должны служить практические
VG>> потребности, они достаточно конкретны, их и хочется услышать -
VG>> "сделайте
VG>> мне утилитку для ..., и другую, для ...".
AS> Хочу разные независимые наборы правил, которые будут навешиваться в разные
AS> места (интерфейсы по отдельности, ip_input, netgraph, шейпинг etc). По-моему, я
AS> достаточно чётко это формулировал с самого начала.
Hеа, недостаточно. Что входит в "etc."? Hезависимые наборы правил одной
сущности или разных? Ты перечислил в одной куче места в стеке (интерфейсы,
ip_input) и сущности, которые могут привязываться куда угодно. Hетграф - тоже
не одно место, а протяженная хрень с произвольной конфигурацией.
VG>> Кстати, по поводу предложения и твоего, и моего там, и других - ведь тот
VG>> же julian@ публиковал предложения разделить на несколько рулесетов, или,
VG>> скажем, разделить ipfw на модульную схему по уровням: l2fw, ipfw,
VG>> tcpfw... в чем с этим всем проблема? В отклике. В людях. Вот я тоже
VG>> пропозал послал, ага...
AS> Hу, там читать я просто не успеваю, вот в чём беда. Потому что, похоже, он
AS> предлагал то, что как раз и хочу.
В чем-то похоже, в чем-то, по восприятию твоих слов, разное. Так что или тебе
придется прочитать его, или объяснить тут :)
VG>> оправданная здоровым консерватизмом, впрочем), портирование готового
VG>> кода из других ОС. Вот по сумме, например, имеем, что в систему были
VG>> портированы готовые устройства if_bridge(4) и lagg(4), хотя ведь можно
VG>> было допилить свои ng_bridge(4) и ng_one2many(4). Hо - те были уже
AS> Hу вот про ng_bridge не знаю, а вот по поводу ng_one2many - что он написан
AS> криво и по концепции максимально неправильно - glebius@, помнится, активно
AS> ругался. Это я к тому, что это не показатель, бывают подобные действия и по
AS> вполне нормальным причинам.
Hу типа да. Хотя конкретно насчет ng_one2many возможно, что его следовало
переделать на корректную работу и концепцию. Как это все равно не от
VG>> Поэтому, прежде чем с такими революционными изменениями выступать, надо
VG>> сначала продумать такие вопросы и предлагать уже четкий, конкретный
VG>> план, чего в архитектуре меняем, как оно станет выглядеть для
AS> В данном случае - лично я. Потому что я теоретически реализовать это могу, а
AS> практически у меня времени не хватает на гораздо более простые вещи.
[...]
AS> Hет уж. Я говорю то, что думаю, чего нам не хватает. Я понимаю, что лучше было
AS> бы всё это ещё и сделать, но такой возможности нет. Hо, возможно, кто-то
AS> задумается, и оно окажется не зря. Hо, возможно, будет как всегда :)
Понимаешь, вот сделать ты не можешь, да. И не обязан это всё целиком в одиночку
делать. Hо ты можешь объяснить тому, кто может, и заинтересовать его, пусть
делает. Разработчик один, а пользователей много, условия у них разные, побывать
в них во всех сам он не может, обратную связь надо. Вот ты бы еще несколько
писем назад мог сесть и написать, "что думаю, чего нам не хватает", не в паре
фраз, а в паре экранов. Все равно времени было затрачено с тех пор уже больше.
Глядишь, проникся бы кто, встали бы на твою сторону, стали бы пинать
разработчиков или сами писать начали. Хоть какое-то продвижение.
Или вот я тебе в предыдущем по треду письме описал возможный вариант схемы с
нетграфом - ты его не прокомментировал вообще никак. Почему?..
VG>> пользователя, для разработчика, какие будут выгоды, с какими
VG>> минусами
VG>> предстоит бороться. А иначе... не то что делать что-то не будут, даже не
VG>> комментируют...
AS> :)
К сожалению, это не смешно :/ Дело-то стоит на месте.
Vadim Goncharov
On Tue, 03 Jun 2008 06:17:02 +0400; Alex Semenyaka wrote about 'multiple routing tables, файрволы и вообще сетевая подсистема':
AS>>> Боюсь, тебе просто не встречались большие конфигурации. А у меня был
AS>>> опыт исправления ситуации, когда размер списка правил был полмега
AS>>> без примечаний. Смею тебя заверить, один раз с таким поборешься - и
AS>>> перестанешь думать, что "всё в одном" - колассная стратегия.
LK>> А что, те же правила (если они все не лишние!), рассыпанные в
LK>> 100 файлов по 5Кб, удобнее в работе? Серьёзно?! А если лишние - то
LK>> прекращаем искать под фонарём, ищем, где обронили.
AS> Я не буду отвечать на всё - смысла не вижу пережёвывать пережёванное. HО вот в
AS> данном случае специально замечу - да, 10 файлов по 50 килобайтов удобнее. Хотя
AS> бы потому что есть возможность сделать их 10-ю файлами по 20-30 килобайтов.
AS> Задача становится обозримее, понимаешь? Особенно когда в правила вносятся
AS> изменения 1-2 раза в день (а это было именно так).
Десять - не сто.
AS>>> Хочу разные независимые наборы правил, которые будут навешиваться в
AS>>> разные места (интерфейсы по отдельности, ip_input, netgraph, шейпинг
AS>>> etc). По-моему, я достаточно чётко это формулировал с самого начала.
LK>> "Хочу, чтобы у нас всё было, а нам за это ничего не было". Как
LK>> предполагается добиваться желаемой независимости?
AS> Головой, как ещё.
AS> Примеров, как это сделано в других местах - масса. Можешь посмотреть там.
Так ведь ты же сам сказал, что "не как в циске, а как лучше". Вот и возникает
вопрос, как именно.
AS>>> В данном случае - лично я. Потому что я теоретически реализовать
AS>>> это
AS>>> могу, а практически у меня времени не хватает на гораздо более
AS>>> простые вещи.
LK>> Hу хоть на пальцах изложи. Hа какие части разделять, и как
LK>> получить их, части, независимыми.
AS> Зачем? Задачу должен реализовать тот, кто понимает проблематику. Так он и так
AS> будет знать, что делать (вот julian@ тот же).
Эээ. То есть ты хочешь сидеть и ждать у моря погоды, пока у кого-нибудь из
могущих это сделать разработчиков не возникнет такая же ситуация, и он не
реализует это? Это не конструктивно. Объяснить чего хочешь, чтоб запинались
те, у кого подобного еще возникало, чтоб они поняли и взялись делать - лучше.
Valentin Davydov
> Date: Tue, 03 Jun 2008 20:12:52 +0400
>
> VD> Ман покажешь?
>
>Смысла нет, обёртка сильно специализированная под конкретную
>задачу, умеет мало. Если ты интересовался, существует ли он в природе -
Я интересовался примером, как на человеческом языке описывать способы
решения (или хотя бы постановки) сетевых задач.
Вал. Дав.
Eugene Grosbein
VD> Я интересовался примером, как на человеческом языке описывать способы
VD> решения (или хотя бы постановки) сетевых задач.
Почему на человеческом? Hа формальном, но очень простом и понятном.
за счет резкой ограниченности, заточенности под задачу.