Серверная Админа | Компьютерные сети

👋 Привет, сетевой друг!

Расскажу еще о 3 способах прокачать защиту Mikrotik.

🟣Scheduler + скрипт для автоматического обновления firmware без простоя: Mikrotik умеет проверять наличие обновлений и устанавливать их по расписанию - удобно для парка роутеров когда обновлять руками нереально:

/system scheduler
add name=auto-upgrade interval=7d on-event={
  /system package update check-for-updates
  :delay 10s
  :if ([/system package update get status] = "New version is available") do={
    /system package update install
  }
}

Скрипт проверяет раз в неделю, и если есть обновление - устанавливает его. Роутер перезагрузится автоматически. Для критичных узлов лучше добавить проверку времени суток чтобы обновление происходило в нерабочие часы.

🟣Детект и блокировка torrent-трафика через p2p-маркировку: встроенный p2p matcher в Mikrotik определяет BitTorrent, eDonkey, Gnutella и другие протоколы без L7-регулярок:

/ip firewall mangle
add chain=forward p2p=all-p2p \
  action=mark-packet new-packet-mark=p2p-traffic passthrough=no \
  comment="Mark P2P traffic"

/queue tree
add name=p2p-limit parent=global \
  packet-mark=p2p-traffic max-limit=1M \
  comment="Limit P2P to 1Mbps"

Не блокируем полностью, а режем до 1 Мбит - пользователь может качать, но не убивает канал для остальных.

🟣IPv6 RA Guard - защита от rogue Router Advertisement: в IPv6-сетях любое устройство может объявить себя шлюзом через RA-пакет. На Mikrotik блокируем RA с клиентских портов оставляя только доверенные интерфейсы:

/ipv6 firewall filter
add chain=forward protocol=icmpv6 icmp-type=134 \
  in-interface=!ether1 action=drop \
  comment="Block rogue Router Advertisement"

add chain=input protocol=icmpv6 icmp-type=134 \
  in-interface=!ether1 action=drop \
  comment="Block RA on untrusted interfaces"

icmp-type=134 это Router Advertisement. Всё что приходит не с доверенного uplink-интерфейса - дропается. Закрывает атаки на IPv6-сегменты аналогичные ARP-спуфингу в IPv4.

Серверная Админа | Zeroday | #Mikrotik

👋 Привет, сетевой друг!

Сегодня разберём eBPF vs iptables/nftables. По факту это два подхода к фильтрации трафика, которые сейчас активно конкурируют в Kubernetes и просто в Linux-окружениях.

🟣Классический стек iptables/nftables: правила обрабатываются последовательно через цепочки netfilter в ядре. Каждый пакет проходит через все правила пока не найдёт совпадение. При тысячах правил (типичная ситуация в Kubernetes) это становится узким местом - каждое новое правило добавляет линейную сложность O(n).

Посмотреть текущие правила и статистику:

iptables -L -n -v --line-numbers
nft list ruleset
iptables -t filter -L -n -v | grep -v "0     0"

🟣Что меняет eBPF: вместо обхода цепочек правил программа на eBPF выполняется прямо в ядре при каждом пакете - без копирования в userspace, без обхода длинных цепочек. Решение принимается за O(1) через hash-таблицы вместо O(n) через правила:

# Простой XDP-дроппер через eBPF
cat > drop_icmp.c << 'EOF'
#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>

SEC("xdp")
int drop_icmp(struct xdp_md *ctx) {
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end) return XDP_PASS;
    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end) return XDP_PASS;
    if (ip->protocol == 1) return XDP_DROP;
    return XDP_PASS;
}
EOF

clang -O2 -target bpf -c drop_icmp.c -o drop_icmp.o
ip link set dev eth0 xdp obj drop_icmp.o sec xdp

🟣Почему Kubernetes переходит на eBPF через Cilium: kube-proxy генерирует тысячи iptables-правил для service routing - по несколько правил на каждый сервис и эндпоинт. При 10000 сервисов это десятки тысяч правил, обновление которых занимает секунды и блокирует пакетную обработку. Cilium заменяет всё это на eBPF-программы с hash-таблицами:

# Проверяем что Cilium использует eBPF вместо iptables
cilium status | grep -i datapath
cilium bpf lb list    # вся load balancing таблица
cilium bpf policy get --all    # политики как eBPF программы

🟣Эмулируем разницу под нагрузкой - добавляем 10000 iptables-правил и меряем деградацию:

# Генерируем 10000 правил
for i in $(seq 1 10000); do
    iptables -A INPUT -s 10.$((i/256)).$((i%256)).0/24 -j ACCEPT
done

# Меряем пропускную способность
iperf3 -c target -t 30

# Чистим и меряем без правил для сравнения
iptables -F INPUT
iperf3 -c target -t 30

🟣Когда iptables/nftables всё ещё правильный выбор: небольшие сети с сотнями правил, классические серверы без Kubernetes, когда команда не готова к eBPF-отладке. eBPF побеждает при тысячах правил, высоком pps и динамически меняющейся конфигурации как в Kubernetes.

Серверная Админа | Zeroday | #eBPF #iptables

📝 История VXLAN: как Ethernet пришлось научиться жить поверх IP

Сегодня про технологию, которая появилась из довольно практичной проблемы дата-центров: VLAN стало слишком мало, а растягивать L2 через огромную сеть было всё сложнее.

🟣Проблема началась с масштаба: классический VLAN использует 12-битный идентификатор, поэтому доступно всего 4094 нормальных VLAN. Для одного офиса этого более чем достаточно. Для облака с тысячами клиентов, виртуальных машин и изолированных сетей - уже нет.

🟣В 2011 году появился VXLAN. Идея довольно простая: взять обычный Ethernet-кадр, завернуть его в UDP/IP и отправить через обычную L3-сеть. Вместо VLAN ID используется 24-битный VNI, поэтому пространство идентификаторов выросло примерно до 16 миллионов.

Ethernet
   ↓
VXLAN header
   ↓
UDP
   ↓
IP
   ↓
Ethernet

🟣Самое важное изменение произошло в архитектуре. Между серверами теперь не обязательно иметь L2-коммутацию. Underlay может быть обычным IP fabric, а VXLAN создаёт поверх него виртуальную L2-сеть. На краях находятся VTEP - устройства, которые инкапсулируют и декапсулируют кадры.

🟣А как VTEP узнаёт, куда отправлять MAC? В небольших схемах можно использовать flood-and-learn, но в современных дата-центрах обычно используется EVPN поверх BGP. Тогда информация о MAC и IP распространяется через control plane, а не изучается только по факту прохождения кадров.

На Cisco полезно посмотреть:

show nve peers
show nve vni
show bgp l2vpn evpn
show l2vpn evpn evi
show mac address-table dynamic

🟣В итоге получилась довольно красивая схема: физическая сеть остаётся маршрутизируемой и может использовать ECMP, а поверх неё можно создавать виртуальные L2-сегменты между серверами, стойками и даже площадками.

🟣Поэтому VXLAN сегодня часто встречается там, где классический VLAN уже начинает упираться в масштаб: дата-центры, облачные платформы и большие виртуализированные инфраструктуры.

Серверная Админа | Zeroday | #история

👋 Привет, сетевой друг!

Сегодня про pingtrace - утилиту, которая собирает ping, traceroute, MTR и TCP-проверки в один CLI. Имба, когда во время аварии не хочется держать открытыми пять терминалов.

🟣Быстрая проверка:

pingtrace 1.1.1.1

Получаем ping, маршрут и DNS-информацию по хопам. На Windows инструмент использует tracert, на Linux/macOS - traceroute, с fallback на tracepath.

🟣Если нужно посмотреть маршрут именно как MTR:

pingtrace 1.1.1.1 --mtr

Можно ограничить тест десятью циклами и интервалом в две секунды:

pingtrace 1.1.1.1 -m --cycles 10 --interval 2

Так проще поймать потери или скачки latency не по одному случайному ping.

🟣Есть и TCP-сканирование. Причём обычным connect scan - raw sockets и root не нужны:

pingtrace 10.0.0.1 --ports 22,80,443

Можно указать диапазон:

pingtrace 10.0.0.1 --ports 8000-9000

Или вообще проверить все 65535 портов:

pingtrace 10.0.0.1 --ports

Для известных портов подтягиваются названия сервисов из IANA.

🟣Интереснее становится с несколькими целями:

pingtrace 10.0.0.1,10.0.0.2,example.com

или сразу подсеть:

pingtrace 10.0.0.0/28 --ports 22,80,443

Можно передать и CSV-файл с целями:

pingtrace --file ./targets.csv

🟣Результаты можно не копировать руками из терминала, а сразу сохранить:

pingtrace 1.1.1.1 --export ./reports --json

На выходе будут CSV и JSON, которые потом удобно скормить скрипту или приложить к отчёту об инциденте.

🟣А если нужен максимально чистый вывод для автоматизации, можно выбрать конкретные колонки:

pingtrace 1.1.1.1 --no-trace --columns seq,ip,time_ms,status

По сути, pingtrace закрывает типичный сценарий диагностики: «хост доступен, но что происходит по дороге до него и где именно начинается проблема?»

Серверная Админа | Zeroday | #Инструмент

Канал свободен, а пинг под нагрузкой скачет до секунды: разбираемся с bufferbloat и очередями

Статья о bufferbloat - ситуации, когда канал вроде бы свободен по пропускной способности, но под нагрузкой задержка внезапно улетает в сотни миллисекунд из-за переполненных очередей. Разбираются CoDel, FQ-CoDel, CAKE, ECN, L4S и BBR, а также показывается, почему большой буфер не всегда спасает от потерь и как диагностировать, где именно появляется задержка. Плюсом обсуждают incast в дата-центрах и способы борьбы с очередями на уровне Linux и сетевого оборудования.

Серверная Админа | Zeroday | #Статья

👨‍💻Серверная Админа | #мем

Dynamic ARP Inspection: как свитч сам проверяет ARP-таблицу

👋 Привет, сетевой друг!

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

🟣Суть проблемы: ARP работает на доверии. Любое устройство может отправить gratuitous ARP и объявить себя владельцем любого IP - соседи обновят кэш и начнут слать трафик атакующему. DAI закрывает именно это, проверяя каждый ARP-пакет против базы DHCP snooping перед тем, как пропустить его дальше.

🟣Как работает связка DHCP Snooping + DAI: DHCP snooping перехватывает все DHCP-сообщения и строит binding table: IP, MAC, порт, VLAN. DAI берёт эту таблицу и проверяет каждый ARP-запрос и ответ, если MAC и IP не совпадают с записью в таблице, пакет дропается.

🟣Включаем DHCP Snooping и DAI на Cisco:

ip dhcp snooping
ip dhcp snooping vlan 10,20,30

ip arp inspection vlan 10,20,30

! Uplink к роутеру помечаем как trusted
interface GigabitEthernet0/1
 ip dhcp snooping trust
 ip arp inspection trust

! Порты к хостам — untrusted по умолчанию, явно ограничиваем rate
interface GigabitEthernet0/2
 ip arp inspection limit rate 100

interface range GigabitEthernet0/3-24
 ip arp inspection limit rate 100

Uplink к роутеру или другому свитчу помечаем trust - там трафик уже проверен. Порты к хостам остаются untrusted, DAI проверяет каждый ARP с них.

🟣Для статических устройств которые не получают адрес через DHCP - серверы, принтеры - создаём ручные ARP ACL:

arp access-list STATIC_HOSTS
 permit ip host 192.168.10.10 mac host 00a1.b2c3.d4e5
 permit ip host 192.168.10.11 mac host 00a1.b2c3.d4e6

ip arp inspection filter STATIC_HOSTS vlan 10

Без этого статические хосты будут дропаться DAI потому что записей о них в DHCP snooping binding table нет.

🟣Проверяем что DAI реально работает:

show ip arp inspection vlan 10
show ip arp inspection statistics
show ip dhcp snooping binding

В статистике видно сколько пакетов прошло проверку и сколько было дропнуто. Если счётчик Forwarded растёт и Dropped нулевой - либо атак нет, либо DAI не применяется.

