Jump to content
Калькуляторы

Отзеркалировать порт с трафиком radius ибо арендуем СОРМ у другой компании

Есть ситуация:

наконец-то про нас "вспомнили" органы и прислали бумажку, чтобы мы купили СОРМ либо договорились СОРМиться у кого-нить "выше" по сетевой иерархии.

Вроде как за деньги договорились СОРМиться у вышестоящего - все равно наш траф идет через них, и у них уже устанвлен СОРМ.

Но нужно еще сыпать радиус трафик с наших NASов - чтобы органы "знали" в реалтайие - кто сейчас с каким IP - ибо IPы раздем белые динамически (через RADIUS в юзерские тунели).

Я предложил им отсылать radius логи на указанный ими IP в формате syslog - но они сказали "нет", мол, "нам нужен сырой радиус трафик".

 

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

 

Если через L3 сети живьем - то не отроутиться - ибо в пакетах будут src и dst IP - моих NASов и Биллинга.

Значит надо как-то во что-то завернуть (инкапсулировать) и на другой стороне развернуть.

 

Или может пробовать вариант с L2 - VLAN прокинем от меня до места сбора этого трафика. Но тоже проблема свитчинга на свчиах - там с маками будут непонятки - ибо опять же в пакетах будут src и dst MAC - опять же биллинга и NASов - причем трафик "в обе стороны" и буду пакеты с одной парой MAC, как srcMAC1 -> dstMAC2, так и srcMAC2 -> dstMAC1.

Транзитным свичам мозг свернет. Как-то надо что-ли отучить свичи изучать маки. Но там вроде только отучаются на отдельных портах. Но нет отдельных портов и волокон для отзеркаленного трафа - все будет идти в тех же волокнах через теже порты (но в другом VLAN), что и трафик юзеров.

Хотя может все таки прокатит на этих портах отключить изучение маков (learning) или время жизни поставить = 0, а для основного трафика сделать какие нить статические записи MAC ?

 

парни, подскажите, плиз. (девушки тоже - если бывают тут такие админшы : )

Edited by dr.Livci

Share this post


Link to post
Share on other sites

Ключевые слова - span, rspan.

Share this post


Link to post
Share on other sites

dr.Livci

Организация сормирования радиус трафика зависит от того как именно сливает ваш трафик ваш аплинк на СОРМ. Если он зеркалирует ваш порт или ваш сабинтерфейс целиком, то можно засунуть радиус-трафик вместе с обычным(и пофиг какие IP и mac-и там будут, лишь бы dst мак не совпадал с mac-адресом L3-интерфейса вашего аплинка). Если же ваш трафик зеркалирует где-то дальше("в общей трубе"), то нужно купить/договориться у вашего аплинка L2VPN с небольшой скоростью для слива радиуса на СОРМ

 

Как вы будете коммутировать/маршрутизировать трафик в вашей сети это уже тривиальный(и чисто технический) вопрос. на "железках" это всяческие span-ы(как выше уже подметили), на linux-е это 'iptables <classifier радиус трафика> -j TEE <куда сливать>' + статический arp(маки ставьте рандомные, СОРМу они не интересны)

Share this post


