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

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

Сегодня про webcensus - инструмент для довольно специфичной задачи: найти один и тот же URL-путь сразу на огромном количестве сайтов.

🟣Например, хочется понять, кто вообще публикует /.well-known/security.txt, robots.txt, ads.txt или sitemap.xml. Перебирать сайты по одному здесь явно не вариант.

🟣webcensus собирает это в конвейер из нескольких этапов:

список доменов
      ↓
    DNS
      ↓
 HTTPS probe
      ↓
  скачивание
      ↓
 проверка файла

Сначала massdns быстро резолвит миллионы доменов и оставляет только те, у которых есть A-запись.

🟣Дальше в дело вступает собственный Rust-пробер skim. Он подключается к :443, выполняет TLS handshake и отправляет обычный HTTP-запрос к нужному пути. Но самое интересное - тело ответа на этом этапе вообще не скачивается.

Инструмент читает только HTTP status line:

{"url":"https://example.com/.well-known/security.txt","status":"success","code":200,"cert_ok":true}

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

🟣И только теперь начинается полноценная загрузка. curl --parallel скачивает найденные URL пачками, причём для каждого запроса есть ограничения по размеру, времени и числу повторных попыток.

Например:

--parallel-max 50
--max-filesize 5M
--max-time 10
--connect-timeout 3
--retry 2

Это важно, потому что сервер вполне может ответить 200, а вместо маленького security.txt отдать несколько мегабайт HTML.

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

HTTP 200
   ≠
нужный файл действительно существует

Например, сайт может отдавать одну и ту же SPA-страницу на любой URL с кодом 200. Для простого сканера это найденный файл, для webcensus - мусор.

🟣Весь процесс запускается внутри Docker, а каждый этап оставляет результат в data/. Можно остановиться после любого шага и продолжить с него, а локальный этап проверки вообще не требует повторно ходить в интернет.

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

Почему SAML снова и снова ломается на одном и том же месте?

SAML больше 20 лет отвечает за корпоративный SSO, но исследователи до сих пор находят способы обходить его защиту. В статье разбирают, как XML-комментарии, особенности парсеров и канонизация позволяют подменять подписанные данные так, что проверка проходит, а приложение получает уже другое содержимое.

🟣Разбирают пять проблем протокола: сложность XML, канонизацию, вложенные подписи, перегруженную спецификацию и устаревшую архитектуру. Отдельно проходят по XSW, parser differential и round-trip-атакам, а затем сравнивают подход SAML с OIDC и показывают, почему современные системы постепенно уходят от XML в сторону JSON/JWT.

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

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

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

Сегодня про Ethernet, который мы привыкли воспринимать как обычный кабельный LAN. Но за ним давно стоит целый набор технологий, которые позволяют гонять трафик на десятки и сотни гигабит.

🟣Сначала был 10BASE-T: В классическом Ethernet по витой паре использовались 10 Мбит/с и обычная схема с хабами. Несколько устройств делили один collision domain и решали, кто сейчас может передавать, через CSMA/CD. С современными коммутаторами эта история практически исчезла.

🟣Потом Ethernet научился работать одновременно: Появился full-duplex: устройство может передавать и принимать данные одновременно, а коллизии на коммутируемом соединении больше не нужны. Поэтому сегодня 1000BASE-T означает не просто «гигабит по кабелю». Это уже point-to-point соединение между портом коммутатора и конечным устройством.

🟣А дальше началась гонка скоростей:

10 → 100 → 1000 → 10G → 25G → 40G → 100G → 200G → 400G → 800G.

Причём скорость росла не только за счёт увеличения частоты сигнала. Используются более сложные схемы кодирования, PAM4, несколько физических линий и всё более продвинутые DSP. Например, 400GbE может передавать данные четырьмя электрическими или оптическими лэйнами по 100 Гбит/с.

🟣Почему 25G вообще появился, если был 10G?: Для дата-центров оказалось удобнее масштабировать серверные подключения по 25G: один 25G lane хорошо сочетается с 100G и 400G аплинками.
Например:

Server
  │ 25G
  ▼
Leaf
  │ 100G
  ▼
Spine
  │ 400G
  ▼
Core

Так Ethernet постепенно превратился из стандарта для офисной сети в основу современных дата-центров.

🟣И самое интересное: Ethernet не выиграл потому, что у него всегда была самая высокая скорость. Его сила в огромной экосистеме: совместимые коммутаторы, NIC, оптика, медь, стандарты, LACP, VLAN, QoS и куча оборудования от разных производителей. Поэтому когда вы подключаете сервер на 25G или 100G, под капотом всё ещё работает тот же Ethernet, которому уже больше 40 лет.

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

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

Собрал три способа прокачать защиту MikroTik - особенно если роутеров уже несколько и хочется меньше ручной работы…

🟣Автоматически обновлять блок-листы через RouterOS API + Python: Когда роутеров десятки, заходить на каждый и вручную добавлять подозрительные IP - сомнительное удовольствие. Через API можно централизованно обновлять address-list и быстро распространять блокировки на весь парк:

import routeros_api

connection = routeros_api.RouterOsApiPool(
    '192.168.1.1',
    username='admin',
    password='pass',
    plaintext_login=True
)

api = connection.get_api()

rules = api.get_resource('/ip/firewall/filter')
print(rules.get())

Например, добавить IP в blocklist:

api.get_resource('/ip/firewall/address-list').add(
    list='blocklist',
    address='10.0.0.5',
    comment='auto-blocked'
)

Так можно быстро блокировать адреса, полученные из SIEM, threat intelligence или внутренней системы мониторинга, сразу на всех MikroTik.

🟣Проверять доступность сервисов через Netwatch: Ping не всегда показывает реальное состояние сервиса. Хост может отвечать на ICMP, пока nginx возвращает 502, приложение не работает, а пользователи уже не могут подключиться. Для дополнительного контроля Netwatch можно связать с HTTP health-check и проверять конкретный endpoint:

/tool netwatch
add host=10.0.0.10 interval=30s timeout=5s \
    type=HTTP http-codes=200 \
    down-script="/log error \"Web server DOWN\"" \
    up-script="/log info \"Web server UP\""

Если сервис перестал отвечать, down-script может добавить его адрес в отдельный список, отправить событие в мониторинг или запустить переключение на резервный сервер.

🟣Ловить сканирование внутри сети: Скомпрометированный хост может начать быстро перебирать адреса и открывать множество TCP-соединений. Для этого можно отслеживать новые SYN и складывать активные источники в отдельный список:

/ip firewall mangle
add chain=forward protocol=tcp tcp-flags=syn \
    connection-state=new \
    src-address-list=!whitelist \
    action=add-src-to-address-list \
    address-list=syn-tracking \
    address-list-timeout=30s

/ip firewall filter
add chain=forward protocol=tcp tcp-flags=syn \
    connection-state=new \
    src-address-list=syn-tracking \
    connection-limit=30,32 \
    action=add-src-to-address-list \
    address-list=internal-scanner \
    address-list-timeout=1h \
    log=yes \
    log-prefix="SCAN DETECTED:"

add chain=forward src-address-list=internal-scanner \
    action=drop \
    log=yes \
    log-prefix="SCANNER BLOCKED: "

В итоге источник, который набирает слишком много одновременных TCP-соединений, попадает в internal-scanner, а следующее правило уже режет ему трафик.

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

Когда в ИТ три человека, появляется четвёртая работа — выяснять, кто чем занимается.

— Кто взял заявку бухгалтерии?
— Саша вроде.
— А сервером кто занимается?
— Я думал, ты.
— А в филиал кто-нибудь написал?
— Сейчас спрошу.

И вот вместо работы кто-то в команде постепенно превращается в диспетчера.

Нужно помнить, кому что передали, проверять, взял ли человек задачу, смотреть, кто сейчас свободен, напоминать про зависшие обращения и периодически разруливать классическое «я думал, это делает кто-то другой».

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

