Хранение NAT трансляций.

[unfraget]

Здравия!

 

Коллеги, назрел вопрос о объеме данных под хранение nat трансляций.

Сейчас собираем по средствам syslog далее парсим в пригодный вид, но так или иначе получается очень много.

 

nfdump не подошел, хоть и хранит в бинарном виде, но не показывает inside global и otside local, лишь inside local и outside global, посему пришлось использовать syslog

 

Кол-во пользователей порядка 15-20к которые будут за nat.

 

Воот, хотелось бы узнать какой объем нужен под данное кол-во пользователей, т.к при расчетах получилось 3ПБайт за 3 года, а это ооочень много

[dazgluk]

Храним nfdump + статическую табличку трансляций local/global

Порядок абонентов тот же, получается ±100ТБ на три года

[unfraget]

dazgluk

Спасибо!

[mightyscv]

Посмотрите в сторону port block allocation nat. Существенно снизит объёмы логов.

[alibek]

Так порты нужно выделять блоками и агрегировать.

Что используется под NAT?

[dazgluk]

А подскажите, за счёт чего экономится место с PBA? Ведь типовой запрос предполагает "кто с адреса <NAT ip> ходил на ВК/мейлру/etc". Dst IP на каждое соединение свой, соответственно либо не хранить Dst IP и отдавать всех, у кого был PBA в <NAT ip>, либо хранить Dst IP и сводить на ноль всю экономию...

[darkagent]

за счёт чего экономится место с PBA?

Последний абзац вкратце описывает

http://net-labs.in/2014/11/04/nat-napt-и-cg-nat-на-оборудовании-cisco-asr1000-csr1000v/

 

Естественно, придется допиливать коллекторы и, возможно, логику обработки и хранения.

На практике экономия выходит очень приличной.

[dazgluk]

за счёт чего экономится место с PBA?

Последний абзац вкратце описывает

http://net-labs.in/2014/11/04/nat-napt-и-cg-nat-на-оборудовании-cisco-asr1000-csr1000v/

 

Естественно, придется допиливать коллекторы и, возможно, логику обработки и хранения.

На практике экономия выходит очень приличной.

Если я правильно понимаю теорию PBA - то там нет Destination IP, если лишь факт выделения портов на NAT-IP для нужд INT-IP

Вопрос - как на запросы без Destination IP отвечать?

 

Отдавать всех, у кого есть PBA с запрошенного SRC IP в запрошенный момент?

Либо таки логгировать Destination IP, но тогда не понятно - в чем экономия?

[Andrei]

Естественно, придется допиливать коллекторы и, возможно, логику обработки и хранения.

На практике экономия выходит очень приличной.

