Network Admin

Как проверить PoE-потребление без доступа к устройству

IP-камера периодически перезагружается, хотя сетевой линк работает нормально. Причина может быть не в сети, а в питании через PoE.

Чтобы это проверить, необязательно идти к камере с тестером. Управляемый PoE-коммутатор часто показывает параметры питания прямо через CLI. ⏺Смотрим общий бюджет PoE На Cisco Catalyst:

show power inline

Команда показывает доступную мощность, сколько уже выделено подключённым устройствам и сколько осталось. Важно не путать allocated power и фактическое потребление. Коммутатор может зарезервировать для камеры 15,4 Вт, хотя сейчас она использует значительно меньше. ⏺Проверяем конкретный порт

show power inline Gi1/0/10 detail

В зависимости от модели и версии ПО можно увидеть класс PoE, выделенную мощность, состояние питания и измеренное потребление. Например, камера днём потребляет 6 Вт, а ночью включает ИК-подсветку и нагреватель. Потребление растёт, и если мощности недостаточно, устройство может перезагрузиться. ⏺Ищем события питания

show logging | include ILPOWER

На поддерживаемых Cisco Catalyst так можно найти сообщения об отказе в питании, превышении лимита или отключении PoE на порту. Если коммутатор не показывает фактические ватты, ориентируемся на выделенную мощность, класс устройства и события контроллера PoE. Не все модели умеют измерять потребление в реальном времени. N.A.

NAT44 vs NAT64: как IPv6-клиент подключается к IPv4-серверу Обычный NAT44 меняет IPv4-адреса, но сам протокол остаётся прежним. NAT64 работает иначе: позволяет клиенту из IPv6-only сети обращаться к серверу, у которого есть только IPv4. ⏺NAT44 чаще всего встречается на домашних маршрутизаторах. Несколько устройств с приватными IPv4-адресами выходят в интернет через один публичный адрес. Например, 192.168.1.10:50000 превращается в 203.0.113.5:40001. Маршрутизатор запоминает соответствие и возвращает ответы нужному клиенту. ⏺NAT64 переводит пакеты между IPv6 и IPv4. Но сначала клиенту нужно получить IPv6-адрес назначения. Для этого часто используется DNS64. Если у сервера есть только A-запись, DNS64 может синтезировать AAAA-запись с IPv4-адресом внутри специального IPv6-префикса. Например, для IPv4 192.0.2.10 при использовании префикса 64:ff9b::/96 получится:

64:ff9b::192.0.2.10

Клиент отправляет IPv6-пакет на этот адрес. NAT64-шлюз извлекает IPv4-адрес назначения, преобразует пакет и пересылает его серверу уже по IPv4. Проверить DNS-ответ можно командой:

dig AAAA ipv4only.arpa

В сети с DNS64 такой запрос помогает обнаружить используемый NAT64-префикс. ⏺Главное ограничение: DNS64 не поможет приложению, которое обращается напрямую к IPv4-литералу и не умеет работать с IPv6. Для таких случаев могут потребоваться дополнительные механизмы, например CLAT в составе 464XLAT. N.A.

Что такое IX и как трафик идёт внутри него IX (Internet Exchange) это физическая точка где провайдеры, CDN и крупные сети подключаются друг к другу напрямую. Вместо того чтобы гонять трафик через транзитного провайдера и платить за каждый гигабит, участники обмениваются трафиком напрямую и бесплатно между собой.

Крупнейшие точки обмена: DE-CIX во Франкфурте, AMS-IX в Амстердаме, MSK-IX в Москве. Через DE-CIX проходит больше 10 Тбит/с в пике.

