Архив рубрики: Networks

Сетевая топология Leaf-Spine

В проектировании сетевой инфраструктуры для дата-центров наметилась тенденция создания быстрой, масштабируемой и эффективной коммуникационной архитектуры. Архитектура Leaf-Spine как раз и отвечает таким запросам.

Объемы данных передаваемых по сети как внутри ЦОД, так и вовне, растут в геометрической прогрессии. Классическая трехуровневая сетевая архитектура «ядро – агрегация – доступ» начинает устаревать. Она постепенно заменяется т.н. Leaf-Spine архитектурой, которая способна быстро адаптироваться к непрерывно меняющимся потребностям предприятий, использующих «анализ больших данных» (Big Data), требующих несколько иных подходов к построению дата-центров.

Традиционная трехуровневая архитектура использовалась в сетях общего применения, обычно сегментированных в точках доставки PoD (Point of Delivery), которые ограничивали расположение устройств, таких как сервера виртуализации. Классическая архитектура обычно состоит из маршрутизаторов ядра сети (Core), маршрутизаторов уровня агрегации (Aggregation, иногда – Distribution) и коммутаторов доступа (Access). С целью резервирования они соединялись дублированными линками, которые в сети могли образовывать петли. Для устранения этого нежелательного явления использовался протокол Spanning Tree. Во время работы все маршруты, кроме основного, деактивируются. Резервный маршрут активируется только при отказе основного.

Рис. 1: Традиционная трехуровневая архитектура.

В архитектуре Leaf-Spine имеются только два уровня, при этом все устройства «равноудалены» от коммутаторов «ядра», т.е. имеют одинаковые и предсказуемые задержки при передаче пакетов. Эти уровни называются Leaf и Spine. Уровень Leaf состоит из коммутаторов доступа, подключенных к другим устройствам дата-центра: серверам, межсетевым шлюзам, балансировщикам нагрузки и оконечным коммутаторам. Уровень Spine, состоящий из маршрутизирующих коммутаторов, является ядром сети, где каждый Leaf-коммутатор подключен к каждому из Spine-коммутаторов. Между уровнями используется динамическая маршрутизация Layer 3, чтобы обеспечить предсказуемое расстояние между устройствами. Динамическая маршрутизация позволяет обеспечить наилучший маршрут. Такая архитектура предназначена в основном для дата-центров и ориентирована на трафик «East-West». В таком трафике передаются только данные, предназначенные для использования только внутри дата-центра. Этот новый подход решает присущие протоколу Spanning Tree ограничения, и дает возможность использовать и другие сетевые протоколы, а также методы построения динамичной сети.

Leaf-Spine

Рис. 2: Архитектура Leaf-Spine

В сети Leaf-Spine используется маршрутизация Layer 3. Все маршруты сконфигурированы в активном режиме при помощи протокола равноудаленных маршрутов ECMP (Equal-Cost Multipathing). Это позволяет всем соединениям быть активными одновременно при сохранении стабильности без боязни образования петель внутри сети.

В традиционных протоколах коммутации Layer 2, таких как STP (Spanning Tree) в трехслойных сетях, все устройства должны быть правильно и вручную сконфигурированы и должны быть учтены все особенности STP. При этом очень велика вероятность ошибки конфигурации, в частности, неправильного определения приоритетов устройств, что может повлечь неэффективную прокладку маршрутов.

Преимущества Leaf-Spine

Замена STP между уровнями Access и Aggregation на маршрутизацию Layer 3 дает более стабильную работу сети. Другое преимущество – легкость добавления дополнительного оборудования и расширение емкости. При возникновении перегрузки линков (oversubscription), что означает генерацию бóльшего объема трафика, чем его может воспринять уровень агрегации), способность к увеличению емкости является очевидным преимуществом. Эта проблема легко решается добавлением еще одного коммутатора Spine. Точно также можно добавлять коммутаторы Leaf, когда не хватает портов доступа. При этом сеть легко расширяется и при этом не требуется возня с протоколами Layer 2

Недостатки Leaf-Spine

При использовании сетевой архитектуры Leaf-Spine возникают и некоторые проблемы. Во-первых, это большое количество кабельной «лапши» в стойках дата-центра, что видно даже на рисунке, показывающем архитектуру Leaf-Spine. И при добавлении новых коммутаторов на обоих уровнях эта проблема будет только расти. Нужно очень тщательно выбирать место расположения коммутаторов Spine в дата-центрах, особенно больших, чтобы минимизировать эту проблему.

