Зеркалирование трафика: Объяснение зеркалирования портов: основы, конфигурация & чаво

Содержание

Объяснение зеркалирования портов: основы, конфигурация & чаво

Купить FS коммутаторы для обеспечения защитной работы Ващей сети

Что такое зеркалирование портов?

Зеркалирования портов— технология дублирования пакетов одного порта сетевого коммутатора (или отдельной VLAN) на другом. Большое количество управляемых сетевых коммутаторов позволяют дублировать трафик от одного или нескольких портов и/или VLAN на отдельно взятый порт.

Зеркалирования портов используется на сетевом коммутаторе или маршрутизаторе для отправки копии сетевых пакетов, видимых на указанных портах (исходный порт), на другие указанные порты (порт назначения). При включенном зеркалировании портов пакеты можно отслеживать и анализировать. Зеркалирование портов применяется широко, например, сетевые инженеры могут использовать зеркалирование портов для анализа и отладки данных или диагностики ошибок в своих сетях, без влияя на возможности обработки пакетов сетевых устройств. А Министерство культуры и общественной безопасности могут собирать связанные данные из зеркалирования портов для анализа поведения сети, чтобы обеспечить здоровую сетевую среду.

Как работает зеркалирование портов?

Локальное и удаленное зеркалирование портов — это два типа зеркалирования портов, основанные на разных рабочих диапазонах зеркалирования. Они работают по разным принципам.

Локальное зеркалирование портов является наиболее простой формой зеркалирования. Все исходные порты расположены на том же сетевом устройстве как порт назначения. Как показано на рисунке 1, зеркалирование локального порта позволяет сетевому коммутатору переслать копию пакета с исходного порта (Eth 1/1) на порт назначения (Eth 1/2). Затем устройство мониторинга, подключенное к порту назначения, может отслеживать и анализировать пакет.

Что касается зеркалирования удаленных портов, исходные порты и порты назначения не находятся на одном устройстве. Как показано на рисунке 2, исходные порты (Eth 1/3) находится на одном коммутаторе, а порт назначения (Eth 1/3) — на другом коммутаторе. Исходный порт пересылает копию пакета на порт назначения через соединение восходящей линии связи, достигнутое портом (Eth 1/4) на двух коммутаторах. Следовательно, зеркалирование локальных портов позволяет осуществлять мониторинг и анализ данных на разных устройствах.

Общие чаво и решения

1. Как настроить зеркалирование портов?

Обязательным условием настройки зеркалирования портов является обеспечение того, что сетевое устройство (независимо от коммутатора или маршрутизатора) поддерживает зеркалирование портов. Затем выберите один из режимов: зеркалирование локальных портов или настройка зеркалирования удаленных портов.

Схема конфигурации зеркалирования локального порта

:

1. Создайте VLAN.

2. Добавьте порт источника и порт назначения в VLAN.

3. Настройте IP-адрес.

4. Настройте зеркалирование порта на порте назначения и скопируйте пакет с исходного порта на порт назначения.

План настройки зеркалирования удаленных портов:

1. Создайте исходный порт в глобальной схеме.

2. Настройте порт восходящей связи на одном коммутаторе.

3. Создайте порт назначения в глобальной схеме.

4. Настройте порт восходящей линии связи на другом коммутаторе.

Обратите внимание, что:

1. Конфигурация вступает в силу после установки одного порта в качестве порта источника и установки другого порта в качестве порта назначения в зеркалировании локального порта.

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

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

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

5. Рекомендуется не применять STP, RSTP или MSTP к порту назначения, в противном случае устройство может работать со сбоями.

2. Зеркалирование портов и зеркалирование трафика, в чем разница?

Зеркалирование порта и Зеркалирование трафика относятся к функции зеркалирования.

Зеркалирование трафика — функция коммутатора, предназначенная для перенаправления трафика с одного порта коммутатора на другой порт этого же коммутатора (локальное зеркалирование) или на удаленный коммутатор (удаленное зеркалирование). Как показано на рисунке 3, исходный порт копирует поток данных, соответствующий правилу от клиента 2 к порту назначения, который затем отправляет скопированный поток данных на устройство мониторинга. Соответствующий поток данных может быть установлен ACL (Access Control List) или командами конфигурации. При зеркалировании трафика на устройство мониторинга отправляется только выбранный или согласованный трафик, а при зеркалировании портов копируется каждый пакет, который проходит через интерфейс, на устройство мониторинга.

3. Зеркальное отображение портов и сопоставление портов: в чем разница?

Port mapping — это переадресация принимаемых данных таким образом, чтобы данные, принимаемые на какой-то порт одного компьютера автоматически переадресовывались на какой-то другой порт другого компьютера. Все передаваемые вами данные безо всяких искажений передаются на другой компьютер, который может быть расположен где угодно. Эта технология в чем-то аналогична прокси серверу, однако она гораздо проще и гораздо менее гибкая. Таким образом, port mapping — это процесс пересылки данных, а зеркалирование порта — это процесс копирования данных.

4. Как проверить зеркалирование портов?

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

Зеркалирование трафика на Juniper MX / Хабр

Сегодня мы поговорим о зеркалировании трафика на маршрутизаторах Juniper серии MX. После свичей производства Cisco, Huawei или Arista конфигурация SPAN и RSPAN на JunOS будет казаться очень сложной, но за сложной (на первый взгляд) конфигурацией скрываются огромные возможности платформы MX в области зеркалирования трафика. Подход Juniper хоть и на первый взгляд сложен, но становится прост и понятен, если не тупо копипастить конфиги с одной коробки на другую, а понимать, что и зачем делается. Идеология JunOS предполагает использовать filter based forwarding (FBF) в целях зеркалирования, что дает нам определенную гибкость в реализации сложных схем зеркалирования трафика.

Итак, начнем. Мы рассмотрим несколько примеров зеркалирования:

1. Локальное зеркалирование с порта на порт
2. Зеркалирование на два и более потребителя
3. Зеркалирование на удаленный хост
4. Избирательное зеркалирование на два и более потребителя
5. Локальное зеркалирование L2 трафика
6. Зеркалирование L2 трафика на удаленный сервер
7. Использование более двух mirroring инстансов на одном FPC

Итак, начнем по порядку.

Локальное зеркалирование с порта на порт.

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


Примечание: сначала я хотел использовать генератор трафика, но потом решил, что и сгенерированные hping3 tcp/udp/icmp пакеты, отловленные на анализаторе трафика (как анализатор использовался просто хост с ubuntu server 14.04 на борту) будут более наглядны, чем просто счетчики с портов в pps (можно к примеру сравнить актуальность отправленных и принятых данных). Счетчики же надо использовать при проведении нагрузочного тестирования для проверки производительности маршрутизатора при использовании данного функционала. Но на виртуальном MX проверять производительность нет смысла — все равно все упрется в возможности сервера вируализации.

Предположим, что между серверами Server-1 (11.0.0.1) и Server-2 (12.0.0.1) есть какой то обмен трафиком. Владельцы сервера Analyzer-1 хотят видеть, что именно передается между этими двумя серверами, поэтому нам надо настроить отправку копии всего трафика между Server-1 и Server-2 на Analyzer-1 — то есть сделать локальное зеркалирование. Итак, приступим.

В теории это должно работать так: мы создаем мирроринг инстанс, в котором указываем параметры входящего трафика (с какой периодичностью зеркалировать трафик) и исходящие параметры в какой или какие порты отравить трафик. Для того, чтобы направить трафик в созданный нами инстанс надо на интерфейс или интерфейсы, с которого(-ых) мы хотим снять копию трафика повесить специальный фильтр, который и завернет наш трафик в нужный инстанс. То есть это классическая схема policy base routing-а, ну или filter base routing-а в терминах Juniper. С теорией разобрались, теперь перейдем к практике — нам надо собрать такую схему зеркалирования:

Сначала нам надо создать инстанс в иерархии [edit forwarding-options port-mirroring], который мы будем использовать для зеркалирования трафика.

[edit forwarding-options port-mirroring]
[email protected]# show
instance {
    SPAN-1 {
        input {
            rate 1;
            run-length 0;
        }
        family inet {
            output {
                interface ge-0/0/1.0 {
                    next-hop 169.254.0.1;
                }
            }
        }
    }

Конфигурация инстанса состоит из двух частей. Сначала разберемся с секцией input — как не трудно догадаться, это параметры входящего трафика, который должен быть отзеркалирован. Тут важными являются параметры rate и run-length. Первый параметр отвечает за то, с какой частотой будут зеркалироваться пакеты (срабатывать триггер), второй параметр отвечает за то, сколько пакетов еще будет отзеркалировано после срабатывания триггера rate.

В нашем случае rate выставлен в 1, то есть каждый пакет будет отзеркалирован. Run-length выставлен в 0-ль, так как при rate, равным 1 его наличие не играет никакой роли.

Для полноты понимания разберем значение данных параметров на более наглядном примере. Параметр rate задает частоту зеркалирования трафика, предположим rate равен 5, то есть триггер будет срабатывать на каждом 5-м пакете, а значит каждый 5-й пакет будет отзеркалирован. Теперь предположим, что run-length установлен в 4. Это говорит нам о том, что еще 4-ре пакета будут отзеркалированы, после каждого 5-го пакета. То есть сначала сработал триггер на 5-м пакете — этот пакет будет отзеркалирован, теперь еще 4-ре пакета, следующие за уже отзеркалированным, будут тоже отзеркалированы. В итоге получим, что мы зеркалируем каждый 5-й пакет плюс еще 4 следующих за ним пакета — итого 100% трафика. Изменяя эти параметры можно отзеркалировать например каждые 10 пакетов из 100 и т д (ну это больше нужно для сэмплинга, нежели зеркалирования, просто принцип работы тот же).

Если вернуться к нашему случаю, то мы и так зеркалируем каждый пакет, поэтому параметр run-length нам просто не нужен и оставлен по умолчанию равный нулю.

Для расчета процента отзеркалированного трафика можно пользоваться формулой %=((run-length+1)/rate)*100). Логично что при параметрах run-length 1 и rate 1, мы получаем зеркалирование 200% трафика или например при rate 1 и run-length 4 — 500% трафика. Огорчу вас или обрадую — больше чем 100% трафика не отзеркалируется — размножать пакеты Juniper не станет, что более чем логично. Да и придумать сценарий, когда вам необходимо сделать две копии одного и того же трафика я так и не смог (если кто знает — пишите в комментарии).

И еще один важный параметр — maximum-packet-length. Это максимальный размер пакета, который будет отзеркалирован. Если вы выставите его например в 128, то при получении пакета, больше чем 128 байт (ну к примеру 1514), от него будет отрезаны первые 128 байт и отправлены потребителю. Остальная часть пакета будет просто отброшена. Это удобно, когда вам на сервер надо отправить только заголовки и пейлоад вам не нужен. Не рекомендуется ставить менее чем 20 для ipv4.

Теперь перейдем к output параметрам. Тут в общем случае нам необходимо указать интерфейс, в который мы ходим отзеркалировать трафик. В случае, когда у нас просто p2p интерфейс, то больше ничего указывать не надо — все и так полетит. Но как мы все помним, ethernet — это далеко не p2p (если быть точным то это csma/cd), и помимо интерфейса нам надо указать адрес хоста, которому предназначен трафик, как IP, так и MAC (но до этого мы дойдем чуть позже). Я выбрал адрес из диапазона линк-локал адресов, чтобы избежать каких либо пересечений с уже имеющимися адресами — вы же можете брать любую адресацию, это абсолютно не изменит ничего в принципе работы технологии. В ethernet чтобы отправить пакет какому то хосту, маршрутизатору необходимо выяснить MAC адрес это хоста с помощью ARP. В моем же случае на стороне сервера-получателя ничего не сконфигурено — просто пустой интерфейс и получится, что маршрутизатор будет тщетно пытаться разрезолвить адрес удаленного хоста. Естественно все зеркалирование на этом закончится. Как быть в данной ситуации? Все гениальное просто — делается статическая ARP запись:

[email protected]# show interfaces ge-0/0/1        
description Analyzer-1;
unit 0 {
    family inet {
        address 169.254.0.0/31 {
            arp 169.254.0.1 mac 02:00:00:00:00:01;
        }
    }
}

В итоге будем иметь вот такую запись на интерфейсе:

[edit]
[email protected]# run show arp interface ge-0/0/1.0  
MAC Address       Address         Name                      Interface               Flags
02:00:00:00:00:01 169.254.0.1     169.254.0.1               ge-0/0/1.0              permanent

Тут хотелось бы остановиться поподробнее. Теоретически вы можете отправить трафик на какой то реальный адрес, сконфигурированный на сервере, но самым простым и наиболее гибким подходом является создание фиктивного IP адреса и ARP записи в сторону потребителя трафика — то есть попросту мы заставляем Juniper думать, что за указанным интерфейсом находится указанный нами IP/MAC адрес, что в итоге заставляет коробку тупо слать туда трафик, не разбираясь, а есть ли там реально указанный хост или нет — главное чтобы порт был в up. Использование статической ARP записи в зеркалировании имеет большое преимущество — статическая ARP запись не устаревает, а так же маршрутизатор не станет отправлять на сервер ARP запросы (которые могут попасть в дамп снимаемого трафика, что не очень хорошо).

Теперь, что бы трафик стал зеркалироваться, нам надо его как то завернуть в созданный нами инстанс. Для этого используется filter base forwarding. Мы создаем фильтр и применяем его на интересующий нас интерфейс:

[edit]
[email protected]# show firewall family inet filter MIRROR>>>SPAN-1
term MIRROR {
    then port-mirror-instance SPAN-1;
}

[edit]
[email protected]# show interfaces ge-0/0/3      
description Server-1;
unit 0 {
    family inet {
        filter {
            input MIRROR>>>SPAN-1;
            output MIRROR>>>SPAN-1;
        }
        address 11.0.0.254/24;
    }
}

Так как нам надо собрать и входящий и исходящий трафик, то мы навешиваем фильтр на на оба направления.

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

Теперь можно проверить состояние сессии зеркалирования:

[email protected]> show forwarding-options port-mirroring
Instance Name: SPAN-1                         
  Instance Id: 2              
  Input parameters:
    Rate                  : 1
    Run-length            : 0
    Maximum-packet-length : 0
  Output parameters:
    Family              State     Destination          Next-hop
    inet                up        ge-0/0/1.0           169.254.0.1         

Судя по всему мирроринг в работе. Давай теперь запустим 5 пакетов с Server-1 на Server-2 и посмотрим, что мы сможем отловить на анализаторе Analyzer-1:

[email protected]:~$ sudo hping3 -S -c 5 12.0.0.1 -d 40 -I eth2
HPING 12.0.0.1 (eth2 12.0.0.1): S set, 40 headers + 40 data bytes
len=40 ip=12.C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Все не так радужно, из вывода видно, что у нас собственно ничего и не работает, хотя Juniper нам рапортовал в выводе выше, что все ок. Дело в том, что инстанс для зеркалирования можно создать самим (что мы и сделали) или же использовать дефолтный инстанс (он один на всю коробку). Если мы создаем инстанс сами, то мы должны ассоциировать данный инстанс с FPC, на которой мы делаем мирроринг (если порты на нескольких FPC — то значит ассоциировать с несколькими). Давайте вернем на Juniper и указем в конфигурации FPC созданный нами инстанс. Почему я на этом сделал акцент? Дело в том, что пару раз и сам на это натыкался и не мог понять в чем подвох — ведь выводы говорят, что все отлично.

[edit]
[email protected]# show | compare
[edit]
+  chassis {
+      fpc 0 {
+          port-mirror-instance SPAN-1;
+      }
+  }

Теперь снова проверим, работает ли зеркало:

[email protected]:~$ sudo hping3 -S -c 5 12.0.0.1 -d 40 -I eth2
HPING 12.0.0.1 (eth2 12.0.0.1): S set, 40 headers + 40 data bytes
len=40 ip=12.0.0.1 ttl=63 DF id=43901 sport=0 flags=RA seq=0 win=0 rtt=4.4 ms
len=40 ip=12.0.0.1 ttl=63 DF id=44117 sport=0 flags=RA seq=1 win=0 rtt=3.4 ms
len=40 ip=12.0.0.1 ttl=63 DF id=44217 sport=0 flags=RA seq=2 win=0 rtt=3.4 ms
len=40 ip=12.0.0.1 ttl=63 DF id=44412 sport=0 flags=RA seq=3 win=0 rtt=3.7 ms
len=40 ip=12.0.0.1 ttl=63 DF id=44416 sport=0 flags=RA seq=4 win=0 rtt=3.5 ms

--- 12.0.0.1 hping statistic ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 3.4/3.7/4.4 ms
[email protected]:~$ sudo tcpdump -i eth2 -B 4096
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
14:48:43.641475 IP 11.0.0.1.2237 > 12.0.0.1.0: Flags [S], seq 1075183755:1075183795, win 512, length 40
14:48:43.642024 IP 12.0.0.1.0 > 11.0.0.1.2237: Flags [R.], seq 0, ack 1075183796, win 0, length 0
14:48:44.C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

В итоге весь обмен трафиком между Server-1 и Server-2 попал на анализатор, чего мы и добивались.

Двигаемся далее, наша схема изменилась и теперь у нас появился Analyzer-2, который также хочет получать весь трафик между Server-1 и Server-2:

Зеркалирование на два и более потребителя

В итоге имеем очередную задачу — надо реализовать новую схему зеркалирования, которая выглядит так:

Вроде бы ничего сложного — создадим интерфейс в сторону Analyzer-2, добавим его в инстанс и дело в шляпе.

[edit]
[email protected]# show interfaces ge-0/0/2                                  
description Analyzer-2;
unit 0 {
    family inet {
        address 169.254.0.2/31 {
            arp 169.254.0.3 mac 02:00:00:00:00:01;
        }
    }
}

[edit]
[email protected]# show forwarding-options port-mirroring instance SPAN-1    
input {
    rate 1;
    run-length 0;
}
family inet {
    output {
        interface ge-0/0/1.0 {
            next-hop 169.254.0.1;
        }
        interface ge-0/0/2.0 {
            next-hop 169.254.0.3;
        }
    }
}

Но при попытке добавить еще один порт в иерархию output в мирроринг инстанс мы получаем ошибку при коммите:

[edit]
[email protected]# commit check
[edit forwarding-options port-mirroring instance SPAN-1 family inet output]
  Port-mirroring configuration error
    Port-mirroring out of multiple nexthops is not allowed on this platform

error: configuration check-out failed

Страшная на первый взгляд фраза — ограничения платформы не дают нам установить сразу два next-hop-а для отзеркалированного трафика. Но это ограничение очень просто обходится, если мы воспользуемся next-hop группами.

Думаю что и так понятно, что такое next-hop группа — название говорит само за себя. Juniper MX поддерживает до 30-ти next-hop групп, в каждой из которой может быть до 16 next-hop-в. Но помимо этого, в каждый next-hop группе можно создать next-hop подгруппы. В одной next-hop группе должно быть как минимум два next-hop-а, иначе JunOS не даст сделать коммит.

Теперь перейдем к конфигурации, создадим next-hop группу:

[edit]
[email protected]# show forwarding-options next-hop-group Analyzer-servers                   
group-type inet;
interface ge-0/0/1.0 {
    next-hop 169.254.0.1;
}
interface ge-0/0/2.0 {
    next-hop 169.254.0.3;
}

И теперь укажем данную группу, как next-hop в ouput:

[edit]
[email protected]# show forwarding-options port-mirroring instance SPAN-1
input {
    rate 1;
    run-length 0;
}
family inet {
    output {
        next-hop-group Analyzer-servers;
    }
}

Весь остальной конфиг не меняется.

Перейдем к проверке. Сначала проверим, в каком состоянии next-hop группа:

[email protected]> show forwarding-options next-hop-group detail
Next-hop-group: Analyzer-servers               
  Type: inet           
  State: up             
  Number of members configured    : 2
  Number of members that are up   : 2
  Number of subgroups configured  : 0
  Number of subgroups that are up : 0
  Members Interfaces:                                 State
    ge-0/0/1.0             next-hop  169.254.0.1      up     
    ge-0/0/2.0             next-hop  169.254.0.3      up     

С группой все в порядке — она в работе (группа будет в up, если в ней есть хотя бы один интерфейс в up). Теперь проверим состояние сессии зеркалирования:

[email protected]> show forwarding-options port-mirroring SPAN-1                        
Instance Name: SPAN-1                         
  Instance Id: 2              
  Input parameters:
    Rate                  : 1
    Run-length            : 0
    Maximum-packet-length : 0
  Output parameters:
    Family              State     Destination          Next-hop
    inet                up        Analyzer-servers                    

Тоже все в порядке, но как мы уже видели раннее — это не значит, что мы сделали все правильно и у нас все взлетит. Поэтому проверим будет ли зеркалироваться трафик на два наших сервера:

[email protected]:~$ sudo hping3 -S -c 5 12.0.0.1 -d 40 -I eth2
HPING 12.0.0.1 (eth2 12.0.0.1): S set, 40 headers + 40 data bytes
len=40 ip=12.0.0.1 ttl=63 DF id=64150 sport=0 flags=RA seq=0 win=0 rtt=3.4 ms
len=40 ip=12.0.0.1 ttl=63 DF id=64222 sport=0 flags=RA seq=1 win=0 rtt=3.5 ms
len=40 ip=12.0.0.1 ttl=63 DF id=64457 sport=0 flags=RA seq=2 win=0 rtt=3.7 ms
len=40 ip=12.0.0.1 ttl=63 DF id=64593 sport=0 flags=RA seq=3 win=0 rtt=3.5 ms
len=40 ip=12.0.0.1 ttl=63 DF id=64801 sport=0 flags=RA seq=4 win=0 rtt=3.4 ms

--- 12.0.0.1 hping statistic ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 3.4/3.5/3.7 ms

Трафик на Analyzer-1:

[email protected]:~$ sudo tcpdump -i eth2 -B 4096
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
15:09:36.837983 IP 11.0.0.1.2304 > 12.0.0.1.0: Flags [S], seq 1255230673:1255230713, win 512, length 40
15:09:36.839367 IP 12.0.0.1.0 > 11.0.0.1.2304: Flags [R.], seq 0, ack 1255230714, win 0, length 0
15:09:37.C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

И аналогичная копия трафика на Analyzer-2:

[email protected]:~$ sudo tcpdump -i eth2 -B 4096
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
15:09:35.125093 IP 11.0.0.1.2304 > 12.0.0.1.0: Flags [S], seq 1255230673:1255230713, win 512, length 40
15:09:35.126394 IP 12.0.0.1.0 > 11.0.0.1.2304: Flags [R.], seq 0, ack 1255230714, win 0, length 0
15:09:36.125044 IP 11.0.0.1.2305 > 12.0.0.1.0: Flags [S], seq 2135769685:2135769725, win 512, length 40
15:09:36.126107 IP 12.0.0.1.0 > 11.0.0.1.2305: Flags [R.], seq 0, ack 2135769726, win 0, length 0
15:09:37.125552 IP 11.0.0.1.2306 > 12.0.0.1.0: Flags [S], seq 1139555126:1139555166, win 512, length 40
15:09:37.126418 IP 12.0.0.1.0 > 11.0.0.1.2306: Flags [R.], seq 0, ack 1139555167, win 0, length 0
15:09:38.125374 IP 11.C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

Отлично — поставленная задача выполнена, трафик льется туда, куда надо — оба потребителя получают запрошенную копию трафика.

Но сеть развивается бешеными темпами, и наша компания под зекалирование и СОРМ денег не жалеет. Теперь у нас появился еще один сервер — Analyzer-3, который тоже хочет получать копию трафика. Но сложность в том, что данный сервер подключен не локально к нашему RZN-PE-1, а в RZN-PE-2:

Зеркалирование на удаленный хост

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

Так как сервер Analyzer-3 находится за RZN-PE-2, то теми методами, которыми мы пользовались раннее решить эту задачу не выйдет. Наша основная проблема не в том, как отзеркалировать трафик, а в том, как этот уже отзеркалированный трафик дотащить до сервера Analyzer-3, который живет за RZN-PE-2, причем сделать это прозрачно для сети, иначе мы получим проблемы (какие, увидите позже). Для этого на оборудовании Juniper принято использовать gre туннель. Идея в том, что мы делаем тоннель до удаленного хоста и весь зеркалированный трафик упаковываем в этот туннель и отправляем или прямиком на сервер или на маршрутизатор, который терминирует сервер-получатель трафика. У вас есть два варианта использования gre туннеля.

Вариант 1. На маршрутизаторе, который производит зеркалирование настраивается gre тоннель, причем как destination указывается сам адрес сервера-получателя трафика. Естественно сеть, в которой находится этот сервер (в нашем случае это Analyzer-3) должна быть известна через какой либо протокол маршрутизации (BGP или IGP — не важно) иначе gre туннель просто не взлетит. Проблема в то, что в таком сценарии трафик на сервер льется вместе с gre заголовками. Для современных систем анализа и мониторинга трафика это не должно быть проблемой — gre не IPSec и трафик не шифруется. То есть на одной чаше весов простота реализации, на второй — лишний заголовок. Возможно в каком то сценарии наличие лишнего заголовка будет не приемлемо, тогда вам придется использовать вариант 2.

Вариант 2. Между маршрутизатором, который производит зеркалирование и маршрутизатором, который терминирует сервер-получатель трафика, поднимается gre тоннель (обычно это делается на лупбеках). На стороне маршрутизатора, который производит зеркалирование от источника все так же как и было в варианте 1, а вот на стороне получателя на маршрутизаторе необходимо настроить инстанс, который будет зеркалировать полученный из gre туннеля трафик в сторону анализатора. То есть на одно зеркало у нас получается необходимо использовать один инстанс зеркалирования на источнике и второй на получателе трафика, что сильно усложняет схему. Но с другой стороны в этом сценарии на сервер льется чистый трафик, без лишних gre заголовков. Помимо этого при реализации данной схемы есть правило, которое надо строго соблюдать — маршрутизатор, который терминирует конечную точку gre тоннеля не должен иметь маршрута к хосту, который будет указан как получатель в зеркалируемом трафике (то есть получателем исходного отзеркалированного пакета). Если это условие не выполняется, то вы получите дубли пакетов — трафик будет вылетать из gre туннеля и помимо того, что будет зеркалироваться на указанный вами порт, еще будет маршрутизировать, как обычный ip пакет. И если маршрутизатор знает маршрут до хоста назначения, то трафик будет отправлен ему. Чтобы этого избежать, gre интерфейс необходимо погрузить в отдельный инстанс с типом virtual-router, хотя есть и другие способы, описанные далее. Если кому то интересно, то конфигурация, суть проблемы и как ее победить под спойлером:

Mirroring via gre problem

Конфигурация gre туннеля на стороне сервера источника:

[email protected]# show interfaces gr-0/0/0
description RSPAN;
unit 0 {
    tunnel {
        source 62.0.0.1;
        destination 62.0.0.2;
    }
    family inet {
        address 169.254.100.1/31;
    }
}

Изменился только адрес назначения тоннеля — стал лупбеком RZN-PE-2.

На RZN-PE-2 необходимо сначала создать gre туннель до RZN-PE-1:

[email protected]> show configuration interfaces gr-0/0/0
description SPAN;
unit 0 {
    tunnel {
        source 62.0.0.2;
        destination 62.0.0.1;
    }
    family inet {
        filter {
            input MIRROR-RSPAN-GE0/0/1;
        }
    }
}

Чтобы теперь с данного интерфейса трафик отправить в мирроринг инстанс, нам надо навесить на него фильтр, который имеет следующий вид:

[email protected]> show configuration firewall family inet filter MIRROR-RSPAN-GE0/0/1
term MIRROR {
    then port-mirror-instance RSAPN;
}

Ну и последний штрих — создание самого инстанса, привязка его к fpc и создание интерфейса, в который будет отправляться трафик:

[email protected]> show configuration forwarding-options port-mirroring instance RSAPN
input {
    rate 1;
}
family inet {
    output {
        interface ge-0/0/1.0 {
            next-hop 169.254.100.1;
        }
    }
}

[email protected]> show configuration chassis
fpc 0 {
    pic 0 {
        tunnel-services {
            bandwidth 10g;
        }
    }
    port-mirror-instance RSAPN;
}

