Network Admin

MikroTik: NAT Hairpin

    
        Сделать так, чтобы устройства внутри локальной сети могли обращаться к публичному IP ресурса (например, веб-серверу) так же, как внешние клиенты. {}
    

Нужно это, если сервер находится внутри LAN, но пользователи подключаются через внешний IP. 🧑‍💻Без hairpin NAT пакеты, отправленные на внешний IP внутри сети, не вернутся обратно, и соединение не будет установлено. Hairpin NAT решает эту проблему и позволяет маршрутизатору «заворачивать» трафик обратно внутрь сети. Настройка на MikroTik:

    
        /ip firewall nat add chain=srcnat \
    src-address=192.168.88.0/24 \
    dst-address=192.168.88.10 \
    action=masquerade{}
    

⏺src-address — сеть клиентов, которым нужен hairpin. ⏺dst-address — внутренний IP сервера. ⏺action=masquerade — «заворачивает» пакет так, чтобы сервер правильно ответил. И проверим: С клиента внутри LAN:

    
        ping <внешний_IP_сервера>{}
    

Проверить активные соединения:

    
        /ip firewall connection print where dst-address=192.168.88.10{}
    

Если всё настроено верно, клиенты смогут обращаться к ресурсу через внешний IP так же, как будто они снаружи сети. N.A.

Выбрать процессор для сервера баз данных и не промахнуться с производительностью, лицензией, бюджетом сложно, но исполнимо. Эти 3 вещи сделают выбор предсказуемым и выгодным... Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFGgLvtx

SNMPv3 - безопасный мониторинг сети

    
        SNMPv3 — это апгрейд старых SNMPv1/v2c. {}
    

Главная цель, конечно, безопасно собирать метрики с коммутаторов, роутеров и серверов без риска, что пароли или данные попадут в сеть. В отличие от SNMPv2c, SNMPv3 поддерживает аутентификацию и шифрование, а права доступа настраиваются детально по объектам. ⏺На практике это значит: можно спокойно опрашивать устройства через SNMP, не боясь, что кто-то подслушает трафик. Простейшая настройка на Cisco:

    
        snmp-server view MyView iso included
snmp-server group SNMPv3Group v3 auth read MyView
snmp-server user snmpuser SNMPv3Group v3 auth sha MyAuthPass priv aes 128 MyPrivPass{}
    

Проверяем:

    
        show snmp user
show snmp group{}
    

N.A.

Настроим BPDU Guard для защиты от петель В сетях с активным STP (Spanning Tree Protocol) важно защитить порты, где подключены только хосты, от случайного подключения коммутаторов или появления петель. ⭐️Если на таком порту появятся BPDUs, это может привести к нарушению топологии и отключению сегмента сети. BPDU Guard — функция Cisco, которая сразу же блокирует порт при получении BPDU, тем самым предотвращая возникновение петли. ✅Когда используем: ⏺Access-порты, где подключены только ПК, принтеры, камеры и другие конечные устройства. ⏺В сетях с PortFast для ускоренного включения порта. Настройка на интерфейсе:

    
        interface Gi1/0/10
 switchport mode access
 spanning-tree portfast
 spanning-tree bpduguard enable{}
    

👮‍♂️Проверим работу:

    
        show spanning-tree interface Gi1/0/10{}
    

Если порт получит BPDU, он автоматически перейдёт в состояние err-disable, а в логах появится сообщение о нарушении BPDU Guard. Восстановление порта после срабатывания BPDU Guard:

    
        shutdown
no shutdown{}
    

или автоматическое восстановление через errdisable recovery. N.A.

🦠🖥 Вредоносное ПО в Linux Штатные утилиты для обнаружения и обезвреживания вредоносов. 💬 Процессы и автозапуск ps / pgrep / top / htop — ищем «левые» процессы, аномальный расход CPU/RAM. systemctl / service — неизвестные юниты/демоны в автозапуске. 💬 Сеть и соединения ss / netstat — кто слушает порты и куда установлены сессии. lsof — какие процессы держат файлы/сокеты, в т.ч. «удалённые» бинарники. 💬 Файлы, изменения и права grep — быстрый поиск характерных паттернов. lsattr / chattr — проверка «immutable»-атрибута. 💬 Логи и следы взлома last / lastb / w — логины и неудачные попытки. 💬 Учётные записи и ключи /etc/passwd — двойные UID 0, «левые» системные пользователи. authorized_keys — подмена ключей. Шаги реагирования и примеры использования читайте здесь. Еще больше полезных инструментов и лайфхаков в канале CORTEL. ➡️ Подписаться Реклама ООО "Кортэл" ИНН: 7816246925

Подсчёт уникальных MAC на порту для диагностики L2 В крупных сетях иногда важно быстро понять, сколько разных устройств «сидят» на порту коммутатора или виртуальном интерфейсе.

    
        Это помогает выявлять ARP‑спуфинг, дубликаты MAC или неожиданные источники трафика.{}
    