Во-вторых, основной недостаток происходит от использования маршрутизации Layer 3, который не дает развертывать виртуальные сети VLAN во всей сети. Сети VLAN в архитектуре Leaf-Spine локализуются в каждом из Leaf-коммутаторов и другим Leaf-коммутаторам недоступны. Это может создавать проблемы при обеспечении мобильности гостевой виртуальной машины в пределах дата-центра.

Примеры применения Leaf-Spine

Веб-приложения, где расположение сервера внутри сети статично – подходящее применение для Leaf-Spine. Использование маршрутизации Layer 3 между уровнями не препятствует работе масштабируемых веб-приложений, потому что они не требуют мобильности серверов внутри дата-центра. Устранение протокола Spanning Tree (STP) положительно влияет на стабильность и надежность сети с преобладанием внутреннего трафика дата-центра (East-West). Масштабируемость архитектуры также улучшается.

Корпоративные приложения с использованием мобильных виртуальных машин (напр. vMotion) создают некоторые проблемы при обслуживании серверов в пределах дата-центра. Причина – использование Layer 3 и невозможность расширения VLAN между Leaf-коммутаторами. Для решения этой проблемы, может быть использовано решение программно-конфигурируемых сетей SDN (Software Defined Networking), которое создает виртуальный уровень Layer 2 поверх сети Leaf-Spine. При этом виртуальные серверы могут свободно перемещаться внутри среды дата-центра, без ухудшения эффективности трафика East-West, масштабируемости и стабильности топологии сети Leaf-Spine.

Как альтернатива маршрутизации Layer 3, в топологии Leaf-Spine могут использоваться и другие протоколы, такие как TRILL (Transparent Interconnection of Lots of Links) или SPB (Shortest Path Bridging), с которыми можно достичь схожей функциональности. При этом задействуется протокол ECMP уровня Layer 2, когда Spanning Tree работает только для организации VLAN’ов между Leaf-коммутаторами.

 Выводы

Таким образом, сети Leaf-Spine имеют существенные преимущества перед традиционной трехслойной архитектурой сети. Использование маршрутизации Layer 3 с протоколом ECMP (Equal Cost Multipathing) помогает значительно расширить доступную полосу пропускания, за счет эффективного использования доступных линков. При этом удается достичь адаптируемости и масштабируемости сети. Устранение протокола STP (Spanning Tree Protocol) существенно повышает стабильность сети. Недостатки Leaf-Spine (например, ограничения VLAN) можно преодолеть при помощи таких решений, как SDN.



2020-03-31T12:34:36
other

Полная настройка Wi-Fi роутера Netis MW5240 от Ботана

Приветствую тебя, владелец этого чудесного роутера! В этой статье по шагам и без всяких там SMS разберем подробно процесс настройки Netis MW5240. Предлагаю перейти к делу)

Ботан Ботан Мастер занудных текстов и технического слога. Мистер классные очки и зачётная бабочка. Дипломированный Wi-Fi специалист. Если остались какие-то вопросы или сомнения, или же вдруг захотелось поделиться своим мнением – добро пожаловать в комментарии. Выслушаем, поможем, будем полезны другим людям. Спасибо! Читать

Как построить серверную, за которую можно быть спокойным

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

Однако что делать, если руководство все-таки прониклось «страданиями» сисадмина и запланировало в бюджете компании расходы на замену на «частное облако»?

Конечно же – немедленно составить список всего необходимого. И разработать проект организации новой серверной комнаты.

Начинаем…

Серверная в офисе

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

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

Оба варианта одинаково комплектуются колесиками, ножками, имеют крышки безинструментального монтажа, заземление, перфорированные двери и подлежат сбору/разбору. Однако последний вариант (SV) является более бюджетным, так как его стойки имеют меньшую несущую способность, а «крыша» не имеет отверстий для монтажа кабельных каналов.

Если нет отдельной комнаты

Если выделить отдельное помещение под серверную компания не может, остается один вариант – установка оборудования прямо в офисе. Модель CX как раз и предназначена для решения этой проблемы – по внешнему виду стойка напоминает деревянный шкаф, при этом она обеспечивает максимальную звукоизоляцию, объединенную вентиляцию и распределённое электроснабжение.

Что с питанием?

ИБП для серверной

Следующий важный момент, который необходимо запланировать — электропитание. Компании предлагают огромный выбор источников бесперебойного питания (ИБП). Последнее поколение оборудовано ЖК-дисплеями, которые дают возможность отслеживать состояние ИБП и управлять ими без компьютера.

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

Если же используется более мощное оборудование, выход только один – выделить под серверную отдельное помещение c серверным ИБП, которое будет хорошо охлаждаться.

Рука на пульсе

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

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



2020-03-05T18:11:46
Сети