В Okdesk эту «диспетчерскую» нагрузку можно снять: заявки распределяются между сотрудниками и командами, назначаются ответственные, задаются приоритеты и сроки, настраивается автоматическая маршрутизация.
 
❓Вопрос «Саша это делает?» больше не нужен — достаточно открыть платформу и увидеть, кто отвечает за заявку и на каком она этапе.

Хотите увидеть, как это работает на практике?

Приходите на вебинар — разберём на примере «Мобиус Технологии», как разделить потоки между поддержкой, инженерами и экспертами, настроить маршрутизацию под разные типы обращений и масштабировать обслуживание без потери SLA.

👉 Получить бесплатный вебинар можно по ссылке https://lead.okdesk.ru/mnogourovnevyj-servis

Реклама. ООО «Облачные решения». erid: 2VtzqxJ7bjz

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

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

🟣Проблема которую решает: приложение не знает топологию сети оператора. P2P-клиент выбирает пира случайно и трафик может идти через дорогой межоператорский линк когда нужный пир сидит в той же AS за соседним свитчем. Стриминг выбирает CDN-узел по географии, а не по реальной близости в сети. Оператор об этом знает, но молчит.

🟣Что делает ALTO: оператор поднимает ALTO-сервер и отдаёт через REST API карту своей сети - стоимость маршрутов между подсетями, предпочтительные точки выхода, ранжирование эндпоинтов. Приложение делает запрос и получает подсказку кого лучше выбрать:

# Запрос стоимости маршрутов между подсетями
curl https://alto.operator.com/networkmap
curl https://alto.operator.com/costmap/pv/num/routingcost

# Ответ содержит матрицу стоимостей между PID-группами
# PID — это группы подсетей которые оператор считает эквивалентными

🟣Как это выглядит на практике: BitTorrent-клиент с поддержкой ALTO спрашивает у оператора какие из доступных пиров предпочтительнее. Оператор отвечает что пиры внутри его AS имеют стоимость 0, а пиры в других AS стоимость 10. Клиент выбирает внутренних - оператор экономит на межоператорском трафике, пользователь получает лучшую скорость.

🟣Endpoint Cost Service - самая полезная часть: приложение отдаёт список конкретных IP и получает их ранжирование:

POST /endpointcost/lookup
{
  "cost-type": {"cost-mode": "numerical", "cost-metric": "routingcost"},
  "endpoints": {
    "srcs": ["ipv4:192.0.2.1"],
    "dsts": ["ipv4:198.51.100.1", "ipv4:203.0.113.1", "ipv4:198.51.100.2"]
  }
}

В ответе каждому dst назначена стоимость - приложение выбирает минимальную.

🟣А где используют: крупные CDN запрашивают ALTO у операторов для выбора точки присутствия, WebRTC-клиенты для выбора TURN-сервера, следующее поколение адаптивного стриминга. RFC 7285 принят в 2014 году, активно развивается - в 2021 вышли расширения для поддержки ALTO в мультидоменных сетях и датацентрах.

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

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

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

Давай расскажу про mdns-scanner, который быстро пробегается по локальной сети и пытается понять, какие устройства там вообще живут.

🟣Запускаете его - и вместо голого списка IP получаете связку адресов с именами:

192.168.1.12 → macbook.local
192.168.1.24 → printer.local
192.168.1.37 → nas.local

Причём он не ограничивается обычным DNS. mdns-scanner умеет собирать mDNS-имена, DNS-SD service instances и другие алиасы, которые устройства сами объявляют в локальной сети.

🟣mDNS особенно крут там, где обычного DNS просто нет. Например, ноутбук или принтер может прекрасно знать себя как printer.local, хотя никакой записи для него на вашем DNS-сервере не существует.

А через DNS-SD можно увидеть ещё и опубликованные сервисы:

_http._tcp
_ssh._tcp
_airplay._tcp
_printer._tcp

То есть можно понять не только «этот IP существует», но и «что устройство вообще предлагает в сети».