Как устроено внутри Физически IX это один большой коммутатор (или несколько связанных), к которому все участники подключают свои роутеры. Эта общая среда называется IXP fabric. Каждый участник получает порт и IP-адрес в общей подсети IX. Дальше всё через BGP. Каждый участник поднимает BGP-сессии с теми с кем хочет обмениваться трафиком, анонсирует свои префиксы и получает чужие. Никакой автоматики, только явные пиринговые договорённости. Route Server Чтобы не поднимать сотни BGP-сессий с каждым участником отдельно, большинство IX предоставляют Route Server. Подключаешься к одному RS, получаешь маршруты от всех участников кто тоже подключён к RS. Можно фильтровать что принимать и что анонсировать.

router bgp 65001 neighbor 193.178.185.1 remote-as 65000 neighbor 193.178.185.1 description MSK-IX Route Server

Как трафик идёт внутри Пакет от пользователя провайдера А до сервера в сети провайдера Б: роутер А смотрит BGP-таблицу, видит что префикс Б получен через IX, отправляет пакет напрямую на роутер Б через IXP fabric. Транзитный провайдер не участвует, задержка меньше, стоимость ниже. N.A.

📘 На Mentorix вышел курс — «Terraform: инфраструктура как код» Хотите не просто писать .tf-файлы, а собирать инфраструктуру кодом, с которой работает вся команда? Этот курс — полный путь от первого apply до пайплайна, который применяет только проверенный план. • Основы: HCL, init → plan → apply, провайдеры и lock-файл • Переменные: типы, коллекции, валидация, sensitive • Ресурсы: граф зависимостей, count и for_each, lifecycle • State: дрейф, state mv и moved, импорт существующего • Модули: контракты, композиция, версии • Окружения: workspaces, tfvars, бэкенды S3/GCS/Yandex • Проверки: preconditions, check-блоки, terraform test • CI/CD: GitLab CI и GitHub Actions, дрейф-детект • Капстоун: платформа из трёх стеков с dev и prod 🎓 Сертификат — добавьте в резюме или LinkedIn 🏷 Скидка 50%, действует 48 часов 12 990 ₽ → 6 495 ₽ ➜ Пройти курс на Mentorix Ещё 25 курсов бесплатно — доступны после регистрации

3 ошибки при настройке BGP prefix-list Prefix-list кажется простой вещью: указал сеть, разрешил или запретил маршрут. Но одна неточная маска может изменить фильтрацию сразу для сотен префиксов. ⏺Забыли про le и ge Например, на Cisco:

ip prefix-list FILTER permit 10.0.0.0/8

Это правило разрешает только точный префикс /8. Маршрут 10.10.0.0/16 под него не попадёт. Чтобы разрешить более специфичные сети:

ip prefix-list FILTER permit 10.0.0.0/8 le 24

Теперь подходят префиксы от /8 до /24 внутри указанной сети. ⏺Случайно разрешили слишком много

ip prefix-list FILTER permit 0.0.0.0/0 le 32

Это не разрешение только default route. Такое правило подходит под любой IPv4-префикс. Если нужен исключительно маршрут по умолчанию:

ip prefix-list FILTER permit 0.0.0.0/0

⏺Забыли про implicit deny В конце prefix-list действует неявный запрет. Если маршрут не совпал ни с одним разрешающим правилом, он будет отклонён при применении списка как фильтра. Проверяем:

show ip prefix-list FILTER
show ip bgp neighbors 192.0.2.1 advertised-routes

Последняя команда помогает увидеть, что реально анонсируется соседу. Синтаксис зависит от платформы. ⚡️В prefix-list важно не только указать сеть, но и правильно задать допустимую длину префикса. Разница между /8 и /8 le 24 может решить, какие маршруты вообще попадут к соседу. N.A

Как проверить, куда исчезают пакеты в nftables Порт открыт, маршрут есть, но соединение не устанавливается. Проверять десятки правил firewall вручную неудобно, особенно когда пакеты проходят через несколько цепочек. В nftables есть трассировка, которая показывает путь пакета через правила. ⏺Сначала включаем трассировку для нужного трафика. Например, для TCP-подключений к порту 443:

nft add table inet debug
nft 'add chain inet debug trace_in { type filter hook prerouting priority -301; policy accept; }'
nft add rule inet debug trace_in tcp dport 443 meta nftrace set 1

