Анализ сетевого трафика является важной задачей, решение которой требуется различным специалистам. Так, специалистам по информационной безопасности необходимо анализировать трафик на наличие подозрительных пакетов, вирусного трафика, сканирования портов, перебора паролей и т. п. Также безопасникам может потребоваться анализировать исходящий трафик на наличие конфиденциальных данных, например, в случае, если в организации используется режим коммерческой тайны. Ну а кроме этого, трафик в автоматическом режиме анализируют системы обнаружения/предотвращения вторжений.
Сетевикам необходимо анализировать трафик для выявления различных аномалий: полуоткрытых соединений, ретрансмитов, потерь пакетов.
Если анализировать трафик, проходящий через периметр могут IDS/IPS, то трафик не выходящий за пределы периметра сети мы можем анализировать только получая копию всех проходящих пакетов. При построении сети важно учитывать потенциальную возможность съема трафика, для того чтобы потом не пришлось использовать дорогостоящие накладные средства съема трафика. Чтобы разобраться с тем, как правильно снимать копию трафика, для начала разберемся с основными принципами зеркалирования.
Зеркалирование трафика (в некоторых случаях также называемое зеркалированием портов) — это метод отправки копии сетевого трафика в серверную систему. Он обычно используется разработчиками сетей и администраторами/операторами для мониторинга сетевого трафика или диагностики проблем. Традиционные решения для зеркального отображения трафика основаны на аппаратных коммутаторах и зависят от производителя, которые часто оказываются дорогостоящими, сложными в использовании и развитии. Здесь уместно вспомнить технологию SPAN от ушедшего от нас вендора. Дело в том, что изначально режим зеркалирования SPAN разрабатывался Циской для выявления проблем в сети и не предполагал постоянного использования. Однако сейчас этот режим используется повсеместно для съема трафика.
Зеркальное отображение трафика предполагает создание копии определенного трафика и отправку этой копии в пункт назначения для дальнейшей обработки. Пунктом назначения может быть либо сетевое устройство: (физический сетевой адаптер/порт, напрямую подключенный по кабелю), либо удаленный узел.
На рисунке ниже выполняется зеркальное отображение только входящих пакетов, но и исходящие также могут быть зеркально отображены; кроме того, вы также можете фильтровать пакеты (например, выбирать только пакеты TCP SYN) перед их копированием.
При построении дизайна системы зеркалирования трафика необходимо решить еще один вопрос: нужно ли нам сохранять каждый полученный пакет, или только его часть? Ответ зависит от ваших потребностей, так, если вы хотите проанализировать содержимое сообщения L7, например HTTP-запросы, вам нужно сохранить пакет полностью. Если вы хотите проанализировать события потока L4, например статистику потока TCP, вы можете просто сохранить заголовки L2-L4 и удалить оставшиеся байты, чтобы сэкономить полосу пропускания и место для хранения. Ну а если предполагается анализировать события потока L2, то, возможно, необходимо сохранить только заголовок L2, чтобы еще больше сократить пропускную способность и объем памяти.
Проблема пересылки зеркальных пакетов
Итак, представим, что мы успешно собираем копии пакетов, но как нам их доставить на нужный удаленный интерфейс? Со SPAN портами все понятно, но что делать если пересылать пакеты надо на удаленный порт. Передача зеркальных пакетов непосредственно по кабелю и не будет работать, поскольку как dsc_mac, так и dst_ip пакетов предназначены локальному узлу. То есть, пакеты все равно могут быть отброшены до того, как попадут на конечное сетевое устройство. Например, конечным устройством, ответственным за обработку этих пакетов, является виртуальное сетевое устройство, расположенное за физической сетевой картой; в этом случае пакеты будут отброшены на сетевой карте из-за несоответствия IP-адреса назначения (и MAC-адреса) текущей сетевой карте.
Один из возможных способов отправки зеркального трафика на удаленный узел заключается в инкапсуляции данного пакета в другой пакет и отправка удаленному узлу. На принимающей стороне мы соответственно извлекаем исходный пакет, декапсулируя внешний заголовок.
Для достижения этой цели существует множество форматов инкапсуляции, например, VxLAN, который помещает исходный пакет в новый UDP-пакет, как показано ниже:
Пример с контейнерами
В качестве примера развернем небольшой стенд с двумя контейнерами Docker. На хост-серверах будет создан Linux-мост docker0 в качестве шлюза сети docker по умолчанию 10.0.108.0/23 (настроенный в /etc/docker/daemon.json).
При запуске контейнера с помощью docker run без указания специальных сетевых параметров он выделит IP-адрес из 10.0.108.0/23 и подключит контейнер к docker0 bridge с помощью пары veth.
$ docker run -d --name ctn-1 alpine:3.11.6 sleep 60d
$ docker run -d --name ctn-2 alpine:3.11.6 sleep 60d
$ docker ps | grep ctn
Далее получим значения идентификаторов для каждого контейнера:
$ NETNS1=$(docker inspect --format "{{.State.Pid}}" ctn-1)
$ NETNS2=$(docker inspect --format "{{.State.Pid}}" ctn-2)
$ echo $NETNS1 $NETNS2
После этого узнаем адреса наших контейнеров
$ nsenter -t $NETNS1 -n ip addr
$ nsenter -t $NETNS2 -n ip addr
В итоге получим следующую топологию:
Далее создадим необходимые сетевые интерфейсы:
$ ip link add docker1 type bridge
$ ip addr add 10.0.110.1/24 dev docker1
$ ip link set docker1 up
Добавим пару виртуальных интерфейсов, одним концом каждый из них будет подключен как vNIC для ctn-1 и ctn-2 соответственно, а второй конец будет подключен к docker.
Настройки для ctn-1:
$ ip link add veth1 type veth peer name peer1
$ ip link set peer1 netns $NETNS1
$ nsenter -t $NETNS1 -n ip link set peer1 name eth1
$ nsenter -t $NETNS1 -n ip addr add 10.0.110.2/23 dev eth1
$ nsenter -t $NETNS1 -n ip link set eth1 up
$ ip link set veth1 master docker1
$ ip link set veth1 up
Настройки для ctn-2:
$ ip link add veth2 type veth peer name peer2
$ ip link set peer2 netns $NETNS2
$ nsenter -t $NETNS2 -n ip link set peer2 name eth1
$ nsenter -t $NETNS2 -n ip addr add 10.0.110.3/23 dev eth1
$ nsenter -t $NETNS2 -n ip link set eth1 up
$ ip link set veth1 master docker1
$ ip link set veth2 up
Сетевые интерфейсы настроены, теперь пропишем маршрутизацию.
$ nsenter -t $NETNS1 -n ip route
В последней записи маршрута указано, что сеть 10.0.110.0/23 (docker 1) доступна через eth1. Проверим это:
$ nsenter -t $NETNS1 -n ping 10.0.110.3
$ nsenter -t $NETNS1 -n ping 10.0.108.3
Как показано на рисунке ниже, теперь мы можем связаться с ctn-2 по отдельному маршруту (через eth1), который не зависит от маршрута, используемого по умолчанию (через eth0). Этот маршрут мы и будем использовать далее.
Туннель VxLAN
Теперь мы готовы к настройке туннеля VxLAN поверх сетевых адаптеров eth1 между ctn-1 и ctn-2.
Настроим туннель на ctn-1:
$ nsenter -t $NETNS1 -n ip link add vxlan0 type vxlan id 100 local 10.0.110.2 remote 10.0.110.3 dev eth1 dstport 4789
$ nsenter -t $NETNS1 -n ip link set vxlan0 up
$ nsenter -t $NETNS1 -n ip addr
Настроим туннель на ctn-2:
$ nsenter -t $NETNS2 -n ip link add vxlan0 type vxlan id 100 local 10.0.110.3 remote 10.0.110.2 dev eth1 dstport 4789
$ nsenter -t $NETNS2 -n ip link set vxlan0 up
В итоге получаем следующую топологию:
Как видно, трафик между vxlan0@ctn-1 и vxlan0@ctn-2 физически идет по следующему пути vxlan0@ctn-1 -> eth1@ctn-1 -> veth1 -> docker1 -> veth2 -> eth1@ctn-2 -> vxlan0@ctn-2, благодаря инкапсуляции пакетов между ctn-1 и ctn-2. Благодаря такому процессу туннелирования мы можем настроить зеркалирование трафика с интерфейса eth0 узла ctn-1 на узел ctn-2.
Для этого на ctn-1 выполним следующую команду:
$ nsenter -t $NETNS1 -n tc filter add dev eth0 parent ffff: protocol all u32 match u32 0 0 action mirred egress mirror dev vxlan0
В итоге, наши зеркалированные пакеты (например ping) будут по такому несколько замысловатому пути доставляться на узел ctn-2.
Заключение
Представленная в статье технология VxLAN позволяет без помощи дополнительных средств инкапсулировать зеркалированные пакеты и передавать их по сети к узлу назначения. Использование данной технологии при передаче трафика позволит эффективно собирать копии пакетов.
Материал подготовлен в преддверии старта онлайн-курса «Дизайн сетей ЦОД» — разработанного для тех, кто знает сетевые технологии и хочет понять, КАК строить сети современных ЦОД.