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

👋 Привет, сетевой друг! Сегодня разберём DNS-over-HTTPS на Mikrotik - как роутер сам шифрует DNS-запросы без сторонних прокси и почему это так важно. 🟣Зачем это нужно: обычный DNS идёт открытым текстом по UDP 53. Провайдер видит каждый запрос, может подменять ответы и блокировать домены на уровне DNS. DoH оборачивает запросы в HTTPS и отправляет на доверенный резолвер - провайдер видит только зашифрованный трафик к известному IP. 🟣RouterOS 7.x умеет DoH нативно - включается в настройках DNS:

/ip dns set use-doh-server=https://1.1.1.1/dns-query \
  verify-doh-cert=yes \
  servers="" \
  allow-remote-requests=yes 

servers=”” важно - убираем обычные DNS-серверы чтобы роутер не fallback’ал на незашифрованный UDP когда DoH недоступен. 🟣Проблема курицы и яйца: чтобы подключиться к DoH-серверу по имени, нужно сначала его зарезолвить. Но если DNS уже переключён на DoH - резолвить нечем. Решение тут прописать IP напрямую:

/ip dns set use-doh-server=https://1.1.1.1/dns-query
/ip dns set verify-doh-cert=yes

Используем IP Cloudflare напрямую в URL, тогда роутеру не нужно резолвить имя для установки соединения. 🟣verify-doh-cert=yes требует корневые сертификаты - без них роутер не проверит подлинность сервера и DoH не поднимется:

/certificate import file-name=cacert.pem passphrase=""

Скачиваем cacert.pem с curl.se/ca/cacert.pem, загружаем на роутер через Files и импортируем. Без этого шага verify-doh-cert=yes вернёт ошибку сертификата и DoH не заработает. 🟣Проверяем что DoH реально используется а не обычный DNS:

/ip dns print
# DoH server должен показывать адрес
# Обычные servers должны быть пустыми

# На клиентской машине захватываем трафик
tcpdump -i eth0 port 53
# Не должно быть UDP 53 запросов с роутера наружу

Если в tcpdump видим UDP 53 уходящий наружу - DoH не работает и роутер fallback’ает на обычный DNS. 🟣Блокируем DNS в обход роутера - клиенты не должны ходить напрямую к 8.8.8.8:

/ip firewall nat
add chain=dstnat protocol=udp dst-port=53 \
  !dst-address=192.168.1.1 \
  action=redirect to-ports=53 \
  comment="Redirect DNS to router"

add chain=dstnat protocol=tcp dst-port=53 \
  !dst-address=192.168.1.1 \
  action=redirect to-ports=53 \
  comment="Redirect DNS to router"

Теперь все DNS-запросы клиентов идут через роутер который использует DoH - никакой обход через хардкод 8.8.8.8 в приложениях не поможет. 🟣Резервный DoH-сервер на случай недоступности основного: RouterOS пока не поддерживает несколько DoH-серверов нативно. Выход - Netwatch который переключает сервер при недоступности:

/tool netwatch
add host=1.1.1.1 interval=30s timeout=2s \
  down-script="/ip dns set use-doh-server=https://8.8.8.8/dns-query" \
  up-script="/ip dns set use-doh-server=https://1.1.1.1/dns-query"

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

👋 Привет, сетевой друг! Сегодня про nmap-vulners - NSE-скрипт, который превращает обычный сервисный скан Nmap в список CVE, известных эксплойтов и реально эксплуатируемых уязвимостей. 🟣Обычный nmap -sV может показать, что на сервере работает, например, Apache 2.4.7. Но дальше начинается ручная работа: искать CVE, проверять CVSS, смотреть наличие эксплойтов и разбираться, что действительно опасно. nmap-vulners автоматизирует этот этап:

nmap -sV --script vulners <target>

Скрипт берёт найденное Nmap ПО, формирует CPE и сверяет его с базой Vulners. На выходе может получиться примерно так:

80/tcp open http Apache httpd 2.4.7

| vulners:
|   SEVERITY  CVSS  FLAGS
|   CRITICAL   9.8  EXP
|   HIGH       8.1
|   HIGH       7.5  KEV