Если хранить надо для СОРМа, то агрегировать данные нельзя :(

[darkagent]

Если хранить надо для СОРМа, то агрегировать данные нельзя :(

Складывается впечатление, что документацию либо не читали, либо читали по диагонали.

Весь фокус в том, что вы получаете меньший объем логируемых данных без потери информативности - взаимодействия точка-точка при Nном количестве соединений укладываются (технически, т.е. на уровне распределения ресурсов) в один(+) порт-блок;

Если вы собираете flow с внешки (на бордерах), то с ната достаточно будет брать данные в следующем объеме:

старт трансляции, стоп трансляции, локальный ip (nat in), внешний ip (nat out), протокол, номер блока портов, размер блока - int,int,int,int,tinyint,tinyint,tinyint.

- фактически то что отдает вам ip nat log translation при включенном mode cgn + pap/bpa;

Остается только следить за синхронизацией времени на сенсорах и при запросах из органов делать перекрестную выборку используя штатные flow данные и очень компактный лог трансляций.

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

p.s. размер блока лучше все-таки хранить, особенно если железок с натом много, чтоб не гадать с настройками при масштабировании.

[Умник]

старт трансляции, стоп трансляции, локальный ip (nat in), внешний ip (nat out), протокол, номер блока портов, размер блока - int,int,int,int,tinyint,tinyint,tinyint.

Пример из реальной жизни. Запрос: кто заходил на ВК с IP-адреса X в ЧЧ:ММ:CC 31 июня н-года. Мы выяснили, что в IP-адрес из запроса в указанное время транслировалось 20 человек. Каждый из них потенциально мог ходить на ВК. Кого из них выдавать органам, исходя из того, что мы сохраняем данные в приведенном выше формате, а Вконтакте у себя не записывает TCP src port number?

 

Учитывайте, что органы иногда даже не говорят (не хотят говорить), куда ходил абонент. Просто хотят знать кому именно выдавался IP-адрес X в момент времени Y. То есть даже если мы все-таки храним destination IP при overload NAT, на такой запрос не ответишь определенно.

[darkagent]

Учитывайте, что органы иногда даже не говорят (не хотят говорить), куда ходил абонент

В таких случаях подготавливается список "кандидатов" и скидывается как есть - если захотят получить более точные данные, будут уточнять и недостающие условия задачи. Плавали, знаем, опыт по взаимодействию наработали приличный.

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

[alibek]

Если хранить надо для СОРМа, то агрегировать данные нельзя :(

Смотря что называть агрегированием.

 

Если говорить за обычный overload NAT, то в общем случае одна трансляция соответствует одной абонентской сессии.

И хранить приходится фактически сессии, а не трансляции.

Но если при трансляции порты выделять блоками, то одна трансляция будет соответствовать большому числу сессий одного абонента.

И объем хранимых данных может снижаться даже не в разы, а на порядки.

[Andrei]

Если хранить надо для СОРМа, то агрегировать данные нельзя :(

 

Складывается впечатление, что документацию либо не читали, либо читали по диагонали.

 

Документацию на что?

 

Если вы собираете flow с внешки (на бордерах), то с ната достаточно будет брать данные в следующем объеме:

старт трансляции, стоп трансляции, локальный ip (nat in), внешний ip (nat out), протокол, номер блока портов, размер блока - int,int,int,int,tinyint,tinyint,tinyint.

 

В требованиях к СОРМ описано вполне конкретно что должно накапливаться в ИС оператора. И эти требования не совпадают с вышеприведенным вами примером.

 

Если хранить надо для СОРМа, то агрегировать данные нельзя :(

 

Смотря что называть агрегированием.

 

Если говорить за обычный overload NAT, то в общем случае одна трансляция соответствует одной абонентской сессии.

И хранить приходится фактически сессии, а не трансляции.

Но если при трансляции порты выделять блоками, то одна трансляция будет соответствовать большому числу сессий одного абонента.

И объем хранимых данных может снижаться даже не в разы, а на порядки.

 

Если честно, то не понял разницу между сессиями и трансляциями.

[dazgluk]

darkagent, получается что с PAP/PBA сырой Netflow один фиг хранить пусть и с бордеров? PBA просто позволяет не хранить его второй раз до НАТа, а хранить лишь лог PBA?

[alks]

Учитывайте, что органы иногда даже не говорят (не хотят говорить), куда ходил абонент

 

В таких случаях подготавливается список "кандидатов" и скидывается как есть - если захотят получить более точные данные, будут уточнять и недостающие условия задачи. Плавали, знаем, опыт по взаимодействию наработали приличный.

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

 

 

+1

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

но учитывая оба запроса круг товарищей сужается

вообще это дело такое, пришел внучок к бабушке и нагадил с ее wifi в сети а опера потом репу чешут ))

[darkagent]

а хранить лишь лог PBA?

Да, причем, как я уже ранее сказал - выходит очень компактно. Разница с классическим NAT выходит сотне, а то и тысячекратная по объемам.

 

вообще это дело такое

Обычно, уже с первой попытки остается 1, максимум 2 потенциальных кандидата в победители, если конечно время указывают с точностью до секунд, или хотя бы до минуты.

[darkagent]

Почему вы так решили?

Наверное потому, что указанные вами данные в миллионы раз проще и компактнее учитывать на уровне аккаунтинга, и при этом netflow не требуется вовсе. Целевое назначение netflow - сбор и анализ данных по трафику, а никак не учет сессий. Другое дело, что некоторые биллинговые системы "изкаропки" не умели радиус-аккаунтинг и выживали исключительно на netflow, который при этом умудрялись частично терять (здравствуй utm5), в следствии чего у некоторых просто происходила подмена понятий. Не, ну конечно никто не мешает вам собирать netflow до и после ната, и жить с этим, если конечно вас устраивает городить хранилища на сотни терабайт ради избыточных данных.

[Andrei]

Ладно. Видимо я не понимаю какой-то тонкости. В любом случае мой ЛанБиллинг при работе юзеров по pptp/pppoe не умеет собирать нужные данные радиус-агентом. Такие данные умеет собирать только "кабельный" агент (netflow-агент). Поэтому приходится направлять эти данные с циски, где терминируются pptp/pppoe, на линух, где уже стоит коллектор, кстати netams, который вроде потом вошел в состав NetUp-а.

[Andrei]

Почему вы так решили?

Наверное потому, что указанные вами данные в миллионы раз проще и компактнее учитывать на уровне аккаунтинга, и при этом netflow не требуется вовсе. Целевое назначение netflow - сбор и анализ данных по трафику, а никак не учет сессий.

Что вы подразумеваете под сессией? Если pptp/pppoe-сеанс, то это одно и такой учет для СОРМа малоинтересен. Если сессия - это каждое соединение внутри pptp/pppoe-сеанса, то не вижу как их можно накапливать компактней в десятки раз, как вы пишете.

[darkagent]

Что вы подразумеваете под сессией?

 

То, что было описано в удаленном вами посте. ppp/isg-сессии подходят под это, при условии что выдаются белые адреса, а чтоб они соответствовали полностью при nat - надо держать логи трансляций.

Radius auth/acct, особенно в связке с isg, дает очень обширный объем информации и возможности управления - остается только найти хорошего программиста (а то и не одного), который построит логику приложений и автоматизирует весь необходимый процесс.

Продукты "из коробки", к сожалению, делаются на базовом уровне и без нормального программиста в штате не пригодны к пользованию, тем более на операторском уровне.

 

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

[Andrei]

Что вы подразумеваете под сессией?

То, что было описано в удаленном вами посте. ppp/isg-сессии подходят под это, при условии что выдаются белые адреса, а чтоб они соответствовали полностью при nat - надо держать логи трансляций.

Под СОРМ хранить статистику по ppp-сессиям не достаточно. Надо хранить сессии в трактовке "этот абонент скачал в такое-то время с такого-то сайта столько байт". ppp/isg-сессии НЕ подходят под это

[darkagent]

Ок. На этом и закончим дискуссию.

[Ivan Rostovikov]

>Надо хранить сессии в трактовке "этот абонент скачал в такое-то время с такого-то сайта столько байт

Вы это сами придумали или сказал кто ?

Можете указать на регламентирующие документы ?

[Andrei]

Вы это сами придумали или сказал кто ?

Можете указать на регламентирующие документы ?

Зачем бы я придумывал себе этот гемморой? :)

Из вышеприведенных постов очевидно откуда взято требование - из ТУ к ИС в рамках плана СОРМ.

Обоснование - Постановление Правительства РФ от 27 августа 2005 г. N 538 "Об утверждении Правил взаимодействия операторов связи с уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность" (п.14)