⏺На Linux или Cisco можно собрать статистику и сразу понять, есть ли перегрузка или подозрительные активности. Каждый Ethernet‑кадр несёт MAC-адрес источника. Коммутатор или Linux-bridge хранит таблицу MAC → порт (FDB, Forwarding Database). Если на порту появляется слишком много MAC: • Это может быть законная виртуализация (VMs через vSwitch, Docker, Kubernetes). • Это может быть rogue device или концентратор. • ARP-флуд или атака типа MAC-flooding. Счёт уникальных MAC помогает быстро отделить нормальные сценарии от потенциальных проблем. Linux — bridge / veth Проверка всех портов:

    
        bridge fdb show | awk '{print $3}' | sort | uniq -c | sort -nr{}
    

Узнать число MAC на конкретном порту (например eth2):

    
        bridge fdb show | awk '$3=="eth2"{print $1}' | sort | uniq | wc -l{}
    

Скрипт‑алерт для порта с >10 MAC:

    
        THRESH=10
bridge fdb show | awk '{print $3}' | sort | uniq -c | while read cnt port; do
  if [ "$cnt" -gt "$THRESH" ]; then
    echo "ALERT: $port has $cnt MACs"
  fi
done{}
    

Cisco Вывести MAC-адреса для порта:

    
        show mac address-table interface Gi1/0/1{}
    

Подсчёт строк (MAC):

    
        show mac address-table interface Gi1/0/1 | include - | wc -l{}
    

N.A.

😊ПРИВЕТ, КОЛЛЕГИ! Знакомьтесь — «В моём VLAN’е тихо!» Это не просто канал, это мой путь становления сетевым инженером. Здесь я делюсь всем, что узнаю, пробую и тестирую в мире Cisco и сетевых технологий.😍😍 Что вы найдёте в канале? - Подробные инструкции по настройке оборудования Cisco - Пошаговые руководства с реальными примерами - Разбор ошибок и их решений - Полезные команды и конфигурации - Опыт работы с реальным оборудованием Почему стоит подписаться? - Честный подход. Я открыто делюсь своим опытом. - Практические знания. - Доступность. Объясняю сложные вещи простым языком. - Регулярные обновления. Новые материалы каждую неделю. Мой путь: - Собственная лаборатория с реальным оборудованием Cisco - Активное обучение и практика - Создание подробных руководств - Обмен опытом с коллегами Присоединяйтесь к каналу! Вместе мы сможем создать активное сообщество, где каждый сможет делиться опытом и помогать друг другу. 👉 Подписывайтесь: @inMyVlan

Проверяем реальный UDP throughput и jitter Когда запускаешь VoIP или стриминг, важно не только знать скорость канала, но и понять, как стабильно он работает. UDP не подтверждает доставку пакетов, поэтому packet loss и jitter сразу отражаются на качестве звонка или видео. ⏺Throughput показывает, сколько реально проходит данных между хостами, а ⏺jitter — насколько разняются задержки между пакетами. Для проверки используем iperf3. На сервере запускаем:

    
        iperf3 -s{}
    

На клиенте тестируем максимальную пропускную способность:

    
        iperf3 -c <IP_сервера> -u -b 0{}
    

-u активирует UDP, -b 0 снимает ограничение пропускной способности. Можно задать фиксированную нагрузку, например 1 Мбит/с:

    
        iperf3 -c <IP_сервера> -u -b 1M -t 30{}
    

В отчёте увидим реальный throughput, packet loss и jitter, что сразу показывает, насколько канал пригоден для реальных задач. N.A.

Как проследить путь пакетов на L2 (MAC-level) Отслеживание пути пакетов на L2 полезно, когда проблемы не видны на уровне IP, например, при «пропавшем» трафике между коммутаторами или подозрении на неправильную VLAN-конфигурацию. Для этого удобно использовать arping и tcpdump. Простейший способ — отправить ARP-запрос и посмотреть, кто отвечает:

    
        arping -I eth0 -f 192.168.1.10{}
    

Флаг -f запускает «flood mode», т.е. пакет посылается сразу несколько раз, что позволяет увидеть ответы и задержки. Одновременно можно слушать кадры на интерфейсе с выводом MAC-адресов:

    
        tcpdump -i eth0 -e arp{}
    

Опция -e показывает L2-заголовки, включая source и destination MAC. Так можно отследить, через какие устройства проходит пакет. N.A.

Как проверить ARP-флуд на L2

    
        Проверка ARP-флуда на L2 - важный этап для диагностики проблем с сетью, особенно когда клиенты теряют связь или наблюдаются странные задержки. {}
    

ARP-флуд — это ситуация, когда одно устройство слишком часто рассылает ARP-запросы, перегружая коммутаторы и приводя к повышенной нагрузке на CPU. Для проверки можно использовать стандартные инструменты Linux. Сначала смотрим текущие ARP-записи и счётчики:

    
        ip -s neigh{}
    

Эта команда покажет, сколько раз Linux отправлял ARP-запросы к каждому IP и получил ли ответы. Если видите один и тот же MAC с большим количеством запросов за короткий период — это повод насторожиться. Можно дополнительно тестировать конкретный IP:

    
        arping -c 10 192.168.1.50{}
    

Команда отправит 10 ARP-запросов и покажет ответы. ⏺Если один MAC отвечает слишком часто или появляются неожиданные ответы от разных MAC на один IP, это признак ARP-флуда или конфликта IP. Для постоянного мониторинга можно использовать watch или tcpdump:

    
        watch -n 1 "ip -s neigh"
tcpdump -i eth0 arp{}
    

N.A.