Как подключить интернет на компьютер с телефона: USB кабель, Wi-Fi, Bluetooth.

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

Установка WireGuard на Ubuntu/Debian

Сегодня в статье приведу пример по установке и настройке VPN сервера WireGuard для операционных систем Ubuntu и Debian. Также данная статья будет справедлива и для всех производных систем данного типа.

WireGuard – это современная высокопроизводительная VPN для Linux,Windows, MacOS. Главной функцией WireGuard является обеспечение безопасного соединения между сторонами через сетевой интерфейс, зашифрованный с помощью аутентификации по открытому ключу. Это означает, что, в отличие от большинства виртуальных частных сетей, WireGuard не применяет топологию, что позволяет создавать различные конфигурации путем изменения конфигураций окружающей сети. Эта модель предлагает большую производительность и гибкость.

Сейчас WireGuard готовится к включению в состав ядра Linux. Если быть точнее, то он появится в ядре версии 5.6, он даже получил похвалу от Линус Торвальдса и в американском сенате.

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

Причина, которая объясняет высокую скорость работы WireGuard, это применение быстрого и современного алгоритма шифрования, благодаря которому скорость передачи данных очень высока.

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

Установка и настройка при помощи скрипта

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

Первым шагом подготовим нашу систему:

sudo -su
apt update && apt upgrade -y
apt install curl

Далее скачиваем скрипт.

curl -O https://raw.githubusercontent.com/angristan/wireguard-install/master/wireguard-install.sh

Делаем его исполняемым:

chmod +x wireguard-install.sh

Запускаем установку и настройку WireGuard

./wireguard-install.sh

Установка WireGuard на Ubuntu

Установку нашего VPN WireGuard я буду производить на сервере под управлением операционной системы Ubuntu/Debian. И так поехали.

Ubuntu 18.04

Для начала надо добавить официальный репозиторий в систему:

sudo add-apt-repository ppa:wireguard/wireguard
  • Обновляем индексы
sudo apt update
  • Устанавливаем wireguard
sudo apt install -y wireguard wireguard-dkms iptables resolvconf qrencode

Ubuntu 20.04/22.04

Так как пакет входит в официальный репозиторий, то необходимо набрать всего лишь данные команды:

  • Обновляем индексы
sudo apt update
  • Устанавливаем wireguard
sudo apt install -y wireguard wireguard-dkms iptables resolvconf qrencode

Установка WireGuard на Debian

Для того чтобы установить WireGuard на Debian с начало необходимо авторизоваться под root пользователем:

sudo su

Далее набираем следующее:

echo "deb http://deb.debian.org/debian buster-backports main" >/etc/apt/sources.list.d/backports.list
apt update
apt install -y iptables resolvconf qrencode
apt install -y -t buster-backports wireguard

Для остальных операционных систем можете посмотреть официальную страничку инсталляции.

Также установите заголовки для вашего ядра, если вы еще этого не сделали:

apt-get install linux-headers-$(uname -r|sed 's/[^-]*-[^-]*-//')

Настройка VPN WireGuard на серверной части

Давайте теперь настроим наш высокопроизводительный VPN на сервере wireguard. Для этого создадим файл конфигурации и необходимые ключи шифрования. Все действия выполняем из под root.

sudo su
(umask 077 && printf "[Interface]nPrivateKey = " | sudo tee /etc/wireguard/wg0.conf > /dev/null)
wg genkey | sudo tee -a /etc/wireguard/wg0.conf | wg pubkey | sudo tee /etc/wireguard/wg-server-publickey.key
  • Первая команда записывает исходное содержимое конфигурационного файла в /etc/wireguard/wg0.conf. Значение umask в суб-оболочке позволяет создать файл с ограниченными разрешениями, не затрагивая обычную среду.
  • Вторая команда генерирует закрытый ключ с помощью команды wg и записывает ее непосредственно в конфигурационный файл с ограниченным доступом. Затем ключ передается обратно команде wg pubkey, чтобы получить связанный с ним открытый ключ, который записывается в /etc/wireguard/wg-sever-publickey.key.

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

sudo nano /etc/sysctl.conf

И уберем знак комментария # со строки:

net.ipv4.ip_forward=1

Применим изменения

sudo sysctl -p

Далее отрываем файл на редактирования и вносим необходимую информацию о нашей VPN сети.

sudo nano /etc/wireguard/wg0.conf

Конфигурационный файл vpn wireguard

Внутри, в разделе [Interface], вы должны увидеть свой сгенерированный закрытый ключ. Этот раздел содержит конфигурацию для локальной стороны соединения.