🟣Диагностика когда легитимный трафик дропается: DAI пишет в syslog каждый дроп с причиной - несовпадение MAC, несовпадение IP или превышение rate limit:

debug ip arp inspection vlan 10
show ip arp inspection log

Чаще всего проблема в том что статический хост не добавлен в ARP ACL или uplink не помечен как trusted.

Серверная Админа | #ARP

👋 Привет, сетевой друг!

Сегодня разберём как устроена сетевая инфраструктура крупных дата-центров - spine-leaf архитектура которая пришла на смену классическому three-tier.

🟣Классический three-tier: core, distribution, access. Три уровня иерархии, трафик от сервера до сервера идёт через все три. При росте нагрузки узкое место всегда наверху, масштабирование болезненное, east-west трафик (между серверами) делает лишние хопы.

🟣Spine-leaf решает именно это: два уровня вместо трёх. Leaf-свитчи подключаются к серверам, spine-свитчи соединяют все leaf между собой. Каждый leaf подключён к каждому spine - нет единой точки отказа, нет иерархии где трафик собирается наверху.

Spine1  Spine2  Spine3  Spine4
  |  \  / |  \  / |  \  / |
Leaf1 Leaf2 Leaf3 Leaf4 Leaf5
  |     |     |     |     |
Servers Servers ...

🟣Почему это важно для east-west трафика: в современных датацентрах 70-80% трафика идёт между серверами внутри ЦОД, а не наружу. В three-tier этот трафик поднимается до distribution и обратно - лишние хопы и задержка. В spine-leaf любой leaf до любого leaf всегда два хопа через spine.

🟣ECMP (Equal-Cost Multi-Path) - основа балансировки в spine-leaf: каждый leaf видит несколько равнозначных путей до любого другого leaf через разные spine. Трафик балансируется по хэшу из заголовков пакета:

show ip route 10.0.0.0/24
# Видим несколько next-hop через разные spine

show ip ecmp
# Статистика распределения по путям

🟣BGP вместо STP в spine-leaf: классический spanning tree не масштабируется и блокирует резервные линки. В spine-leaf используют BGP (часто eBGP с разными AS на каждом устройстве) или OSPF для маршрутизации — все линки активны, нет заблокированных портов:

router bgp 65001  # leaf1
 neighbor 10.0.0.1 remote-as 65100  # spine1
 neighbor 10.0.0.2 remote-as 65100  # spine2

router bgp 65100  # spine
 neighbor 10.0.0.10 remote-as 65001  # leaf1
 neighbor 10.0.0.20 remote-as 65002  # leaf2

🟣Ограничение spine-leaf и как его решают: классическая топология плохо работает когда нужно L2-связность между leaf (например для vMotion или кластеризации). Решение - VXLAN поверх IP-фабрики с EVPN для управления MAC/IP-адресами через BGP. Leaf инкапсулирует L2-фреймы в UDP/IP, fabric остаётся чистым L3.

Серверная Админа | #история #Network

👋 Привет, сетевой друг!

Сегодня о PAM - механизме, через который в Linux проходит почти каждая аутентификация.

🟣Что такое PAM: Pluggable Authentication Modules - прослойка между приложением и системой проверки доступа. Её используют sudo, SSH, login, su и многие другие сервисы.

🟣Как это работает: Приложение отправляет запрос в PAM. Библиотека libpam.so читает конфигурацию из /etc/pam.d/ или /etc/pam.conf и определяет, какие модули нужно запустить.

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

🟣Финальное решение: После выполнения модулей PAM собирает результаты и возвращает приложению только одно - доступ разрешён или запрещён.

🟣Главный плюс: Чтобы изменить правила входа сразу для всех сервисов, достаточно поменять конфигурацию PAM - переписывать сами приложения не нужно.

Серверная Админа | Zeroday | #Linux

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

☮️13,5 млн → 2,09 млн — крупнейший ботнет квартала сократился почти в шесть раз.

☮️12 — столько DDoS-атак мощностью свыше 1 Тбит/с зафиксировано всего за три месяца.

☮️16,92% — индекс ботовости в EdTech при среднем по рынку 1,56%.

