Victor Sudakov wrote: > Mykola Dzham wrote: > > > > > > > > Ну да, нужно добавить еще keep-state (который в pf тоже есть, > > > > > > > > просто > > > > > > > > автоматически добавляется) > > > > > > > > > > > > > > И это приятно, тоже в этом плане PIX напоминает. > > > > > > > > > > > > А в ipfw кстати, если одно правило создает state, например на > > > > > > входе, а > > > > > > потом другое на выходе создает тот же самый state, то идёт ругань на > > > > > > консоль ярко-белым. Я не понимаю, жалко что ли? В pf это нормальная > > > > > > ситуация. > > > > > > > > > > И еще в pf заявлена такая фича: "Another advantage of keeping state is > > > > > that corresponding ICMP traffic will be passed through the firewall. > > > > > For example, if a TCP connection passing through the firewall is being > > > > > tracked statefully and an ICMP source-quench message referring to this > > > > > TCP connection arrives, it will be matched to the appropriate state > > > > > entry and passed through the firewall. " > > > > > > > > > > В ipfw такое разве есть? > > > > > > > > Если бы Вы виделе код, который в pf это всё реализует, Вы бы только > > > > обрадовались что в ipfw этого нет. > > > > > > А что именно не так с кодом? > > > > Он страшен. Куча налепленых проверок. Никакой общей системы, стройная > > система костылей и подпорок. > > Понятно. Хотя странно при этом, что с неожиданным поведением в pf я пока > не столкнулся, а в ipfw таки да.
Это вдвойне странно: нарваться на неожиданное поведение pf элементарно. Достаточно чтобы конфиг перерос определенный уровень. -- LEFT-(UANIC|RIPE) JID: [email protected] PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280