В разделе Interface нужно также определить IP-адрес VPN, который будет использовать этот узел, и порт, который он будет прослушивать для соединений с одноранговыми узлами.

Давайте добавим в него следующие строки ListenPort, SaveConfig и Address:

[Interface]
PrivateKey = приватный_ключ_сервера
ListenPort = 5555
SaveConfig = true
Address = 10.0.0.1/24 
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE
  • ListenPort – указываем свободный порт который будет прослушивать наш сервис wg-quick (VPN WireGuard)
  • SaveConfig – имеет значение true, чтобы сервис wg-quick мог автоматически сохранять свою активную конфигурацию в этом файле при завершении работы.
  • Address – это наш IP-адрес и маска сети
  • PostUP и PostDown – запускают необходимые правило для iptables

Пробуем поднять нашу сеть скриптом wg-quick:

sudo wg-quick up /etc/wireguard/wg0.conf

В системах с systemd вместо этого можно использовать следующую запись:

sudo systemctl start wg-quick@wg0.service

Если systemd ругается, то сперва необходимо включить сервис следующей командой:

sudo systemctl enable wg-quick@wg0.service

Настройка VPN WireGuard на клиентской машине

В качестве клиента у меня будет выступать ноутбук с операционной системой Ubuntu Desktop 18.04 LTS

Все действия выполняем из под пользователя root.

sudo su
add-apt-repository ppa:wireguard/wireguard 
apt install wireguard -y

Для Ubuntu 20.04 необходимо повторить тоже самое, что и при установке на серверную часть. (см. Выше)

Далее создаем конфигурационный файл и генерируем ключи:

(umask 077 && printf "[Interface]nPrivateKey = " | sudo tee /etc/wireguard/wg0.conf > /dev/null)
wg genkey | sudo tee -a /etc/wireguard/wg0.conf | wg pubkey | sudo tee /etc/wireguard/wg-server-publickey.key

Открываем наш конфигурационный файл и вносим изменения.

sudo nano /etc/wireguard/wg0.conf
[Interface]
PrivateKey = приватный_ключ_клиента
ListenPort = 5555
Address = 10.0.0.2/32 

Создайте раздел под названием [Peer] после раздела [Interface].

[Peer]
PublicKey = Публичный_ключ_сервера
AllowedIPs = 10.0.0.0/24
Endpoint = IP-адрес_сервера:5555
PersistentKeepalive = 10
  • PublicKey – укажите значение открытого ключа сервера. Вы можете найти это значение, набрав на сервере команду: wg
  • AllowedIPs – указывает на пропуск трафика через VPN. В данном случае будет проходить через VPN только трафик сети 10.0.0.0/24. Весть остальной трафик пойдет через вашего провайдер. Для заворота всего трафика через VPN указываем значение 0.0.0.0/0
  • PersistentKeepalive – время в секундах для постоянной проверки доступности ресурса.

Запускаем сервис на Ubuntu:

 sudo systemctl start wg-quick@wg0.service 

Запускаем сервис на Debian:

sudo wg-quick up /etc/wireguard/wg0.conf

Peer на стороне сервера

На сервере также необходимо добавить информацию о клиенте. Иначе ваш туннель VPN не откроется. Для этого возвращаемся на сервер и останавливаем службу wireguard:

sudo systemctl stop wg-quick@wg0.service

Далее открываем конфигурационный файл:

sudo nano /etc/wireguard/wg0.conf

И вносим информацию о клиенте.

[Peer]
PublicKey = публичный_ключ_клиента
AllowedIPs = 10.0.0.5/32
PersistentKeepalive = 10
  • PublicKey – ключ клиента можно посмотреть на клиентской машине при помощи команды wg.
  • AllowedIPs – указывает на IP клиента. Обязательно с маской 32

Запускаем наш сервис:

 sudo systemctl start wg-quick@wg0.service 

Пробуем пропинговать клиента.

ping 10.0.0.2
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.916 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.545 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.647 ms

Со стороны клиента также должен проходить пинг до сервера.

ping 10.0.0.1
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=2.40 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.646 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.555 ms

Хотя статья получилась большой, но все настраивается очень быстро.

