По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Классический стандарт связующего дерева работает нормально, но в настоящее время для современных сетей он слишком медленный 🐌 В настоящее время мы наблюдаем в наших сетях все больше и больше маршрутизации. Протоколы маршрутизации, такие как OSPF и EIGRP, намного быстрее адаптируются к изменениям в сети, чем spanning-tree. Чтобы не отставать от скорости этих протоколов маршрутизации, была создана еще одна разновидность связующего дерева... (rapid spanning tree) быстрое связующее дерево. Rapid spanning tree - это не революция spanning tree, а его эволюция. Некоторые вещи были изменены для того, что бы ускорить процесс, но с точки зрения конфигурации - это то же самое, что классический spanning tree . Я называю оригинальное spanning tree "классическим spanning tree". Азы Rapid spanning tree Помните состояние портов spanning tree? У нас есть блокирующее, прослушивающее, обучающее и пересылающее состояние порта. Это первое различие между spanning tree и rapid spanning tree. Rapid spanning tree имеет только три состояния портов: Отбрасывание; Обучение; Пересылка. Вы уже знакомы с состоянием порта в режиме обучения и пересылки, но отбрасывание - это новое состояние порта. В основном он объединяет в себе блокировку и прослушивание состояния порта. Вот хороший обзор с различными состояниями портов для spanning tree и rapid spanning tree. В таблице отображено состояние портов: активны ли они и узнают ли они MAC-адреса или нет. Помните ли вы все остальные роли портов, которые есть у spanning tree? Давайте сделаем небольшой обзор, и будет показано отличие от rapid spanning tree. Коммутатор с лучшим ID моста (priority + MAC -адрес) становится корневым мостом. Другие коммутаторы (non-root) должны найти кратчайший путь стоимости к корневому мосту. Это корневой порт. Здесь нет ничего нового, все это работает аналогично и в rapid spanning tree. На каждом сегменте может быть только один назначенный порт, иначе мы получим петлю. Порт станет назначенным портом, если он сможет отправить лучший BPDU. Коммутатор А, как корневой мост, всегда будет иметь лучшие порты, поэтому все интерфейсы будут назначены. Интерфейс fa0/16 на коммутаторе B будет назначенным портом в моем примере, потому что он имеет лучший идентификатор моста, чем коммутатор C. Здесь все еще нет ничего нового по сравнению с классическим связующим деревом. Коммутатор C получает лучшие BPDU на своем интерфейсе fa0/16 от коммутатора B, и таким образом он будет заблокирован. Это альтернативный порт, и это все еще то же самое, что и для rapid spanning tree. Вот вам новый порт, взгляните на интерфейс fa0/17 коммутатора B. Он называется резервным портом и является новым для rapid spanning tree. Однако вы вряд ли увидите этот порт в производственной сети. Между коммутатором B и коммутатором C был добавлен хаб. Обычно (без промежуточного концентратора) оба fa0/16 и fa0/17 будут назначены портами. Из-за хаба интерфейсы fa0/16 и fa0/17 коммутатора B теперь находятся в одном домене коллизий. Fa0/16 будет выбран в качестве назначенного порта, а fa0/17 станет резервным портом для интерфейса fa0/16. Причина, по которой коммутатор B видит интерфейс fa0/17 в качестве резервного порта, заключается в том, что он получает свои собственные BPDU на интерфейсах fa0/16 и fa0/17 и понимает, что у него есть два соединения с одним и тем же сегментом. Если вы удалите хаб, то fa0/16 и fa0/17 будут назначены портами точно так же, как classic spanning tree. BPDU отличается для rapid spanning tree. В classic spanning tree поле flags использовало только два бита: Topology change.; Topology change acknowledgment.; Теперь используются все биты поля flags. Роль порта, который создает BPDU, будет добавлена с помощью поля port role, оно имеет следующие параметры: Unknown; Alternate / Backup port; Root port; Designated port. Эта BPDU называется BPDUv2. Коммутаторы, работающие со старой версией spanning tree, проигнорируют эту новую версию BPDU. Если вам интересно ... rapid spanning tree и старое spanning tree совместимы! Rapid spanning tree способно работать с коммутаторами, работающими под управлением более старой версии spanning tree. Что поменялось BPDU теперь отправляются каждый hello time. Только корневой мост генерирует BPDU в classic spanning tree, и они ретранслировались non-root, если они получали его на свой корневой порт. Rapid spanning tree работает по-разному...все коммутаторы генерируют BPDU каждые две секунды (hello time). Это hello timeпо умолчанию, но вы можете его изменить. classic spanning tree использует максимального время жизни (20 секунд) для BPDU, прежде чем они будут отброшены. Rapid spanning работает по-другому! BPDU теперь используются в качестве механизма поддержания активности, аналогичного тому, что используют протоколы маршрутизации, такие как OSPF или EIGRP. Если коммутатор пропускает три BPDU от соседнего коммутатора, он будет считать, что подключение к этому коммутатору было потеряно, и он немедленно удалит все MAC-адреса. Rapid spanning tree будет принимать низшие BPDU. Classic spanning tree игнорирует их. Скорость перехода (время сходимости) является наиболее важной характеристикой rapid spanning tree. Classic spanning tree должно было пройти через состояние прослушивания и обучения, прежде чем оно переведет интерфейс в forwarding состояние, это занимает 30 секунд (таймер по умолчанию). Classic spanning было основано на таймерах. Rapid spanning не использует таймеры, чтобы решить, может ли интерфейс перейти в forwarding состояние или нет. Для этого он будет использовать переговорный (negotiation) механизм. Чуть позже я покажу вам, как это работает. Помните ли вы понятие portfast? Если мы включим portfast во время запуска classic spanning tree, оно пропустит состояние прослушивания и обучения и сразу же переведет интерфейс в forwarding состояние. Помимо перевода интерфейса в forwarding состояние, он также не будет генерировать изменения топологии, когда интерфейс переходит в состояние UP или DOWN. Мы все еще используем portfast для rapid spanning tree, но теперь он называется пограничным портом (edge port). Rapid spanning tree может только очень быстро переводить интерфейсы в forwarding состояние на edge ports (portfast) или интерфейсы типа point-to-point. Он будет смотреть на link type, и есть только два ink types: Point-to-point (full duplex); Shared (half duplex). Обычно мы используем коммутаторы, и все наши интерфейсы настроены как full duplex, rapid spanning tree видит эти интерфейсы как point-to-point. Если мы введем концентратор в нашу сеть, то у нас будет half duplex, который рассматривается как shared interface к rapid spanning-tree. Позвольте мне описать механизм быстрой синхронизации spanning tree, используя рисунок выше. Коммутатор А сверху - это корневой мост. Коммутатор B, C и D- некорневые мосты (non-root). Как только появится связь между коммутатором А и коммутатором B, их интерфейсы будут находиться в режиме блокировки. Коммутатор B получит BPDU от коммутатора A, и теперь будет происходить согласование, называемое синхронизацией. После того, как коммутатор B получил BPDU от корневого моста, он немедленно блокирует все свои порты, не обозначенные в списке non-edge. Non-edge порты - это интерфейсы для подключения к другим коммутаторам, пока edge порты- интерфейсы, настроены как portfast. Как только коммутатор B блокирует свои non-edge порты, связь между коммутатором A и коммутатором B переходит в forwarding состояние. Коммутатор B также выполнит операцию синхронизации как с коммутатором C, так и с коммутатором D, чтобы они могли быстро перейти в forwarding состояние. Главное, что следует усвоить здесь, заключается в том, что rapid spanning tree использует этот механизм синхронизации вместо механизма "таймера", который использует classic spanning tree (прослушивание → обучение → forwarding). Давайте увеличим масштаб механизма синхронизации rapid spanning tree, подробно рассмотрев коммутатор A и коммутатор B. Сначала интерфейсы будут заблокированы до тех пор, пока они не получат BPDU друг от друга. В этот момент коммутатор B поймет, что коммутатор A является корневым мостом, потому что он имеет лучшую информацию BPDU. Механизм синхронизации начнется, потому что коммутатор А установит proposal bit в поле flag BPDU. Коммутатор B получает предложение от коммутатора A и понимает, что он должен что-то сделать. Он заблокирует все свои non-edge интерфейсы и запустит синхронизацию в направлении коммутатора C и коммутатора D. Как только коммутатор B перевед свои интерфейсы в режим синхронизации, это позволит коммутатору А узнать об этом, отправив соответствующее соглашение. Это соглашение является копией proposal BPDU, где proposal bit, был switched off, а agreement bit - switched on. Интерфейс fa0/14 на коммутаторе B теперь перейдет в режим forwarding. Как только коммутатор A получит соглашение от коммутатора B, он немедленно переведет свой интерфейс fa0/14 в режим пересылки. А как насчет интерфейса fa0 / 16 и fa0 / 19 на коммутаторе B? Точно такой же механизм синхронизации будет иметь место и сейчас на этих интерфейсах. Коммутатор B направит предложение по своим интерфейсам fa0/16 и fa0/19 в сторону коммутатора C и коммутатора D. Коммутатор C и коммутатор D не имеют никаких других интерфейсов, поэтому они отправят соглашение обратно на коммутатор B. Коммутатор B переведет свои интерфейсы fa0/16 и fa0/19 в режим forwarding, и на этом мы закончим. Этот механизм синхронизации - всего лишь пара сообщений, летающих туда-сюда, и очень быстро, это намного быстрее, чем механизм на основе таймера classic spanning tree! Что еще нового в rapid spanning tree? Есть еще три вещи: UplinkFast; Механизм изменения топологии; Совместимость с классическим связующим деревом. Когда вы настраиваете classic spanning tree, вы должны включить UplinkFast самостоятельно. Rapid spanning tree использует UpLinkFast по умолчанию, вам не нужно настраивать его самостоятельно. Когда коммутатор теряет свой корневой порт, он немедленно переводит свой альтернативный порт в forwarding. Разница заключается в том, что classic spanning tree нуждалось в multicast кадрах для обновления таблиц MAC-адресов всех коммутаторов. Нам это больше не нужно, потому что механизм изменения топологии для rapid spanning tree отличается. Так что же изменилось в механизме изменения топологии? С classic spanning tree сбой связи вызвал бы изменение топологии. При использовании rapid spanning tree сбой связи не влияет на изменение топологии. Только non-edge интерфейсы (ведущие к другим коммутаторам), которые переходят в forwarding состояние, рассматриваются как изменение топологии. Как только коммутатор обнаружит изменение топологии это произойдет: Он начнет изменение топологии при значении таймера, которое в два раза превышает hello time. Это будет сделано для всех назначенных non-edge и корневых портов.; Он будет очищать MAC-адреса, которые изучаются на этих портах.; До тех пор, пока происходит изменение топологии, во время активности таймера, он будет устанавливать бит изменения топологии в BPDU, которые отправляются из этих портов. BPDU также будет отправлен из своего корневого порта.; Когда соседний коммутатор получит этот BPDU с установленным битом изменения топологии, произойдет следующее: Он очистит все свои MAC-адреса на всех интерфейсах, кроме того, на котором он получил BPDU с включенным изменением топологии.; Он запустит изменение топологии во время самого таймера и отправит BPDU на все назначенные порты и корневой порт, установив бит изменения топологии.; Вместо того, чтобы отправлять изменения топологии вплоть до корневого моста, как это делает classic spanning tree, изменение топологии теперь быстро распространяется по всей сети. И последнее, но не менее важное, давайте поговорим о совместимости. Rapid spanning tree и classic spanning tree совместимы. Однако, когда коммутатор, на котором работает Rapid spanning tree, связывается с коммутатором, на котором работает classic spanning tree, все функции скоростной передачи данных не будут работать! В приведенном выше примере у меня есть три коммутатора. Между коммутатором A и коммутатором B мы запустим rapid spanning tree. Между коммутатором B и коммутатором C мы вернемся к classic spanning tree.
img
Достаточно просто посмотреть «железные» компоненты вашего сервера в том случае, если он установлен поверх операционной системы на базе Windows. А что делать, если на сервере используется Linux – based операционная система? У нас есть ответ. В Linux имеется множество различных команд, которые расскажут вам о процессорных или оперативных мощностях, дисках, USB или сетевых адаптерах, контроллерах или сетевых интерфейсах, а также о прочих «hardware» компонентах. Итак, спешим поделиться 16 командами, которые помогут вам познакомиться с сервером поближе. lscpu Самая простая команда для получения информации о процессорных мощностях (CPU) - lscpu. Она не имеет каких – либо дополнительных опций (ключей) и выполняется в единственном исполнении: [root@hq ~]# lscpu Architecture: i686 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 1 On-line CPU(s) list: 0 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 94 Stepping: 3 CPU MHz: 3191.969 BogoMIPS: 6383.93 Hypervisor vendor: Microsoft Virtualization type: full L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 3072K lshw – список железных компонентов Если у вас не исполняется данная команда, то вам необходимо установить lshw дополнительно. Например, в CentOS это можно сделать командой sudo yum install lshw. Данная команда позволяет получить информативное описание компонентов вашего сервера, в том числе CPU, памяти, USB/NIC, аудио и прочих: [root@hq ~]# lshw -short H/W path Device Class Description ===================================================== system Virtual Machine /0 bus Virtual Machine /0/0 memory 64KiB BIOS /0/5 processor Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz /0/51 memory 4GiB System Memory /0/100 bridge 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled) /0/100/7 bridge 82371AB/EB/MB PIIX4 ISA /0/100/7.1 scsi1 storage 82371AB/EB/MB PIIX4 IDE /0/100/7.1/0.0.0 /dev/cdrom1 disk DVD reader /0/100/7.3 bridge 82371AB/EB/MB PIIX4 ACPI /0/100/8 display Hyper-V virtual VGA /0/1 scsi2 storage /0/1/0.0.0 /dev/sda disk 160GB SCSI Disk /0/1/0.0.0/1 /dev/sda1 volume 500MiB EXT4 volume /0/1/0.0.0/2 /dev/sda2 volume 149GiB Linux LVM Physical Volume partition /1 eth0 network Ethernet interface lspci – список PCI Данная команда отображает список всех PCI – шин и устройств, подключенных к ним. Среди них могут быть VGA – адаптеры, видео – карты, NIC, USB, SATA – контроллеры и прочие: [root@hq ~]# lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled) (rev 03) 00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01) 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) 00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual VGA lsscsi – список SCSI устройств Данная команды выведет список SCSI/SATA устройств, например, таких как оптические приводы: [root@hq ~]# lsscsi [3:0:0:0] disk ATA WD1600JS-55NCB1 CC38 /dev/sdb [4:0:0:0] cd/dvd SONY DVD RW DRU-190A 1.63 /dev/sr0 lsusb – список USB – шин и подробная информация об устройствах Команда расскажет про USB – контроллеры и устройства, подключенные к ним. По умолчанию, команда отобразит краткую информацию. В случае, если необходима глубокая детализация, воспользуйтесь опцией -v: [root@hq ~]# lsusb Bus 003 Device 001: ID 9c6a:00c1 Linux Foundation 1.1 root hub Bus 004 Device 002: ID 092e:00de Microsoft Corp. Basic Optical Mouse v2.0 lsblk - устройства и партиции для хранения Команда выведет информацию о разделах (партициях) жесткого диска и прочих устройствах, предназначенных для хранения: [root@hq ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom sda 8:0 0 149.6G 0 disk +-sda1 8:1 0 500M 0 part /boot L-sda2 8:2 0 149.1G 0 part +-VolGroup-lv_root (dm-0) 253:0 0 50G 0 lvm / +-VolGroup-lv_swap (dm-1) 253:1 0 2G 0 lvm [SWAP] L-VolGroup-lv_home (dm-2) 253:2 0 97.2G 0 lvm /home df - информация о пространстве файловой системы Команда отображает информацию о различных разделах, точек монтирования это разделов а также размер, занятое и доступное пространство для хранения: [root@hq ~]# df -H Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup-lv_root 53G 7.1G 43G 15% / tmpfs 2.1G 0 2.1G 0% /dev/shm /dev/sda1 500M 26M 448M 6% /boot /dev/mapper/VolGroup-lv_home 103G 143M 98G 1% /home pydf - df на языке Python Если у вас не исполняется данная команда, то вам необходимо установить pydf дополнительно. Например, в CentOS это можно сделать командой sudo yum install pydf. Улучшенная версия команды df, написанная на Питоне. Подсвечивает вывод цветом, что улучшает восприятие: fdisk Утилита fdisk для управления разделами на жестких дисках. Помимо всего, утилита может использоваться для отображения информации: [root@hq ~]# sudo fdisk -l Disk /dev/sda: 160.7 GB, 160657440768 bytes 255 heads, 63 sectors/track, 19532 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000e0ba6 Device Boot Start End Blocks Id System /dev/sda1 * 1 64 512000 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 64 19533 156378112 8e Linux LVM Disk /dev/mapper/VolGroup-lv_root: 53.7 GB, 53687091200 bytes 255 heads, 63 sectors/track, 6527 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 mount Утилита mount предназначена для управления и просмотра смонтированных файлов систем и соответствующих точек: [root@hq ~]# mount | column -t /dev/mapper/VolGroup-lv_root on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) /dev/sda1 on /boot type ext4 (rw) /dev/mapper/VolGroup-lv_home on /home type ext4 (rw) /var/spool/asterisk/monitor on /var/www/html/ast_mon_dir type none (rw,bind) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) free Посмотреть общий объем оперативной памяти (RAM), свободный или занятый? Легко, с помощью команды free: [root@hq ~]# free -m total used free shared buffers cached Mem: 3919 3692 227 0 196 407 -/+ buffers/cache: 3088 830 Swap: 2015 0 2015 dmidecode Данная команда отличается от остальных тем, что парсит информацию о железе из SMBIOS/DMI (очень детальный вывод). #посмотреть информацию о cpu sudo dmidecode -t processor #ram информация sudo dmidecode -t memory #информация о bios sudo dmidecode -t bios файлы /proc В директории /proc существует целое множество файлов, содержимое которых расскажет множество интересной и полезной информации о компонентах. Например, информация о CPU и памяти: #cpu информация cat /proc/cpuinfo #информация о памяти cat /proc/meminfo Информация об операционной системе: [root@hq ~]# cat /proc/version Linux version 2.6.32-504.8.1.el6.i686 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Jan 28 18:25:26 UTC 2015 SCSI/Sata устройства: [root@hq ~]# cat /proc/scsi/scsi Attached devices: Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: Msft Model: Virtual CD/ROM Rev: 1.0 Type: CD-ROM ANSI SCSI revision: 05 Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: Msft Model: Virtual Disk Rev: 1.0 Type: Direct-Access ANSI SCSI revision: 05 Партиции: [root@hq ~]# cat /proc/partitions major minor #blocks name 8 0 156892032 sda 8 1 512000 sda1 8 2 156378112 sda2 253 0 52428800 dm-0 253 1 2064384 dm-1 253 2 101883904 dm-2
img
В сегодняшней статье расскажем о первичной защите Вашего Asterisk’a - Fail2ban. На самом деле Fail2ban - это стандартный функционал любой операционной системы на базе Linux, который сканирует лог-файлы и блокирует подозрительные IP –адреса. На самом деле Fail2ban - это стандартный функционал любой операционной системы на базе Linux, который сканирует лог-файлы и блокирует подозрительные IP –адреса. Fail2ban - это система предотвращения вторжений (Intrusion Prevention System), которая защищает сервер от атак типа Brute-force (Полный перебор). Написанный на языке программирования Python, Fail2ban может работать поверх систем POSIX, которые оперируют локально установленным брандмауэром (Firewall) или системой контроля пакетов, таких как TCP Wrapper или IPTABLES Стоит заметить, что Fail2ban является лишь системой предотвращения вторжений, но не в коем случае не системой обнаружения вторжений или анти-хакерским инструментом Когда речь идёт о работе Fail2ban с Asterisk, необходимо рассказать о роли IPTABLES в данном взаимодействии. IPTABLES - это административный инструмент оболочки Linux, который предназначается для управления фильтрацией IP адресов и NAT. IPTABLES используется проверки таблиц правил фильтрации пакетов IP в ядре Linux . В IPTABLES могут быть определены несколько различных таблиц. Каждая таблица содержит ряд встроенных цепочек (chains) и может также содержать цепочки, определяемые пользователем. Каждая цепь представляет собой список правил, которым могут совпадать пакеты. Каждое правило определяет, что делать с пакетом, который имеет соответствие правилам. Для проверки IPTABLES, необходимо ввести следующую команду с правами рута: # iptables –L Эта команда отобразит список цепочек (chains), которые называются INPUT, FORWARD и OUTPUT, в самом низу ещё есть кастомные цепи, созданные пользователем. Дефолтные IPTABLES выглядят примерно следующим образом: Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination По умолчанию , IPTABLES разрешают весь трафик. Когда IPTABLES работает в паре с Fail2ban, то трафик не будет блокироваться, пока Fail2ban не создаст запрещающих правил. Fail2ban , по умолчанию, вставляет правила в верхней части цепи, поэтому они имеют приоритет над правилами, настроенными в IPTABLES пользователем. Это хорошо, потому что можно сначала разрешить весь SIP трафик, а затем Fail2ban будет блокировать отдельных хостов, которые совершили попытку нападения, до тех пор, пока они не будут разрешены этим правилом снова. Стандартная настройка Fail2ban приведена ниже. Данные изменения, вносятся в файл /etc/fail2ban/jail.conf [asterisk-iptables] enabled = true filter = asterisk action = iptables-allports[name=ASTERISK, protocol=all] sendmail-whois[name=ASTERISK, dest=root, sender=fail2ban@merionet.ru] logpath = /var/log/asterisk/security maxretry = 5 bantime = 259200 А теперь расшифруем, что же означает данная запись. Это фильтр, который на 3 дня банит любой IP-адрес, который 5 раз пытался неудачно получить доступ к Asterisk, а потом отправляет e-mail, уведомляющий о данном факте.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59