[email protected]> show configuration interfaces ge-0/0/1  
description Analyzer-3;
unit 0 {
    family inet {
        address 169.C
--- 12.0.0.1 ping statistics ---
1 packets transmitted, 1 received, +41 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.444/17.916/34.712/9.126 ms

Часть дубликатов я удалил из вывода, но количество их можно увидеть — один валидный пакет и 41 дубль. На анализаторе трафика вы естественно увидите такую же картину:

[email protected]:~$ sudo tcpdump -i eth2 -B 9192
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
11:52:13.275451 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1601, seq 1, length 64
11:52:13.275462 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1601, seq 1, length 64
11:52:13.276703 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1601, seq 1, length 64
…
…

Кроме зеркалирования, маршрутизатор производит еще и форвардинг пакета, полученного из gre туннеля, так как знает маршрут до адреса назначения. Чтобы это пофиксить, создаем инстанс с типом virtual router и добавим в него gre интерфейс и интерфейс, на который мы зеркалируем трафик:

[edit]
[email protected]# show routing-instances RSPAN-VR
description "for RSPAN use only";
instance-type virtual-router;
interface gr-0/0/0.C
--- 12.0.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 1.332/3.288/8.137/2.459 ms

Ну и отсутствие дубликатов доказывает дамп на анализаторе Analyzer-3:

[email protected]:~$ sudo tcpdump -i eth2 -B 9192
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
11:59:12.605205 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1602, seq 1, length 64
11:59:12.605350 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1602, seq 1, length 64
11:59:13.611070 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1602, seq 2, length 64
11:59:13.612356 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1602, seq 2, length 64
11:59:14.606350 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1602, seq 3, length 64
11:59:14.606739 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1602, seq 3, length 64
11:59:15.612423 IP 11.0.0.1 > 12.C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

Кроме создания отдельного инстанса на RZN-PE-2, можно воспользоваться и другими способами. О них нигде не написано и узнал я про них просто проводя тестирование.

Можно указать в фильтре, что весь трафик из тоннеля надо отправить в discard (именно discard, так как если будет reject, то Juniper будет отправлять назад icmp сообщение о том, что пакет зафильтрован)

[email protected]# show firewall family inet filter MIRROR-RSPAN-GE0/0/1
term MIRROR {
    then {
        port-mirror-instance RSAPN;
        discard;
    }
}

Если верить тестам, то с таким фильтром все работает:

[email protected]:~$ ping 12.0.0.1 -I eth2
PING 12.0.0.1 (12.0.0.1) from 11.0.0.1 eth2: 56(84) bytes of data.
64 bytes from 12.0.0.1: icmp_seq=1 ttl=63 time=2.68 ms
64 bytes from 12.0.0.1: icmp_seq=2 ttl=63 time=1.22 ms
64 bytes from 12.0.0.1: icmp_seq=3 ttl=63 time=1.96 ms
64 bytes from 12.C
--- 12.0.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 1.220/2.028/2.685/0.487 ms

На анализаторе трафик есть:

[email protected]:~$ sudo tcpdump -i eth2 -B 9192
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
12:03:11.934805 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1604, seq 1, length 64
12:03:11.934834 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1604, seq 1, length 64
12:03:12.982685 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1604, seq 2, length 64
12:03:12.982716 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1604, seq 2, length 64
12:03:13.935027 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1604, seq 3, length 64
12:03:13.935607 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1604, seq 3, length 64
12:03:14.936859 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1604, seq 4, length 64
12:03:14.C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

Еще один вариант позволяет нам вообще не конфигурировать мирроринг инстанс для зеркалирования на RZN-PE-2. Нам надо сделать next-hop группу (если у вас будет один интерфейс, как у меня, то надо добавить какой то фейковый, чтобы JunOS дал сделать коммит), а на gre интерфейс повесить фильтр, который будет изменять next-hop для входящего трафика на нужный нам:

[email protected]> show configuration interfaces gr-0/0/0
description SPAN;
unit 0 {
    tunnel {
        source 62.0.0.2;
        destination 62.0.0.1;
    }
    family inet {
        filter {
            input MIRROR-RSPAN-GE0/0/1;
        }
    }
}

[email protected]> show configuration firewall family inet filter MIRROR-RSPAN-GE0/0/1
term MIRROR {
    then next-hop-group Analyzer-3;
}

Next-hop группа поднялась:

[email protected]> show forwarding-options next-hop-group Analyzer-3 detail
Next-hop-group: Analyzer-3                     
  Type: inet           
  State: up             
  Number of members configured    : 2
  Number of members that are up   : 1
  Number of subgroups configured  : 0
  Number of subgroups that are up : 0
  Members Interfaces:                                 State
    ge-0/0/1.0             next-hop  169.254.100.1    up     
    ge-0/0/100.0                                      down   

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

[email protected]:~$ ping 12.0.0.1 -I eth2 -c 5
PING 12.0.0.1 (12.0.0.1) from 11.0.0.1 eth2: 56(84) bytes of data.
64 bytes from 12.0.0.1: icmp_seq=1 ttl=63 time=3.38 ms
64 bytes from 12.0.0.1: icmp_seq=2 ttl=63 time=2.17 ms
64 bytes from 12.0.0.1: icmp_seq=3 ttl=63 time=2.14 ms
64 bytes from 12.0.0.1: icmp_seq=4 ttl=63 time=2.06 ms
64 bytes from 12.0.0.1: icmp_seq=5 ttl=63 time=1.89 ms

--- 12.0.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 1.891/2.332/3.387/0.538 ms

Дублей нет, осталось проверить, попало ли что нибудь на анализатор:

[email protected]:~$ sudo tcpdump -i eth2 -B 9192
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
12:19:28.C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

Судя по тестам — все отрабатывает как надо. Какой из вариантов внедрять в продакшене — решать вам.

Мы же воспользуемся первым вариантом. Для начала нам надо включить туннельные сервисы, чтобы у нас появился gre интерфейс (gr-X/X/X):

[email protected]# show chassis fpc 0
pic 0 {
    tunnel-services {
        bandwidth 10g;
    }
}
port-mirror-instance SPAN-1;

Тут стоит немного вернуться к теории и поговорить о туннельных интерфейсах и резервировании ресурсов. В данной конфигурации я выделяю 10G под тоннельные сервисы на нулевом PIC нулевого FPC. Это не значит, что 10G от пропускной способности pfe обрезаются — это говорит о том, что тоннельные сервисы могут использовать не более 10G пропускной способности pfe, и не занятая ими часть ресурсов может использоваться под форвардинг трафика физических портов — то есть 10G на pfe шарится между туннельными сервисами и реальными интерфейсами.(gr|lt|vt)-» gr-0/0/0 up up lt-0/0/0 up up vt-0/0/0 up up

На линейных картах с TRIO-чипсетом максимально возможно резервируемая полоса под туннельные сервисы — 60G.


Примечание: хотелось бы добавить, что lt и vt это разные интерфейсы. lt — logical tunnel — логический тоннель, который предназначен, как правило, для связывания логических систем или роутинг инстансов между собой — он позволяет прогнать трафик между ними, как будто эти инстансы или логические системы соединены прямым патчкордом. А вот vt — это virtual tunnel — виртуальный лупбек, который предназначен не для связывания каких то виртуальных сущностный, а для заворота трафика на pfe для повторного лукапа (например в vpls).

После того, как мы создали туннельные интерфейсы, то у нас появилась возможность сконфигурировать gr-0/0/0. Так как мы выдрали вариант, в котором удаленный PE маршрутизатор не терминирует gre тоннель а просто отправляет трафик в сторону сервера, то как sourse адрес тоннеля на RZN-PE-1 мы указываем собственный лупбек, а вот как destination адрес сервера-получателя отзерклированного трафика, причем данный адрес должен быть доступен.

Собственно говоря, на сервере может быть а может и не быть адреса. Вы можете его выбрать сами и сделать статическую ARP запись, как это показано ниже:

[edit]
[email protected]# show | compare
[edit interfaces]
+   ge-0/0/1 {
+       description Analyzer-3;
+       unit 0 {
+           family inet {
+               address 192.168.0.0/31 {
+                   arp 192.168.0.1 mac 02:00:00:19:21:68;
+               }
+           }
+       }
+   }
[edit protocols ospf area 0.0.0.0]
      interface ge-0/0/0.0 { ... }
+     interface ge-0/0/1.0 {
+         passive;
+     }

Причем, как видно из представленной конфигурации, интерфейс добавлен как пассивный в ospf, чтобы RZN-PE-1 знал маршрут до этой сети:

[edit]
[email protected]# run show route 192.168.0.1

inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.0/31     *[OSPF/10] 00:00:16, metric 3
                    > to 10.0.0.0 via ge-0/0/0.0

Теперь создадим gre тоннель на RZN-PE-1 и добавим его в next-hop группу:

[edit]
[email protected]# show interfaces gr-0/0/0
description RSPAN;
unit 0 {
    tunnel {
        source 62.0.0.1;
        destination 192.168.0.1;
    }
    family inet {
        address 169.254.100.1/31;
    }
}

[edit]
[email protected]# show forwarding-options next-hop-group Analyzer-servers
group-type inet;
interface gr-0/0/0.0;
interface ge-0/0/1.0 {
    next-hop 169.254.0.1;
}
interface ge-0/0/2.0 {
    next-hop 169.254.0.3;
}

В отличии от ge интерфейсов, gre интерфейс является p2p и поэтому указывать next-hop адрес для него нет смысла — трафик все равно вылетит с другого конца, хотя указать вы его можете.

Ну и далее все как обычно — проверим состояние сессии зеркалирования:

[edit]
[email protected]# run show forwarding-options next-hop-group detail          
Next-hop-group: Analyzer-servers               
  Type: inet           
  State: up             
  Number of members configured    : 3
  Number of members that are up   : 3
  Number of subgroups configured  : 0
  Number of subgroups that are up : 0
  Members Interfaces:                                 State
    gr-0/0/0.0                                        up     
    ge-0/0/1.0             next-hop  169.254.0.1      up     
    ge-0/0/2.0             next-hop  169.254.0.3      up     

Ну и теперь проверим, что трафик на удаленном сервере получается:

[email protected]:~$ sudo hping3 -S -c 5 12.0.0.1 -d 40 -I eth2
HPING 12.0.0.1 (eth2 12.0.0.1): S set, 40 headers + 40 data bytes
len=40 ip=12.0.0.1 ttl=63 DF id=53439 sport=0 flags=RA seq=0 win=0 rtt=8.2 ms
len=40 ip=12.0.0.1 ttl=63 DF id=53515 sport=0 flags=RA seq=1 win=0 rtt=3.5 ms
len=40 ip=12.0.0.1 ttl=63 DF id=53610 sport=0 flags=RA seq=2 win=0 rtt=3.4 ms
len=40 ip=12.0.0.1 ttl=63 DF id=53734 sport=0 flags=RA seq=3 win=0 rtt=3.8 ms
len=40 ip=12.0.0.1 ttl=63 DF id=53897 sport=0 flags=RA seq=4 win=0 rtt=3.3 ms

--- 12.0.0.1 hping statistic ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 3.3/4.4/8.2 ms
[email protected]:~$ sudo tcpdump -i eth2 -B 4096
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
16:34:34.923370 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 11.0.0.1.2894 > 12.0.0.1.0: Flags [S], seq 1149405522:1149405562, win 512, length 40
16:34:34.926586 IP 62.0.0.1 > 192.168.0.1: GREv0, length 44: IP 12.0.0.1.0 > 11.0.0.1.2894: Flags [R.], seq 0, ack 1149405563, win 0, length 0
16:34:35.923022 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 11.0.0.1.2895 > 12.0.0.1.0: Flags [S], seq 1598018315:1598018355, win 512, length 40
16:34:35.923855 IP 62.0.0.1 > 192.168.0.1: GREv0, length 44: IP 12.0.0.1.0 > 11.0.0.1.2895: Flags [R.], seq 0, ack 1598018356, win 0, length 0
16:34:36.922903 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 11.0.0.1.2896 > 12.0.0.1.0: Flags [S], seq 592229199:592229239, win 512, length 40
16:34:36.924048 IP 62.0.0.1 > 192.168.0.1: GREv0, length 44: IP 12.0.0.1.0 > 11.0.0.1.2896: Flags [R.], seq 0, ack 592229240, win 0, length 0
16:34:37.923278 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 11.0.0.1.2897 > 12.0.0.1.0: Flags [S], seq 694611591:694611631, win 512, length 40
16:34:37.C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

Но, как я и сказал — трафик gre заголовком, и если для вашего сервера это не проблема, то данный подход самый простой и гибкий.

Но как оказалось, теперь владельцам серверов-получателей отзеркалированного трафика не хочется получать весь трафик, так как его стало слишком много. Серверу Analyzer-1 нужен только TCP трафик, серверу Analyzer-2 только UDP трафик, а вот серверу Analyzer-3 нужен весь трафик, не ограничиваясь TCP/UDP. То есть теперь нам надо реализовать такую схему:

Избирательное зеркалирование на два и более потребителя

Вот тут нам понадобится туннельный интерфейс vt-0/0/0 (виртуальный лупбек) ну или можете использовать lt-0/0/0 (виртуальный тоннель), но первое более предпочтительно. Итак, замысел избирательного зеркалирования заключается в следующем — трафик с порта зеркалируется сначала в виртуальный лупбек vt-порт, а далее с данного порта раскидывается с помощью фильтра на разные next-hop группы на основании выбранных вами параметров — протоколов, портов и т д. Для лучшего понимания происходящего давайте теперь соберем данную схему. Сначала изменим мирроринг инстанс, чтобы трафик зеркалировался в виртуальный лупбек:

[edit]
[email protected]# show forwarding-options port-mirroring instance SPAN-1
input {
    rate 1;
    run-length 0;
}
family inet {
    output {
        interface vt-0/0/0.0;
        no-filter-check;
    }
}

Очень важным является параметр no-filter-check — эта команда позволяет нам навесить фильтр на интерфейс, в который зеркалируется трафик. По умолчанию фильтрация на этих интерфейсах запрещена. Теперь создадим сам vt-интерфейс:

[edit]
[email protected]# show interfaces vt-0/0/0
unit 0 {
    description SPAN-USE;
    family inet;
}

На данный интерфейс никаких адресов вы навесить не можете, а семейство адресов, которые можно на нем разрешить ограничено.

Сейчас мы получили следующую картину — весь трафик с интерфейса ge-0/0/3 направлен в порт vt-0/0/0.0. Теперь нам надо отзеркалировать этот трафик в сторону разных потребителей. Для этого сначала надо создать next-hop группы, в которые включить необходимых потребителей:

[edit]
[email protected]# show forwarding-options next-hop-group Analyzer-TCP                                             
group-type inet;
interface gr-0/0/0.0;
interface ge-0/0/1.0 {
    next-hop 169.254.0.1;
}

[edit]
[email protected]# show forwarding-options next-hop-group Analyzer-UDP    
group-type inet;
interface gr-0/0/0.0;
interface ge-0/0/2.0 {
    next-hop 169.254.0.3;
}

[edit]
[email protected]# show forwarding-options next-hop-group Analyzer-default
group-type inet;
interface gr-0/0/0.0;
interface ge-0/0/100.0;

Интерфейс gr-0/0/0, который предназначен для зеркалирования трафика на Analyzer-3 добавлен во все три группы. Это сделано изза того, что данный сервер хочет получать и TCP и UDP трафик, и сделать для него отдельную группу и применить ее потом в фильтре не получится. Использовать один и тот же next-hop в разных группах не запрещено. В группе Analyzer-default есть еще порт ge-0/0/100.0 — это фейковый порт, добавленный в группу для того, чтобы суметь закоммитить конфигурацию — так как в группе должно быть как минимум два интерфейса.

Теперь нам надо создать фильтр, который будет матчить трафик по нужным нам критериям и раскидывать по next-hop группам:

[edit]
[email protected]# show firewall family inet filter MIRROR-SORTED
term MIRROR-TCP {
    from {
        protocol tcp;
    }
    then next-hop-group Analyzer-TCP;
}
term MIRROR-UDP {
    from {
        protocol udp;
    }
    then next-hop-group Analyzer-UDP;
}
term MIRROR-DEFAUL {
    then next-hop-group Analyzer-default;
}

И прикрутим ее на vt интерфейс:

[edit]
[email protected]# show interfaces vt-0/0/0
unit 0 {
    description SPAN-USE;
    family inet {
        filter {
            input MIRROR-SORTED;
        }
    }
}

Проверяем нашу конструкцию. Зеркалирование в vt интерфейс в состоянии up:

[email protected]> show forwarding-options port-mirroring SPAN-1
Instance Name: SPAN-1                         
  Instance Id: 2              
  Input parameters:
    Rate                  : 1
    Run-length            : 0
    Maximum-packet-length : 0
  Output parameters:
    Family              State     Destination          Next-hop
    inet                up        vt-0/0/0.0    

Все группы в работе (помним, что как минимум один порт должен быть в up, чтобы группа перешла в состояние up):

[email protected]> show forwarding-options next-hop-group detail
Next-hop-group: Analyzer-TCP                   
  Type: inet           
  State: up             
  Number of members configured    : 2
  Number of members that are up   : 2
  Number of subgroups configured  : 0
  Number of subgroups that are up : 0
  Members Interfaces:                                 State
    gr-0/0/0.0                                        up     
    ge-0/0/1.0             next-hop  169.254.0.1      up     

Next-hop-group: Analyzer-UDP                   
  Type: inet           
  State: up             
  Number of members configured    : 2
  Number of members that are up   : 2
  Number of subgroups configured  : 0
  Number of subgroups that are up : 0
  Members Interfaces:                                 State
    gr-0/0/0.0                                        up     
    ge-0/0/2.0             next-hop  169.254.0.3      up     

Next-hop-group: Analyzer-default               
  Type: inet           
  State: up             
  Number of members configured    : 2
  Number of members that are up   : 1
  Number of subgroups configured  : 0
  Number of subgroups that are up : 0
  Members Interfaces:                                 State
    gr-0/0/0.0                                        up     
    ge-0/0/100.0                                      down   

Ну а теперь сгенериуем по 5 icmp, tcp и udp пакетов и посмотрим, что на какой сервер попадет. На всех серверах-клиентах одновременно включим tcpdump. Я использовал hping3 с ключем —rand-source, поэтому обратного трафика мы не увидим, так как снимается трафик только на порту в сторону Server-1.

Итак, смотрим что мы отловили на Analyzer-1, там должен быть только TCP:

[email protected]:~$ sudo tcpdump -i eth2 -B 9192
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
19:58:25.C
5 packets captured
5 packets received by filter
0 packets dropped by kernel

Ну и остался у на Analyzer-3, там мы ловим все подряд, суммарное количество пакетов должно быть 15 (5 UDP/ 5 TCP/ 5 ICMP):

[email protected]:~$ sudo tcpdump -i eth2 -B 9192
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
19:58:11.782669 IP 62.0.0.1 > 192.168.0.1: GREv0, length 72: IP 132.43.66.243.1121 > 12.0.0.1.0: UDP, length 40
19:58:12.783508 IP 62.0.0.1 > 192.168.0.1: GREv0, length 72: IP 205.172.124.143.1122 > 12.0.0.1.0: UDP, length 40
19:58:13.783166 IP 62.0.0.1 > 192.168.0.1: GREv0, length 72: IP 253.127.33.120.1123 > 12.0.0.1.0: UDP, length 40
19:58:14.782758 IP 62.0.0.1 > 192.168.0.1: GREv0, length 72: IP 246.68.75.25.1124 > 12.0.0.1.0: UDP, length 40
19:58:15.783594 IP 62.0.0.1 > 192.168.0.1: GREv0, length 72: IP 95.89.126.64.1125 > 12.0.0.1.0: UDP, length 40
19:58:18.310249 IP 62.0.0.1 > 192.168.0.1: GREv0, length 100: IP 65.173.140.215 > 12.0.0.1: ICMP net 5.6.7.8 unreachable, length 76
19:58:19.311045 IP 62.0.0.1 > 192.168.0.1: GREv0, length 100: IP 171.91.95.222 > 12.0.0.1: ICMP net 5.6.7.8 unreachable, length 76
19:58:20.312496 IP 62.0.0.1 > 192.168.0.1: GREv0, length 100: IP 228.215.127.12 > 12.0.0.1: ICMP net 5.6.7.8 unreachable, length 76
19:58:21.311067 IP 62.0.0.1 > 192.168.0.1: GREv0, length 100: IP 214.149.191.71 > 12.0.0.1: ICMP net 5.6.7.8 unreachable, length 76
19:58:22.311398 IP 62.0.0.1 > 192.168.0.1: GREv0, length 100: IP 119.130.166.53 > 12.0.0.1: ICMP net 5.6.7.8 unreachable, length 76
19:58:26.186528 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 108.215.126.169.1668 > 12.0.0.1.0: Flags [S], seq 1842749676:1842749716, win 512, length 40
19:58:27.187385 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 230.181.170.188.1669 > 12.0.0.1.0: Flags [S], seq 1810452177:1810452217, win 512, length 40
19:58:28.C
15 packets captured
15 packets received by filter
0 packets dropped by kernel

Отлично, все что надо было реализовать — сделано — трафик зеркалируется и раскидывается по потребителям, как и было задумано.

Выше мы зеркалировали L3 трафик, но маршрутизаторы Juniper серии MX очень гибкие устройства и они позволяют зеркалировать не только IP трафик (семейство inet/inet6), но и например L2 трафик — например vpls или l2ckt (xconnect в терминах Cisco).

Локальное зеркалирование L2 трафика

Рассмотрим простейший случай, когда вам надо подсмотреть, что передается в L2CKT-е (это конечно нехорошо делать, так как клиент, чей трафик вы завернете на анализатор, даже не узнает об этом, и делать такие вещи надо исключительно с согласия клиента). Схема проста — между RZN-PE-1 и RZN-PE-2 натянут какой то L2CKT:

То есть нам надо реализовать такую схему зеркалирования:

Между RZN-PE-1 и RZN-PE-2 натянут L2CKT, который мы и хотим прослушать:

[email protected]> show configuration protocols l2circuit           
neighbor 62.0.0.2 {
    interface ge-0/0/6.100 {
        virtual-circuit-id 100;
    }
}

[email protected]> show configuration interfaces ge-0/0/6.100
encapsulation vlan-ccc;
vlan-id 100;
family ccc {
    filter {
        input MIRROR-L2CKT-SPAN-1;
        output MIRROR-L2CKT-SPAN-1;
    }
}

Логично, что на интерфейсе включено семейство ccc — это ж L2CKT как никак. В конфигурации на нужном нам интерфейсе уже навешен фильтр в обе стороны — так как мы хотим получать весь трафик, который будет проходит по нашему L2CKT. Фильтр по сути такой же, как и был ранее, только семейство адресов не inet, а ccc:

[email protected]> show configuration firewall family ccc filter MIRROR-L2CKT-SPAN-1
term MIRROR {
    then port-mirror-instance SPAN-1;
}

Далее настраиваем мирроринг инстанс, который хотим использовать для зеркалирования. В секции input никаких изменений нет — все как и раньше, а вот в секции output есть существенные отличия:

[email protected]> show configuration forwarding-options port-mirroring instance SPAN-1
input {
    rate 1;
    run-length 0;
}
family ccc {
    output {
        interface ge-0/0/1.0;
    }
}

У нас изменилось семейство адресов — теперь это ccc. Это тянет за собой неизбежные изменения в и конфигурации интерфейса, в который мы хотим отправлять трафик. Если мы попробуем задать какой то адрес next-hop-а, как это делалось ранее на не p2p интерфейсе, то у нас ничего не получится:

[email protected]# set forwarding-options port-mirroring instance SPAN-1 family ccc output interface ge-0/0/1 ?  
Possible completions:
  <[Enter]>            Execute this command
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  no-filter-check      Do not check for filters on port-mirroring interface
  |                    Pipe through a command

У нас просто нет такой возможности. Поэтому на интерфейсе, в который нам надо отправить трафик надо включить семейство bridge или ccc:

[edit]
[email protected]# show interfaces ge-0/0/1   
description Analyzer-1;
encapsulation ethernet-ccc;
unit 0 {
    family ccc;
}

Семейство ccc естественно использовать проще, но если вам приспичило использовать bridge, то не забудьте про важный нюанс — интерфейс с инкапсуляцией bridge должен быть помещен в бридж-домен (номер влана в домене можно использовать нулевой (none), так вы не отберете реальные номера вланов под зеркалирование у остальных сервисов).

Все готово, проверим состояние сессии зеркалирвания:

[email protected]> show forwarding-options port-mirroring
Instance Name: SPAN-1                         
  Instance Id: 2              
  Input parameters:
    Rate                  : 1
    Run-length            : 0
    Maximum-packet-length : 0
  Output parameters:
    Family              State     Destination          Next-hop
    ccc                 up        ge-0/0/1.0 

Все отлично — сессия в up. Теперь запустим пинг между нашими хостами и проверим, что получится собрать на анализаторе:

[email protected]> ping routing-instance VR-1 10.0.0.2 count 5
PING 10.0.0.2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=64 time=10.159 ms
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=11.136 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=9.723 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=7.754 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=10.619 ms

--- 10.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 7.754/9.878/11.136/1.162 ms

Вот что получилось собрать:

[email protected]:~$ sudo tcpdump -i eth2 -B 9192
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
23:44:31.948237 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 17420, seq 0, length 64
23:44:31.954408 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 17420, seq 0, length 64
23:44:32.955149 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 17420, seq 1, length 64
23:44:32.964115 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 17420, seq 1, length 64
23:44:33.967789 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 17420, seq 2, length 64
23:44:33.973388 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 17420, seq 2, length 64
23:44:34.975442 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 17420, seq 3, length 64
23:44:34.C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

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

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

Зеркалирование L2 трафика на удаленный сервер

Первая мысль — все просто, можно ж использовать gre туннель. Но, к сожалению, gre не поддерживает инкапсуляцию ccc/tcc/vpls/bridge. Но в Junos очень много различных инструментов, которые позволяют решить одну и ту же задачу разными методами, причем иногда кажется, что сделать что то вроде не реально, но в итоге через N-ое количество времени и N-го количества скуренных мануалов все взлетает. Тут так же. Сейчас мы будем собирать вот такую сложную схему:

Объясню, что и зачем. Итак, мы зеркалируем трафик из виртуального свича (L2CKT-а или бридж-домена) в мирроринг инстанс, причем трафик зеркалиуется не в какой то физический интерфейс, а в виртуальный туннельный интерфейс lt-0/0/0. Этот интерфейс одни на коробку и его юниты создается парами, которые называются peer-unit-ми — один юнит это входной конец туннеля, второй юнит — выходной. В итоге, все что попадает в один юнит — вылетит из связанного с ним второго юнита и наоборот. На этом интерфейсе мы включим инкапсуляцию ccc и с него построим L2CKT до удаленного маршрутизатора, который терминирует сервер-получатель трафика — то есть мы просто отдадим L2 трафик через L2CKT прямиком на удаленный сервер. Для удаленного маршуртизатора это будет простой L2CKT.

Теперь перейдем к конфигурированию. Интерфейсы в сторону серверов в access, и расположены в виртуальном свиче:

[email protected]# wildcard range show interfaces ge-0/0/[3-4]
description Server-1;
encapsulation ethernet-bridge;
unit 0 {
    family bridge {
        filter {
            input MIRROR-BRIDGE-vSwitch-1;
        }
        interface-mode access;
        vlan-id 100;
    }
}
description Server-2;
encapsulation ethernet-bridge;
unit 0 {
    family bridge {
        filter {
            input MIRROR-BRIDGE-vSwitch-1;
        }
        interface-mode access;
        vlan-id 100;
    }
}

[edit]
[email protected]# show routing-instances vSwitch-1
instance-type virtual-switch;
interface ge-0/0/3.0;
interface ge-0/0/4.0;
bridge-domains {
    BD100 {
        vlan-id 100;
    }
}

На интерфейсах навешены фильтры для зеркалирования входящего трафика в инстанс SPAN-1. Фильтр ничем не отличается от ранее использованных, кроме семейства — в этом сценарии используется bridge:


[edit]
[email protected]# show firewall family bridge filter MIRROR-BRIDGE-vSwitch-1
term MIRROR {
    then port-mirror-instance SPAN-1;
}

Теперь создадим инстанс SPAN-1:

[edit]
[email protected]# show forwarding-options port-mirroring instance SPAN-1
input {
    rate 1;
    run-length 0;
}
family vpls {
    output {
        interface lt-0/0/0.0;
    }
}

Тут есть маленький нюанс. Семейство адресов указывается не bridge — такого семейства вы в конфигурации инстанса даже не найдете, а vpls. Данное семейство (VPLS) используется для зеркалирования трафика из vpls/бридж-доменов.

Далее создаем туннельный интерфейс, в который хотим отправлять трафик:

[edit]
[email protected]# show interfaces lt-0/0/0
unit 0 {
    description RSPAN-IN;
    encapsulation ethernet-ccc;
    peer-unit 1;
    family ccc;
}
unit 1 {
    description RSPAN-OUT;
    encapsulation ethernet-ccc;
    peer-unit 0;
    family ccc;
}

Как я написал ранее, lt интерфейс состоит из двух юнитов — в нашем случае юниты 0 и 1. Все что влетит в юнит 0 вылетит через юнит 1. Вообще с одной стороны юнит может быть как L3, например inet, а с другой как L2, например ccc — и это будет работать. У нас же с обоих концов ccc, на нулевом юните это обусловлено тем, что трафик должен зеркалироваться в инстанс с семейством ccc/bridge/vpls, а использование ccc на первом юните обусловлено тем, что с данного юнита строится L2CKT.

Далее создаем L2CKT между RZN-PE-1 и RZN-PE-2. Со стороны RZN-PE-1:

[edit]
[email protected]# show protocols l2circuit
neighbor 62.0.0.2 {
    interface lt-0/0/0.1 {
        virtual-circuit-id 1;
        encapsulation-type ethernet;
    }
}

Со стороны RZN-PE-2:


[email protected]> show configuration protocols l2circuit    
neighbor 62.0.0.1 {
    interface ge-0/0/1.0 {
        virtual-circuit-id 1;
        encapsulation-type ethernet;
    }
}

[email protected]> show configuration interfaces ge-0/0/1  
description Analyzer-3;
encapsulation ethernet-ccc;
unit 0 {
    family ccc;
}

Теперь можно проверить, работает ли наш «Франкенштейн».Nei Neighbor: 62.0.0.2 Interface Type St Time last up # Up trans lt-0/0/0.1(vc 1) rmt Up Sep 2 07:28:05 2017 1 Remote PE: 62.0.0.2, Negotiated control-word: Yes (Null) Incoming label: 299840, Outgoing label: 299872 Negotiated PW status TLV: No Local interface: lt-0/0/0.1, Status: Up, Encapsulation: ETHERNET Flow Label Transmit: No, Flow Label Receive: No

Отлично, L2CKT в работе. Далее проверяем состояние сессии зеркалирования:

[edit]
[email protected]# run show forwarding-options port-mirroring SPAN-1
Instance Name: SPAN-1                         
  Instance Id: 2              
  Input parameters:
    Rate                  : 1
    Run-length            : 0
    Maximum-packet-length : 0
  Output parameters:
    Family              State     Destination          Next-hop
    vpls                up        lt-0/0/0.0                            

Все отлично, теперь запустим пинг между серверами Server-1 и Server-2 и посмотрим, что попадает на анализатор трафика:

[email protected]:~$ ping 11.0.0.2 -I 11.0.0.1 -c 5 -i 0.2
PING 11.0.0.2 (11.0.0.2) from 11.0.0.1 : 56(84) bytes of data.
64 bytes from 11.0.0.2: icmp_seq=1 ttl=64 time=3.86 ms
64 bytes from 11.0.0.2: icmp_seq=2 ttl=64 time=2.34 ms
64 bytes from 11.0.0.2: icmp_seq=3 ttl=64 time=2.30 ms
64 bytes from 11.0.0.2: icmp_seq=4 ttl=64 time=9.56 ms
64 bytes from 11.0.0.2: icmp_seq=5 ttl=64 time=1.43 ms

--- 11.0.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 803ms
rtt min/avg/max/mdev = 1.436/3.903/9.565/2.937 ms

Теперь идем на Analyzer-3 и посмотрим, что попало в tcpdump:

[email protected]:~$ sudo tcpdump -i eth2 -B 9192
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
10:48:46.296920 IP 11.0.0.1 > 11.0.0.2: ICMP echo request, id 2000, seq 1, length 64
10:48:46.297969 IP 11.0.0.2 > 11.0.0.1: ICMP echo reply, id 2000, seq 1, length 64
10:48:46.496380 IP 11.C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

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

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

Конечно, можно воспользоваться двумя user-defined инстансами и дефолтный инстанс (который всего один), но во-первых это не лучшее решение, ну а во вторых, что делать, если дефолтный инстанс уже занят? Естественно JunOS позволяет вам обойти это ограничение. В принципе, тут нет ничего сверхестественного — принцип работы все тот же, изменения касаются только конфигурации инстансов.

Использование более двух mirroring инстансов на одном FPC

Итак, основной смысл в создании связки между несколькими мирроринг инстансами: делается родительская инстанс и дочерние инстансы, которые на нее ссылаются. В родительском инстансе мы указываем input параметры — то есть скорость мирроринга/сэмплинга, максимальный размер пакета. В дочерних инстансах указываются уже output параметры — интерфейсы или next-hop группы, а вот input параметры наследуются от родительского инстанса, указанного в конфигурации. Без конфигов это явно непонятно, поэтому соберем такую схему зеркалирования:

Сначала создадим родительский инстанс, я назвал его просто SPAN.

[email protected]# show forwarding-options port-mirroring instance SPAN     
input {
    rate 1;
    run-length 0;
}

В инстансе указаны только входящие параметры зеркалирования. Больше ничего тут указывать не надо.

Теперь создадим три дочерних инстанса:

[edit]
[email protected]# show forwarding-options port-mirroring instance SPAN-1  
input-parameters-instance SPAN;
family inet {
    output {
        interface ge-0/0/1.0 {
            next-hop 169.254.0.1;
        }
    }
}

[edit]
[email protected]# show forwarding-options port-mirroring instance SPAN-2    
input-parameters-instance SPAN;
family inet {
    output {
        interface ge-0/0/2.0 {
            next-hop 169.254.0.3;
        }
    }
}

[edit]
[email protected]# show forwarding-options port-mirroring instance SPAN-3    
input-parameters-instance SPAN;
family inet {
    output {
        interface gr-0/0/0.0 {
    }
}

Тут уже мы указываем исходящие параметры зеркалирования. Связка между родительским и дочерним инстансом происходит с помощью следующей команды:

input-parameters-instance SPAN;

В итоге все три созданных мной инстанса SPAN-1/2/3 будут наследовать input параметры от инстанса SPAN. Как вы помните, теперь нам надо привязать инстансы к какой то (или каким то, если входящие порты на разных картах) FPC. Как я и сказал ранее — к FPC надо привязать только родительский инстанс:

[email protected]# show chassis fpc 0
pic 0 {
    tunnel-services {
        bandwidth 10g;
    }
}
port-mirror-instance SPAN;

Ну а далее все так же — создаем фильтры и вешаем их на входящие порты:

[email protected]# wildcard range show interfaces ge-0/0/[3-5]
description Server-1;
unit 0 {
    family inet {
        filter {
            input MIRROR>>>SPAN-3;
            output MIRROR>>>SPAN-3;
        }
        address 11.0.0.254/24;
    }
}
description Server-2;
unit 0 {
    family inet {
        filter {
            input MIRROR>>>SPAN-2;
            output MIRROR>>>SPAN-2;
        }
        address 12.0.0.254/24;
    }
}
description Server-3;
unit 0 {
    family inet {
        filter {
            input MIRROR>>>SPAN-1;
            output MIRROR>>>SPAN-1;
        }
        address 13.0.0.254/24;
    }
}

Обращаю внимание, что в фильтрах указываются не родительский инстанс, а дочерние инстансы:

[edit]
[email protected]# wildcard range show firewall family inet filter MIRROR>>>SPAN-[1-3]    
term MIRROR {
    then port-mirror-instance SPAN-1;
}
term MIRROR {
    then port-mirror-instance SPAN-2;
}
term MIRROR {
    then port-mirror-instance SPAN-3;
}

Теперь проверим состояние сессий зеркалирования:

[email protected]# run show forwarding-options port-mirroring
Instance Name: SPAN-1                         
  Instance Id: 3              
  Input parameters:
    Rate                  : 1
    Run-length            : 0
    Maximum-packet-length : 0
  Output parameters:
    Family              State     Destination          Next-hop
    inet                up        gr-0/0/0.0       

Instance Name: SPAN-2                         
  Instance Id: 4              
  Input parameters:
    Rate                  : 1
    Run-length            : 0
    Maximum-packet-length : 0
  Output parameters:
    Family              State     Destination          Next-hop
    inet                up        ge-0/0/2.0           169.254.0.3         

Instance Name: SPAN-3                         
  Instance Id: 5              
  Input parameters:
    Rate                  : 1
    Run-length            : 0
    Maximum-packet-length : 0
  Output parameters:
    Family              State     Destination          Next-hop
    inet                up        ge-0/0/1.0           169.254.0.1       

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

Вроде бы все, что хотел написать — написал. Если будут замечания или дополнения — пишите.

Спасибо за внимание.

Проблемы использования SPAN для мониторинга в современной сети / Хабр

Ранее мы опубликовывали статью «TAP или SPAN? Рекомендации по зеркалированию трафика для профессионалов», в которой описаны отличия подходов по съему трафика и проведен их анализ. Опрос и комментарии показали, что многие специалисты активно используют SPAN. Данной статьей мы дополним информацию о SPAN и расскажем, почему ее нельзя использовать для мониторинга и съема трафика в современной сети.

Как работает SPAN?

SPAN – это функция коммутатора или маршрутизатора, которая позволяет копировать пакеты с указанного порта/портов (порт зеркалирования) и отправлять на выбранный порт (порт мониторинга). Порт мониторинга при этом является обычным портом, который конфигурируется для передачи трафика от зеркалируемого порта/портов. При этом зеркалировать можно пакеты и на прием, и на передачу или только в одном направлении.

Для понимания работы функции SPAN схематично изобразим коммутатор (рисунок 1). На схеме мы оставляем только порты, коммутационную матрицу и буфер коммутационной матрицы. Как же работает коммутатор? На порт приходит пакет и поступает на коммутационную матрицу. Матрица сохраняет пакет в буфер, определяет порт назначения и передаёт в него пакет, освобождая буфер. Буфер коммутационной матрицы представляет собой память, в которую помещается пакет, ожидающий своей обработки.

Рисунок 1

Разберемся, как работает функция SPAN (рисунок 4). Для начала надо назначить зеркалируемые порты (все пакеты, поступающие с него или на него, в зависимости от конфигурации, будут копироваться) и порт мониторинга. Как только коммутационная матрица принимает или собирается передать пакет через зеркалируемые порты, она дополнительно передаёт копии пакетов на порт мониторинга. И пока пакет не будет передан на порт мониторинга, он остаётся в буфере.

Стоит отметить, когда пакет приходит на порт коммутатора/маршрутизатора, он проходит проверку целостности, а затем может быть модифицирован (добавление/замена заголовков) или отброшен. В итоге на порт мониторинга придёт не исходный пакет, а модифицированный. Или вовсе не придёт.

Поведение SPAN при нагрузке

Как же будет себя вести коммутатор при различных нагрузках и вариантах использования порта мониторинга? Ведь зеркалируемых портов может быть как один, так и десять, а количество SPAN-портов обычно не превышает 4. Кроме того, меняется загруженность зеркалируемых портов.

Самой важной характеристикой порта мониторинга является пропускная способность: если коммутационная матрица будет подавать на порт мониторинга больше пакетов, чем он сможет передать, то они будут отбрасываться. На графике (рисунок 2) показано зеркалирование трафика с одного порта: пропускной способности порта мониторинга хватает с запасом, чтобы передать все пакеты. Но что будет, если зеркалировать трафик с нескольких портов? Трафика будет в разы больше пропускной способности порта мониторинга (рисунок 3). Пропускной способности порта мониторинга не будет хватать, и часть пакетов будет отбрасываться.

Рисунок 2Рисунок 3

Поговорим про реализацию функции SPAN. Как мы уже упоминали, пока пакет не будет передан и на целевой порт, и на порт зеркалирования, он занимает место в буфере пакетов. Зеркалирование нескольких портов (или обоих направлений передачи одного порта) приводит к скапливанию пакетов в очереди на порт мониторинга и заполнению буфера. Некоторые производители ставят самый низкий приоритет для портов мониторинга, иными словами, оборудование под нагрузкой будет выбирать между передачей трафика на обычные порты или порты мониторинга. В таком оборудовании ситуация с превышением зеркалируемого трафика над пропускной способностью порта мониторинга будет сопровождаться отбрасыванием зеркалируемого трафика (рисунок 4). Некоторые производители делают отдельно буфер для порта мониторинга. Он необходим для того, чтобы исключить влияние порта мониторинга на работоспособность обычных портов. Но этот буфер меньше основного, и когда он переполняется, происходит такая же потеря зеркалируемых пакетов.

Рисунок 4

Влияние функции SPAN на сеть

Почему же производители оборудования ставят низкий приоритет и заранее закладывают потерю зеркалируемого трафика? Превышение объема зеркалируемого трафика над полосой пропускания портов мониторинга приводит к заполнению буфера и отбрасыванию пакетов по обычным портам (даже если они слабонагружены), ведь пакетный буфер — общий (рисунок 5). Критичный к задержкам трафик (например IP-телефония) при этом будет потерян. Переповторы остального трафика на транспортном уровне (преимущественно, это TCP) увеличат нагрузку, вызовут снижение пропускной способности и приведут к деградации производительности сети. Переповторы также передаются на порт мониторинга и усложняют анализ данных.

Рисунок 5

Более того, даже с пониженным приоритетом все эти эффекты будут наблюдаться при повышенной нагрузке на коммутатор: пакетный буфер рассчитан на обычную работу устройства. Если половина буфера будет занята пакетами, ожидающими отправки на порт мониторинга, оставшейся половины для полноценный работы устройства уже не хватит.

Потери пакетов при низкой нагрузке на коммутатор

Даже в слабонагруженных сетях трафик передается неравномерно. Сетевые карты накапливают данные для передачи и затем передают их на скорости порта. Так называемые всплески трафика (Burst) вызывают эффект локальных по времени перегрузок портов (рисунок 6). Именно на их сглаживание при совпадении порта назначения закладываются ресурсы буфера в коммутаторе. Но даже в устройстве с 10G портами это единицы мегабайт, а соответственно, единицы миллисекунд превышения пропускной способности по одному порту. Назначая один из портов портом мониторинга, мы гарантируем переполнение буфера и потери, как минимум, зеркалируемых пакетов.

Рисунок 6

Заключение

Функция SPAN была придумана уже давно для:

  • Выборочного мониторинга портов при поиске неисправностей и ошибок передачи в сети

  • Обеспечения информационной безопасности на слабонагруженных портах, выходящих за границы периметра

SPAN – вспомогательная функция коммутаторов или маршрутизаторов, фактически работающая в режиме «как есть». При этом в современной сети зеркалируемых трафик является уже не вспомогательным. Зеркалирование трафика необходимо для мониторинга внутрисетевой активности и одновременного подключения средств анализа и информационной безопасности.

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

Настройка зеркального анализатора портов | Juniper Networks

Анализатор

В зеркальной конфигурации анализатор включает:

  • Имя анализатора

  • Исходные (вводимые) порты, VLANs или домены моста

  • Место назначения зеркальных пакетов (локальный порт, VLAN или домен моста)

Выходной интерфейс анализатора

(Также известен как порт монитора)

Интерфейс, на который отправляется зеркальный трафик и подключается анализатор протокола.

Интерфейсы, используемые в качестве выходных данных для анализатора, должны конфигурироваться на forwarding-options уровне иерархии.

Выходные интерфейсы анализатора имеют следующие ограничения:

  • Они также не могут быть исходными портами.

  • Они не участвуют в протоколах уровня 2, таких как протокол STP.

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

Анализатор VLAN или домен моста

(Также известен как VLAN монитора или домен моста)

VLAN или домен моста, в который отправляется зеркальный трафик для использования анализатором протокола. Членские интерфейсы в VLAN монитора или домене моста распространяются по коммутатным устройствам сети.

Анализатор на основе моста-домена

Сеанс анализатора, настроенный на использование доменов моста для ввода, вывода или того и иного.

Анализатор по умолчанию

Анализатор с зеркальными параметрами по умолчанию. По умолчанию зеркальная скорость составляет 1, а максимальной длиной пакета является длина полного пакета.

Входной интерфейс

(Также известен как зеркальные порты или отслеживаются интерфейсы)

Интерфейс коммутатора, в котором зеркально отражается включении или выходе трафика.

Анализатор на базе LAG

Анализатор с группой агрегирования соединений (LAG), указанным в качестве входного (входного) интерфейса в конфигурации анализатора.

Локальное зеркальное отражение

Конфигурация анализатора, в которой пакеты зеркалируются локальным портом анализатора.

станция мониторинга

Компьютер с анализатором протоколов.

Анализатор на основе группы следующих переходов

Конфигурация анализатора, которая использует группу следующего перехода в качестве выходных данных для анализатора.

Анализатор на основе порта

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

Приложение анализатора протоколов

Приложение для проверки пакетов, передаваемых через сетевой сегмент. Также называется сетевым анализатором, анализатором пакетов или зондом.

Удаленное зеркальное отражение

Функции точно так же, как и локальное зеркальное отражение, за исключением того, что зеркальный трафик не копируется в порт локального анализатора, а перенагрен в анализатор VLAN или домен моста, который создается специально для получения зеркального трафика. Зеркальные пакеты имеют дополнительную внешнюю метку для анализатора VLAN или домена моста.

Статистический анализатор

(Также известен как анализатор по умолчанию)

Набор зеркальных свойств, которые можно явно связать с физическими портами коммутатора. Данный набор свойств анализатора известен как статистический анализатор.

Анализатор на основе VLAN

Конфигурация анализатора, использующая VLANs для доставки зеркального трафика анализатору.

Зеркалирование портов в Hyper-V 2012

В Windows Server 2012 Hyper-V появилась новая функция — зеркалирование портов (port mirroring), позволяющая мониторить трафик виртуальных машин без необходимости захватывать трафик непосредственно внутри самой гостевой ОС. По сути, эта функция то же самое, что и аппаратный port mirroring, но на уровне виртуального коммутатора Hyper-V. Зеркалирование портов можно использовать в системах на базе Hyper-V для поиска неисправностей в сети, тестирования, мониторинга, анализа сетевого трафика и перенаправления трафика на анализ в IDS системы (системы обнаружения вторжений). Попробуем настроить зеркалирование трафика в Hyper-V 2012 на конкретном примере.

Системные требования для организации мирроринга портов в Hyper-V 2012:

  • Система с Windows Server 2012 Hyper-V и административного доступа к ней
  • Как минимум один виртуальный коммутатор (vSwitch)
  • Как минимум две виртуальные машины: трафик первой мы будет дублировать на вторую

Настройка зеркалирования портов с помощью GUI

  1. Откройте консоль управления Hyper-V Manager
  2. Перейдите в настройки виртуальной машины, трафик которой будем зеркалировать (Settings)
  3. В окне параметров виртуальной машины найдите сетевой адаптер, на котором необходимо включить захват трафика и перейдите в раздел расширенных настроек (Advanced Features)
  4. В разделе Port mirroring найдите параметр Mirroring Mode и измените его значение на Source (тем самым мы на уровне виртуального коммутатора Hyper-V включим зеркалирование данного порта)
  5. Если в вашей конфигурации Hyper-V используется более одного виртуального коммутатора, необходимо запомнить его имя (в нашем примере это Hyper-V-Guests).

Следующий этап – настройка виртуальной машины, на которую будет дублироваться трафик с первой. Для удобства анализа сетевого трафика рекомендуется в данную машину добавить отдельную виртуальную сетевую карту (vNIC), подключенную к тому же виртуальному коммутатору. Выделенная карточка позволяет получить максимально полный дамп сетевого трафика за счет отключения ненужных служб и протоколов в гостевой ОС (подробнее об этом ниже). Для этого:

  1. Погасите виртуальную машину, которая будет выступать в качестве приемника «захватываемого» трафика
  2. Перейдите в ее настройки (Settings) и добавьте новое оборудование (Add Hardware) типа Network Adapter
  3. Если используется несколько коммутаторов, включите новую сетевую карту именно в тот, в котором находилась первая виртуальная машина (коммутатор Hyper-V-Guests). В расширенных свойствах новой сетевой карты в разделе Port mirroring укажите, что сетевая карта будет выступать в качестве приемника сетевого трафика Mirroring ModeDestination.
  4. Включите виртуальную машину

Далее перейдем к настройке зеркалирования в гостевой Windows, являющейся приемником трафика.

  1. Зайдите на машину через консоль Hyper-V или по rdp.
  2. В панели управления сетевыми подключениями найдите добавленную ранее сетевую карту и для упрощения дальнейшей идентификации переименуйте ее (например, в Hyper-V-Guests-Mirror-Port).
  3. Откройте свойства данного сетевого подключения и отключите все протоколы и службы. Тем самым мы добьемся «чистоты» захватываемого трафика, который ничем не фильтруется и не ограничивается, поступая в точно таком же виде, в каком он попадает на mirror порт.

Далее можно переходить непосредственно к работе с перенаправленным трафиком: это может быть некая IDS система или система захвата и анализа сетевого трафика (Packet Capture), например Microsoft Network Monitor, Message Analyzer, Wireshark или т.п.

Port Mirroring с помощью Powershell

В Windows Server 2012 Hyper-V управлять настройками зеркалирования трафика можно и с помощью Powershell.

В следующем примере мы с помощью Powershell включим port mirroring на виртуальной машине с именем VMWin2008Source и направим трафик на виртуальную машину с именем VMWin2008Monitor:

Set-VMNetworkAdapter –VMName VMWin2008Source –PortMirroring Source
Set-VMNetworkAdapter –VMName VMWin2008Monitor –PortMirroring Destination

Информация: Кроме того, полезными могут быть следующе команды:

  • Add-VMNetworkAdapter — добавить новый сетевой адаптер в виртуальную машину
  • Get-NetAdapter — получить список сетевых карт (NIC)
  • Rename-Netadapter — переименовать сетевую карту

Но есть и небольшая ложка дегтя – порт мирроринг работает в пределах только одного сервера Hyper-V (который, кстати, может работать непосредственно с USB флешки). Это означает, что если виртуальная машина, трафик которой зеркалируется, смигрировала на другой сервер кластера Hyper-V, то зеркалирование трафика перестает работать (на втором хосте также придется настроить отдельную машину для захвата трафика).

Open vSwitch часть №10. Зеркалирование портов — iVirt-it.ru

Open vSwitch — все статьи

Open vSwitch позволяет, направлять копию потока трафика из одного или нескольких интерфейсов в другой. Так же, возможно перенаправление трафика из всего VLAN’a в конкретный порт или на оборот.  Может зеркалироваться только входящий, исходящий или оба типа. Понадобиться это может, например, для прослушки трафика в целях информационной безопасности или диагностики.

Выполним зеркалирование трафика из интерфейса vnet2 принадлежащего одной из ВМ в специально созданный для прослушивания порт mirror0 с типом internal.
Команда, реализующая эту функцию в отличии предыдущих, просто ломает мозг

# ovs-vsctl — set Bridge ovs-sw0 [email protected] — —[email protected] get Port mirror0 — —[email protected] get Port vnet2 — —[email protected] create Mirror name=mymirror [email protected] [email protected] [email protected]

В данной команде, как нетрудно заметить, во всю производится работа с БД, а также используются своего рода внутренние переменные — —[email protected]<имя_переменной>
set Bridge ovs-sw0 [email protected] — эта часть описывает создание зеркала, имя и параметры которого должна быть получена из переменной @m.
—[email protected] get Port mirror0 — —[email protected] get Port vnet2 — здесь в переменные @mirror0, @vnet2 записываются идентификаторы соответствующих портов.
—[email protected] create Mirror name=mymirror [email protected] [email protected] [email protected] — а тут собственно в переменную @m записывается идентификатор моста mymirror, которая будет подставлена в первой команде в переменную @m.

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

Теперь, например с помощью tcpdump запущенного в хост-системе можно наблюдать весь трафик ВМ:

# tcpdump -i mirror0

Кстати, подобное зеркалирование трафика наверняка возможно у таких облачных провайдеров как Amazon EC2, Rackspace, Digitalocean и других. По этому не стоит забывать об использовании защищенных сетевых протоколов!

Flowmon теперь предоставляет «cloud-native» анализ сетевого трафика с использованием Google Cloud Packet Mirroring

Flowmon Networks, компания, предоставляющая решения для сбора информации о действиях в сети, объявила об улучшении «native cloud» прозрачности и о поддержке Google Cloud Packet Mirroring. Этот новый функционал позволяет клиентам зеркалировать Google Cloud трафик в исходном формате в решение Flowmon для дальнейшего передового мониторинга угроз, диагностики и решения проблем с производительностью и обнаружения аномалий. 

Компании продолжают перемещать свои приложения в облако, однако контроль производительности и управление безопасностью облачных ресурсов не всегда соответствует требованиям. Подобная ситуация часто вызывает беспокойство сетевых инженеров и специалистов по информационной безопасности, которые, несмотря на отсутствие полной картины происходящего в облаке, продолжают отвечать за надежность и работоспособность сети. С появлением в Google Cloud сервиса Packet Mirroring, клиенты могут получать сырой сетевой трафик в среде виртуального частного облака (VPC) и обходить таким образом ограничения в прозрачности данных в облаке. На основе этого сервиса Flowmon открыл возможность анализа сетевого трафика для управления производительностью и безопасностью в Google Cloud.

“Появившийся в Google Cloud сервис Packet Mirroring – это очень полезный сервис, который позволяет нашим клиентам контролировать облачный трафик таким же образом, как и локальный, — говорит Павел Минарик, технический директор Flowmon Networks, — ИТ-подразделения должны обеспечивать работоспособность сервисов и обнаруживать необычные модели трафика, которые указывают на нарушения безопасности. Благодаря Flowmon и Packet Mirroring теперь это стало возможным и в Google Cloud».

Packet Mirroring – это виртуализированный аналог сетевого ответвителя. Этот сервис доставляет копию сырого трафика на устройства мониторинга и информационной безопасности для дальнейшего анализа. Зеркалированные пакеты отправляются на внутренний балансировщик нагрузки, а оттуда – на один или несколько коллекторов Flowmon Collectors с встроенным зондом Flowmon, объединенных в группу Instance Group. С этого момента клиенты имеют в своем распоряжении всю мощь решений Flowmon, получая сетевой трафик с таким же уровнем прозрачности, что и при размещении в частном облаке или локально.

Рис. 1. Зеркалирование трафика Google Cloud в Flowmon

Благодаря Flowmon и Packet Mirroring клиенты получают следующие возможности.

  • Раннее реагирование на угрозы и снижение среднего времени разрешения проблем для текущих инцидентов, влияющих на доступность приложений и безопасность данных, благодаря анализу трафика и обнаружению угроз. 
  • Полезная информация об отказах и ухудшении производительности услуг, а также их влиянии на инфраструктуру. 
  • Оптимизация производительности приложений с мониторингом взаимодействия конечных пользователей с приложением. 
  • Динамический выбор источников зеркалирования пакетов с помощью фильтров и/или меток, что позволяет достичь баланса между стоимостью мониторинга и достигаемой прозрачностью. 

«Прозрачность трафика очень важна для предотвращения нарушений безопасности и атак, так как сети становятся более многокомпонентными, — говорит Махеш Нараянан, продакт менеджер в Google Cloud. — Благодаря  Packet Mirroring наши клиенты теперь имеют возможность проактивно обнаруживать проникновения в сеть, анализировать и диагностировать проблемы с производительностью приложений в Compute Engine и Google Kubernetes Engine во всех регионах и со всеми типами машин».

Flowmon – это единое решение, которое предоставляет инструменты в равной степени для сетевых инженеров и специалистов по кибербезопасности. Добавляя возможность зеркалирования пакетов Packet Mirroring в набор услуг, Flowmon еще больше укрепляет свое лидерство в «native cloud» инструментах мониторинга. Помимо Google Cloud компания Flowmon позволяет своим клиентам контролировать также инфраструктуру Amazon VPC и Microsoft Azure. 

Больше информации см. Flowmon blog post, Google Cloud’s VPC Packer Mirroring blog post или страницу Google Cloud’s VPC. Для получения пробной версии Flowmon для Google Cloud свяжитесь с нами по адресу [email protected]

Источник ►

Что такое зеркалирование трафика? — Amazon Virtual Private Cloud

Traffic Mirroring — это функция Amazon VPC, которую можно использовать для копирования сетевого трафика из эластичной сети. интерфейс инстансов Amazon EC2. Затем вы можете отправить трафик на внеполосную защиту и приборы контроля для:

  • Проверка содержимого

  • Мониторинг угроз

  • Поиск и устранение неисправностей

Устройства безопасности и мониторинга могут быть развернуты как отдельные экземпляры или как парк экземпляров за балансировщиком сетевой нагрузки с прослушивателем UDP.Зеркалирование трафика поддерживает фильтры и усечение, так что вы извлекаете только интересующий трафик для мониторинга с помощью мониторинга инструменты на ваш выбор.

Концепции зеркалирования трафика

Ниже приведены ключевые концепции зеркалирования трафика:

  • Источник — сетевой интерфейс с типом экземпляр .

  • Target — место назначения для зеркального трафик.

  • Фильтр — Набор правил, определяющих трафик который копируется в сеансе зеркала трафика.

  • Session — объект, описывающий зеркалирование трафика из источник к цели с помощью фильтров.

Работа с зеркалированием трафика

Вы можете создавать, получать доступ и управлять своими ресурсами зеркала трафика, используя любой из далее:

  • Консоль управления AWS — предоставляет веб-интерфейс, можно использовать для доступа к ресурсам зеркала трафика.

  • Интерфейс командной строки AWS (AWS CLI) — Предоставляет команды для широкий набор сервисов AWS, включая Amazon VPC. Интерфейс командной строки AWS поддерживается в Windows, macOS и Линукс. Дополнительные сведения см. в разделе Интерфейс командной строки AWS.

  • AWS SDK — предоставление API для конкретных языков. Пакеты AWS SDK заботятся о многих деталях подключения, таких как расчет подписи, обработка повторных запросов и обработка ошибок.Для получения дополнительной информации см. SDK для AWS.

  • Query API — Предоставляет низкоуровневые действия API, которые вы звоните, используя HTTPS-запросы. Использование Query API — самый прямой способ доступа к Amazon VPC. Однако для этого требуется, чтобы ваше приложение обрабатывало детали низкого уровня, такие как создание hash для подписи запроса и обработки ошибок. Для получения дополнительной информации см. Справочник по API Amazon EC2.

Преимущества зеркалирования трафика

Traffic Mirroring предлагает следующие преимущества:

  • Упрощенная работа — Отразить любой диапазон ваш трафик VPC без необходимости управлять агентами пересылки пакетов на вашем EC2 экземпляры.

  • Повышенная безопасность — Захват пакетов в эластичный сетевой интерфейс, который не может быть отключен или изменен пользователем Космос.

  • Расширенные возможности мониторинга — Отправить зеркальный трафик на любое устройство безопасности.

Цена

Для получения информации о ценах см. VPC ценообразование.

Начало работы с зеркалированием трафика

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

Предпосылки

  • Убедитесь, что источник зеркала трафика и цель зеркала трафика:

  • Убедитесь, что целевой экземпляр зеркала трафика разрешает трафик на порт UDP 4789.

  • Убедитесь, что источник зеркала трафика имеет запись в таблице маршрутов для целевое зеркало трафика.

  • Убедитесь, что в цель зеркала трафика, которая отбрасывает зеркальный трафик с зеркала трафика источник.

  • Ознакомьтесь с рекомендациями по зеркалированию трафика.Дополнительные сведения см. в разделе Квоты и рекомендации по зеркалированию трафика.

Шаг 1: Создайте цель зеркала трафика

Создайте пункт назначения для зеркального трафика.

Создать цель зеркала трафика

  1. Откройте консоль Amazon VPC по адресу https://console.aws.amazon.com/vpc/.

  2. В селекторе Region выберите регион AWS, который вы использовали при вы создали VPC.

  3. На панели навигации выберите Traffic Mirroring , Зеркальные мишени .

  4. Выберите Создать цель зеркала трафика .

  5. Для Тег имени введите имя для целевого зеркала трафика.

  6. (необязательно) Для Описание введите описание зеркала трафика. цель.

  7. Для Тип цели выберите тип цели зеркала трафика.

  8. Для Target выберите цель зеркала трафика.

  9. (Необязательно) Добавьте или удалите тег.

    [Добавить тег] Выберите Добавить тег и выполните следующие действия:

    • Для Key введите имя ключа.

    • Для Значение введите значение ключа.

    [Удалить тег] Рядом с тегом выберите Удалить тег .

  10. Выбрать Создать .

Шаг 2. Создайте зеркало трафика фильтр

Фильтр зеркалирования трафика содержит одно или несколько правил зеркалирования трафика и набор Сервисы. Фильтры и правила, которые вы добавляете, определяют зеркальный трафик.

Чтобы создать фильтр зеркала трафика

  1. Откройте консоль Amazon VPC по адресу https://консоль.aws.amazon.com/vpc/.

  2. В селекторе Region выберите регион AWS, который вы использовали при вы создали VPC.

  3. На панели навигации выберите Traffic Mirroring , Зеркальные фильтры .

  4. Выберите Создать фильтр зеркала трафика .

  5. Для Тег имени введите имя фильтра зеркала трафика.

  6. (необязательно) Для Описание введите описание зеркала трафика. фильтр.

  7. (Необязательно) Зеркальные сетевые службы.

    [Зеркало DNS-трафика Amazon] Выберите amazon-dns .

  8. (Необязательно) Добавьте правила для входящих подключений. В разделе Правила входящих подключений выберите Добавьте правило , а затем укажите следующую информацию о входящий трафик источника зеркала трафика:

    • Номер правила : Введите приоритет для назначения правилу.

    • Действие правила : Выберите действие для пакета.

    • Протокол : Выберите протокол L4 для назначения правило.

    • (необязательно) Диапазон исходных портов : Введите исходный порт диапазон.

    • (необязательно) Диапазон портов назначения : Введите порт назначения диапазон.

    • Исходный блок CIDR : Введите исходный блок CIDR.

    • Блок CIDR назначения : Введите CIDR назначения блокировать.

    • (необязательно) Описание : Введите описание для правило.

    Повторите для каждого входящего правила, которое вы хотите добавить.

  9. (Необязательно) Добавьте исходящие правила.В разделе Правила исходящего трафика выберите Добавьте правило , а затем укажите следующую информацию о исходящий трафик зеркала трафика:

    • Номер правила : введите приоритет для назначения правилу.

    • Действие правила : Выберите действие для пакета.

    • Протокол : Выберите IP-протокол для назначения правило.

    • (необязательно) Диапазон исходных портов : Введите исходный порт диапазон.

    • (необязательно) Диапазон портов назначения : Введите порт назначения диапазон.

    • Исходный блок CIDR : Введите исходный блок CIDR.

    • Блок CIDR назначения : Введите CIDR назначения блокировать.

    • (необязательно) Описание : Введите описание для правило.

    Повторите для каждого исходящего правила, которое вы хотите добавить.

  10. (Необязательно) Добавьте или удалите тег.

    [Добавить тег] Выберите Добавить тег и выполните следующие действия:

    • Для Key введите имя ключа.

    • Для Значение введите значение ключа.

    [Удалить тег] Рядом с тегом выберите Удалить тег .

  11. Выбрать Создать .

Шаг 3. Создайте зеркало трафика сессия

Создайте сеанс зеркалирования трафика, который отправляет зеркальные пакеты от источника к цели, чтобы что вы можете отслеживать и анализировать трафик.

Для создания сеанса зеркалирования трафика

  1. Откройте консоль Amazon VPC по адресу https://console.aws.amazon.com/vpc/.

  2. В селекторе Region выберите регион AWS, который вы использовали при вы создали VPC.

  3. На панели навигации выберите Traffic Mirroring , Mirror Сессии .

  4. Выберите Создать сеанс зеркалирования трафика .

  5. (необязательно) Для Тег имени введите имя для зеркала трафика. сессия.

  6. (необязательно) Для Описание введите описание зеркала трафика. сессия.

  7. Для Источник зеркала выберите сетевой интерфейс экземпляра которые вы хотите отслеживать.

  8. В качестве Зеркальная цель выберите цель зеркалирования трафика.

  9. В разделе Дополнительные настройки выполните следующие действия:

    1. Для Номер сеанса введите номер сеанса.

      Номер сеанса определяет порядок, в котором оцениваются сеансы зеркалирования трафика. в обеих следующих ситуациях:

      Трафик зеркалируется только один раз.

      Используйте 1 для наивысшего приоритета.

      Допустимые значения: 1-32766.

    2. (необязательно) Для VNI введите идентификатор VXLAN, который будет использоваться для зеркала трафика. сессия. Дополнительные сведения о протоколе VXLAN см. в RFC 7348.

      Если вы не введете значение, мы присвоим случайное неиспользованное число.

    3. (необязательно) Для Длина пакета введите количество байтов в каждый пакет для зеркалирования.

      Если вы не хотите зеркалировать весь пакет, установите Packet Длина от до количества байтов в каждом пакете для зеркалирования. Например, если вы устанавливаете это значение на 100, первые 100 байтов после заголовка VXLAN, которые соответствуют критерии фильтра копируются в цель.

      Чтобы отразить весь пакет, не вводите значение в это поле.

    4. Для Фильтр выберите фильтр зеркала трафика, который определяет, что трафик зеркалируется.

  10. (Необязательно) Добавьте или удалите тег.

    [Добавить тег] Выберите Добавить тег и выполните следующие действия:

    • Для Key введите имя ключа.

    • Для Значение введите значение ключа.

    [Удалить тег] Рядом с тегом выберите Удалить тег .

  11. Выбрать Создать .

Шаг 4. Анализ данных

После того, как зеркальный трафик находится на целевом зеркале трафика, вы можете использовать инструмент из АМС Партнерская сеть для анализа данных.

Квоты и рекомендации по зеркалированию трафика

Соображения

  • Инкапсулированный зеркальный трафик маршрутизируется с помощью таблицы маршрутов VPC.Убедись, что ваша таблица маршрутов настроена на отправку зеркального трафика на правильный зеркало трафика.

  • Вы можете создать сеанс зеркалирования трафика, только если вы являетесь владельцем источника сетевой интерфейс или его подсеть.

  • Мы обрезаем пакет до значения MTU, когда выполняются оба следующих условия. правда:

    Например, если зеркалируется пакет размером 8996 байт, а целевой MTU зеркала трафика значение равно 9001 байт, в результате зеркальной инкапсуляции зеркальный пакет больше, чем значение MTU.В этом случае зеркальный пакет усекается. Предотвращать зеркальные пакеты от усечения, установите MTU исходного зеркального интерфейса трафика значение на 54 байта меньше, чем значение MTU целевого зеркала трафика для IPv4 и 74 байта меньше значения MTU целевого зеркала трафика при использовании IPv6. Следовательно максимальное значение MTU, поддерживаемое зеркалированием трафика без усечения пакетов, равно 8947. байт. Дополнительные сведения о настройке значения сетевого MTU см. в разделе Максимальная единица передачи сети (MTU). для вашего инстанса EC2 в Руководстве пользователя Amazon EC2 для инстансов Linux .

  • Зеркальный трафик учитывается в пропускной способности экземпляра. Например, если вы зеркалируете сетевой интерфейс, который имеет 1 Гбит/с входящего трафика и 1 Гбит/с исходящего трафика, экземпляр должен обрабатывать 4 Гбит/с трафика (1 Гбит/с входящий, 1 Гбит/с зеркальный входящий, исходящая скорость 1 Гбит/с и зеркальная исходящая скорость 1 Гбит/с).

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

  • Зеркальный исходящий трафик из исходного экземпляра не подлежит группе безопасности оценка.

  • Журналы потоков не фиксируют зеркальный трафик.

  • При удалении сетевого интерфейса, являющегося зеркальным источником трафика, сеансы зеркалирования трафика, связанные с источником, автоматически удален.

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

  • Эластичный сетевой интерфейс не может быть целью зеркала трафика и зеркалом трафика источник сеанса одновременно.

  • Мы рекомендуем использовать Network Load Balancer в качестве цели для обеспечения высокой доступности.

  • Если у вас нет прослушивателей UDP в балансировщике сетевой нагрузки, вы все равно можете использовать балансировщик сетевой нагрузки в качестве цель. Однако зеркалирование трафика не может быть выполнено, так как нет прослушивателей UDP.

  • Если вы удалите прослушиватели UDP из балансировщика сетевой нагрузки, который является целью зеркалирования трафика, зеркалирование трафика выходит из строя без индикации ошибки.

  • Когда Network Load Balancer удаляет узел в зоне доступности из таблицы DNS, Зеркалирование трафика продолжает отправлять зеркальные пакеты на этот узел.

  • Если у вас есть существующий компонент Network Load Balancer, который является целевым зеркалом трафика, и вы добавляете дополнительных подсетей к нему, эффекта нет. Например, зеркальный трафик в Зона доступности новой подсети не маршрутизируется в той же зоне доступности если вы не включите балансировку нагрузки между зонами.

  • Мы рекомендуем использовать межзональную балансировку нагрузки с Network Load Balancer, чтобы убедиться, что пакеты продолжают зеркалироваться, когда все цели в зоне доступности не здоровый.

Ограничения

Зеркалирование трафика недоступно для следующих типов инстансов EC2:

Невозможно зеркалировать следующие типы трафика:

Квоты

Ниже приведены квоты для зеркалирования трафика для вашей учетной записи AWS.

Сеансы

  • Максимальное количество сеансов на учетную запись: 10 000

  • Максимальное количество сеансов на исходный сетевой интерфейс: 3

Фильтры

  • Максимальное количество фильтров на учетную запись: 10 000

  • Максимальное количество правил на фильтр: 10 †

Источники

  • Максимальное количество источников на Network Load Balancer: без ограничений

  • Максимальное количество источников на цель (меньшие размеры): 10 †

  • Максимальное количество источников на цель (наибольший размер): 100 *

† Эта квота не может быть увеличена.

* Применяется только к самому большому размеру экземпляра для данного типа экземпляра. Например, для инстансов M5 максимальное значение составляет 100 для m5.24xlarge . и 10 для всех других размеров инстансов M5.

Выгрузка контрольной суммы

Эластичный сетевой адаптер (ENA) обеспечивает возможность разгрузки контрольной суммы. Если пакет усекается, это может привести к тому, что контрольная сумма пакета не будет рассчитана для зеркальный пакет.Следующие контрольные суммы не рассчитываются, когда зеркальный пакет усекается:

  • Если зеркальный пакет усечен, контрольная сумма зеркального пакета L4 не вычислено.

  • Если какая-либо часть заголовка L3 усечена, контрольная сумма L3 не вычислено.

Используйте следующие команды, чтобы отключить разгрузку контрольной суммы ENA в Amazon Linux 2. АМИ:

  [[email protected] ~]$ sudo ethtool --offload eth0 tx off
[[email protected] ~]$ sudo ethtool --show-offload eth0
Возможности для eth0:
rx-контрольная сумма: вкл.
tx-контрольная сумма: выключено
     tx-контрольная сумма-ipv4: выключено
     tx-checksum-ip-generic: выключено [исправлено]
     tx-checksum-ipv6: выключено [исправлено]
     tx-checksum-fcoe-crc: выключено [исправлено]
     tx-checksum-sctp: выключено [исправлено]  

Что такое зеркалирование трафика? — Сервисы или возможности Amazon Virtual Private Cloud

, описанные в документации Amazon Web Services, могут различаться в зависимости от региона.Чтобы увидеть различия, применимые к регионам Китая, см. раздел Начало работы с Amazon Web Services в Китае.

Traffic Mirroring — это функция Amazon VPC, которую можно использовать для копирования сетевого трафика из эластичной сети. интерфейс инстансов Amazon EC2. Затем вы можете отправить трафик на внеполосную защиту и приборы контроля для:

  • Проверка содержимого

  • Мониторинг угроз

  • Поиск и устранение неисправностей

Устройства безопасности и мониторинга могут быть развернуты как отдельные экземпляры или как парк экземпляров за балансировщиком сетевой нагрузки с прослушивателем UDP.Зеркалирование трафика поддерживает фильтры и усечение, так что вы извлекаете только интересующий трафик для мониторинга с помощью мониторинга инструменты на ваш выбор.

Концепции зеркалирования трафика

Ниже приведены ключевые концепции зеркалирования трафика:

  • Источник — сетевой интерфейс с типом экземпляр .

  • Target — место назначения для зеркального трафик.

  • Фильтр — Набор правил, определяющих трафик который копируется в сеансе зеркала трафика.

  • Session — объект, описывающий зеркалирование трафика из источник к цели с помощью фильтров.

Работа с зеркалированием трафика

Вы можете создавать, получать доступ и управлять своими ресурсами зеркала трафика, используя любой из далее:

  • Консоль управления Amazon Web Services — предоставляет веб-интерфейс, который вы можно использовать для доступа к ресурсам зеркала трафика.

  • Интерфейс командной строки Amazon (Amazon CLI) — Предоставляет команды для широкий набор сервисов Amazon, включая Amazon VPC. Amazon CLI поддерживается в Windows, macOS и Линукс. Дополнительные сведения см. в разделе Интерфейс командной строки Amazon.

  • Пакеты Amazon SDK — предоставление API для конкретных языков. Пакеты Amazon SDK заботятся о многих деталях подключения, таких как вычисление подписи, обработка повторных запросов и обработка ошибок.Для получения дополнительной информации см. Амазон SDK.

  • Query API — Предоставляет низкоуровневые действия API, которые вы звоните, используя HTTPS-запросы. Использование Query API — самый прямой способ доступа к Amazon VPC. Однако для этого требуется, чтобы ваше приложение обрабатывало детали низкого уровня, такие как создание hash для подписи запроса и обработки ошибок. Для получения дополнительной информации см. Справочник по API Amazon EC2.

Преимущества зеркалирования трафика

Traffic Mirroring предлагает следующие преимущества:

  • Упрощенная работа — Отразить любой диапазон ваш трафик VPC без необходимости управлять агентами пересылки пакетов на вашем EC2 экземпляры.

  • Повышенная безопасность — Захват пакетов в эластичный сетевой интерфейс, который не может быть отключен или изменен пользователем Космос.

  • Расширенные возможности мониторинга — Отправить зеркальный трафик на любое устройство безопасности.

Цена

Для получения информации о ценах см. VPC ценообразование.

Зазеркалье — Часть 1 | Люк Пейн

Общие сведения о зеркалировании трафика AWS и его злонамеренном использовании

Зеркалирование трафика AWS — это функция, представленная Amazon Web Services (AWS) 25 июня 2019 года.После выпуска Майк Лосапио из Palantir определил, что это может представлять риск, и предложил мне изучить эту функцию в рамках партнерства между нашими двумя компаниями. Огромное спасибо ему и всей команде Palantir за то, что они вдохновили меня на этот пост, и в целом отличным людям.

В этом посте я собираюсь предоставить подробную информацию о том, как работает эта новая функция, законные варианты использования и возможные способы злоупотребления. Часть 2 будет посвящена разбивке доступных источников данных AWS для обнаружения и предоставит возможность отличить законное использование от незаконного злоупотребления этой функцией.

Этот пост предполагает, что читатель имеет начальный уровень знаний об AWS, но каждый новый термин AWS, который я ввожу, я на всякий случай ссылаюсь на соответствующую документацию.

Объявления о функциях AWS

При использовании облачных ресурсов администраторы теряют определенный уровень контроля над своей средой. Новые функции и возможности могут внедряться без предупреждения или разрешения, поэтому важно быть в курсе новых выпусков и обновлений, чтобы повысить уровень безопасности облачной среды.Официальный блог AWS — отличный ресурс для объявлений о новых функциях, которые могут открыть пути атаки на вашу организацию, и за ними должен следить любой, кто отвечает за безопасность среды AWS. В аккаунте AWS в Твиттере публикуются аналогичные объявления, а также множество отраслевых экспертов, отслеживающих выпуски облачных функций.

При введении новых функций часто добавляются разрешения к ролям по умолчанию, которые уже используются. В случае зеркалирования трафика разрешения были добавлены к таким ролям, как EC2:AllAccess под прозвищем Elastic Compute Cloud (EC2).Если вы не знаете об этих изменениях, у вас могут быть ненужные разрешения, предоставленные пользователям, которые делают организацию более уязвимой для атак.

Зеркалирование трафика AWS позволяет создать сеанс зеркалирования трафика. Сеанс состоит из трех частей, описанных ниже:

1. Источник зеркала трафика:

Сетевой интерфейс является источником зеркала трафика, а затем трафик источника зеркалируется и перенаправляется на цель зеркала трафика — в настоящее время это ограничено Elastic Network Interface (ENI) экземпляра EC2, но возможности могут быть расширены в будущем.Поддерживаются только экземпляры на базе системы Nitro, которые перечислены здесь.

2. Цель зеркалирования трафика

Цель зеркалирования трафика — это балансировщик сетевой нагрузки (NLB) или ENI EC2, который получает зеркальный трафик. Цель должна находиться в том же виртуальном частном облаке (VPC), что и источник, если только вы не используете одноранговые VPC (способ создания маршрутов intra-vpc между вашими VPC без дополнительного оборудования или ресурсов) или маршрутизацию через транзитный шлюз (виртуальный маршрутизатор). для обработки трафика между вашими VPC).Кроме того, если вы решите подключить два VPC одним из этих способов — , они не обязательно должны находиться в одной учетной записи.

3. Фильтр зеркалирования трафика

Фильтр зеркалирования трафика представляет собой набор правил, определяющих, какой трафик будет отражаться и какой объем трафика. Параметры включают определенные подсети, порты и размеры пакетов. Примечание. Если фильтр не установлен, то трафик не будет зеркалироваться — фильтр представляет собой окончательный список всего, что будет зеркалироваться на цель.В этом смысле фильтр является скорее конфигурацией, чем фактическим фильтром.

После установки этих параметров вы можете создать сеанс зеркалирования трафика. Каждый ENI может участвовать в качестве источника зеркала трафика до трех раз одновременно, в то время как цель зеркала трафика может принимать столько сеансов, сколько необходимо.

После установления сеанса копия всего трафика (входящего или исходящего), соответствующего фильтру, дублируется из источника в цель. Трафик отправляется в виде инкапсулированных пакетов VXLAN через UDP-порт 4789.

Базовый сеанс зеркалирования трафика

Существует множество законных способов использования зеркалирования трафика AWS. Эти виды использования аналогичны использованию зеркального/промежуткового порта на физическом коммутаторе, главными из них являются устройства типа системы обнаружения вторжений/системы предотвращения вторжений (IDS/IPS), где вам может потребоваться отслеживать трафик устройств в вашей сети. Преимущество использования этих зеркальных сеансов заключается в разгрузке рабочей нагрузки по созданию зеркального трафика с сетевого устройства, такого как маршрутизатор или балансировщик нагрузки, и в том, что AWS берет на себя рабочую нагрузку на серверной части.

В этих законных вариантах использования показаны примеры одного и нескольких VPC, но они сосредоточены на использовании нескольких учетных записей в одной организации. Случаи злоупотреблений в следующем разделе основаны на несколько ином макете, поскольку используемые учетные записи никак не связаны. Это процедурное изменение поможет отличить законное и незаконное использование функции, когда мы начнем пытаться обнаружить такое поведение.

Использование внутри VPC:

Внутри одного VPC можно перенаправлять трафик со всех экземпляров на центральный NLB или EC2 ENI.

Пример одного VPC с использованием NLB

Использование Inter-VPC:

Используя возможность зеркалирования трафика AWS для нескольких учетных записей, вы можете собирать данные со всех подчиненных учетных записей в организации и пересылать их в центральный VPC для проверки с использованием нескольких методы.

Законный вариант использования с использованием пиринга VPC для подключения VPC подчиненных учетных записей. Законный вариант использования с подключением подчиненных учетных записей к Transit Gateway.Эти типы атак в общих чертах сопоставляются с облачной матрицей Mitre ATT&CK в разделе Эксфильтрация/передача данных в облачную учетную запись.

Зачем кому-то воровать трафик из VPC? Поскольку многие организации в значительной степени полагаются на ресурсы AWS для внутренних и внешних сервисов, часто критический трафик можно найти в этих VPC. Кроме того, многие организации используют терминацию TLS/SSL, чтобы снизить нагрузку на внутренние системы. Завершение SSL доступно в Elastic Load Balancer (ELB) с 2010 года.В январе 2019 года AWS также представила возможность прерывания TLS/SSL на NLB, что увеличило вероятность незашифрованного внутреннего трафика во многих средах AWS.

Если злоумышленник сможет использовать украденные учетные данные AWS для зеркалирования и эксфильтрации трафика, это может привести к массовому раскрытию личной информации. Имея это в виду, я составил два метода, которые, по моему мнению, были значительными рисками, и наткнулся на еще один, созданный Rhino Security Labs (подробно описанный в методе 3). Все эти методы сосредоточены на удалении трафика из исходной (или жертвы) учетной записи AWS и его эксфильтрации во вторую учетную запись злоумышленника.Для каждого из них требуются украденные или скомпрометированные учетные данные AWS. Я перечислил необходимые разрешения для каждого из методов атаки, чтобы упростить тестирование.

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

Метод 1. Общие ресурсы с помощью AWS Resource Access Manager

Вредоносное зеркало общего ресурса

В этом методе используется ENI и транзитный шлюз, которые были переданы из одной учетной записи в другую в качестве цели для зеркального трафика в учетной записи AWS Люка.Результат зеркала отправляется непосредственно экземпляру в учетной записи Дэвида.

Требуемые разрешения AWS:

  • ec2:DescribeInstances (для определения экземпляров EC2 для зеркалирования)
  • ec2:CreateTrafficMirrorTarget (для указания нашего балансировщика нагрузки/экземпляра EC2 в качестве цели зеркала VPC)
  • для каждого экземпляра EC2, который мы хотим отразить)
  • ec2:CreateTrafficMirrorFilter (для создания фильтра трафика для наших сеансов зеркалирования)
  • ec2:CreateTrafficMirrorFilterRule (чтобы указать, что мы хотим, чтобы весь трафик просмотреть ожидающее приглашение поделиться балансировщиком нагрузки/экземпляром EC2 из учетной записи Дэвида)
  • ram:AcceptResourceShareInvitation (чтобы принять приглашение из учетной записи Дэвида)
  • ВСТАВИТЬ НОВЫЕ РАЗРЕШЕНИЯ, ИСПОЛЬЗОВАННЫЕ ЗДЕСЬ

EC2 ENI или NLB, в зависимости от того, как цель определена до ее совместного использования.

Метод 2: одноранговый VPC

Peered VPC Malicious Mirror

В этом методе используется пиринговое соединение между VPC в учетной записи Люка и VPC в учетной записи Дэвида, что дает экземплярам возможность зеркалировать свой трафик непосредственно на экземпляр NLB или EC2 в учетной записи Дэвида. учетная запись.

Требуемые разрешения AWS:

  • ec2:DescribeInstances (для определения экземпляров EC2 для зеркалирования)
  • ec2:CreateTrafficMirrorTarget (для указания нашего балансировщика нагрузки/экземпляра EC2 в качестве цели зеркала VPC)
  • для каждого экземпляра EC2, который мы хотим отразить)
  • ec2:CreateTrafficMirrorFilter (для создания фильтра трафика для наших сеансов зеркалирования)
  • ec2:CreateTrafficMirrorFilterRule (чтобы указать, что мы хотим, чтобы весь трафик создать пиринг VPC между учетными записями Люка и Дэвида)

