1.1, AdVv (ok), 12:27, 10/06/2009 [ответить]
| +/– |
Блин фразу "ipfw + natd - использовать не рекомендую из-за запутанности правил и
связки natd + ipfw. При работе с ipfw+natd ttl вырастал до бешенных резмеров что привело к тому, что пинги ходили с задержками в 2-3 секунды" надо на баш отправить.
| |
|
2.2, Xaionaro (?), 23:21, 11/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
Да вообще, писал человек достаточно слабый :). Хотя я лично тоже не рекомендую natd, но всё-таки совсем по другим причинам :). А именно, natd очень не экономичен в плане ресурсов CPU. Да и вообще, тот же pf, лично по-моему, значительно более "мощный" (по функционалу) и удобный, чем ipfw.
| |
|
3.3, AdVv (ok), 14:46, 12/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Да вообще, писал человек достаточно слабый :). Хотя я лично тоже не
>рекомендую natd, но всё-таки совсем по другим причинам :). А именно,
>natd очень не экономичен в плане ресурсов CPU. Да и вообще,
>тот же pf, лично по-моему, значительно более "мощный" (по функционалу) и
>удобный, чем ipfw.
natd единственный под FreeBSD справляется с задачей nat для pptp соединений. PF этого не умеет до сих пор. Свистелок типа os detection и pfauth в ipfw нет, но их необходимость сомнительна. Функционала ipfw достаточно для любых реальных задач по обработке траффика, никакого "значительного" превосходства тут не может быть в принципе. На мой взгляд у всех unixlike файрволов сходный синтаксис и возможности. В плане производительности natd вероятно уступает in kernel реализациям, хотя насколько сильно лично я не измерял. Для средних размеров организации на современном железе ее хватает за глаза, ну а для магистралей существуют совсем другие решения. И еще надо заметить что ipfw часть FreeBSD, а PF всетаки порт с другой системы. В некоторых случаях ipfw оказывается гибче. Если есть желание почитайте http://nuclight.livejournal.com/
| |
|
|
1.4, dimanoname (?), 15:31, 27/06/2009 [ответить]
| +/– |
статьи такого уровня запудривают ньюбам моск, искажая их представление о ФриБСД вцелом.имхо:)
| |
|