🟣Инструмент автоматически сканирует доступные non-loopback интерфейсы, ищет хосты и пытается разрешить найденные IP в связанные имена. Получается довольно удобная быстрая инвентаризация локалки без ручного просмотра ARP-таблиц и DNS.

🟣Написан mdns-scanner на Rust, есть версии для Linux, macOS и Windows. На Windows понадобится Npcap.

Установка из Git:

cargo install --git https://github.com/CramBL/mdns-scanner mdns-scanner

Или можно скачать готовый бинарник из Releases.

🟣Но есть маленький нюанс. Утилита действительно сканирует сеть, причём довольно бодро - автор предупреждает о сотнях IP-проверок в секунду. Поэтому в рабочей сети лучше сначала предупредить админа, а не устраивать внезапную перепись всего /24.

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

V100 вместо RTX 3090: как собрать домашний LLM-сервер из списанного железа

В статье показывают, как собрать домашний сервер для локальных LLM из бывших в употреблении Tesla V100. Эти ускорители 2017 года с 32 ГБ HBM2 и пропускной способностью 900 ГБ/с сегодня можно найти за $100–150. А если объединить несколько карт, получится уже 64–128 ГБ видеопамяти - достаточно, чтобы запускать модели, которым тесно в обычных потребительских видеокартах.

🟣Правда, лёгкой такую сборку не назовёшь: понадобятся переходники для SXM2, мощное охлаждение, блок питания на несколько киловатт и терпение при настройке CUDA с PyTorch. Четыре V100 могут потреблять до 1200 Вт, зато за относительно небольшие деньги получится настоящий домашний сервер для локальных LLM.

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

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

📝HMAC: три шага, которые защищают запрос от подделки

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

GET /api/user/42
X-Timestamp: 1714000000
X-Signature: 8f3a91...

Сервер повторяет расчёт с тем же секретом. Подписи совпали - запрос не изменён и знает секрет.

🟣Что именно подписывается: обычно метод, путь, timestamp, nonce и тело запроса. Например:

POST
/api/payment
1714000000
abc123
{"amount":100}

Из этой строки и секретного ключа получается HMAC:
HMAC-SHA256(data, secret)

🟣Почему просто отправить секрет нельзя: клиент не передаёт ключ серверу при каждом запросе. Он используется только для вычисления подписи.

Если атакующий изменит:

{"amount":100}

на:

{"amount":100000}

подпись уже не совпадёт.

🟣Но HMAC сам по себе не защищает от повторной отправки запроса. Если украсть настоящий запрос, его можно попробовать отправить ещё раз.

Поэтому рядом используют timestamp и nonce:

timestamp → запрос должен быть свежим
nonce     → конкретный запрос можно использовать один раз
signature → данные нельзя незаметно изменить

Такую схему часто используют API, вебхуки и взаимодействие между сервисами, где важно доказать не только «кто отправил запрос», но и что его содержимое не меняли по дороге.

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

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

Сегодня разберём, в чём разница между Private VLAN и VLAN ACL (VACL).

🟣Private VLAN ограничивает связь между портами ещё на уровне L2. Устройства могут находиться в одном IP-сегменте и использовать общий шлюз, но при этом не иметь возможности напрямую общаться друг с другом.

Например:

Host A ─┐
Host B ─┼─ Isolated PVLAN ── Gateway
Host C ─┘

Хосты доходят до шлюза, но не видят соседей внутри своего изолированного сегмента.

🟣VACL решает другую задачу - фильтрует трафик внутри VLAN по правилам доступа. Можно задавать условия по IP, протоколам и другим параметрам и разрешать или запрещать конкретные виды трафика.

Условно:

Host A ──┐
         ├── VLAN ── Gateway
Host B ──┤
         │
Host C ──┘
          ↓
         VACL

То есть VACL может сказать: TCP/22 между двумя подсетями разрешить, а определённый другой трафик запретить.

🟣Главная разница: PVLAN определяет кто вообще может общаться с кем внутри L2-сегмента, а VACL определяет какой трафик разрешён или запрещён правилами фильтрации.

PVLAN:

Host A ↛ Host B Host A → Gateway