Теперь запускаем мониторинг: nft monitor trace Пробуем подключиться к серверу с другого устройства. ⏺В выводе появятся цепочки и правила, через которые проходит пакет. Например:

trace ... rule tcp dport 443 drop
trace ... verdict drop

Так можно увидеть не просто факт блокировки, а конкретное правило, которое приняло решение. Если пакет вообще не появляется в трассировке, стоит проверить, доходит ли он до выбранного hook и соответствует ли условию трассировки. ⏺После диагностики удаляем временную таблицу:

nft delete table inet debug

⚡️tcpdump показывает, что пакет пришёл на интерфейс. nft monitor trace помогает выяснить, что с ним произошло внутри nftables. N.A

Миф: Port Security защищает от всех атак на L2 Port Security ограничивает количество MAC-адресов на порту коммутатора. Например, разрешаем один MAC, и если появляется второй, порт блокируется или начинает отбрасывать нарушающий трафик в зависимости от режима. Кажется, что этого достаточно для защиты от посторонних устройств. Но Port Security контролирует MAC-адреса, а не поведение самого устройства. ⏺Rogue DHCP Server Атакующий подключает устройство с разрешённым MAC и начинает раздавать клиентам неправильный шлюз или DNS. Port Security не анализирует DHCP-ответы. Для этого нужен DHCP Snooping, который запрещает ответы DHCP-сервера с недоверенных портов. ⏺ARP Spoofing Устройство с разрешённым MAC отправляет поддельные ARP-ответы, связывая IP шлюза со своим MAC. Port Security не проверяет соответствие IP и MAC внутри ARP. Этим занимается Dynamic ARP Inspection, используя доверенные привязки, например из DHCP Snooping. ⏺Подмена разрешённого MAC Если атакующий узнает допустимый MAC и использует его вместо своего, Port Security не сможет определить личность устройства только по этому адресу. Для аутентификации применяют 802.1X, хотя и он требует правильной настройки. На Cisco проверяем состояние защиты:

show port-security interface Gi0/1
show ip dhcp snooping
show ip arp inspection

⚡️Port Security ограничивает MAC-адреса на порту. DHCP Snooping контролирует DHCP-серверы, DAI проверяет ARP, а 802.1X аутентифицирует подключение. Один механизм не заменяет остальные. N.A

⚡️5 фундаментальных курсов по ИБ по цене одного Это предложение для тех, кто готов войти в новую профессию прямо сейчас! 🔥Пакет курсов за 50 000 ₽ вместо 250 000 ₽: ▪️ Linux CyberPunk - обычная цена 49 500 ₽ (+ Курс идет с официальным дипломом системного администратора!) ▪️ SQL для хакера - обычная цена 15 000 ₽ ▪️ HackerPoint - обычная цена ~70 000 ₽ ▪️ HackerPoint (Blue vs Red Team) - обычная цена 43 500 ₽ ▪️ AI-помощники на Python - обычная цена 71 500 ₽ Вы экономите 200 000 ₽ и получаете полную базу: от работы с терминалом и базами данных до разработки ИИ-агентов и взлома систем. 🔒 Квота: набор на программу ограничен по количеству мест. 🦔Отправь промокод NetworkAdmin в чат с менеджером, чтобы закрепить за собой скидку и узнать подробности: 👉@cyacademy_support

Один IP, два MAC: как ARP-конфликт ломает сеть Два устройства случайно получили одинаковый IP-адрес. Оба доступны на L2, оба отвечают на ARP-запросы, но MAC-адреса у них разные. Для соседних хостов начинается путаница. Один ARP-ответ связывает 192.168.1.50 с первым MAC, следующий может заменить запись на MAC второго устройства. В результате соединения периодически обрываются, SSH зависает, а ping то проходит, то нет. ⏺Смотрим neighbor table

ip neigh show 192.168.1.50

