Серверная Админа | Компьютерные сети
Я действующий сетевой инженер, расскажу вам о сетях в доступной форме. Реклама - @bashmak_media Мы на бирже: https://telega.in/c/school_network РКН: https://vk.cc/cHYqt5
Show more📈 Analytical overview of Telegram channel Серверная Админа | Компьютерные сети
Channel Серверная Админа | Компьютерные сети (@school_network) in the Russian language segment is an active participant. Currently, the community unites 26 681 subscribers, ranking 4 971 in the Technologies & Applications category and 24 500 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 26 681 subscribers.
According to the latest data from 26 July, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 12 over the last 30 days and by 7 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 10.66%. Within the first 24 hours after publication, content typically collects 5.08% reactions from the total number of subscribers.
- Post reach: On average, each post receives 2 843 views. Within the first day, a publication typically gains 1 355 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 10.
- Thematic interests: Content is focused on key topics such as tcp, протокол, src, интерфейс, mpls.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Я действующий сетевой инженер, расскажу вам о сетях в доступной форме.
Реклама - @bashmak_media
Мы на бирже: https://telega.in/c/school_network
РКН: https://vk.cc/cHYqt5”
Thanks to the high frequency of updates (latest data received on 27 July, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
Привет, сетевой друг!
Сегодня разберём 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 | #протокол
• работу с Linux и командной строкой • Git и контроль версий в реальных проектах • создание Docker-образов и запуск контейнеров • автоматизацию сборки, тестирования и деплоя в GitLab CI/CD • развёртывание и управление приложениями в Kubernetes • сети, хранилища, конфигурации и секреты • диагностику инфраструктуры и автоматизацию рутинных задач ... и многое другоеВсе знания закрепляются на практике с помощью заданий с автопроверкой. Материал подаётся последовательно и понятным языком: с примерами, схемами и демонстрациями. Во время обучения можно задавать вопросы по урокам и заданиям, получать обратную связь и помощь при возникновении сложностей. После прохождения программы вы получите сертификат, который можно добавить в резюме. Скидка 20% на 48 часов: по промокоду
INFOSEC стоимость всей программы составит 10 392 ₽.
Открыть программу на StepikПривет, сетевой друг!
Расскажу о 3 фишках Mikrotik которые реально не все знают.
🟣User Manager - встроенный RADIUS прямо на роутере: не нужен отдельный FreeRADIUS-сервер для небольшой сети. User Manager поднимается прямо на Mikrotik и раздаёт аутентификацию для HotSpot, WiFi по 802.1X и PPP:
/user-manager/router/add name=self address=127.0.0.1 \
shared-secret=radiussecret
/user-manager/user/add name=john password=pass123 \
shared-users=1
/radius/add service=hotspot,wireless address=127.0.0.1 \
secret=radiussecret
/ip/hotspot/set [find] use-radius=yes
Все учётки хранятся локально, работает без интернета, лимиты по трафику и времени настраиваются прямо в User Manager через веб-интерфейс.
🟣IPSec IKEv2 с EAP без L2TP - современный способ поднять мобильный доступ. L2TP добавляет накладные расходы и лишний слой, IKEv2 с EAP-MSCHAPv2 подключается нативно из Windows, iOS, Android без сторонних клиентов:
/ip/ipsec/profile/add name=ike2 dh-group=ecp256 \
enc-algorithm=aes-256 hash-algorithm=sha256
/ip/ipsec/policy/group/add name=eap-clients
/ip/ipsec/peer/add name=eap-mobile exchange-mode=ike2 \
passive=yes send-initial-contact=no
/ip/ipsec/identity/add peer=eap-mobile auth-method=eap \
eap-methods=eap-mschapv2 username=vpnuser password=pass \
generate-policy=port-strict policy-group=eap-clients
Клиент подключается используя только логин и пароль - никаких сертификатов для конечных пользователей, никаких сторонних клиентов.
🟣EoIP туннель для L2-связности между площадками: когда нужно растянуть один broadcast-домен между двумя Mikrotik через интернет без сложностей VXLAN. EoIP работает поверх обычного IP, создаёт виртуальный Ethernet-интерфейс и прозрачно передаёт L2-фреймы:
# На первом роутере
/interface/eoip/add name=eoip-tunnel1 \
remote-address=2.2.2.2 tunnel-id=1
/interface/bridge/add name=br-lan
/interface/bridge/port/add interface=ether3 bridge=br-lan
/interface/bridge/port/add interface=eoip-tunnel1 bridge=br-lan
# На втором роутере зеркально
/interface/eoip/add name=eoip-tunnel1 \
remote-address=1.1.1.1 tunnel-id=1
Устройства в разных офисах оказываются в одном L2-сегменте - ARP-запросы, broadcast и всё остальное ходит прозрачно через туннель. Для шифрования добавляется IPSec поверх EoIP отдельно.
Серверная Админа | Бункер Хакера | #MikrotikПривет, сетевой друг!
Firewall и IDS/IPS - оба анализируют трафик и оба про безопасность, но принимают решения на основе разной логики. Разберём в чём разница.
🟣Firewall - фильтрует трафик по правилам которые описывают структуру соединения: IP-адреса, порты, протоколы, состояние сессии (stateful). Он не смотрит что внутри пакета с точки зрения содержимого - задача файрвола ответить на вопрос “разрешено ли этому источнику обращаться к этому назначению по этому порту”. Если правило разрешает трафик на 443 порт - файрвол пропустит любой TCP-пакет туда, даже если внутри реальная атака, потому что для него это выглядит как легитимное HTTPS-соединение.
🟣IDS/IPS (Intrusion Detection/Prevention System) - анализирует содержимое трафика на предмет сигнатур атак, аномального поведения и известных паттернов эксплуатации. IDS работает в пассивном режиме - видит копию трафика через SPAN-порт, обнаруживает угрозу и просто сигнализирует. IPS работает inline - стоит прямо в разрыве канала и может заблокировать пакет в реальном времени до того как он дойдёт до цели.
🟣Ключевое различие: Firewall решает “кому вообще можно сюда стучаться” на уровне структуры соединения, IDS/IPS решает “что происходит внутри разрешённого соединения” на уровне содержимого и поведения. Файрвол пропустит SQL-инъекцию на 443 порт потому что порт открыт легитимно - IPS увидит саму инъекцию в теле HTTP-запроса и заблокирует именно её, не трогая остальной трафик на этом порту.
🟣На деле они работают слоями: файрвол на периметре режет всё что явно не должно проходить по портам и адресам, IPS дальше разбирает то что файрвол пропустил и ищет уже конкретные признаки атаки внутри разрешённого трафика. Убрать любой слой - и защита становится однобокой: без файрвола IPS захлебнётся анализируя весь трафик подряд включая заведомо неразрешённый, без IPS файрвол пропустит любую атаку которая маскируется под легитимный протокол на открытом порту.
Серверная Админа | Zeroday | #firewall #idsПривет, сетевой друг!
Сегодня разберём vps-audit, небольшой Bash-скрипт, который делает из обычного VPS - объект для быстрого security-аудита.
🟣Что это: часто после установки сервера проверяют только “работает ли SSH и сайт”. Но в реальности на VPS могут остаться открытые порты, включённый root login, слабые настройки SSH, лишние сервисы или переполненный диск. vps-audit собирает всё это в один отчёт без установки тяжёлых инструментов.
🟣Как работает: внутри это обычный Bash-скрипт, который последовательно проверяет системные параметры через стандартные Linux-команды.
Например:
• SSH-конфигурацию (sshd_config)
• состояние firewall (UFW)
• Fail2ban
• последние неудачные входы
• обновления системы
• запущенные сервисы через systemd
• открытые порты
• SUID-файлы
• нагрузку CPU, RAM и диска
После проверки каждому пункту присваивается статус:
⏺PASS - всё нормально
⏺WARN — стоит проверить
⏺FAIL — потенциальная проблема
🟣Установка:
wget https://raw.githubusercontent.com/vernu/vps-audit/main/vps-audit.sh
chmod +x vps-audit.sh
Запуск:
sudo ./vps-audit.sh
🟣Примеры проверок:
Проверка SSH:
[PASS] SSH Root Login - disabled [WARN] SSH Port - using default port 22Проверка открытых портов:
ss -tulpnСкрипт анализирует, какие сервисы слушают сеть, и показывает потенциально лишние точки входа. 🟣Что ещё полезно смотреть вручную после отчёта: Активные сервисы:
systemctl list-units --type=service --state=running
SUID-файлы:
find / -perm -4000 -type f 2>/dev/null
Последние попытки входа:
lastbСерверная Админа | Zeroday | #Инструмент
Привет, сетевой друг!
Продолжаем разбираться с API. В прошлый раз говорили, что это способ общения программ. Сегодня расскажу, как происходит этот "разговор" на практике.
🟣Из чего состоит запрос: почти любой API использует четыре вещи: адрес (URL), метод, заголовки и, при необходимости, тело запроса.
Например:
curl -X GET https://router/api/interfaces \
-H "Authorization: Bearer TOKEN"
Здесь GET - метод, /api/interfaces - нужный ресурс, а токен в заголовке подтверждает, что у нас есть право получить информацию.
🟣Что приходит в ответ: чаще всего - JSON. Его легко читать человеку и ещё проще обрабатывать программами.
{
"name": "Gi0/1",
"admin_state": "up",
"oper_state": "up",
"speed": "1G"
}
После этого Python, Ansible или даже Bash могут сразу использовать эти данные без парсинга CLI.
🟣Коды ответа тоже важны:
200 — всё успешно 201 — объект создан 400 — ошибка в запросе 401 — нет авторизации 403 — доступ запрещён 404 — объект не найден 500 — проблема на стороне сервераПо одному статус-коду часто уже можно понять, где искать проблему. 🟣Полезные команды:
# Красиво вывести JSON
curl https://device/api/interfaces | jq
# Посмотреть только HTTP-заголовки
curl -I https://device/api
# Посмотреть полный обмен
curl -v https://device/api
Последняя команда особенно полезна при отладке - видно, какие заголовки отправились, какой код вернул сервер и не возникло ли проблем с TLS.
Серверная Админа | Zeroday | #APIПривет, сетевой друг!
Сегодня расскажу про протокол UDLD, который ловит одну из самых противных неисправностей в Ethernet: когда линк вроде бы живой, а трафик идёт только в одну сторону.
🟣Что это: бывает, что одно волокно в оптической паре повредилось. Один коммутатор продолжает видеть соседа, интерфейс горит зелёным, а вот ответы обратно уже не приходят. Для Ethernet всё выглядит нормально - порт up/up, хотя связь фактически сломана.
🟣Как это работает: устройства регулярно обмениваются UDLD-пакетами, в которых сообщают, кто они и через какой порт подключены. Если коммутатор перестал получать такие пакеты от соседа, но физический линк всё ещё поднят, он понимает: это не обычный обрыв, а однонаправленная связь.
🟣Почему это опасно: в такой ситуации могут начать странно работать STP, EtherChannel и даже обычная коммутация. Где-то появится blackhole, где-то зависнет агрегированный канал, а поиск причины легко может затянуться на часы - ведь интерфейс продолжает выглядеть полностью рабочим.
🟣Базовая настройка (Cisco):
udld enable interface TenGigabitEthernet1/0/1 udld portЕсли нужен более жёсткий контроль:
udld aggressive
В этом режиме устройство несколько раз пытается восстановить обмен, а если ничего не меняется - автоматически переводит порт в err-disabled, чтобы неисправный линк не успел натворить проблем.
🟣Что посмотреть при диагностике:
show udld show udld interface show interfaces status err-disabledЕсли порт отключился именно по UDLD, первым делом стоит проверить SFP-модули, патч-корды и оптические волокна. Очень часто проблема оказывается не в настройках сети, а в физике. Серверная Админа | Zeroday | #Network
Привет, сетевой друг!
Сегодня разберём ещё 5 полезных фишек для Cisco IOS, которые реально экономят время и нервы.
🟣TCP Fast Open (TFO) - отправляем данные уже во время SYN, не дожидаясь завершения трёхстороннего рукопожатия:
sysctl -w net.ipv4.tcp_fastopen=3
sysctl net.ipv4.tcp_fastopen
Клиент может передать первые данные ещё на этапе установки соединения, сокращая задержку на один RTT. Особенно полезно для часто повторяющихся коротких подключений.
🟣TCP MTU Probing - автоматически подбираем рабочий MTU, если ICMP режется где-то по пути:
sysctl -w net.ipv4.tcp_mtu_probing=1
sysctl -w net.ipv4.tcp_base_mss=1024
Помогает при PMTU Black Hole, когда пакеты теряются из-за слишком большого MTU, а ICMP Fragmentation Needed не проходит.
🟣BBR вместо CUBIC - меняем алгоритм контроля перегрузки:
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
BBR оценивает пропускную способность и RTT, а не реагирует только на потери. На каналах с высокой задержкой часто даёт более стабильную скорость.
🟣TCP SYN Cookies - защита от переполнения очереди SYN:
sysctl -w net.ipv4.tcp_syncookies=1
sysctl net.ipv4.tcp_syncookies
При SYN Flood ядро перестаёт хранить состояние для полуоткрытых соединений и кодирует его прямо в SYN-ACK, сохраняя работоспособность сервиса.
🟣Просмотр TCP-сокетов через ss - получаем гораздо больше информации, чем через netstat:
ss -ti
ss -o state established
Можно увидеть congestion control, RTT, congestion window, retransmits, таймеры и другие параметры конкретного соединения - очень полезно при разборе проблем с производительностью.
Серверная Админа | Zeroday | #CiscoПривет, сетевой друг!
Сегодня про инструмент bgscan. Это быстрый многопротокольный сканер, который умеет строить целые цепочки проверок: например, ICMP → TCP → HTTP.
🟣Зачем он: обычно сначала пингуют сеть, потом отдельно сканируют порты, затем вручную проверяют веб-сервисы. bgscan позволяет собрать всё это в один pipeline, чтобы на следующий этап попадали только хосты, прошедшие предыдущий.
🟣Как работает: каждый протокол - отдельный модуль. Сначала можно найти живые узлы по ICMP, затем проверить открытые TCP-порты и только после этого отправить HTTP/HTTPS-запросы. Есть три режима работы: Streaming (результаты сразу передаются дальше), Sequential (этап за этапом) и Batch (пакетами).
🟣Установка:
curl -fsSL https://raw.githubusercontent.com/MohsenBg/bgscan/refs/heads/main/scripts/install.sh | bash
или собрать из исходников:
git clone https://github.com/MohsenBg/bgscan.git
cd bgscan
go run ./cmd/bgscan/
🟣Что умеет:
ICMP — поиск живых хостов TCP — проверка портов HTTP/1-3 — тест веб-сервисов TLS — анализ TLS DNS — проверка резолверов Xray — валидация прокси
🟣Чем крут: после каждого этапа результаты автоматически сохраняются в CSV и могут стать входными данными для следующего запуска. Например, сначала просканировали миллион адресов по ICMP, затем взяли только ответившие и проверили TCP, а потом - только узлы с открытым 443-м портом на поддержку HTTP/3 или TLS.
🟣Приятная мелочь: вместо десятков параметров в командной строке здесь полноценный терминальный интерфейс на BubbleTea - запуск сканирования, просмотр прогресса, управление результатами и настройками выполняются прямо из TUI, без браузера и веб-панелей.
Серверная Админа | Zeroday | #Инструмент