🟣Самое интересное здесь - приоритизация. Высокий CVSS ещё не означает, что именно эту уязвимость нужно исправлять первой. Скрипт учитывает несколько сигналов: • KEV - уязвимость подтверждённо эксплуатируется в реальном мире • EXP - существует опубликованный эксплойт • EPSS - вероятность эксплуатации в ближайшие 30 дней Поэтому активно эксплуатируемая уязвимость с CVSS 7.5 может оказаться выше теоретически более критичной CVSS 9.8. 🟣На HTTP-портах скрипт идёт дальше простого баннера. Он может искать дополнительное ПО по HTTP-заголовкам, cookies, title, meta-тегам, именам скриптов и содержимому страниц. Например, Nmap увидел только Coyote, а nmap-vulners дополнительно может определить Tomcat, PHP или JavaScript-библиотеки, которые работают за веб-сервером. 🟣Для более точной информации можно использовать API-ключ. Тогда появляются дополнительные данные: KEV, EPSS, информация об известных эксплойтах и более качественная сортировка результатов. Но базовый поиск работает и без ключа. 🟣Полезный вариант для первичного аудита:

nmap -sV --script vulners \
  --script-args mincvss=7 \
  <target>

Так в выводе останутся уязвимости с CVSS от 7 и выше, хотя известные эксплойты могут показываться отдельно. 🟣Если HTTP-портов много, стоит помнить, что расширенный web fingerprinting может отправлять сотни запросов для поиска компонентов. Его можно отключить:

--script-args vulners.paths=none

Получается удобная связка: Nmap сначала отвечает на вопрос «что здесь работает?», а nmap-vulners - «что из этого уже известно как уязвимое и что может быть реально атаковано». Серверная Админа | Zeroday | #Инструмент

Как устроен современный антивирус: поведенческий анализ, драйверы, архитектура Современный антивирус уже не ищет только знакомые сигнатуры. Он смотрит, что делает процесс: прописался в автозагрузку, создал файл, полез в другой процесс и открыл соединение наружу. Отдельно это может быть нормой, но вместе уже подозрительная цепочка. За этим следят драйверы ядра, файловые и сетевые фильтры, ETW, AMSI и другие механизмы. Серверная Админа | Zeroday | #Статья

Привет. Вот тебе самые топовые каналы по IT! ⚙️ Dev Boost — Самая огромная коллекция платных курсов, которые можно скачать бесплатно; 👩‍💻 IT Books — Самая огромная библиотека книг; 💻 Hacking & InfoSec Base — Крутой блог белого хакера; 🤔 ИБ Вакансии — Всё, чтобы найти работу в ИБ; 👩‍💻 linux administration — Всё про Линукс; 📲 В Max тоже есть место для линуксоидов; 👩‍💻 Программистика — Python, python и ещё раз python; 👩‍💻 GameDev Base — Всё про GameDev; 😆 //code — Самые топовые мемы по IT: 📲 Мы в Max; Подпишись, чтобы не потерять!

👋 Привет, сетевой друг! Сегодня разберём CFM (Connectivity Fault Management, IEEE 802.1ag) - протокол который провайдеры используют для мониторинга Ethernet-линков на уровне L2. 🟣Что это и зачем: обычный ping работает на L3 и не покажет проблему внутри Ethernet-сегмента между двумя коммутаторами. CFM работает на L2 и позволяет проверять связность, измерять задержку и потери между любыми двумя точками в сети без IP-адресов. Провайдеры используют для контроля SLA на арендованных каналах - клиент видит, что линк поднят, но CFM показывает реальное качество внутри. 🟣Три основных инструмента внутри CFM: Continuity Check Message (CCM) - аналог keepalive, устройства периодически обмениваются между собой и обнаруживают отказы. Loopback (LBM/LBR) - аналог ping на L2, проверяем связность до конкретного MEP. Linktrace (LTM/LTR) - аналог traceroute на L2, видим путь через коммутаторы. 🟣Ключевые понятия: 1️⃣MEP (Maintenance End Point) - конечная точка домена обслуживания, здесь CFM-сообщения генерируются и терминируются. 2️⃣MIP (Maintenance Intermediate Point) - промежуточная точка, пропускает и отвечает на linktrace но не генерирует CCM. 3️⃣MD (Maintenance Domain) - уровень обслуживания от 0 до 7, провайдер обычно использует уровень 4-7, клиент 0-3. 🟣Настройка на Cisco IOS:

ethernet cfm domain PROVIDER level 5
 service CUSTOMER_A evc CUSTOMER_A
  continuity-check
  continuity-check interval 1s

interface GigabitEthernet0/1
 ethernet cfm mep domain PROVIDER mpid 1 service CUSTOMER_A
 ethernet cfm mip level 5

show ethernet cfm maintenance-points local
show ethernet cfm errors

🟣Проверяем связность через L2 ping и traceroute:

ping ethernet mpid 2 domain PROVIDER service CUSTOMER_A
traceroute ethernet mpid 2 domain PROVIDER service CUSTOMER_A