Метод 3: Локальный экземпляр (MalMirror)

Локальный экземпляр Malicious Mirror

).MalMirror — это скрипт Python, который принимает учетные данные AWS и запускает вредоносный экземпляр EC2 с намерением создать сеанс зеркалирования трафика между собой и каждым подходящим экземпляром в VPC. Каждые 100 МБ захваченных данных экземпляр EC2 загружает PCAP в корзину S3, которая находится в учетной записи AWS Дэвида.

Требуемые разрешения AWS (заимствовано из сообщения блога, упомянутого выше):

  • ec2:DescribeInstances (для определения экземпляров EC2 для зеркалирования)
  • ec2:RunInstances (для создания экземпляра EC2, который будет зеркальным целевым объектом VPC)
  • ec2:CreateSecurityGroup (чтобы создать группу безопасности для нашего экземпляра EC2)
  • ec2:AuthorizeSecurityGroupIngress (чтобы разрешить входящий доступ к нашему экземпляру EC2)
  • ec2:CreateTrafficMirrorTarget (чтобы указать наш экземпляр EC2 в качестве цели зеркала VPC)
  • ec2 CreateTrafficMirrorSession (для создания зеркальных сеансов для каждого экземпляра EC2, который мы хотим отразить)
  • ec2:CreateTrafficMirrorFilter (для создания фильтра трафика для наших сеансов зеркалирования)
  • ec2:CreateTrafficMirrorFilterRule (чтобы указать, что мы хотим, чтобы весь трафик зеркалировался в наш экземпляр EC2)