Запись может меняться между двумя MAC-адресами. Но это не обязательно происходит после каждого ARP-ответа: Linux учитывает состояние записи и правила её обновления. ⏺Ловим конфликт

tcpdump -eni eth0 arp

Если два устройства отвечают за один IP, в захвате можно увидеть ARP Reply с одинаковым sender IP, но разными sender MAC. Дополнительно проверяем адрес через arping:

arping -I eth0 -c 5 192.168.1.50

Несколько ответов с разными MAC - сильный признак конфликта. ⏺Что происходит с соединениями Когда сосед начинает отправлять кадры на другой MAC, пакеты попадают не на тот сервер. Старое TCP-соединение при этом не переносится на новое устройство. N.A

PBR vs VRF: два способа управлять маршрутизацией Обе технологии позволяют отправлять трафик не по обычной таблице маршрутизации. Но решают разные задачи. ⏺PBR (Policy-Based Routing) выбирает маршрут по заданным условиям. Например, весь трафик из подсети 192.168.10.0/24 должен идти через второго провайдера, даже если default route указывает на первого. На Linux это можно сделать через ip rule:

ip rule add from 192.168.10.0/24 table 100
ip route add default via 10.0.0.1 dev eth1 table 100

Теперь пакеты из этой подсети используют таблицу 100. Остальной трафик продолжает маршрутизироваться по обычным правилам. ⏺VRF (Virtual Routing and Forwarding) создаёт отдельный routing domain со своей таблицей маршрутизации. Например, на одном сервере работают две изолированные сети. У каждой свой default gateway, а адресные пространства могут даже пересекаться. Создаём VRF:

ip link add vrf-blue type vrf table 100
ip link set vrf-blue up
ip link set eth1 master vrf-blue

Теперь eth1 принадлежит VRF, а маршруты подключённых к нему сетей находятся в таблице 100. Для отдельного default route его нужно настроить дополнительно. Посмотреть маршруты:

ip route show vrf vrf-blue

Главная разница в том, что PBR выбирает таблицу или маршрут по условиям, а VRF привязывает интерфейсы и трафик к отдельному домену маршрутизации. N.A

😒 N.A

🚨 Вебинар: Что делать при DDoS-атаке — 7 первых шагов и 7 ошибок Как действовать, если DDoS-атака уже началась, а любая минута простоя или ошибка в реагировании грозят миллионными издержками для всего бизнеса? Пошаговый план представят эксперты StormWall. Подключайтесь в четверг 22 октября, чтобы узнать: 🔹 что делать в первые 30 минут DDoS-атаки и в какой последовательности; 🔹 какие ошибки чаще всего приводят к дополнительным потерям; 🔹 как организовать работу команды во время инцидента; 🔹 что проверить после инцидента и как подготовить инфраструктуру к новым угрозам. В прямом эфире также выступит Валерий Щекочихин, заместитель начальника УТС ДИТ СДМ-Банка ➡️ Спикер поделится собственным опытом отражения крупной DDoS-атаки, которая затронула 9 ключевых сервисов банка, а также расскажет о сложностях, с которыми столкнулась его команда во время инцидента. 📅 22 октября, 11:00 МСК 👉 Зарегистрироваться на вебинар #реклама О рекламодателе

RSS vs RPS vs RFS: кто распределяет сетевой трафик между CPU На сервере 32 ядра, но при высокой сетевой нагрузке несколько ядер забиты под 100%, а остальные почти простаивают. Проблема может быть в том, как входящие пакеты распределяются между CPU. В Linux для этого есть три механизма: RSS, RPS и RFS. ⏺RSS - распределение на уровне сетевой карты NIC вычисляет хеш по заголовкам пакета и выбирает RX-очередь. Каждая очередь обычно обслуживается своим CPU через IRQ/NAPI. Проверяем количество очередей:

ethtool -l eth0