show ethernet cfm statistics
show ethernet cfm ccm-learning-table

🟣Измерение задержки и потерь через Y.1731 - расширение CFM для SLA-метрик:

ethernet cfm domain PROVIDER level 5
 service CUSTOMER_A evc CUSTOMER_A
  sender-id chassis

ip sla 1
 ethernet y1731 delay dmm domain PROVIDER service CUSTOMER_A mpid 2
  cos 5
  frequency 10
ip sla schedule 1 life forever start-time now

show ip sla statistics 1

Y.1731 даёт точные измерения one-way delay, delay variation и frame loss - именно эти цифры идут в SLA-отчёты клиентам. 🟣Где точно используется: Metro Ethernet между офисами через провайдера, мониторинг арендованных L2-каналов в датацентрах, операторские сети где нужно видеть проблему внутри Ethernet-сегмента до того как клиент позвонит в поддержку. Серверная Админа | Бункер Хакера | #Network

Здравствуйте! Я маркетолог компании Слёрм и меня попросили найти хардовых девопсов и сисадминов. Понятия не имею кто это, поэтому делаю типичную рекламу и прикладываю смешную (по моему мнению) картинку. Хук: Хватит быть оператором кластера. Станьте тем, кто проектирует платформу. Продвинутый Kubernetes, 79% практики. Содержание: 16 тем продвинутого администрирования: от планировщика и собственного scheduler до Istio с Kiali. Внутри HA-кластер на три мастера, сетевые политики Calico и Cilium, интеграция с HashiCorp Vault четырьмя способами доставки секретов, горизонтальное масштабирование на событиях через KEDA, резервное копирование Velero и написание собственных операторов на operator-sdk (я ни слова не понял) Кол ту экшн: приобретайте место на потоке 14 сентября! Или же проходите видеокурс в своем темпе Ну и тут добавить лёгкого ФОМО: следующий поток только в ноябре, а на этот поток осталось только 20 мест!

📝 Радиа Перлман: женщина, которая заставила Ethernet работать без петель Расскажу о человеке, без которого современные L2-сети выглядели бы вообще иначе. 🟣В 80-х Ethernet быстро распространялся, но с ростом сетей появилась неприятная проблема: инженеры хотели добавлять резервные соединения между коммутаторами, а обычный Ethernet не умел нормально жить с петлями. Кадры начинали ходить по кругу, появлялись broadcast storms, сеть могла буквально положить сама себя. 🟣Радиа Перлман в 1985 году разработала Spanning Tree Protocol - STP. Идея была простой: разрешить физически избыточную топологию, но логически оставить дерево без петель. Коммутаторы обмениваются BPDU, выбирают root bridge, рассчитывают лучший путь и блокируют лишние соединения. 🟣Самое интересное - при отказе основного линка заблокированный путь можно снова включить. То есть резервный кабель не пропадает зря: он ждёт аварии и становится частью рабочей топологии. 🟣Именно поэтому можно было строить сети вроде:

        SW1
       /   \
     SW2---SW3

Физическая петля есть, но STP блокирует один из путей. Если связь между SW1 и SW2 пропадёт, дерево пересчитается и трафик пойдёт через SW3. 🟣Перлман на этом не остановилась. Она работала над маршрутизацией, сетевыми протоколами и безопасностью, участвовала в разработке TRILL, а её работы сильно повлияли на то, как инженеры проектируют отказоустойчивые сети. 🟣Ирония в том, что сегодня STP часто считают старой технологией и стараются заменять более современными механизмами. Но сама идея осталась: избыточные связи нужны, просто сеть должна уметь понимать, какие из них сейчас можно использовать. Серверная Админа | Бункер Хакера | #network

Хочешь этой осенью сделать первый шаг к работе в Росатоме? Начни с кейслаба по информационной безопасности! 🔐Кейслаб по информационной безопасности — это бесплатная программа с обучением, наставниками и практическими задачами Росатома. За месяц ты сможешь прокачать профессиональные навыки, познакомиться с реальными рабочими процессами и побороться за место в финале молодежного фестиваля «ИТ КоР 5.0. Новый код атомной отрасли». 🎯Лучшие участники кейслаба отправятся на очный финал в Нижний Новгород, а победители получат возможность пройти стажировку или начать работать на предприятиях Росатома. Регистрация на кейслаб уже открыта: https://itcore.depreg.ru Старт обучения — 24 августа. Подробнее о фестивале: https://it-core2026.ru 🔥Если ИБ — направление, в котором ты хочешь развиваться, сейчас самое время проверить свои силы на реальных задачах. Реклама. О рекламодателе.