Link to post
Share on other sites
то можно засунуть радиус-трафик вместе с обычным(и пофиг какие IP и mac-и там будут

 

У нас приблизительно где-то так:

 

Наши волокна идут на местный "узел связи" - там магистрал со своими свичами и роутерами и пирингом и другими клиентами. Еще в нашем городе у нашего вышестоящего есть тоже другие клиенты. Причем магистрал - не равно наш вышестоящий.

Наш вышестоящий сам арендует инфраструктуру у магистрала между городами.

 

 

 

 

про SPAN и RSPAN почитал. Но это похоже фишка у каталистов только ?

 

Cуть то вообщем ясна и простая. И как я понял - можно с помощью iptables - замутить

 

спс

Edited by dr.Livci

Share this post


Link to post
Share on other sites

dr.Livci

Нарисуйте схему вашего центрального узла(особенно важны релейшны между asbr, bras, радиус-сервером и включением аплинка), тогда можно будет подсказать как именно вы можете слить трафик.

И почему пофиг какие там ипы и маки?

Главное сообщить IP радиус-сервера, а какой именно он будет - пофиг. Маки(и вообще L2 заголовок) не интересен для СОРМа в контексте обработке радиус-трафика.

 

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

Share this post


Link to post
Share on other sites

В целом суть мне ясна.

Но нужно для начало обсудить с вышестоящим.

 

1. Если все таки весь мой трафик идет в VLANе через магистрала "прозрачно" без всяких извращений до площадки моего вышестоящего, где СОРМ - то тогда да - я подмешаю туда RADIUS трафик и пусть разгребают (IP адрес радиус сервера будет идти живьем и он известен и = const).

 

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

 

Но скорее всего трафик не идет по L2 до площадки с СОРМ - а роутиться сквозь инфраструктуру "промежуточного" оператора.

 

тогда

 

2. Можно с помощью iptables маркировать радиус трафик и отроутить его на указанный хост с помощью iptables tee. Но Хост должен быть в одной подсети. Нельзя указать конечный роутер в цепочке - промежуточные роутеры уже ничего не знают про мои хотелки и маркировку - промежуточный роутер увидит "живой" IP адрес назначения - который равен ипу моего радиус сервера и вернет его согласно таблицы маршрутизации (если этот ип - белый, а вообще он серый - и просто "занулится"). Таким образом не дойдя до площадки с СОРМ.

 

Значит нужно установить ipip тунель с моей площадки на площадку с СОРМ и уже скопировать радиус траф с помощью все того же iptables tee внутрь этого тунеля.

А там уже пусть ловят. Только надо договориться, чтобы они согласились там IP тунель поднять. (кстати вариантов тунелей дофига, и наспыпать в тунель тоже рзные варианты - если на биллинге вдруг netfilter не умеет tee, или по другим причинам нет возможности прямо там замутить тунель - можно опять же отзеркалить порт свича, в который всунут биллинг, насыпать этот траф на отдельную машинку, сбриджевать физ фейс с тунелем и т.д. и т.п. ))))

 

Кстати - почитал ман к своим свичам - они умеют мирроринг трафика по различным критериям. Но адрес назначения указать нельзя - опять же - только выбрать mirror порт .... (Это вам не SPAN/RSPAN :)

 

3. На микротике есть прикольная фича - sniffer - умеет "копировать" на удаленную машину трафик с нужными критериями). Причем трафк этот инкапсулируется в TZSP (Tazmen Sniffer Protocol) - т.е. можно слать через множество L3 хопов, в отличие от iptables tee (где трафик копируется живьем). Но нужно "развернуть" трафик на принимающей стороне. Кстати, Wireshark , без всяких доп настроек разворачивает эти пакеты.

И на сайте микротика есть утилита, которая для этого предназначена trafr - Traffic sniffer reader for Linux distributions (http://www.mikrotik.com/download/trafr.tgz)

Просто готовый скомпилированный испольняемый файлег - не требует ни прав рута, ни сборки, ни инсталяции и прочих зависимостей.

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

 

usage: trafr <file | -s> [ip_addr]

-s write output to stdout. pipe it into tcpdump for example:

./trafr -s | /usr/sbin/tcpdump -r -

ip_addr use to filter one source router by ip address

 

 

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

 

 

4. ??? Ваши дополнения и замечания

Edited by dr.Livci

Share this post


Link to post
Share on other sites

В целом суть мне ясна.

Но нужно для начало обсудить с вышестоящим.

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

Как уже выше сказали, вариантов может быть ровно два:

 

1. Ваш RADIUS трафик отдельным портом

2. Ваш RADIUS трафик примешан к порту зеркала трафика аплинка

 

В любом случае, нужно доводить RADIUS трафик до оборудования вышестоящего провайдера, и уже этот провайдер будет отдавать ваш трафик на свой СОРМ. Да, органы не будут что-то специально для вас настраивать, но вы уже договорились с вышестоящим провайдером, что он за деньги организует вам эту услугу. А как это технически реализовать - либо ERSPAN over layer 3 links, либо программно - это уже детали, которые нужно обсуждать с провайдером.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this