Серверная Админа | Компьютерные сети
Відкрити в Telegram
Я действующий сетевой инженер, расскажу вам о сетях в доступной форме. Реклама - @bashmak_media Мы на бирже: https://telega.in/c/school_network РКН: https://vk.cc/cHYqt5
Показати більше
Сітка:📈 Аналітичний огляд Telegram-каналу Серверная Админа | Компьютерные сети
Канал Серверная Админа | Компьютерные сети (@school_network) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 26 540 підписників, посідаючи 4 858 місце в категорії Технології та додатки та 24 051 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 26 540 підписників.
За останніми даними від 07 жовтня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -129, а за останні 24 години на -7, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 10.30%. Протягом перших 24 годин після публікації контент зазвичай збирає 4.57% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 2 734 переглядів. Протягом першої доби публікація в середньому набирає 1 212 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 12.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як tcp, протокол, src, интерфейс, mpls.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Я действующий сетевой инженер, расскажу вам о сетях в доступной форме.
Реклама - @bashmak_media
Мы на бирже: https://telega.in/c/school_network
РКН: https://vk.cc/cHYqt5”
Завдяки високій частоті оновлень (останні дані отримано 08 жовтня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
26 540
Підписники
-724 години
-367 днів
-12930 днів
Триває завантаження даних...
Схожі канали
Хмара тегів
Вхідні та вихідні згадування
---
---
---
---
---
---
Залучення підписників
жовтень '26жовт '26
жовтень '26
+9
в 0 каналах
вересень '26
+82
в 17 каналах
Get PRO
серпень '26
+71
в 12 каналах
Get PRO
липень '26
+276
в 27 каналах
Get PRO
червень '26
+94
в 15 каналах
Get PRO
травень '26
+156
в 21 каналах
Get PRO
квітень '26
+86
в 25 каналах
Get PRO
березень '26
+228
в 24 каналах
Get PRO
лютий '26
+323
в 40 каналах
Get PRO
січень '26
+1 172
в 196 каналах
Get PRO
грудень '25
+201
в 15 каналах
Get PRO
листопад '25
+110
в 2 каналах
Get PRO
жовтень '25
+586
в 139 каналах
Get PRO
вересень '25
+50
в 0 каналах
Get PRO
серпень '25
+4 042
в 33 каналах
Get PRO
липень '25
+498
в 164 каналах
Get PRO
червень '25
+107
в 8 каналах
Get PRO
травень '25
+249
в 0 каналах
Get PRO
квітень '25
+2 286
в 163 каналах
Get PRO
березень '25
+1 398
в 158 каналах
Get PRO
лютий '25
+488
в 132 каналах
Get PRO
січень '25
+609
в 36 каналах
Get PRO
грудень '24
+1 048
в 183 каналах
Get PRO
листопад '24
+900
в 48 каналах
Get PRO
жовтень '24
+717
в 75 каналах
Get PRO
вересень '24
+639
в 186 каналах
Get PRO
серпень '24
+371
в 21 каналах
Get PRO
липень '24
+527
в 54 каналах
Get PRO
червень '24
+451
в 6 каналах
Get PRO
травень '24
+1 239
в 36 каналах
Get PRO
квітень '24
+393
в 51 каналах
Get PRO
березень '24
+273
в 6 каналах
Get PRO
лютий '24
+10 908
в 28 каналах
Get PRO
січень '24
+845
в 10 каналах
Get PRO
грудень '23
+805
в 2 каналах
Get PRO
листопад '23
+661
в 11 каналах
Get PRO
жовтень '23
+513
в 8 каналах
Get PRO
вересень '23
+995
в 0 каналах
Get PRO
серпень '23
+1 456
в 0 каналах
Get PRO
липень '23
+977
в 0 каналах
Get PRO
червень '23
+1 325
в 0 каналах
Get PRO
травень '23
+1 155
в 0 каналах
Get PRO
квітень '23
+854
в 0 каналах
Get PRO
березень '23
+1 193
в 0 каналах
Get PRO
лютий '23
+1 763
в 0 каналах
Get PRO
січень '23
+1 785
в 0 каналах
Get PRO
грудень '22
+3 646
в 0 каналах
Get PRO
листопад '22
+248
в 0 каналах
Get PRO
жовтень '22
+255
в 0 каналах
Get PRO
вересень '22
+853
в 0 каналах
Get PRO
серпень '22
+478
в 0 каналах
| Дата | Залучення підписників | Згадування | Канали | |
| 08 жовтня | +1 | |||
| 07 жовтня | 0 | |||
| 06 жовтня | +1 | |||
| 05 жовтня | +1 | |||
| 04 жовтня | +1 | |||
| 03 жовтня | 0 | |||
| 02 жовтня | +1 | |||
| 01 жовтня | +4 |
Дописи каналу
🎇Главная идея DevSecOps: безопасность перестаёт тормозить разработку.
Вместо проверок «после релиза» всё встроено в пайплайн: код проходит SAST, контейнеры сканируются, инфраструктура проверяется на комплайенс. В итоге релизы выходят быстрее и при этом безопаснее.
Этому и учит курс DevSecOps от Академии Codeby на практике:
⏺️9 модулей, 48 занятий, 90% практики
⏺️Стек: Docker, Kubernetes, Terraform, Vault, Ansible, Prometheus
⏺️Финальный экзамен в стиле OSCP — только реальные задачи
⏺️Авторы — практики: внедрение Zero Trust, построение SOC, разработка DevSec-инструментов под Burp Suite
Инженеры, которые умеют встраивать безопасность в CI/CD, сегодня в дефиците на стыке ИБ и DevOps — компании поняли, что «сначала сделать, потом чинить» обходится дороже.
👉 Успейте записаться на текущий поток до 15 октября
➡️️️Программа и регистрация
Бесплатная консультация — @CodebyAcademyBot
| 2 |  👋 Привет, сетевой друг!
Сегодня разберём recursive routing на MikroTik - настроим переключение между двумя провайдерами так, чтобы роутер проверял не только шлюз, но и доступность интернета за ним.
🟣Сценарий: основной WAN работает через 192.168.1.1, резервный - через 192.168.2.1.
Если проверять только gateway:
check-gateway=ping
роутер увидит 192.168.1.1 и решит, что маршрут исправен. Даже если у самого провайдера дальше уже ничего не работает.
Поэтому проверять будем внешний адрес, например 1.1.1.1.
🟣Сначала создаём маршрут до контрольного IP через основного провайдера:
/ip route
add dst-address=1.1.1.1/32 gateway=192.168.1.1 scope=10
Теперь 1.1.1.1 доступен только через первый WAN.
Создаём default route, но в качестве gateway указываем уже контрольный адрес:
/ip route
add dst-address=0.0.0.0/0 gateway=1.1.1.1 \
distance=1 check-gateway=ping target-scope=11
RouterOS сначала рекурсивно ищет, как добраться до 1.1.1.1, и находит маршрут через 192.168.1.1.
🟣Для резервного WAN делаем то же самое с другим контрольным адресом:
/ip route
add dst-address=8.8.8.8/32 gateway=192.168.2.1 scope=10
add dst-address=0.0.0.0/0 gateway=8.8.8.8 \
distance=2 check-gateway=ping target-scope=11
distance=2 делает этот маршрут резервным.
Пока 1.1.1.1 отвечает через первого провайдера, используется основной WAN. Если проверка перестаёт проходить, маршрут становится неактивным и RouterOS выбирает второй default route.
🟣Посмотреть, какой маршрут сейчас активен:
/ip route print detail where dst-address=0.0.0.0/0
Получается такая схема:
1.1.1.1 → WAN1 → distance 1
8.8.8.8 → WAN2 → distance 2
↓
default route
🟣Можно пойти ещё дальше и не завязывать состояние WAN на один контрольный IP. Для каждого провайдера создают несколько probe-маршрутов, например до 1.1.1.1 и 8.8.8.8, чтобы отказ одного публичного адреса сам по себе не переключал весь канал.
Серверная Админа | Zeroday | #Mikrotik | 764 |
| 3 |  🗂 Пакет Безопасности — папка, которую админ собирал более 10 лет
⚡️ Слитые курсы по IT и ИБ
⚡️ Сервисы и тулзы для приватности
⚡️ Инструкции и шпаргалки
⚡️ Редкие книги и утилиты
⚡️ Гайды написанные автором
Большинство собирает такую базу годами.
Здесь все отсортировали и разбили в одном канале
ссылка действует 48 часов
📌 Подписывайся: @package_security | 1 459 |
| 4 |  👋 Привет, сетевой друг!
Сегодня про Network Doctor - TUI для диагностики сети, который пытается не просто показать пачку вывода от ping, dig и curl, а найти место, где именно ломается соединение.
🟣Запускаете:
netdoc github.com
И инструмент последовательно проверяет DNS, TCP, TLS и HTTP, связывая результаты между собой. Если DNS не работает, зависимые проверки не запускаются, а итог прямо говорит, что проблема в разрешении имени.
То есть вместо:
ping - не работает
curl - не работает
получаете примерно:
DNS: FAIL
TCP: SKIP
TLS: SKIP
HTTP: SKIP
Diagnosis: target hostname does not resolve
🟣При этом проверки разбиты на независимые ветки. Отдельно проверяются локальный интерфейс и Wi-Fi, выход в интернет, QUIC/UDP 443, DNS, DoH/DoT, proxy и путь до конкретного сервиса.
Можно проверить даже порт:
netdoc github.com:22
Тогда вместо HTTP-проверок появится SSH banner check.
🟣Интересная часть - Path MTU. Network Doctor умеет искать проблемы с MTU без root-доступа и обычного ICMP-пинга. Это полезно для случаев, когда соединение вроде бы устанавливается, но определённые пакеты по пути начинают теряться.
🟣Если проблема плавающая, есть Watch Mode:
netdoc --watch host
Он повторяет проверки и сохраняет небольшую историю инцидента: что работало до сбоя, где появилась проблема и когда всё восстановилось.
А для автоматизации есть JSON:
netdoc --json host
и стабильные exit codes, поэтому результат можно использовать уже в скриптах и мониторинге.
🟣Ещё можно сохранить диагностику:
netdoc --save failure.ndoc host
netdoc --support support.ndoc host
А потом сравнить хороший и плохой запуск:
netdoc --compare good.ndoc bad.ndoc
Причём сравнение сохранённых отчётов не требует нового сетевого подключения.
🟣Сам Network Doctor написан на Go и работает на Linux, macOS и Windows. Внутри TUI используется Bubble Tea, а если одной встроенной проверки мало, прямо из интерфейса можно запустить привычные route, ss, ping, DNS, curl, traceroute, mtr или nmap. Получается не очередной «ping с красивым интерфейсом», а попытка разложить сетевую проблему по слоям и сразу связать результат с конкретной причиной.
Серверная Админа | Zeroday | #Инструмент | 1 471 |
| 5 |  Как хаотичные подсети убивают масштабируемость
В статье показывают, как случайные /24, пересекающиеся диапазоны и адресация «как получилось» годами копят проблемы, а потом взрываются при росте или слиянии компаний. Разбирают, почему двойной NAT не спасает, и как нормальная иерархия адресов помогает не превращать расширение сети в многонедельный квест.
Серверная Админа | Zeroday | #Статья | 1 888 |
| 6 | Почему STP блокирует один из избыточных L2-путей? | 2 838 |
| 7 |  👋 Привет, сетевой друг!
Ещё три функции MikroTik, которые легко пропустить, пока не столкнёшься с конкретной задачей.
🟣Connection Tracking Helpers - когда роутер понимает протокол
RouterOS умеет подключать helpers для некоторых протоколов, где одного IP/порта недостаточно, чтобы нормально отслеживать соединения. Например, FTP может открывать дополнительные соединения для передачи данных. Helper анализирует управляющий канал и помогает connection tracking понять, какой трафик относится к этой сессии.
Проверить helpers:
/ip/firewall/service-port/print
А ненужные можно отключить:
/ip/firewall/service-port/set ftp disabled=yes
🟣Torch - посмотреть трафик прямо на интерфейсе: Когда нужно быстро понять, кто и куда ходит, не обязательно сразу запускать Wireshark.
/tool/torch interface=ether1
Можно фильтровать по IP, порту, протоколу и направлению. Например, быстро найти, кто забивает uplink или куда конкретно уходит трафик.
🟣Packet Sniffer умеет отдавать трафик прямо в Wireshark: На MikroTik можно захватить пакеты и открыть их в Wireshark:
/tool/sniffer
set filter-interface=ether1 \
filter-ip-address=10.0.0.10/32 \
file-name=capture.pcap
start
После остановки получаете обычный PCAP:
/tool/sniffer/stop
Это удобно, когда проблема происходит на самом роутере: SYN приходит, ответ уходит, но дальше что-то теряется.
Серверная Админа | Бункер Хакера | #Mikrotik | 2 730 |
| 8 |  Для тех, кто работает с Kubernetes и облачной инфраструктурой, в октябре намечается отличный повод выбраться из рабочих чатов и встретиться офлайн 👀
Обсудим:
– как пройти путь от бизнес-требования к ядру Linux
– как дать агенту управление кластером вашей инфраструктуры
– как в MWS Cloud Platform доставляют системный софт в managed K8s
– мультитенантность в Kubernetes-платформе — «Проект вместо namespace»
– как работает LLM-диагностика инцидентов в Kubernetes и OpenStack
Не обойдётся и без дискуссий: на круглых столах разберём, действительно ли Kubernetes победил и что делать, если из-за ИИ нас всех уволят.
В течение дня вас ждут доклады, общение с коллегами и активности от партнеров. Будет возможность обсудить кейсы, обменяться опытом и познакомиться с коллегами из индустрии. После конференции вас ждет афтепати, где можно будет пообщаться с единомышленниками в более неформальной обстановке.
📍 Москва, 5-й Донской проезд, 17, Connect
📅 22 октября, 10:00–21:00
👉 Программу, билеты и подробности сможете найти на сайте Kuber Conf от АОТ! | 2 333 |
| 9 |  👋 Привет, сетевой друг!
Сегодня про UUCP - протокол и набор утилит, через которые Unix-машины десятилетиями обменивались файлами, почтой и командами задолго до привычного нам интернета.
🟣Название расшифровывается как Unix-to-Unix Copy. Изначально идея была максимально простой: одна машина звонит другой по модему, устанавливает соединение и передаёт задания. Никаких постоянных TCP-соединений. Машины могли вообще не быть одновременно онлайн.
🟣Например, сервер A хотел отправить файл серверу B. UUCP складывал задание в очередь:
A
├── файл
├── адрес получателя
└── команда на обработку
Когда наступало время связи, машина дозванивалась до B, передавала накопившиеся задания и забирала то, что накопилось в обратную сторону.
🟣Из этого выросла довольно интересная схема маршрутизации. Если A не мог напрямую связаться с C, файл можно было отправить через B:
A → B → C
Узлы образовывали цепочки, а сообщения могли проходить через несколько промежуточных машин.
🟣UUCP использовали не только для файлов. Через него пересылали электронную почту, новости Usenet и удалённые команды. Особенно это подходило для дорогих dial-up соединений: связь поднималась только тогда, когда действительно появлялись данные для передачи.
🟣Сегодня идея выглядит архаично, но концепция никуда не делась. Очередь заданий, store-and-forward и передача при появлении связи всё ещё используются там, где постоянное соединение невозможно или слишком дорого. Просто вместо пары Unix-серверов с модемами теперь это могут быть устройства с нестабильным спутниковым каналом, IoT и системы в удалённых местах.
Серверная Админа | #XMODEM | 2 094 |
| 10 |  👋 Привет, сетевой друг!
Давай разберём несколько TCP-флагов и состояний, которые особенно полезны, когда смотришь трафик в Wireshark и пытаешься понять, где именно всё сломалось.
🟣SYN без SYN-ACK
Клиент отправляет
Client → Server SYN
Client → Server SYN
Client → Server SYN
а ответа нет.
Это ещё не значит «сервер лежит». SYN мог потеряться, его мог отбросить файрвол, либо обратный маршрут сломан. Поэтому следующий шаг - смотреть, доходят ли пакеты до сервера и есть ли от него ответ.
🟣SYN-ACK приходит, но клиент отвечает RST: Здесь картина уже интереснее:
Client → Server SYN
Server → Client SYN-ACK
Client → Server RST
Сервер явно ответил, но клиент сразу сбросил соединение. Такое бывает, например, когда клиентский стек уже не ожидает этот ответ или состояние соединения исчезло из-за NAT/stateful firewall.
🟣RST вместо SYN-ACK
Client → Server SYN
Server → Client RST
TCP-порт на той стороне явно отверг попытку соединения. Классический случай - приложение не слушает этот порт.
Но RST может генерироваться и сетевым оборудованием или security-механизмом, поэтому источник пакета тоже стоит проверить.
🟣FIN и RST - совсем разные истории
FIN означает: «я закончил отправлять данные».
RST означает: «эту TCP-сессию прекращаем прямо сейчас».
Например, нормальное закрытие выглядит примерно так:
Client → Server FIN
Server → Client ACK
Server → Client FIN
Client → Server ACK
А RST посреди нормального обмена уже требует посмотреть, что происходило непосредственно перед ним.
🟣ACK с неожиданным номером: TCP подтверждает не отдельные пакеты, а последовательность байтов.
Например:
SEQ=1000 LEN=500
ACK=1500
Если сервер продолжает получать ACK=1000, хотя уже отправил данные дальше, можно увидеть retransmission, duplicate ACK и проблемы с доставкой.
Именно по комбинации SEQ, ACK, SYN, FIN, RST и времени между пакетами часто можно восстановить всю историю TCP-сессии - кто начал соединение, где потерялся пакет и на каком этапе оно развалилось.
Серверная Админа | Zeroday | #Инструмент | 2 043 |
| 11 |  👋 Привет, сетевой друг!
Сегодня про 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 | #Инструмент | 2 061 |
| 12 |  Почему SAML снова и снова ломается на одном и том же месте?
SAML больше 20 лет отвечает за корпоративный SSO, но исследователи до сих пор находят способы обходить его защиту. В статье разбирают, как XML-комментарии, особенности парсеров и канонизация позволяют подменять подписанные данные так, что проверка проходит, а приложение получает уже другое содержимое.
🟣Разбирают пять проблем протокола: сложность XML, канонизацию, вложенные подписи, перегруженную спецификацию и устаревшую архитектуру. Отдельно проходят по XSW, parser differential и round-trip-атакам, а затем сравнивают подход SAML с OIDC и показывают, почему современные системы постепенно уходят от XML в сторону JSON/JWT.
Серверная Админа | Zeroday | #Статья | 2 541 |
| 13 |  👨💻Серверная Админа | #мем | 3 073 |
| 14 |  👋 Привет, сетевой друг!
Сегодня про 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 | 2 906 |
| 15 |  👋 Привет, сетевой друг!
Собрал три способа прокачать защиту 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 | 2 631 |
| 16 |  Когда в ИТ три человека, появляется четвёртая работа — выяснять, кто чем занимается.
— Кто взял заявку бухгалтерии?
— Саша вроде.
— А сервером кто занимается?
— Я думал, ты.
— А в филиал кто-нибудь написал?
— Сейчас спрошу.
И вот вместо работы кто-то в команде постепенно превращается в диспетчера.
Нужно помнить, кому что передали, проверять, взял ли человек задачу, смотреть, кто сейчас свободен, напоминать про зависшие обращения и периодически разруливать классическое «я думал, это делает кто-то другой».
Пока админ один, такой проблемы почти нет. Когда появляется команда и поток обращений растёт — координация сама становится отдельной работой.
В Okdesk эту «диспетчерскую» нагрузку можно снять: заявки распределяются между сотрудниками и командами, назначаются ответственные, задаются приоритеты и сроки, настраивается автоматическая маршрутизация.
❓Вопрос «Саша это делает?» больше не нужен — достаточно открыть платформу и увидеть, кто отвечает за заявку и на каком она этапе.
Хотите увидеть, как это работает на практике?
Приходите на вебинар — разберём на примере «Мобиус Технологии», как разделить потоки между поддержкой, инженерами и экспертами, настроить маршрутизацию под разные типы обращений и масштабировать обслуживание без потери SLA.
👉 Получить бесплатный вебинар можно по ссылке https://lead.okdesk.ru/mnogourovnevyj-servis
Реклама. ООО «Облачные решения». erid: 2VtzqxJ7bjz | 2 628 |
| 17 |  👋 Привет, сетевой друг!
Давай расскажу про протокол 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 | 2 663 |
| 18 |  👋 Привет, сетевой друг!
Давай расскажу про 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 | #Инструмент | 2 883 |
| 19 |  Девопсы, сисадмины, архитекторы, техлиды (и вообще все, кто принимает технические или бизнесовые решения в ИТ-сфере), обратите внимание на канал Кучевые АйТи. Тут рассказывают о новинках облачных технологий, об устройстве инфраструктуры, о роли ИИ, а ещё берут интервью у экспертов ведущих ИТ-компаний.
Читайте в канале:
⭐️ Бэкап на чекап. Что нужно знать, чтобы с уверенностью сказать: «У нас есть бэкап»? Нужно разобраться, как работает восстановление — отвечаем на самые частые вопросы.
⭐️ Закрепились в облаке. Как перестроить инфраструктуру и провести миграцию без остановки работы.
⭐️ Свежую виртуальную машину с белым IP начинают брутфорсить через несколько минут после поднятия. Как защитить только что арендованную VM?
⭐️ Новый интерфейс хочется изучить так, чтобы потом не пришлось ничего восстанавливать. Как безопасно знакомиться с возможностями облачных сервисов?
Подписывайтесь на канал ➡️ «Кучевые АйТи» | 1 554 |
| 20 |  V100 вместо RTX 3090: как собрать домашний LLM-сервер из списанного железа
В статье показывают, как собрать домашний сервер для локальных LLM из бывших в употреблении Tesla V100. Эти ускорители 2017 года с 32 ГБ HBM2 и пропускной способностью 900 ГБ/с сегодня можно найти за $100–150. А если объединить несколько карт, получится уже 64–128 ГБ видеопамяти - достаточно, чтобы запускать модели, которым тесно в обычных потребительских видеокартах.
🟣Правда, лёгкой такую сборку не назовёшь: понадобятся переходники для SXM2, мощное охлаждение, блок питания на несколько киловатт и терпение при настройке CUDA с PyTorch. Четыре V100 могут потреблять до 1200 Вт, зато за относительно небольшие деньги получится настоящий домашний сервер для локальных LLM.
Серверная Админа | Zeroday | #Статья | 3 403 |