Если у карты одна RX-очередь, аппаратное распределение трафика ограничено. ⏺RPS - распределение средствами ядра Receive Packet Steering позволяет перенаправлять обработку пакетов на другие CPU уже после приёма через RX-очередь. Смотрим маску разрешённых CPU:

cat /sys/class/net/eth0/queues/rx-0/rps_cpus

RPS полезен, когда аппаратных RX-очередей мало, но добавляет межъядерную обработку. ⏺RFS - распределение с учётом приложения Receive Flow Steering идёт дальше. Он старается обрабатывать пакеты потока на том CPU, где выполняется приложение, которое их читает. Это помогает уменьшить потери производительности из-за миграции данных между CPU-кешами. Проверяем настройку:

cat /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

⚡️RSS выбирает аппаратную RX-очередь, RPS распределяет обработку по CPU, а RFS учитывает расположение приложения. Но больше распределения не всегда означает выше производительность. На многоканальных NIC дополнительный RPS может только увеличить overhead. N.A

Один VLAN не совпал, и DHCP перестал выдавать адреса Клиент подключается к сети, линк поднят, но IP-адрес не получает. DHCP-сервер работает, свободные адреса есть, а Discover до него не доходит. Проблема может быть в одном неверном PVID или настройке tagged/untagged на порту коммутатора. ⏺Где теряется DHCP Discover Клиент отправляет DHCP Discover широковещательно, обычно без VLAN-тега. Коммутатор принимает кадр и относит его к VLAN, заданному через PVID. Если вместо VLAN 20 на порту стоит VLAN 10, Discover попадёт не в тот широковещательный домен. DHCP-сервер в VLAN 20 его просто не увидит. ⏺Проверяем VLAN на порту На Linux bridge с включённой VLAN-фильтрацией:

bridge vlan show

Например:

eth1  10 PVID Egress Untagged
eth2  20

Здесь нетегированные кадры с eth1 попадут в VLAN 10, а не в VLAN 20. Если клиент должен находиться в VLAN 20, проверяем и исправляем конфигурацию порта. ⏺Ищем Discover

tcpdump -eni eth1 'udp port 67 or 68'

Ключ -e показывает Ethernet-заголовок. На trunk-порту можно дополнительно проверить, с каким VLAN-тегом проходит DHCP-трафик. Если Discover виден на клиентском порту, но отсутствует в нужном VLAN на uplink, проблема может быть в PVID, VLAN membership или правилах тегирования. ⚡️DHCP Discover не знает, в какой VLAN ему нужно попасть. Для нетегированного кадра это решает коммутатор. Один неверный PVID может отправить весь DHCP-трафик в чужую сеть. N.A

ARP Flux: почему Linux отвечает не с того интерфейса На сервере два интерфейса в одной подсети. У каждого свой IP, но при ARP-запросе к 192.168.1.10 сосед неожиданно получает MAC второго интерфейса. Это ARP Flux. Linux по умолчанию рассматривает IP-адреса как принадлежащие всему хосту, а не строго конкретному интерфейсу. ⏺Как это происходит Допустим, eth0 имеет адрес 192.168.1.10, а eth1 - 192.168.1.20. Сосед спрашивает, кому принадлежит 192.168.1.10. Запрос приходит на eth1, и Linux может ответить MAC-адресом eth1, хотя нужный IP назначен на eth0. В результате ARP-таблица соседа может неожиданно меняться, а трафик начинает приходить не на тот интерфейс. ⏺Проверяем настройки

sysctl net.ipv4.conf.all.arp_ignore
sysctl net.ipv4.conf.all.arp_announce

При arp_ignore=0 Linux может отвечать на ARP-запросы за локальные IP независимо от интерфейса, на который пришёл запрос. ⏺Ограничиваем ARP-ответы

sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2

arp_ignore=1 разрешает отвечать только за адреса, назначенные входящему интерфейсу. arp_announce=2 помогает избежать объявления неподходящего исходного IP в исходящих ARP-запросах. N.A

BGP Zombie Routes: маршруты, которые не хотят исчезать