☮️−34% — настолько снизилось число BGP-перехватов год к году.

☮️180 000 — вредоносных запросов в секунду достигла бот-атака на одну из медиакомпаний.

↕️Главный вывод отчета: угрозы становятся не просто мощнее, а сложнее — меняются их масштаб, цели и механики.

🔁Полную версию отчета с разбором ключевых тенденций ищите в Telegram-канале CURATOR.

👋 Привет, сетевой друг!

Сегодня про KillerScan - бесплатный сетевой сканер для Windows, который не ограничивается поиском устройств, а сразу пытается понять, что именно он нашёл.

🟣Зачем он: большинство сканеров показывают IP, MAC и открытые порты. Дальше администратору самому приходится разбираться, где принтер, где NAS, а где гипервизор. KillerScan автоматически собирает дополнительные признаки и классифицирует устройства.

🟣Как работает: сначала выполняется ARP и ping-обход сети. Затем инструмент проверяет популярные TCP-порты, получает HTTP-заголовки, SSH-баннеры, TLS-сертификаты, NetBIOS, SNMP, mDNS и SSDP. После этого все полученные данные оцениваются по весам, и устройству присваивается наиболее вероятный тип.

Например, если обнаружены:

• SSH + Linux banner
• OUI от Dell
• HTTPS с заголовком Proxmox VE

то устройство с высокой вероятностью будет определено как гипервизор, а не просто «хост с открытым 22-м портом».

🟣Что умеет:
1️⃣ARP + Ping - быстрый поиск устройств
2️⃣HTTP / SSH / TLS - активный fingerprinting
3️⃣NetBIOS и SNMP - получение информации о системе
4️⃣mDNS и SSDP - поиск принтеров, 5️⃣Chromecast, NAS, IoT и другой техники
6️⃣MAC Vendor Lookup - определение производителя по IEEE OUI

🟣Полезная возможность - можно сканировать сразу несколько сетей за один запуск:

192.168.1.0/24,
192.168.10.0/24,
10.0.0.15-10.0.0.80

Все найденные устройства объединяются в один список без дублей.

🟣Приятная мелочь: это один portable EXE без установки зависимостей. Есть экспорт результатов в CSV и HTML, быстрый запуск RDP, SSH или браузера прямо из контекстного меню, а также повторное глубокое сканирование выбранных устройств без повторного обхода всей сети.

Серверная Админа | Zeroday | #Инструмент

Советский МК88 - шарим по BBS консольного интернета

Небольшое путешествие в мир ретрокомпьютеров: автор оживил советский МК88, расширил ему память, подключил Wi-Fi-модем через COM-порт и вывел машину в BBS-сети. В статье о том, как устроена такая сборка, что можно делать на компьютере 80-х сегодня и почему даже древнее железо всё ещё способно удивлять.

Серверная Админа | Zeroday | #Статья

👨‍💻Серверная Админа | #мем

👋 Привет, сетевой друг!

Расскажу о 3 фишках Mikrotik которые реально не все знают.

🟣Interface Lists в Firewall - перестаньте привязывать правила к конкретным портам. Вместо этого можно работать с группами интерфейсов:

/interface/list/add name=WAN
/interface/list/member/add list=WAN interface=ether1
/interface/list/member/add list=WAN interface=lte1

/ip/firewall/filter/add chain=input \
in-interface-list=WAN action=drop

Если позже основной WAN сменится с ether1 на PPPoE или LTE, достаточно изменить состав списка - сами правила firewall останутся без изменений. На больших конфигурациях это заметно упрощает сопровождение.

🟣Bridge Horizon - простой способ изолировать клиентов внутри одного L2-сегмента без отдельных VLAN:

/interface/bridge/port
set [find interface=ether2] horizon=1
set [find interface=ether3] horizon=1
set [find interface=ether4] horizon=1

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

🟣Routing Rules - policy routing без mangle. Во многих случаях можно вообще не использовать маркировку пакетов:

/routing/table/add fib name=VPN

/routing/rule/add \
src-address=192.168.50.0/24 \
action=lookup \
table=VPN

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