На этом первая часть этой серии завершается. Во второй и последней части будет подробно рассказано, как использовать источники данных AWS для обнаружения, d как мы можем использовать их для разработки надежного обнаружения с помощью Capability Abstraction и Funnel of Fidelity Джареда Аткинсона.

Работа с зеркалированием трафика — Эксплуатация, обслуживание и мониторинг

Зеркальное отображение трафика — это функция, отражающая сетевой трафик из эластичной сети. интерфейс (ENI). Зеркалируется только сетевой трафик, соответствующий фильтрам, а затем направляется в указанный экземпляр. В этом разделе описывается, как использовать зеркалирование трафика характерная черта.

Справочная информация

Если фильтр не содержит правил, трафик не зеркалируется.

Предпосылки

  • Если вы впервые используете зеркалирование трафика, перейдите на страницу Зеркалирование трафика и следуйте инструкциям, чтобы включить эту функцию.
  • Если источник и назначение зеркала трафика в сеансе зеркала трафика принадлежат к различным виртуальным частным облакам (VPC), убедитесь, что VPC могут взаимодействовать друг с другом.Дополнительные сведения см. в разделе Подключение VPC.

Операции

Создать фильтр зеркала трафика

Если фильтр не содержит правил, трафик не зеркалируется.

  1. Войдите в консоль VPC.
  2. В левой панели навигации выберите .
  3. В верхней панели навигации выберите регион, в котором вы хотите создать фильтр.
  4. На странице «Фильтр» нажмите «Создать фильтр».
  5. В разделе Информация укажите Имя и Описание фильтра.
  6. На вкладках «Правила для входящих подключений» и «Правила для исходящих подключений» в разделе «Конфигурация правил» щелкните «Создать правило», чтобы создать правила для входящих и исходящих подключений. Затем нажмите ОК. В следующей таблице описаны параметры, которые необходимо задать при создании правила.Дополнительные сведения о правилах для входящего и исходящего трафика см. в разделе Фильтры.
    Параметр Описание
    Тип протокола Укажите протокол транспортного уровня сетевого трафика, который вы хотите зеркально отразить. из экземпляров Elastic Compute Service (ECS).Допустимые значения:
    • ВСЕ: все протоколы
    • ICMP: протокол управляющих сообщений Интернета (ICMP).
    • TCP: протокол управления передачей (TCP).
    • UDP: протокол пользовательских дейтаграмм (UDP).
    Исходный блок CIDR Укажите исходный блок CIDR трафика.
    Целевой блок CIDR Укажите целевой блок CIDR трафика.
    Исходный порт Введите диапазон исходных портов трафика.

    Допустимые значения: от 1 до 65535. Разделите первый порт и последний порт прямым косая черта (/), например, 1/200 или 80/80. Значение -1/-1 указывает все порты.

    Порт назначения Введите диапазон портов назначения трафика.

    Допустимые значения: от 1 до 65535. Разделите первый порт и последний порт прямым косая черта (/), например, 1/200 или 80/80. Значение -1/-1 указывает все порты.

    Приоритет Укажите приоритет правила. Допустимые значения: от 1 до 16777216.

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

    Полис Укажите действие, которое вы хотите выполнить с сетевым трафиком.Допустимые значения:
    • Сбор: принимает сетевой трафик.
    • Не собирать: отклоняет сетевой трафик.