BGP withdrawal сообщает соседям, что маршрут больше недоступен. Но это не значит, что он сразу исчезнет из всех таблиц маршрутизации.

Cloudflare исследовала случаи, когда отозванные маршруты продолжали существовать в других сетях. Их называют BGP Zombies. ⏺Допустим, префикс 203.0.113.0/24 доступен через провайдера A. Провайдер отзывает маршрут, но часть AS ещё использует старую информацию. Начинается path hunting. Маршрутизаторы перебирают альтернативные BGP-пути, некоторые из которых тоже уже недоступны. Из-за этого сходимость затягивается, а трафик может уходить в blackhole или петлю. Проверяем маршруты на своём роутере:

show bgp ipv4 unicast 203.0.113.0/24
show ip route 203.0.113.0

Первая команда показывает известные BGP-пути, вторая - какой маршрут установлен в RIB. Но локальной таблицы мало. Через RIPE RIS или RouteViews можно посмотреть, продолжают ли другие AS видеть старый путь. При плановой смене провайдера лучше сначала анонсировать префикс через нового, дождаться распространения маршрута и только потом отзывать старый. Withdrawal означает, что маршрут отозван. Но не гарантирует, что весь интернет уже перестал его использовать. N.A

Пока одни облака лежат, другие работают. Бизнесу нужен сайт без простоев и быстрые серверы без перерывов на обед. Клиенты должны пользоваться продуктом даже ночью. В DLine Media ставка на доступность и стабильность: — VPS/VDS от 210 ₽ в месяц; — выделенные серверы от 3 930 ₽ в месяц; — colocation для вашего оборудования; — скидки до 30%; — собственный ЦОД. DLine Media — инфраструктура без переплаты. 👉 Забронировать ресурсы

Почему jumbo frames включили, а производительность не выросла Jumbo frames это MTU 9000 вместо стандартных 1500. Меньше заголовков на байт данных, меньше прерываний CPU. В теории быстрее, на практике часто никакого эффекта. ⏺Самая частая причина: один интерфейс или коммутатор на пути со стандартным MTU. Пакеты фрагментируются или дропаются, выигрыша нет. Jumbo frames работают только если все устройства end-to-end настроены одинаково. Проверяем что путь реально поддерживает 9000:

ping -M do -s 8972 <IP>

8972 это 9000 минус 28 байт заголовков. Если пакет прошёл, путь чистый. ⏺Вторая причина: приложение шлёт маленькими чанками. Jumbo frames помогают только когда есть что класть в большой пакет. Мелкие запросы останутся мелкими пакетами независимо от MTU. ⏺Третья: узкое место вообще не в сетевом стеке. Jumbo frames снижают CPU overhead от обработки пакетов, но если bottleneck в диске или логике приложения, результата не будет.

mpstat -I ALL 1
ethtool -S eth0 | grep rx_packets

⚡️Реально помогает в узких сценариях: iSCSI, NFS, HPC, высоконагруженные линки между серверами в одном датацентре. В смешанном трафике через разные устройства эффект минимальный. N.A

Такое не прощают N.A.

👀Ты давно мечтал обучиться этичному хакингу? ⚠️Мы нашли для тебя ЛУЧШЕЕ ПРЕДЛОЖЕНИЕ на рынке 🌐Это бот, в котором собраны ТЫСЯЧИ ВИДЕОКУРСОВ 💎И полный роадмап, который проведет тебя с нуля до профессионала в этичном хакинге 🔴Это не очередной дорогой мусор по типу skillbox, skillfactory и прочего мусора 💎В боте есть мини апп, в котором ты сможешь учиться, следить за своим прогрессом и попрактиковаться, приэтом все это стоит всего лишь жалкие 8$ - это лучшая инвестиция в твое образование ➡️Запускай @TorbaCS_bot и начинай учиться OSINT'у, пентесту и кибербезопасности! ‼️Также подпишитесь на канал создателя, там тоже много полезной инфы по этой теме