Перенос работающего сервера без остановки сервисов 👋 Привет, сетевой друг! В прошлый раз разбирали базовый перенос через снапшоты. Сегодня расскажу про инкрементальную передачу, проверку целостности и более надёжный процесс. 🟣Что изменилось в подходе: главная проблема старого метода - снапшот делается один раз, потом долго передаётся, а за это время данные на источнике меняются. И решение тут - это инкрементальная передача через несколько снапшотов, финальный diff минимален и сервис останавливается на секунды а не часы. 🟣Создаём первый базовый снапшот и начинаем передачу в фоне:

# ZFS — базовый снапшот
zfs snapshot zpool/rootfs@base
zfs send zpool/rootfs@base | ssh root@new-server zfs receive -F zpool/rootfs

# Btrfs — базовый снапшот
btrfs subvolume snapshot -r / /mnt/snapshots/base
btrfs send /mnt/snapshots/base | ssh root@new-server btrfs receive /mnt/

Пока передаётся base - сервер продолжает работать, данные меняются. 🟣Инкрементальный diff: передаём только изменения

# ZFS — создаём второй снапшот и шлём только дельту
zfs snapshot zpool/rootfs@incremental
zfs send -i zpool/rootfs@base zpool/rootfs@incremental | \
  ssh root@new-server zfs receive -F zpool/rootfs

# Btrfs — аналогично
btrfs subvolume snapshot -r / /mnt/snapshots/incremental
btrfs send -p /mnt/snapshots/base /mnt/snapshots/incremental | \
  ssh root@new-server btrfs receive /mnt/

Флаг -i (ZFS) и -p (Btrfs) означают инкрементальную передачу - только дельта между снапшотами, не весь объём. 🟣Финальная синхронизация с минимальным даунтаймом:

# Останавливаем сервисы
systemctl stop nginx postgresql

# Финальный инкрементальный снапшот
zfs snapshot zpool/rootfs@final
zfs send -i zpool/rootfs@incremental zpool/rootfs@final | \
  ssh root@new-server zfs receive -F zpool/rootfs

# Поднимаем сервисы уже на новом сервере

Финальный diff минимален, только изменения за последние минуты пока останавливались сервисы. 🟣Проверка целостности после передачи:

# ZFS встроенная проверка
ssh root@new-server zfs get checksum zpool/rootfs
ssh root@new-server zpool scrub zpool

# Btrfs
ssh root@new-server btrfs scrub start /mnt
ssh root@new-server btrfs scrub status /mnt

Без проверки можно перенести данные с тихим битовым повреждением и узнать об этом только при чтении. 🟣Восстановление загрузки:

arch-chroot /mnt

# Обновляем fstab с новыми UUID
blkid >> /etc/fstab
# Правим вручную — убираем старые UUID

# Обновляем initramfs
update-initramfs -u -k all

# Устанавливаем загрузчик
grub-install /dev/sdX
update-grub

# Для систем с systemd-boot
bootctl install

🟣Чистим снапшоты после успешного переноса:

# ZFS
zfs destroy zpool/rootfs@base
zfs destroy zpool/rootfs@incremental
zfs destroy zpool/rootfs@final

# Btrfs
btrfs subvolume delete /mnt/snapshots/base
btrfs subvolume delete /mnt/snapshots/incremental

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

Защита от петель L2: что выбрать, если STP уже не устраивает. Бесплатный урок курса «Сетевой инженер. Продвинутый уровень» STP остаётся классическим способом защиты локальных сетей от петель, но далеко не всегда отвечает современным требованиям к скорости восстановления и отказоустойчивости. В крупных инфраструктурах всё чаще используются альтернативные протоколы, позволяющие быстрее реагировать на изменения топологии и обеспечивать более предсказуемую работу сети. На открытом уроке 24 августа в 20:00 разберём принципы работы ERPS, RRPP и REP, сравним их между собой и со STP. Поговорим о преимуществах и ограничениях каждого подхода, рассмотрим сценарии применения и обсудим, как выбрать протокол защиты от петель под конкретную инфраструктуру. Урок не для тех, кто считает STP единственным возможным решением и не готов изучать современные подходы к построению отказоустойчивых сетей. Будет полезен сетевым инженерам, архитекторам и специалистам, которые проектируют и сопровождают корпоративные сети. 👉 Записаться: https://otus.pw/8zDS/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

👋 Привет, сетевой друг! Сегодня про ghorg - утилиту для массового клонирования репозиториев. Даёте ей организацию или пользователя, а она сама собирает все доступные репозитории в одну директорию. 🟣Зачем он: когда в организации десятки или сотни репозиториев, делать git clone для каждого вручную - сомнительное удовольствие. ghorg подходит для аудита, локального поиска по всему коду, бэкапов и быстрого онбординга.