Создать сеанс зеркалирования трафика

  1. Войдите в консоль VPC.
  2. В левой панели навигации выберите .
  3. В верхней панели навигации выберите регион, в котором создана сессия зеркала трафика.
  4. На странице «Сеанс Traffic Mirror» нажмите «Создать сеанс Traffic Mirror».
  5. На странице мастера создания сеанса зеркалирования трафика задайте следующие параметры и нажмите кнопку Далее.
    Параметр Описание
    Имя Введите имя сеанса зеркалирования трафика.

    Имя должно иметь длину от 2 до 128 символов и может содержать цифры, символы подчеркивания (_) и дефис (-). Оно должно начинаться с буквы.

    Описание Введите описание сеанса зеркалирования трафика.

    Длина описания должна быть от 2 до 256 символов.Он не может начинаться с http:// или https:// .

    ВНИ Укажите сетевой идентификатор VXLAN (VNI) зеркального трафика. Допустимые значения: от 0 до 16777215.

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

    Приоритет Укажите приоритет сеанса зеркалирования трафика. Допустимые значения: от 1 до 32766.

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

  6. Выберите «Связать фильтр» и нажмите «Далее».
  7. На странице мастера «Выбор источника зеркалирования трафика» выберите ENI, с которого вы хотите зеркалировать трафик, и нажмите «Далее».
  8. Щелкните ENI или SLB.
  9. В разделе «Выбор экземпляра» выберите экземпляр ENI или Server Load Balancer (SLB), а затем нажмите «Далее».
    • ENI не может быть указан в качестве источника зеркала трафика и назначения зеркала трафика в то же время.
    • Если экземпляр SLB указан в качестве получателя зеркала трафика, функция Listen by Port Функция диапазона должна быть включена. Чтобы включить эту функцию, отправьте заявку.
  10. Нажмите «Отправить».