VACL:

Host A → TCP/443 → Host B ✅ Host A → TCP/23 → Host B ❌

🟣Их можно использовать вместе. Например, PVLAN изолирует клиентов друг от друга, а VACL дополнительно фильтрует разрешённый трафик внутри VLAN.

Это разные уровни контроля: Private VLAN строит саму модель L2-доступа, а VACL добавляет фильтрацию поверх неё.

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

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

Сегодня разберём LAG (Link Aggregation) - механизм, который объединяет несколько физических линков между устройствами в один логический канал.

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

10G + 10G + 10G + 10G → LAG 40G

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

🟣Но здесь есть важный нюанс: один TCP-поток обычно не начинает передаваться со скоростью всех физических линков сразу. Коммутатор выбирает физический линк с помощью hashing. В расчёт могут попадать MAC-адреса, IP-адреса и TCP/UDP-порты.

Например:

10.0.0.10:443 → 10.0.0.20:53142 → Link 1

10.0.0.11:443 → 10.0.0.20:53143 → Link 2

Разные потоки могут распределяться по разным физическим интерфейсам.

🟣Поэтому четыре 10G-порта не гарантируют одному соединению 40 Гбит/с. Если через LAG проходит всего один большой flow, hashing может отправить его целиком на один линк. А вот десятки и сотни независимых соединений уже позволяют гораздо эффективнее использовать всю агрегацию.

🟣LACP также помогает обнаруживать проблемы с участниками группы. Если один физический линк перестал отвечать, он может быть исключён из агрегата, а остальные продолжают передавать трафик.

Например:

4 × 10G → 40G

после отказа:

3 × 10G → 30G

Без необходимости перестраивать логическую топологию вручную.

🟣Именно поэтому при диагностике LAG недостаточно смотреть на состояние самого Port-Channel. Если один физический интерфейс перегружен, а остальные почти простаивают, проблема может быть не в LACP, а в алгоритме hashing и характере трафика.

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

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

Расскажу про LAN Sheriff - self-hosted тул, который показывает, с какими серверами и организациями общаются устройства в вашей сети.

🟣После запуска он открывает веб-интерфейс и начинает собирать карту исходящих соединений. Можно увидеть, куда уходит трафик, страну и организацию назначения, reverse DNS, протокол, порт, объём данных, длительность соединения и приложение или устройство, которое его создало. При этом аккаунт и облако не нужны - данные хранятся локально.

🟣У LAN Sheriff есть два режима. По умолчанию работает Deputy Mode: он без повышенных привилегий показывает соединения самого компьютера и точно определяет приложение, которое их открыло. Patrol Mode использует libpcap/Npcap и может видеть трафик других устройств. Но здесь есть важный нюанс: просто запустить packet capture недостаточно. Машина должна находиться в правильной точке сети, например на роутере или SPAN/mirror-порту коммутатора.

🟣Отдельно есть Radio Chatter - поток DNS-запросов:

кто запросил → какой домен → во что он разрешился → сколько занял запрос.

🟣Инструмент также отмечает обращения к известным tracker, ad, telemetry и malware-доменам, но ничего не блокирует. Encrypted DNS при этом остаётся невидимым. DoH и DoT проходят через зашифрованные соединения, поэтому LAN Sheriff не пытается их расшифровывать.

🟣Есть и Wanted List - набор правил, которые ищут подозрительное поведение:

➖новое направление для устройства
➖регулярный beaconing
➖редкие назначения
➖DGA-домены
➖port scan
➖plaintext credentials
➖аномальный объём трафика
➖обращения к доменам из malware-листов

Причём результат не выглядит как просто «подозрительно». Например, инструмент может показать, что устройство 73 раза отправляло FTP-трафик на hosting provider без шифрования.

🟣LAN Sheriff ничего не блокирует, не сбрасывает и не модифицирует пакеты. Захват полностью пассивный, а единственная активная часть - локальный discovery, который может отправлять небольшие probes по адресам сети. Есть экспорт в CSV/JSON, webhook, ntfy, Discord и Slack, поиск по устройствам, приложениям и назначениям, а также TUI и Docker.