ghorg clone kubernetes

На выходе получите примерно такую структуру:

~/ghorg/kubernetes/
├── apimachinery
├── kubeadm
├── git-sync
├── kubernetes-template-project
└── ...

🟣Можно не тащить всё подряд. Например, оставить только репозитории, начинающиеся с sig-: ghorg clone kubernetes --match-regex=^sig- Или исключить форки и архивные репозитории:

ghorg clone kubernetes --skip-forks --skip-archived

🟣Интереснее режим бэкапа. --backup использует git clone --mirror, а вместе с --clone-wiki и --include-submodules можно собрать гораздо более полный набор данных:

ghorg clone kubernetes \
  --backup \
  --clone-wiki \
  --include-submodules

🟣Есть и сценарий регулярного обновления: если репозиторий уже скачан, следующий запуск не клонирует его заново, а делает pull и clean. Для рабочих каталогов это важно учитывать: локальные изменения по умолчанию могут быть затёрты. Если нужно сохранить их, используется --no-clean. 🟣А если таких наборов несколько, команды можно сохранить в reclone.yaml и запускать одной командой:

ghorg reclone

Для этого же есть HTTP-сервер и cron-режим - уже получается вполне нормальная автоматизация бэкапов и периодической синхронизации. Серверная Админа | Zeroday | #Инструмент

Разработка цифрового радиолюбительского протокола на базе OFDM. PHY-уровень Автор решил собрать собственный протокол цифровой радиосвязи на базе OFDM - той же идеи, которая используется в Wi-Fi и LTE. Данные здесь одновременно передаются по множеству поднесущих, а пилоты, циклический префикс, FEC и CRC помогают пережить шум и помехи. В итоге прототип передаёт данные со скоростью до 708 бит/с и способен работать даже при отрицательном SNR. Получился небольшой Wi-Fi, только вместо роутера - радиолюбительский SSB-трансивер. Серверная Админа | Zeroday | #Статья

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

👋 Привет, сетевой друг! Сегодня ИТ — это взаимосвязанные процессы, поэтому, есть проект, который затрагивает сразу несколько направлений.  T-Elements — конференция, которая уже в четвертый раз собирает архитекторов, инженеров, специалистов по информационной безопасности, SRE-команды, инфраструктурщиков и технических руководителей и всех тех, кто выстраивает и поддерживает цифровой фундамент нынешних российских компаний, для обмена опытом и обсуждения решений, проверенных в реальных проектах  🟣О чем будут говорить: О задачах, с которыми инженеры сталкиваются каждый день: миграции с зарубежных решений, отказоустойчивости, защите инфраструктуры, автоматизации эксплуатации и восстановлении сервисов после инцидентов 🟣Главное в программе: Инженерная работа — на выступлениях будут обсуждать честный опыт тех, кто на практике обеспечивает непрерывность и безопасность ИТ-систем страны 🟣Что ждет участников: Технические доклады, инженерные кейсы, воркшопы, лаборатории и дискуссии о современных вызовах — от искусственного интеллекта и импортозамещения до наблюдаемости, киберустойчивости и эксплуатации сложной инфраструктуры. 🟣Отдельный трек: Темы на стыке технологий, науки и человека. В том числе — как ИИ меняет мышление, можно ли принимать решения с помощью математики и как незрячий инженер работает с одной из самых популярных аналитических СУБД Конференция будет проходить в Москве 9-10 сентября. Для участия нужно зарегистрироваться

👋 Привет, сетевой друг! Расскажу еще о 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 | #история

Если вы работаете в IT, у нас для вас плохие новости. Вас опять хотят схантить.

СМЕЛЫЙ - Telegram-канал финтех-предпринимателя Сергея, который сколотил команду из 100+ разработчиков и прочих особей. На работе они дурью маются, а себя гордо называют IT Monsters.

Дурь, правда, серьезная: финтех, AI-решения, собственная LLM и прочие эксперименты с технологиями. Сам Сергей много двигается по миру, зависает с интересными челами в Долине и придумывает разные бредовые идеи, которые потом почему-то воплощаются в жизнь. Плюс рассказывает про бизнес, собственные переживания, что идет по плану, что идет по пизде и как со всем этим жить. И да, IT Monsters постоянно размножаются - новых людей в команду ищут регулярно. Так что можно просто подписаться и читать. А можно однажды обнаружить, что вас все-таки схантили и теперь вы тоже IT Monster. Подписывайтесь 👇 https://t.me/smelov_77