kaN5300 Опубликовано 6 марта, 2012 · Жалоба Но ngctl list при большом количестве сессий вместо результата выдавало у меня ошибку даже после нескольких удвоений дефолта, вплоть до 8M. Тогда, обозлившись, я удесятерил - и ngctl list заработал. Это было при более чем 1500 сессях. Спасибо за ценный совет. Переписал механизм получения к-ва активных сессий с ifconfig на ngctl, тем самым ускорив выполнение команды примерно в 27 раз. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 6 марта, 2012 · Жалоба С момента создания темы новый сервер совершил две произвольных перезагрузки. 20.02 и 29.02. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 6 марта, 2012 · Жалоба правила файрвола в студию паники в логах есть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 6 марта, 2012 · Жалоба 00200 allow ip from any to any via lo0 00300 allow gre from any to any via igb0 00400 allow ospf from any to any via igb0 00624 allow tcp from any to 192.168.254.254 dst-port 1723 in recv igb0 00650 allow tcp from table(1) to 192.168.254.254 dst-port 1001 in recv igb0 00651 allow ip from 192.168.254.0/24 to 192.168.254.254 in recv igb0 00652 allow ip from 172.16.111.0/24 to 192.168.254.254 in recv igb0 00653 allow icmp from any to 192.168.254.254 in recv igb0 00800 nat tablearg ip from table(10) to any out xmit igb1 00800 nat tablearg ip from any to table(30) in recv igb1 10000 allow ip from table(3) to any 10001 allow ip from any to table(3) 11111 allow ip from me to any out 65000 deny ip from any to any 65535 allow ip from any to any /var/crash остается пустым, хотя по всем параметрам там должен оказываться дамп ядра. Словом - незачто зацепиться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 6 марта, 2012 (изменено) · Жалоба сколько адресов в третьей таблице? я к тому спрашиваю, что лишний матчинг делается при таком виде правил :) Изменено 6 марта, 2012 пользователем lagman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 6 марта, 2012 · Жалоба 5k правил в ней. Остальные таблицы для админов и для разбиения нат-адресов по подсетям. Там совсем мало записей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 6 марта, 2012 · Жалоба Тоже были ребуты на 9.0 + MPD5. Вырезал из ядра ipv6 - рубутов нет. (полтора месяца). Сейчас на одном серваке вернул ipv6. (Начал в туннели раздавать). Посмотрим что будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 6 марта, 2012 · Жалоба У нас ядро GENERIC просто с инклюдом кернел-ната и нетграф. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 6 марта, 2012 (изменено) · Жалоба 5k правил в ней. Остальные таблицы для админов и для разбиения нат-адресов по подсетям. Там совсем мало записей. 10000 allow ip from table(3) to any 10001 allow ip from any to table(3) Я бы поменял например на allow ip from table(3) to any recv igb0 in allow ip from table(3) to any xmit igb0 out А вообще из практики: пока не развели направления трафика (вход, выход, внешка, пиринг) по разным skipto - ребутились машинки и на 7х и на 8х ветках. Ребутится именно из-за избыточного матчинга по таблицам в ipfw при директ диспатчинге :( PS: причем ребутилось рандомно, не в пики нагрузки Изменено 6 марта, 2012 пользователем lagman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 6 марта, 2012 · Жалоба Спасибо за совет. Мы не стали уточнять направления для этих правил в связи с тем, что по факту это множество интерфейсов ngX. Теоретически, внешний интерфейс igb0 должен определять направления трафика от и для нат-пула до маскировки и соответственно после. Сейчас поковыряюсь с этим. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 6 марта, 2012 · Жалоба Замечу, что правила recv ... in xmit ... out это как "масло масленное". recv это альяс для in, xmit, соответственно, для out. Поправьте, если я неправ. Спасибо за совет. Мы не стали уточнять направления для этих правил в связи с тем, что по факту это множество интерфейсов ngX. Теоретически, внешний интерфейс igb0 должен определять направления трафика от и для нат-пула до маскировки и соответственно после. Сейчас поковыряюсь с этим.Штука в том, что поиск в правилах идёт, насколько мне помнится, от конца правила, так что теоретически заданием интерфейсов вы сильно уменьшаете количество проверок в ipfw. Правда, говорят что "via ng*" может быть даже хуже по производительности, чем отсутствия указания - как-то там "не так" ipfw проходит по списку интерфейсов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 6 марта, 2012 · Жалоба Замечу, что правила recv ... in xmit ... out это как "масло масленное". recv это альяс для in, xmit, соответственно, для out. Поправьте, если я неправ. Нет, это разные вещи. Один признак матчит на входе/выходе в ip_input/ip_output, другой матчит по интерфейсу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 6 марта, 2012 · Жалоба Правда, говорят что "via ng*" может быть даже хуже по производительности, чем отсутствия указания - как-то там "не так" ipfw проходит по списку интерфейсов. Согласен. Именно по этому я стараюсь избегать таких вольностей как ng*. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 6 марта, 2012 · Жалоба Нет, это разные вещи. Один признак матчит на входе/выходе в ip_input/ip_output, другой матчит по интерфейсу. А можно чуть подробнее расписать прохождение пакета в обоих случаях? Я полагал, что recv $iface == via $iface in. Согласен. Именно по этому я стараюсь избегать таких вольностей как ng*. А кто-нибудь вообще проверял это поведение? А то я последний раз проверял это лет эдак 4-5 назад. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 6 марта, 2012 · Жалоба Вобщем, никакие in, recv не помогают. При указании направлений трафика всё отваливается у конечного пользователя. По этому остановился на таком сценарии: 10000 1200775 1174900483 Tue Mar 6 18:51:26 2012 allow ip from any to table(3) in recv igb1 10001 62726 9453822 Tue Mar 6 18:51:11 2012 deny ip from any to 10.10.0.0/16 in recv igb1 10002 1155796 330462590 Tue Mar 6 18:51:26 2012 allow ip from 10.10.0.0/16 to any 10003 1191741 1174078430 Tue Mar 6 18:51:26 2012 allow ip from any to 10.10.0.0/16 Теперь обращение к таблице №3, содержащей 5к записей происходит лишь в одном правиле. Правило №10000 охватывает только входящий трафик, в котором прослеживаются серые адреса пользователей после деалиасинга и позволяет отдавать его пользователям с включенным инетом. Следующее правило со схожими признаками блокирует доступ всем остальным. Теперь для того чтобы трафик смог свободно ходить по виртуальным интерфейсам ng* создаем входящую и исходящую трубу без указания интерфейсов и направлений. Такая схема лучше предыдущей только за счет более редкого обращения к таблицам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 6 марта, 2012 · Жалоба А кто-нибудь вообще проверял это поведение? А то я последний раз проверял это лет эдак 4-5 назад. Сомневаюсь, что load average или еще что подскочит так что будет заметно на глаз. Меня волнует прежде всего стабильность работы, по этому спустя пару перезагрузок при текущем конфиге попробую указать ng* в своих правилах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 6 марта, 2012 (изменено) · Жалоба чото я совсем запутался :) а юзеры с реальными адресами через нас ходят? и как маршрутизируется трафик извне до клиентов на насе? что до ng* - у меня ipfw add 50 deny log logamount 100 ip from any to any not verrevpath recv ng* уже не первый год без проблем используется Изменено 6 марта, 2012 пользователем lagman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 6 марта, 2012 · Жалоба Про внешних я забыл и только щас вспомнил. На насе установлен белый IP. Нас выполняет шейпинг, нат, pptp, netflow. Буду перестраивать на ng* завтра утром. Пока всё вернул взад. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 6 марта, 2012 · Жалоба Просто если с бордера до наса трафик заворачивается статикой, то вполне вероятна такая ситуация: пакет на реальный адрес прилетает с внехи, уходит по статике на нас, на насе такого клиента нет, нас заворачивает трафик обратно на дефолт, и так пока ттл не кончится :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 6 марта, 2012 · Жалоба В этом плане всё нормально, NAS с бордером в одной подсети, активные туннели белые через прокси-арп видны на циске. С этим проблем нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 6 марта, 2012 · Жалоба Про арп-прокси я слышал плохие вещи, у меня /32 клиентские по оспф ходят. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 6 марта, 2012 · Жалоба net.link.ether.inet.proxyall=1 Вот за счет этого белые pptp адреса видят инет. Дело в том, что маршрутизации никакой нету. Достаточно весь трафик с наса направить на стандартный шлюз из этой же подсети. Можно конечно поизвращаться и сделать DMZ, но такой вариант у нас обкатан годами и всем устраивает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 6 марта, 2012 · Жалоба У нас ядро GENERIC просто с инклюдом кернел-ната и нетграф. GENERIC как раз и включает в себя ipv6. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 6 марта, 2012 · Жалоба У нас ядро GENERIC просто с инклюдом кернел-ната и нетграф. GENERIC как раз и включает в себя ipv6. У меня с генериком все ОК Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 6 марта, 2012 · Жалоба Правда, говорят что "via ng*" может быть даже хуже по производительности, чем отсутствия указания - как-то там "не так" ipfw проходит по списку интерфейсов. Тут в параллельном топике на такое утверждение меня поправили, что я редко заглядываю в сорцы и все там уже "не все так плохо" :) http://forum.nag.ru/forum/index.php?showtopic=72378&view=findpost&p=694954 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...