А есть ли кто-нибудь, кто знает, как собирать статистику nat translation для FreeBSD? Аналог N(S)EL у Cisco и sysctl nat.netflow.nat_events у ipt_NETFLOW в Linux.

ng_netflow уже лет пять не менялся, если не больше. (

ng_netflow уже лет пять не менялся, если не больше. (

Он стабилен

Он стабильно с отсутствующей важной фичей, да

У меня вопрос не про стабильность, так-то

O_o

Я не понял сути вопроса — что именно нужно собирать?

— netflow по трафику, который потом NAT'ится?

— netflow по трафику, который потом NAT'ится?

лог нат трансляций наверное хочет

так то можно собрать до ната, этого обычно должно быть достаточно

так то можно собрать до ната, этого обычно должно быть достаточно

в том-то и дело, на внутреннем интерфейсе

А а чем проблема, я просто не понимаю

Да чё гадать(?) :)

Кстати, кто потом как обрабатывает дампы

Например в базу для поиска

А то лежат грудой файлов

А вообще интересно, можно ли с pf выгружать трансляции и реализовать PBA с выдачей сразу блоков адресов

pfctl -s выгружаит жы

что как бы намекаэ

а так чтобы потоком

куданить в сислог

патчег нужен будет, скорее всего

Но я бы даже поигрался ))

Цгнат с сормом может человек городит

Вот и интересно ему, куда что странслировалось

а чо, с ipfw nat тоже можно выгружать?

Сразу видно, кто в провайдере работает, а кто нет ;)

а зачем весь этот огород? ng_ipacct на внутреннем интерфейсе все расскажет

Типичный вопрос от органов: "кто выходил с $внешний_ip на vk.com в $datetime?"

Ваши варианты вааще в этом не помогут

Поэтому да, нужен лог nat трансляций

Как это сделать на цисках или в Линуксе, я привёл пример

Типичный вопрос от органов: "кто выходил с $внешний_ip на vk.com в $datetime?"

угу. я такие вопросы обрабатывал =(

Да они нам пачками приходят. Задолбали уже :(

не нужен лог трансляций, н втруннем интефейсе будет src из приватной сети и dst из vk.com

не нужен лог трансляций, н втруннем интефейсе будет src из приватной сети и dst из vk.com

И как его сопоставить с внешним адресом?

а их много внешних адресов? как правило он либо один, либо правила кто в кого натятся прибиты гвоздями в nat.conf

И как его сопоставить с внешним адресом?

Я подсети прибиваю тоже к адресам

Ну так не 1:1 прибиваете-то?

Как бы то ни было, ваши методы расследования требуют полного лога соединений

Что не есть удобно и красиво

+100

Ну ладно, не полного, но :80 и :443

Но трек не менее, однозначно гарантированно сопоставить будет трудно

Тем не менее

Да этого тоже дохрена всё равно, учитывая, что vk надо все адреса искать, учитывая и их cdn

Ваши варианты вааще в этом не помогут

чо блять не помогут то

у тебя есть айпи до ната и dst vk.com

ты точно продюссер? ©

бля. links preview задолбали

внешний nat ip вообще побоку в этой ситуации

внешний nat ip вообще побоку в этой ситуации

Речь о том, что из органов обычно приходит только внешний адрес и дата и если у тебя не прибитые адреса, особенно на физиках, то это надо логировать постоянно конечно же

Не понятно другое, в чем проблема то

netflow v9 вроде умеет. главное сдать это

netflow v9 на чём? На FreeBSD? )

да, на FreeBSD

с pf'ом в связке?

pf и провайдерские задачи далеки друг от друга

только ipfw

да ладно, расскажи мне

У меня на гейтах одновременно работали ipfw и ipfilter, например

ровно тоже самое можно сделать и с pf'ом. Тем более для трансляции я бы именно pf предпочёл, чем ковыряние с netgraph, например

Не рассказываю, высказываю мнение, то что можно все вместе, еще и netgraph сбоку зачемнибудь никто не спорит

Но кто сказал, что это нужный дизайн?

pf и провайдерские задачи далеки друг от друга

ну это очень резкое суждение, так сказать

ERROR: S client not available

стейтфул не всегда круто

скажем так

хех

Особенно на транзите

на транзите NAT делать будешь?

а что провайдер что-то еще делает

?

если будешь, будет stateful. Не будешь — не надо, о чём речь тогда вобще

Ну где-то его надо будет сделать

где NAТ там и states

Ну так разница же, блин

только нат-ы

или вся сессия

Вы нагрузите серьезно pf

что значит вся сессия? O_o

как нибудь

Алексей, вы что-то про NAT не понимаете

Возможно, но и pf под болшой нагрузкой не справляется с задачей

да и не под большой :)

это глупое утверждение

всегда можно сделать такую нагрузку, что одна точка не будет справляться

И практически всегда нагрузку можно разнести на несколько точек обработки

Я делал так с дохлыми Cisco, причём безо всякого state exchange

И это правда, но когда он не работает также при прочих равных, из-за того, что более ресурсоемкий, я не понимаю зачем продолжать спор

Иначе бы смысла не было

Ну причем тут циски

Да при том, что коробочек можно поставить несколько. Если у вас одна не справляется

И не важно, что там Cisco или FreeBSD

Если есть такие тазики, просто сравните

Да при том, что коробочек можно поставить несколько. Если у вас одна не справляется

Не всегда хочется зоопарк разводить всем

это не зоопарк

Можно, как я уже писал выше - все что угодно