🟣Идея довольно простая: не заменять Wireshark, Zeek или Suricata, а дать быстрый способ увидеть, куда ваша сеть вообще разговаривает, без настройки полноценного monitoring/security-стека.

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

Печать на конверте ничего не доказывает: разбираем SPF, DKIM и DMARC на живом примере

В статье на примере курьера и бумажного письма разбирают, почему From в SMTP ничем не подтвержден. SPF проверяет по DNS, имеет ли IP право слать почту от домена, но смотрит на технический Mail From, а не на From. DKIM подписывает заголовки и тело криптографическим ключом и ловит изменения по пути, но подтверждает только домен из самой подписи. Оба могут пройти успешно и при этом подтвердить чужой домен, поэтому разбирают DMARC с alignment, relaxed и strict, политики none/quarantine/reject и делегирование поддомена под рассылки через NS-записи.

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

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

Сегодня разберём в чём реальная разница между PBR и SR-TE для управления трафиком.

🟣Policy-Based Routing работает локально на каждом роутере: смотришь на заголовок пакета, матчишь по ACL, отправляешь на нужный next-hop. Просто, понятно, но масштабируется плохо - правила нужно настраивать на каждом устройстве отдельно, а состояние пути нигде не отслеживается:

ip access-list extended VOICE
 permit udp any any range 16384 32767

route-map PBR_VOICE permit 10
 match ip address VOICE
 set ip next-hop verify-availability 10.0.0.1 10 track 1

interface GigabitEthernet0/1
 ip policy route-map PBR_VOICE

Если next-hop упал - PBR об этом узнает только через track, и только если ты это настроил.

🟣SR-TE (Segment Routing Traffic Engineering) работает иначе: весь путь кодируется в заголовке пакета на входном узле, промежуточные роутеры просто следуют инструкциям. Headend знает топологию через IGP с расширениями и сам вычисляет оптимальный путь:

segment-routing traffic-eng policy VOICE_PATH
 color 10 endpoint 10.255.255.4
 candidate-paths
  preference 100
   dynamic
    pcep
    metric
     type latency

Метрика latency означает что контроллер или сам роутер выберет путь с минимальной задержкой, не по IGP-метрике.

🟣Главная разница: PBR статичен и локален, SR-TE динамичен и глобален. PBR не знает что происходит дальше по пути, SR-TE видит всю топологию и может перестроить маршрут при деградации канала автоматически.

Диагностика тоже разная:

show route-map PBR_VOICE          # статистика PBR
show segment-routing traffic-eng policy
show segment-routing traffic-eng policy detail

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

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

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

Сегодня расскажу про RD и RT в MPLS L3VPN. Их часто путают, хотя задачи у них совершенно разные.

🟣RD (Route Distinguisher) нужен, чтобы сделать VPN-префикс уникальным. Один и тот же 10.10.10.0/24 может существовать у разных клиентов:

Customer A → 10.10.10.0/24
Customer B → 10.10.10.0/24

С RD маршруты превращаются в разные VPNv4-префиксы:

65000:10:10.10.10.0/24
65000:20:10.10.10.0/24

То есть RD решает проблему пересечения адресных пространств.

🟣RT (Route Target) отвечает уже за другое: какие VPN-маршруты конкретный VRF должен импортировать или экспортировать.

Например:

VRF-CUSTOMER-A
Export RT: 65000:100
Import RT: 65000:200

Маршрут сначала получает RD и становится уникальным VPNv4-префиксом, а затем RT определяет, в какие VRF этот маршрут можно импортировать.

🟣Поэтому RD не говорит маршрутизатору, кому отдавать маршрут. И RT не делает префикс уникальным.

Упрощённо:

RD → какой это VPN-префикс?
RT → в какие VRF его можно импортировать?

🟣Из-за этого один и тот же RD может быть частью разных политик RT. Например, VRF филиалов может экспортировать маршруты с RT 65000:10, а центральный VRF импортировать их вместе с маршрутами других VPN.

