ex-transfer Опубликовано 27 сентября, 2010 (изменено) · Жалоба Уважаемые ГУРУ! Долго бьюсь с проблемой, читал много тем с форума и инета, не могу победить свой сервачок: Стоит две сетевушки em0 (alias vlan700) и em1 (alias vlan250) На vlan700 - транспорт до всех 3750, на vlan250 - куча реальных адресов/32 маске (алиасами) - транспорт на бордер Задача сервера: шейпинг и НАТ для небольшого количества трафика (около 120 Мбит) Все клиенты терминируются на 3750, предоставляется влан-на-абонента (opt82, dhcp-snooping). На сервер долетают пакеты с серыми адресами, попадают в НАТ, и режутся altq. При включенном net.isr.direct=1 возникает # netstat -w1 -i vlan250 input (Total) output packets errs bytes packets errs bytes colls 9971 242 5081867 9385 0 5042877 0 9906 197 5141062 9237 0 5120116 0 9837 161 4993819 9042 0 4976199 0 10107 419 5337893 9334 0 5291947 0 9809 223 4874975 9165 0 4874842 0 9854 310 5190356 9036 0 5076692 0 9868 177 5270392 9192 0 5171840 0 9646 272 4920796 8871 0 4879827 0 У юзеров тормозят странички web конечно ЖУТКО. При net.isr.direct=0 Пакеты не выпадают: # netstat -w1 -i vlan250 input (Total) output packets errs bytes packets errs bytes colls 12887 0 5156078 12058 0 5408769 0 12709 0 5135044 12014 0 5260029 0 12640 0 5214073 11876 0 5294148 0 12466 0 5166291 11604 0 5114483 0 12675 0 5223386 12075 0 5583122 0 12728 0 5379418 11923 0 5396520 0 12865 0 5499945 12081 0 5491322 0 Но появляются кошмарные задержки пакетов, проходящих через шейпер, даже если пинговать собственный интнрфейс: # ping 10.11.10.49 PING 10.11.10.49 (10.11.10.49): 56 data bytes 64 bytes from 10.11.10.49: icmp_seq=0 ttl=64 time=473.065 ms 64 bytes from 10.11.10.49: icmp_seq=1 ttl=64 time=445.350 ms 64 bytes from 10.11.10.49: icmp_seq=2 ttl=64 time=465.794 ms 64 bytes from 10.11.10.49: icmp_seq=3 ttl=64 time=474.941 ms Вот кусочек конфига для трех клиентов: set skip on lo0 set block-policy return set optimization normal set limit { states 300000, frags 600000 } set limit table-entries 600000 altq on vlan700 cbq bandwidth 10240000Kb queue { inqueue } altq on vlan250 cbq bandwidth 10240000Kb queue { inqueue } queue inqueue bandwidth 100% cbq(default) {\ user1, \ user2, \ user3 \ } queue user1 bandwidth 2048Kb queue user2 bandwidth 2048Kb queue user3 bandwidth 1024Kb nat on vlan250 inet from { 172.16.16.0/23, 172.16.18.0/23 } to any -> realIP/28 source-hash pass quick from 172.16.20.4 to any queue user1 pass quick from any to 172.16.20.4 queue user1 pass quick from 172.16.20.3 to any queue user2 pass quick from any to 172.16.20.3 queue user2 pass quick from 172.16.8.40 to any queue user3 pass quick from any to 172.16.8.40 queue user3 Нагрузка на проц с net.isr.direct=0: last pid: 1288; load averages: 0.48, 0.84, 0.69 114 processes: 6 running, 87 sleeping, 21 waiting CPU 0: 3.7% user, 0.0% nice, 12.4% system, 0.0% interrupt, 83.9% idle CPU 1: 2.6% user, 0.0% nice, 3.4% system, 39.6% interrupt, 54.3% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 98.1% interrupt, 1.9% idle CPU 3: 0.7% user, 0.0% nice, 10.5% system, 0.0% interrupt, 88.8% idle Mem: 25M Active, 12M Inact, 144M Wired, 504K Cache, 30M Buf, 1791M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root -44 - 0K 352K CPU2 2 62:50 94.92% {swi1: netisr 0} 11 root 171 ki31 0K 64K RUN 0 56:05 93.41% {idle: cpu0} 11 root 171 ki31 0K 64K CPU3 3 54:01 90.87% {idle: cpu3} 11 root 171 ki31 0K 64K CPU1 1 57:25 56.10% {idle: cpu1} 886 nobody 48 0 8016K 3680K select 0 7:45 7.81% softflowd 0 root -68 0 0K 128K - 0 10:37 5.52% {em1 taskq} 884 nobody 47 0 8016K 3608K select 1 4:21 4.88% softflowd 11 root 171 ki31 0K 64K RUN 2 11:12 2.29% {idle: cpu2} 12 root -32 - 0K 352K WAIT 1 5:57 0.10% {swi4: clock} 0 root -68 0 0K 128K - 3 17:20 0.00% {em0 taskq} 12 root -68 - 0K 352K WAIT 1 1:34 0.00% {irq258: bge0} 13 root -16 - 0K 16K - 1 0:09 0.00% yarrow 7 root 44 - 0K 16K pftm 1 0:07 0.00% pfpurge 578 root 44 0 14736K 4556K select 1 0:03 0.00% ospfd 689 root 44 0 24308K 6360K select 0 0:03 0.00% snmpd 983 root 44 0 17708K 5820K wait 1 0:02 0.00% mc 966 ex 44 0 45280K 6300K select 1 0:01 0.00% sshd 412 _pflogd 44 0 7080K 1716K bpf 3 0:01 0.00% pflogd 12 root -32 - 0K 352K WAIT 0 0:00 0.00% {swi4: clock} 3 root -8 - 0K 16K - 1 0:00 0.00% g_up 2 root -8 - 0K 16K - 0 0:00 0.00% g_event 4 root -8 - 0K 16K - 3 0:00 0.00% g_down 12 root -32 - 0K 352K WAIT 0 0:00 0.00% {swi4: clock} 18 root 44 - 0K 16K syncer 0 0:00 0.00% syncer 601 root 44 0 5864K 1500K select 1 0:00 0.00% syslogd 12 root -32 - 0K 352K WAIT 0 0:00 0.00% {swi4: clock} 21 root 44 - 0K 16K flowcl 3 0:00 0.00% flowcleaner 14 root -64 - 0K 512K - 0 0:00 0.00% {usbus4} 14 root -64 - 0K 512K - 3 0:00 0.00% {usbus7} 14 root -64 - 0K 512K - 0 0:00 0.00% {usbus3} 14 root -64 - 0K 512K - 0 0:00 0.00% {usbus0} 14 root -64 - 0K 512K - 0 0:00 0.00% {usbus5} 14 root -64 - 0K 512K - 0 0:00 0.00% {usbus6} 12 root -64 - 0K 352K WAIT 0 0:00 0.00% {irq14: ata0} 14 root -64 - 0K 512K - 0 0:00 0.00% {usbus2} Куда рыть?! Может я PF неправильно конфигурю? Изменено 27 сентября, 2010 пользователем ex-transfer Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 27 сентября, 2010 · Жалоба перенеси всё на dummynet, и забудь про pf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 27 сентября, 2010 · Жалоба перенеси всё на dummynet, и забудь про pf я наоборот с dummynet'а перенес все на pf (это нелегкого стоило, т.к. написать скрипт автодобавления юзера в pf в разы сложнее чем в ipfw) параллельный вопрос: как бороться с задержками в dummynet с маленькими скоростями в pipe? Если это можно решить - перейду на ipfw. Но дело кроется не в нем, по-моему Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 27 сентября, 2010 · Жалоба А что за "маленькие скорости" в dummynet? Общие рекомендации - используй one_pass, таблицы ну и GRED наше всё. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XeonVs Опубликовано 27 сентября, 2010 (изменено) · Жалоба перенеси всё на dummynet, и забудь про pf я наоборот с dummynet'а перенес все на pf (это нелегкого стоило, т.к. написать скрипт автодобавления юзера в pf в разы сложнее чем в ipfw) параллельный вопрос: как бороться с задержками в dummynet с маленькими скоростями в pipe? Если это можно решить - перейду на ipfw. Но дело кроется не в нем, по-моему PF использует глобальные блокировки и фактически получается однопоточным.Насколько маленькие скорости в pipe? Как тут правильно посоветовали gred и подбор размера очереди под требуемую скорость. Вот не плохая мурзилка http://osboy.blog.ru/33351283.html по данному вопросу для начала. Изменено 27 сентября, 2010 пользователем XeonVs Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 27 сентября, 2010 (изменено) · Жалоба GRED -- далеко не самое главное. Обладатели Cisco SCE вообще полисинг делают, и юзеры не жалуются. Важно, чтобы для классификации трафика использовались хэши на основе пользовательских IP-адресов. В ipfw это реализуется динамическими пайпами или правилом вида pipe tablearg. Примеры легко найти на данном форуме. В противном случае, каждый пакет будет пробегать тысячи правил, и процессорное время будет расходоваться так же неоптимально, как в pf/ALTQ. Кроме того, в ipfw меньше проблем с гигантскими блокировками, чем в pf. Изменено 27 сентября, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 28 сентября, 2010 (изменено) · Жалоба А что за "маленькие скорости" в dummynet?Общие рекомендации - используй one_pass, таблицы ну и GRED наше всё. "Маленькие" - это до 1024 кбита, (слава аллаху, что сейчас тарифы с такими скоростями уже не существуют, но вот пример такого тарифа, у него задержки были около 400мс): ipfw add 228 pipe 228 ip from any to 172.16.5.2 in via vlan190 ipfw add 229 pipe 229 ip from 172.16.5.2 to any in via vlan700 ipfw pipe 228 config bw 128Kbit/s queue 100 ipfw pipe 229 config bw 128Kbit/s queue 100 ONE_PASS - я так понимаю, опция в ядре должна быть? Можно рабочий пример для GRED например для скорости 2Мбита? И нужны ли тонкие настройки в самой ФРЕ? Я имею в виду тонкий тюнинг сетевой подсистемы для IPFW ? p.s. вообще спасибо всем за комменты и советы. Начинаю заново "знакомиться" с IPFW Изменено 28 сентября, 2010 пользователем ex-transfer Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XeonVs Опубликовано 28 сентября, 2010 (изменено) · Жалоба А что за "маленькие скорости" в dummynet?Общие рекомендации - используй one_pass, таблицы ну и GRED наше всё. "Маленькие" - это до 1024 кбита, (слава аллаху, что сейчас тарифы с такими скоростями уже не существуют, но вот пример такого тарифа, у него задержки были около 400мс): ipfw add 228 pipe 228 ip from any to 172.16.5.2 in via vlan190 ipfw add 229 pipe 229 ip from 172.16.5.2 to any in via vlan700 ipfw pipe 228 config bw 128Kbit/s queue 100 ipfw pipe 229 config bw 128Kbit/s queue 100 ONE_PASS - я так понимаю, опция в ядре должна быть? Можно рабочий пример для GRED например для скорости 2Мбита? И нужны ли тонкие настройки в самой ФРЕ? Я имею в виду тонкий тюнинг сетевой подсистемы для IPFW ? p.s. вообще спасибо всем за комменты и советы. Начинаю заново "знакомиться" с IPFW one-pass sysctl переменная net.inet.ip.fw.one_pass Правильно что большие задержки, очередь-то здоровая. для 128к и 100мсек. будет примерно так: queue 8 gred 0.002/1/2/0.1 как-то так: ipfw table 10 flush ipfw table 10 add 172.16.5.2/32 28 ipfw table 10 add 172.16.5.3/32 29 ..... ..... ipfw table 11 flush ipfw table 11 add 172.16.5.2/32 228 ipfw table 11 add 172.16.5.3/32 229 .... .... ipfw pipe 28 config queue 32 bw 1Mbit/s mask dst-ip 0xffffffff gred 0.002/8/16/0.1 ipfw pipe 228 config queue 32 bw 1Mbit/s mask src-ip 0xffffffff gred 0.002/8/16/0.1 ipfw pipe 29 config queue 68 bw 2Mbit/s mask dst-ip 0xffffffff gred 0.002/17/34/0.1 ipfw pipe 229 config queue 68 bw 2Mbit/s mask src-ip 0xffffffff gred 0.002/17/34/0.1 ipfw add 705 pipe tablearg ip from any to "table(10)" out xmit vlan0 ipfw add 705 pipe tablearg ip from "table(11)" to any in recv vlan0 Изменено 30 сентября, 2010 пользователем XeonVs Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 28 сентября, 2010 · Жалоба XeonVs Огромное спасибо за примерчик! Уже начитался про ipfw table, пора приниматься за практическое применение. Ядро пересобрал с поддержкой dummynet. На pf наверное оставлю только НАТ, ipfw - только шейперство. ПОсмотрим на результаты... Сегодня-завтра-отпишусь Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XeonVs Опубликовано 28 сентября, 2010 (изменено) · Жалоба XeonVs Огромное спасибо за примерчик! Уже начитался про ipfw table, пора приниматься за практическое применение. Ядро пересобрал с поддержкой dummynet. На pf наверное оставлю только НАТ, ipfw - только шейперство. ПОсмотрим на результаты... Сегодня-завтра-отпишусь лучше вообще убрать(разделить функционал по разным машинкам) pf, если не нужны его специфичные фичи. ipfw nat справится. Изменено 28 сентября, 2010 пользователем XeonVs Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 28 сентября, 2010 · Жалоба XeonVs Огромное спасибо за примерчик! Уже начитался про ipfw table, пора приниматься за практическое применение. Ядро пересобрал с поддержкой dummynet. На pf наверное оставлю только НАТ, ipfw - только шейперство. ПОсмотрим на результаты... Сегодня-завтра-отпишусь лучше вообще убрать(разделить функционал по разным машинкам) pf, если не нужны его специфичные фичи. ipfw nat справится. Я тоже так думаю, сервачок под выделенный НАТ уже в пути ))Юзеров-то у нас всего ~2000 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 28 сентября, 2010 · Жалоба XeonVs непонятно, зачем Вы в конфиге заполняете таблицы с различными скоростями для юзеров в рамке одной таблицы? ipfw table 10 add 172.16.5.2/32 28 ipfw table 10 add 172.16.5.3/32 29 Последнее число, как я понял из man'а - это указатель к какой pipe привязать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 28 сентября, 2010 (изменено) · Жалоба Ну это просто пример асимметричного шэйпинга 1/2Mbps Последнее число - пресловутый tablearg, оч. полезная вещь, и не только в pipe/queue Изменено 28 сентября, 2010 пользователем Deac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 28 сентября, 2010 · Жалоба Я тоже так думаю, сервачок под выделенный НАТ уже в пути ))Юзеров-то у нас всего ~2000 На такое количество клиентов и 100mbps должно хватить одного сервера ipfw+dummynet+netflow+pfnat.Второй сервер здесь может быть нужен только на тот случай, если первый сломается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 29 сентября, 2010 · Жалоба Я тоже так думаю, сервачок под выделенный НАТ уже в пути ))Юзеров-то у нас всего ~2000 На такое количество клиентов и 100mbps должно хватить одного сервера ipfw+dummynet+netflow+pfnat.Второй сервер здесь может быть нужен только на тот случай, если первый сломается. Оттестировал! Пока ни потерь, ни тормозов в web.Во: shapper# netstat -w1 -i vlan250 input (Total) output packets errs bytes packets errs bytes colls 9732 0 6562222 9512 0 6788224 0 10069 0 6829139 9872 0 7066174 0 10139 0 6874054 9609 0 7108733 0 10681 0 7467601 10785 0 7717429 0 9715 0 6521394 9613 0 6771326 0 9750 0 6626889 9690 0 6842818 0 10779 0 7062299 10567 0 7291172 0 10229 0 7091838 9824 0 7313028 0 10097 0 7003873 9935 0 7216538 0 10401 0 6977869 10325 0 7234084 0 Скорости режутся практически идеально. Нагрузка на процы менее 15% !!! last pid: 39061; load averages: 0.08, 0.17, 0.15 up 0+23:34:47 17:02:21 138 processes: 5 running, 107 sleeping, 26 waiting CPU 0: 2.6% user, 0.0% nice, 5.3% system, 14.9% interrupt, 77.2% idle CPU 1: 2.6% user, 0.0% nice, 5.3% system, 0.9% interrupt, 91.2% idle CPU 2: 2.6% user, 0.0% nice, 1.8% system, 1.8% interrupt, 93.9% idle CPU 3: 0.0% user, 0.0% nice, 4.4% system, 0.0% interrupt, 95.6% idle Mem: 39M Active, 201M Inact, 330M Wired, 296K Cache, 213M Buf, 1403M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 64K CPU1 1 20.7H 97.85% {idle: cpu1} 11 root 171 ki31 0K 64K CPU3 3 19.4H 95.36% {idle: cpu3} 11 root 171 ki31 0K 64K CPU2 2 19.7H 87.35% {idle: cpu2} 11 root 171 ki31 0K 64K RUN 0 18.4H 86.13% {idle: cpu0} 12 root -44 - 0K 416K WAIT 1 455:00 6.69% {swi1: netisr 0} 0 root 45 0 0K 176K WAIT 2 52:43 1.66% {em1_rx_0} 905 nobody 46 0 8016K 3684K select 1 94:07 1.51% softflowd 903 nobody 45 0 8016K 3648K select 0 84:54 1.51% softflowd 0 root 45 0 0K 176K WAIT 1 49:03 1.17% {em0_rx_1} 0 root 45 0 0K 176K WAIT 3 49:31 0.93% {em0_rx_0} 0 root 45 0 0K 176K WAIT 1 52:28 0.78% {em1_rx_1} 12 root -32 - 0K 416K WAIT 2 21:12 0.10% {swi4: clock} 0 root -68 0 0K 176K - 2 41:29 0.00% {dummynet} 12 root -68 - 0K 416K WAIT 0 13:11 0.00% {irq258: bge0} 12 root 16 - 0K 416K WAIT 2 5:18 0.00% {swi16: em0_tx} 12 root 16 - 0K 416K WAIT 1 4:49 0.00% {swi16: em1_tx} Тестю дальше, на нагрузке поболее.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 29 сентября, 2010 · Жалоба Толи ещё будет, у Луиджи там "планов громадьё", пока правда больше ломает чем строит. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andriko Опубликовано 29 сентября, 2010 · Жалоба Толи ещё будет, у Луиджи там "планов громадьё", пока правда больше ломает чем строит. :)кста :)http://docs.freebsd.org/cgi/getmsg.cgi?fet...ent/svn-src-all Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 29 сентября, 2010 · Жалоба ipfw table 10 flush ipfw pipe 28 config queue 32 bw 1Mbit/s mask dst-ip 0xffffffff gred 0.002/8/16/0.1 ipfw pipe 228 config queue 32 bw 1Mbit/s mask dst-ip 0xffffffff gred 0.002/8/16/0.1 ipfw pipe 29 config queue 68 bw 2Mbit/s mask dst-ip 0xffffffff gred 0.002/17/34/0.1 ipfw pipe 229 config queue 68 bw 2Mbit/s mask dst-ip 0xffffffff gred 0.002/17/34/0.1 ipfw add 705 pipe tablearg ip from any to "table(10)" out xmit vlan0 ipfw add 705 pipe tablearg ip from "table(11)" to any in recv vlan0 Только для труб 228 и 229 dst сменить на src .... :) А то шейпиться будет не скорость от клиента, а скорость _к_ www.microsoft.com Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 30 сентября, 2010 · Жалоба ГУРУ, вопрос может и глубый, но как вы пропускаете в инет ТОЛЬКО юзеров из таблиц, а остальных рубите? У меня не выходит каменный цветок. Ткните кусочком конфига Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 30 сентября, 2010 · Жалоба Не использовать IPFIREWALL_DEFAULT_TO_ACCEPT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 30 сентября, 2010 · Жалоба Не использовать IPFIREWALL_DEFAULT_TO_ACCEPT уже убрал ) хана халявщикам! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
blackjack Опубликовано 30 сентября, 2010 · Жалоба последним правилом прописать deny from any to any Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
denis_vid Опубликовано 30 сентября, 2010 · Жалоба Не использовать IPFIREWALL_DEFAULT_TO_ACCEPTЭто очень и очень глупо. Особенно если сервер где то там куда надо добираться.Лучше one pass 1 и правила 65533 65534 запрещающие все что не попало выше в клиентских сетях Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 1 октября, 2010 · Жалоба Ознакомься что делает вышеуказанная опция. Детская болезнь боязни собственной неумелости, этим надо просто переболеть. Все контролируемые мной сервера более или менее удалены, некоторые больше чем на 100км. Есть общепринятые правила внесения изменений в файервол, читай маны, доки, материала достаточно и обязательно обкатывай всё на стенде. Если уж чувствуешь свою неготовость - имей "удалённые руки". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
denis_vid Опубликовано 1 октября, 2010 (изменено) · Жалоба Ознакомься что делает вышеуказанная опция.Детская болезнь боязни собственной неумелости, этим надо просто переболеть. Все контролируемые мной сервера более или менее удалены, некоторые больше чем на 100км. Есть общепринятые правила внесения изменений в файервол, читай маны, доки, материала достаточно и обязательно обкатывай всё на стенде. Если уж чувствуешь свою неготовость - имей "удалённые руки". Указанная функция включает правило по умолчанию 65535 deny from any to anyПо остальному если ты такой идеальный что никогда не катаешься за 100 км потому что "ой все пропало" я тебе завидую А у меня например биллинг управляет правилами ipfw и ежедневно необходимо добавлять изменять общие правила а иногда и обновлять систему. А после обновления может оказаться что синтаксис в rc.firewall самую чуточку изменился а net.inet.ip.fw.enable 1 У меня лично валидола бы не хватило так работать с сервером за 100 км. Изменено 1 октября, 2010 пользователем denis_vid Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...