Тонкая настройка параметров WireGuard на примере Proxmox

  • /usr/lib/sysctl.d/10-pve-ct-inotify-limits.conf
    fs.inotify.max_queued_events = 8388608
    fs.inotify.max_user_instances = 65536
    fs.inotify.max_user_watches = 4194304
    vm.max_map_count = 262144
    net.ipv4.neigh.default.gc_thresh3 = 8192
    net.ipv6.neigh.default.gc_thresh3 = 8192
    kernel.keys.maxkeys = 2000
  • /usr/lib/sysctl.d/10-pve.conf
    net.bridge.bridge-nf-call-ip6tables = 0
    net.bridge.bridge-nf-call-iptables = 0
    net.bridge.bridge-nf-call-arptables = 0
    net.bridge.bridge-nf-filter-vlan-tagged = 0
    net.ipv4.igmp_link_local_mcast_reports = 0
    fs.aio-max-nr = 1048576
  • /usr/lib/sysctl.d/50-pid-max.conf
    kernel.pid_max = 4194304
  • /etc/sysctl.d/99-sysctl.conf
    net.ipv4.ip_forward = 1
  • /usr/lib/sysctl.d/protect-links.conf
    fs.protected_fifos = 1
    fs.protected_hardlinks = 1
    fs.protected_regular = 2
    fs.protected_symlinks = 1
  • /usr/lib/sysctl.d/pve-firewall.conf
    net.ipv4.conf.all.rp_filter = 2
  • /etc/sysctl.d/wg.conf
    net.ipv4.ip_forward = 1
    net.ipv6.conf.all.forwarding = 1
  • /etc/sysctl.conf
    net.ipv4.ip_forward = 1

🔥 Как перехватить трафик в коммутируемой среде?

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

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

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

Так как же перехватить трафик?

Как расположить и настроить оборудование для прослушивания ?

Предлагаю рассмотреть варианты расположения (подключения) оборудования для снифа в коммутируемой среде (перехват wi-fi канала рассмотрим в следующей статье).

Самым удобным способ является установка сниффера непосредственно на интересующем нас прослушиваемом хосте.

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

К примеру ARP запрос, который используют хосты для определения MAC-адреса, который соответствует определенному IP-адресу.

Зная IP, направляем ARP запрос с целью сопоставления IP-MAC всем устройствам внутри широковещательного домена.

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

Для наглядности, с помощью Cisco Packet racer, рассмотрим как хост с IP-адрессом 192.168.1.2 направляет ARP запрос на хост 192.168.1.4.

Предварительно проверив, что ARP записей на 192.168.1.2 нет от слова совсем командой arp -a (удалить их можно с помощью arp -d) выолняем команду ping на 192.168.1.4.

Так как мы не знаем MAC адрес, то первончально направляем ARP запрос. Запрос приходит на коммутатор (cisco 2960), далее он направляется на все хосты, подключенные к коммутатору. После этого хост 192.168.1.3 отбрасывает указанный, а 192.168.1.4 соответственно отвечает.

 

Для того, чтобы захватывать весь поступающий траффик на 192.168.1.3 необходимо на сетевом интерфейсе включить смешанный режим раюоты. Это позволяют сделать программные компоненты Aircrack-ng, Wireshark, tcp dump  идр.

Когда нет возможности разместить анализатор трафика на целевом хосте помочь может концентратор.

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

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

Так например, отправив пакеты с Host1 на Host2,  концентратор Hub0 направит их как на исследуемый Host2,  так и на анализатор пакетов Sniffer.

Отброс пакетов Sniffer’ом на картинке, обусловлен отключенным смешанным режимом работы сетевого адаптера.

Самым популярным способом перехвата трафика остается метод зеркалирование портов.

Для реализации этого метода необходимо чтобы коммутатор был управляемым, а также иметь физический или через удаленный ssh/Web-интерфейс доступ к нему.

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

Так, подключившись, настроим коммутатор Сisco 2960 для зеркалирования трафика на портах fastEthernet 0/1 и fastEthernet 0/2 куда подключены host1 и host2 соответсвенно:

Switch>enable

Switch#conf terminal

Switch(config)#monitor session 1 source interface fastEthernet 0/1

Switch(config)#monitor session 1 source interface fastEthernet 0/2

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

Switch(config)#monitor session 1 destination interface f0/24

Проверим:

Switch#show monitor

Session 1

---------

Type                   : Local Session

Description            : -

Source Ports           :

Both               : Fa0/1,Fa0/2

Destination Ports      : Fa0/24

Encapsulation      : Native

Ingress      : Disabled

Итак направим пакеты от Host1 (192.168.1.1)  на Host2( 192.168.1.2) и видим, что они зеркалируются коммутатором наш снифер:

Открываем перехваченный ICMP пакет на снифере:

 

Указанные методы не лишены недостатков, а другие методы перехвата сетевого трафика – такие как заражение ARP-кэша и применение сетевых ответвителей рассмотрим в следующих статьях.

¯_(ツ)_/¯

Примечание: Информация для исследования, обучения или проведения аудита. Применение в корыстных целях карается законодательством РФ.



2020-02-05T13:23:31
Аудит ИБ