🟣Именно разделение этих двух механизмов позволяет MPLS L3VPN одновременно поддерживать одинаковые IP-адреса у разных клиентов и гибко управлять обменом маршрутами между VRF.

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

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

Разберём Private VLAN - механизм изоляции хостов внутри одного VLAN, который закрывает горизонтальные атаки между устройствами в одном сегменте.

🟣Суть проблемы: обычный VLAN изолирует трафик между разными VLAN, но внутри одного VLAN все устройства видят друг друга. В гостевых сетях, хостинге или DMZ это проблема - скомпрометированный хост может атаковать соседей в том же сегменте через ARP-спуфинг, брутфорс или lateral movement.

🟣Как работает Private VLAN: вводится иерархия портов. Promiscuous порт видит всех — это обычно шлюз или роутер. Isolated порты видят только promiscuous, но не друг друга. Community порты видят promiscuous и других участников своей community-группы, но не isolated и другие community.

🟣Настройка на Cisco:

! Создаём primary VLAN
vlan 100
 private-vlan primary

! Создаём isolated VLAN для изолированных хостов
vlan 101
 private-vlan isolated

! Связываем isolated с primary
vlan 100
 private-vlan association 101

! Promiscuous порт — шлюз
interface GigabitEthernet0/1
 switchport mode private-vlan promiscuous
 switchport private-vlan mapping 100 101

! Isolated порты — хосты которые не должны видеть друг друга
interface range GigabitEthernet0/2-10
 switchport mode private-vlan host
 switchport private-vlan host-association 100 101

🟣Проверяем что изоляция работает:

show vlan private-vlan
show interfaces GigabitEthernet0/2 switchport | include Private

🟣Чем это лучше просто разных VLAN: не нужно создавать десятки VLAN под каждый изолированный хост и прописывать маршруты между ними. Все хосты в одном IP-подсети, один шлюз, но горизонтальный трафик между ними физически заблокирован на уровне коммутатора. ARP-спуфинг между изолированными хостами становится невозможным - пакеты просто не доходят до соседа.

🟣Типичное применение: хостинг где клиенты в одной подсети не должны видеть друг друга, гостевые Wi-Fi сети через проводной uplink, серверные DMZ где каждый сервер изолирован от соседей.

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

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

Сегодня про Kula - лёгкий мониторинг Linux-сервера который помещается в один бинарник.

🟣Что это: Go-приложение которое читает метрики напрямую из /proc и /sys каждую секунду, хранит их во встроенном ring-buffer хранилище и отдаёт через веб-дашборд или TUI в терминале.

🟣Что мониторит: CPU с разбивкой по типам нагрузки (user, system, iowait, steal), память, swap, сетевые интерфейсы с throughput и TCP-метриками, диски по IOPS, температуры, контейнеры Docker/Podman, PostgreSQL, MySQL, nginx, apache2. Плюс кастомные метрики через свои скрипты.

🟣Установка за минуту:

# Guided установка
bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install_v2.sh)"

# Или вручную
wget https://github.com/c0m4r/kula/releases/download/0.19.0/kula-0.19.0-amd64.tar.gz
tar -xvf kula-0.19.0-amd64.tar.gz && cd kula && ./kula

Дашборд поднимается на http://localhost:27960.

🟣Через Docker если не хочется ничего ставить на хост:

docker run --rm -it --name kula --pid host --network host \
  -v /proc:/proc:ro c0m4r/kula:latest

🟣TUI для терминала - если нет браузера или нужен быстрый взгляд:

./kula tui

🟣Хранение данных по трём тирам: сырые данные с интервалом 1 секунда занимают до 250 МБ, агрегация по минуте до 150 МБ, по 5 минут до 50 МБ. Ring-buffer - старые данные перезаписываются новыми автоматически, место не растёт бесконечно.

🟣Есть Prometheus endpoint для интеграции в существующий стек, аутентификация через Argon2id с токенами, и опциональный AI-ассистент через локальный Ollama - анализирует метрики прямо в дашборде.

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