Серверная Админа | Бункер Хакера | #Mikrotik

📝 История VRRP: как маршрутизатор перестал быть единственной точкой отказа

Технология, благодаря которой отказ шлюза перестал означать потерю связи для всей сети.

🟣Когда появился VRRP: долгое время у сети был один шлюз по умолчанию. Пока маршрутизатор работал - всё было хорошо. Но стоило ему выйти из строя, и вся подсеть теряла доступ к другим сегментам. В конце 90-х появился VRRP (Virtual Router Redundancy Protocol), который позволил нескольким маршрутизаторам представляться одним виртуальным шлюзом.

🟣Как это работает: устройства объединяются в группу и используют общий виртуальный IP-адрес. Один маршрутизатор становится Master и обрабатывает весь трафик, остальные находятся в режиме Backup. Если Master перестаёт отправлять служебные объявления, один из резервных автоматически занимает его место. Для клиентов ничего менять не нужно - шлюз остаётся тем же.

🟣Почему это стало важно: раньше даже короткий сбой шлюза обрывал соединения для сотен или тысяч устройств. С VRRP отказ одного маршрутизатора перестал быть критичным - переключение обычно занимает всего несколько секунд, а при правильной настройке ещё меньше.

🟣Что изменилось со временем: сегодня VRRP поддерживают практически все крупные сетевые вендоры, а рядом появились собственные реализации вроде HSRP и GLBP. Несмотря на развитие SDN и EVPN, классическая схема с резервным шлюзом до сих пор остаётся стандартом для большинства корпоративных сетей.

Серверная Админа | Zeroday | #VRRP

👋 Привет, сетевой друг!

Сегодня разберём в чём реальная разница между SR-MPLS и SRv6 - оба Segment Routing, но внутри вообще разные решения.

🟣SR-MPLS - Segment Routing поверх существующего MPLS-стека. Сегменты кодируются, как обычные MPLS-метки, промежуточные роутеры работают с привычным label swapping. Никакой новой плоскости данных - то же железо, те же ASIC, просто контрольная плоскость стала проще (нет RSVP-TE, сигнализация через IGP):

segment-routing mpls

router isis 1
 segment-routing mpls

show segment-routing mpls lb
show segment-routing mpls forwarding
show mpls forwarding-table labels 16001

Работает на любом железе которое уже умеет MPLS - миграция с классического MPLS минимальна, операторы переходят без замены оборудования.

🟣SRv6 - принципиально другой подход. Сегменты кодируются как IPv6-адреса в Segment Routing Header (SRH) - расширении IPv6-заголовка. Промежуточные роутеры обрабатывают обычный IPv6-трафик, никаких меток:

segment-routing srv6
 encapsulation source-address 2001:db8::1

router isis 1
 segment-routing srv6
  locator MAIN

show segment-routing srv6 sid
show segment-routing srv6 forwarding

Каждый сегмент это полноценный IPv6-адрес (128 бит) - в него зашиты локатор (где узел), функция (что делать с пакетом) и аргументы. Это даёт программируемость, которой нет в MPLS: один SID может означать не тупо “перейди на следующий хоп”, но и “примени QoS политику X” или “направь в конкретный VRF”.

🟣Главные различия на деле: SR-MPLS требует MPLS-capable железо везде, SRv6 работает на любом IPv6-роутере, включая белые ящики. SR-MPLS проще в диагностике - привычные MPLS-инструменты, SRv6 сложнее отлаживать, потому что SRH добавляет накладные расходы и не все инструменты его хорошо разбирают. SRv6 даёт нативную интеграцию с IPv6 без дополнительной инкапсуляции, SR-MPLS требует инкапсуляции для IPv6-трафика.

Серверная Админа | Zeroday | #SR6 #SRMPLS

👋 Привет, сетевой друг!

Сегодня про инструмент Forerunner - библиотеку для разрабов, которая делает из сетевого сканирования готовый набор компонентов для .NET. И это не готовый сканер с интерфейсом, а движок, на базе которого можно собирать свои сетевые утилиты.