Включить сеанс зеркалирования трафика

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

  1. Войдите в консоль VPC.
  2. В левой панели навигации выберите .
  3. В верхней панели навигации выберите регион, в котором создана сессия зеркала трафика.
  4. На странице «Сеанс зеркалирования трафика» найдите сеанс зеркалирования трафика, который вы хотите включить, и нажмите «Начать» в столбце «Действия».

Отключить сеанс зеркалирования трафика

  1. Войдите в консоль VPC.
  2. В левой панели навигации выберите .
  3. В верхней панели навигации выберите регион, в котором создана сессия зеркала трафика.
  4. На странице «Сеанс зеркалирования трафика» найдите сеанс зеркалирования трафика, который вы хотите отключить, и нажмите «Остановить» в столбце «Действия».
  5. В появившемся сообщении нажмите OK.

Удалить и добавить зеркальный источник

Если вы хотите изменить ENI, с которого зеркалируется сетевой трафик, удалите исходный источник зеркала трафика и создайте новый.

  1. Войдите в консоль VPC.
  2. В левой панели навигации выберите .
  3. В верхней панели навигации выберите регион, в котором создана сессия зеркала трафика.
  4. На странице «Сеанс зеркала трафика» найдите сеанс зеркала трафика, для которого вы хотите удалить зеркало трафика. источник и щелкните идентификатор сеанса.
  5. В разделе Источники зеркал трафика нажмите Удалить в столбце Действия.
  6. В появившемся сообщении нажмите OK.
  7. В разделе «Источник зеркала» щелкните «Добавить источники зеркалирования трафика».
  8. В диалоговом окне «Добавить источники зеркалирования трафика» выберите ENI, который вы хотите добавить в качестве источника зеркалирования трафика, и щелкните ХОРОШО.