🟣Зачем он: когда нужно написать свой IP-сканер, мониторинг доступности или проверку портов, обычно приходится самостоятельно реализовывать потоки, таймауты, обработку ошибок и сбор результатов. Forerunner берёт эту рутину на себя и отдаёт всё в виде готовых объектов.

🟣Как работает: библиотека построена вокруг асинхронного событийного подхода. Вы создаёте Scanner, запускаете проверку IP или диапазона адресов, а результаты приходят через события с прогрессом и итоговыми объектами.

Например, можно просканировать сеть:

Scanner scanner = new Scanner();

IPScanObject result = scanner.Scan("192.168.1.1");

В результате объект содержит:
• IP-адрес
• статус доступности
• время ответа Ping
• hostname
• MAC-адрес
• ошибки при проверке

🟣Что умеет:

IP Scan - проверка одного адреса или диапазона

ScanRange("192.168.1.1", "192.168.1.255")

Port Scan - поиск доступных TCP/UDP портов

IsPortOpen("192.168.1.1", 443)

Ping Monitoring - проверка доступности и средней задержки

GetAveragePingResponse("192.168.1.1", 5, 1000)

Port Knock - массовая проверка портов на хостах

🟣Главная фишка, что всё работает параллельно. Библиотека рассчитана на многопоточность, поэтому можно одновременно проверять сотни адресов без блокировки основного приложения. Например, свой мониторинг можно построить так:
серверы → Forerunner → проверка Ping → проверка портов → отправка результата в панель мониторинга

🟣Пример асинхронного сканирования:

scanner.ScanAsync("10.0.0.1");

scanner.ScanAsyncComplete += (sender, result) =>
{
    Console.WriteLine(result.IP);
};

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

Серверная Админа | Zeroday | #Инструмент

Когда Ethernet ломает отказоустойчивость: скрытая проблема асимметрии задержек

Даже идеально настроенная промышленная сеть может работать нестабильно из-за причины, которую сложно заметить. Разная задержка передачи в прямом и обратном направлении нарушает работу протоколов синхронизации и резервирования, хотя оборудование остаётся полностью исправным.

🟣В статье разбирается феномен path delay asymmetry - асимметрии задержек в Ethernet-сетях. Автор объясняет, как различия в длине кабелей, работе коммутаторов Store-and-Forward и Cut-Through, очередях QoS, оптических трансиверах и резервных маршрутах влияют на IEEE 1588 PTP и промышленные сети.

Серверная Админа | Zeroday | #Статья

👋 Привет, сетевой друг!

Сегодня разберём BIER (Bit Index Explicit Replication) - технологию, которая позволяет передавать multicast-трафик без PIM, RP и построения multicast-деревьев.

🟣Что это: в классическом multicast каждый маршрутизатор хранит состояние групп и строит дерево доставки через PIM. Чем больше получателей, тем больше записей в памяти устройств. BIER предлагает другой подход - информацию о получателях не хранит сеть, она передаётся прямо в пакете.

🟣Как это работает: каждому BIER-маршрутизатору назначается свой Bit Position. Когда пакет попадает в BIER-домен, ingress-маршрутизатор формирует битовую маску, где каждый установленный бит соответствует получателю. По пути устройства просто очищают “свои” биты и копируют пакет только туда, где ещё остались адресаты.
В результате сети не нужно строить отдельные multicast-деревья и хранить состояние для каждой группы.

🟣Зачем это вообще нужно: в крупных сетях IPTV, дата-центрах и MPLS multicast становится сложным в сопровождении. BIER значительно упрощает архитектуру - меньше протоколов, меньше служебного состояния и быстрее запуск новых multicast-сервисов.

🟣Пример проверки (Cisco IOS XR):

show bier topology
show bier forwarding
show bier bitstring

В выводе можно увидеть назначенные Bit Position, таблицу пересылки и битовые маски, по которым маршрутизатор принимает решение о репликации.

🟣Где применяется: технология поддерживается рядом операторских платформ Cisco, Juniper и Nokia и чаще встречается в MPLS-сетях провайдеров. В корпоративных сетях BIER пока редкость, но для операторов это одна из наиболее интересных альтернатив классическому multicast.

Серверная Админа | Zeroday | #протокол