Удалить сеанс зеркала трафика

  1. Войдите в консоль VPC.
  2. В левой панели навигации выберите .
  3. В верхней панели навигации выберите регион, в котором создана сессия зеркала трафика.
  4. На странице «Сеанс зеркалирования трафика» найдите сеанс зеркалирования трафика, который вы хотите удалить, и нажмите «Удалить» в столбце «Действия».
  5. В появившемся сообщении нажмите OK.

Удалить фильтр зеркала трафика

Перед удалением фильтра убедитесь, что фильтр не связан с трафиком. зеркальная сессия.Если фильтр связан с сеансом зеркала трафика, отключите его. фильтр из сеанса зеркала трафика перед удалением фильтра.

  1. Войдите в консоль VPC.
  2. В левой панели навигации выберите .
  3. В верхней панели навигации выберите регион, в котором вы хотите создать фильтр.
  4. На странице «Фильтр» найдите фильтр, который нужно удалить, и нажмите «Удалить» в столбце «Действия».
  5. В появившемся сообщении нажмите OK.

Каталожные номера

AWS расширяет поддержку зеркалирования облачного трафика

Amazon теперь расширила зеркалирование трафика в виртуальном частном облаке (Amazon VPC) для поддержки дополнительных избранных типов инстансов, отличных от Nitro EC2. Зеркалирование трафика Amazon VPC позволяет реплицировать сетевой трафик из инстансов EC2 в VPC на выбранные устройства безопасности и мониторинга.Эта расширенная поддержка зеркалирования трафика VPC для инстансов EC2 позволяет NETSCOUT обеспечивать сквозную видимость для обеспечения безопасности и гарантии обслуживания приложений и сервисов, работающих в AWS.

Ранее клиенты AWS могли включать зеркалирование трафика VPC только на своих инстансах EC2 на базе Nitro. Теперь клиенты могут включить зеркалирование трафика VPC для дополнительных типов инстансов, таких как C4, D2, G3, G3s, h2, I3, M4, P2, P3, R4, X1 и X1e, которые используют гипервизор на основе Xen. Это позволяет клиентам AWS теперь единообразно проверять сетевой трафик на этих дополнительных типах инстансов EC2.Эта функция доступна во всех 22 регионах AWS, где в настоящее время поддерживается зеркалирование трафика VPC.

Зеркальное отображение трафика Amazon VPC помогает NETSCOUT беспрепятственно расширять наши возможности захвата пакетов на AWS и эффективно получать неограниченный обзор приложений и их зависимостей в гибридных облачных средах. Трафик, зеркально отраженный от рабочих нагрузок AWS AMI (Amazon Machine Image) к виртуальным зондам NETSCOUT, развернутым в AWS, преобразуется в интеллектуальные данные и анализируется, чтобы обеспечить глубокое понимание производительности и безопасности приложений.Эти точные и актуальные аналитические данные в режиме реального времени передаются во все подключенные приложения и их взаимодействие с инфраструктурой предоставления услуг.

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

Объединяя зеркалирование трафика Amazon VPC с технологией NETSCOUT, предприятия получают инновационное безагентное решение для оптимизации сбора пакетных данных для эффективного мониторинга безопасности и обеспечения качества обслуживания в гибридных облачных средах до, во время и после переноса рабочей нагрузки в AWS.

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

Добавить комментарий

Ваш адрес email не будет опубликован.