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

Сегодня про инструмент 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 | #Инструмент

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

Сегодня разберём ещё 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

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

Сегодня расскажу про протокол 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

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

Продолжаем разбираться с 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

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

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

Сегодня разберём 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 | #Инструмент

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

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

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

Расскажу о 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

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

Сегодня разберём 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 | #протокол

Когда Ethernet ломает отказоустойчивость: скрытая проблема асимметрии задержек

Даже идеально настроенная промышленная сеть может работать нестабильно из-за причины, которую сложно заметить. Разная задержка передачи в прямом и обратном направлении нарушает работу протоколов синхронизации и резервирования, хотя оборудование остаётся полностью исправным.

🟣В статье разбирается феномен path delay asymmetry - асимметрии задержек в Ethernet-сетях. Автор объясняет, как различия в длине кабелей, работе коммутаторов Store-and-Forward и Cut-Through, очередях QoS, оптических трансиверах и резервных маршрутах влияют на IEEE 1588 PTP и промышленные сети.

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

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

Сегодня про инструмент Forerunner - библиотеку для разрабов, которая делает из сетевого сканирования готовый набор компонентов для .NET. И это не готовый сканер с интерфейсом, а движок, на базе которого можно собирать свои сетевые утилиты.

🟣Зачем он: когда нужно написать свой IP-сканер, мониторинг доступности или проверку портов, обычно приходится самостоятельно реализовывать потоки, таймауты, обработку ошибок и сбор результатов. Forerunner берёт эту рутину на себя и отдаёт всё в виде готовых объектов.

🟣Как работает: библиотека построена вокруг асинхронного событийного подхода. Вы создаёте Scanner, запускаете проверку IP или диапазона адресов, а результаты приходят через события с прогрессом и итоговыми объектами.

Например, можно просканировать сеть:

Scanner scanner = new Scanner();

IPScanObject result = scanner.Scan("192.168.1.1");

В результате объект содержит:
• IP-адрес
• статус доступности
• время ответа Ping
• hostname
• MAC-адрес
• ошибки при проверке

🟣Что умеет:

IP Scan - проверка одного адреса или диапазона

ScanRange("192.168.1.1", "192.168.1.255")

Port Scan - поиск доступных TCP/UDP портов

IsPortOpen("192.168.1.1", 443)

Ping Monitoring - проверка доступности и средней задержки

GetAveragePingResponse("192.168.1.1", 5, 1000)

Port Knock - массовая проверка портов на хостах

🟣Главная фишка, что всё работает параллельно. Библиотека рассчитана на многопоточность, поэтому можно одновременно проверять сотни адресов без блокировки основного приложения. Например, свой мониторинг можно построить так:
серверы → Forerunner → проверка Ping → проверка портов → отправка результата в панель мониторинга

🟣Пример асинхронного сканирования:

scanner.ScanAsync("10.0.0.1");

scanner.ScanAsyncComplete += (sender, result) =>
{
    Console.WriteLine(result.IP);
};

Программа не зависает в ожидании ответа, а получает события по мере завершения проверок.

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

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

Сегодня разберём в чём реальная разница между SR-MPLS и SRv6 - оба Segment Routing, но внутри вообще разные решения.

🟣SR-MPLS - Segment Routing поверх существующего MPLS-стека. Сегменты кодируются, как обычные MPLS-метки, промежуточные роутеры работают с привычным label swapping. Никакой новой плоскости данных - то же железо, те же ASIC, просто контрольная плоскость стала проще (нет RSVP-TE, сигнализация через IGP):

segment-routing mpls

router isis 1
 segment-routing mpls

show segment-routing mpls lb
show segment-routing mpls forwarding
show mpls forwarding-table labels 16001

Работает на любом железе которое уже умеет MPLS - миграция с классического MPLS минимальна, операторы переходят без замены оборудования.

🟣SRv6 - принципиально другой подход. Сегменты кодируются как IPv6-адреса в Segment Routing Header (SRH) - расширении IPv6-заголовка. Промежуточные роутеры обрабатывают обычный IPv6-трафик, никаких меток:

segment-routing srv6
 encapsulation source-address 2001:db8::1

router isis 1
 segment-routing srv6
  locator MAIN

show segment-routing srv6 sid
show segment-routing srv6 forwarding

Каждый сегмент это полноценный IPv6-адрес (128 бит) - в него зашиты локатор (где узел), функция (что делать с пакетом) и аргументы. Это даёт программируемость, которой нет в MPLS: один SID может означать не тупо “перейди на следующий хоп”, но и “примени QoS политику X” или “направь в конкретный VRF”.

🟣Главные различия на деле: SR-MPLS требует MPLS-capable железо везде, SRv6 работает на любом IPv6-роутере, включая белые ящики. SR-MPLS проще в диагностике - привычные MPLS-инструменты, SRv6 сложнее отлаживать, потому что SRH добавляет накладные расходы и не все инструменты его хорошо разбирают. SRv6 даёт нативную интеграцию с IPv6 без дополнительной инкапсуляции, SR-MPLS требует инкапсуляции для IPv6-трафика.

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

📝 История VRRP: как маршрутизатор перестал быть единственной точкой отказа

Технология, благодаря которой отказ шлюза перестал означать потерю связи для всей сети.

🟣Когда появился VRRP: долгое время у сети был один шлюз по умолчанию. Пока маршрутизатор работал - всё было хорошо. Но стоило ему выйти из строя, и вся подсеть теряла доступ к другим сегментам. В конце 90-х появился VRRP (Virtual Router Redundancy Protocol), который позволил нескольким маршрутизаторам представляться одним виртуальным шлюзом.

🟣Как это работает: устройства объединяются в группу и используют общий виртуальный IP-адрес. Один маршрутизатор становится Master и обрабатывает весь трафик, остальные находятся в режиме Backup. Если Master перестаёт отправлять служебные объявления, один из резервных автоматически занимает его место. Для клиентов ничего менять не нужно - шлюз остаётся тем же.

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

🟣Что изменилось со временем: сегодня VRRP поддерживают практически все крупные сетевые вендоры, а рядом появились собственные реализации вроде HSRP и GLBP. Несмотря на развитие SDN и EVPN, классическая схема с резервным шлюзом до сих пор остаётся стандартом для большинства корпоративных сетей.

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

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

Расскажу о 3 фишках Mikrotik которые реально не все знают.

🟣Interface Lists в Firewall - перестаньте привязывать правила к конкретным портам. Вместо этого можно работать с группами интерфейсов:

/interface/list/add name=WAN
/interface/list/member/add list=WAN interface=ether1
/interface/list/member/add list=WAN interface=lte1

/ip/firewall/filter/add chain=input \
in-interface-list=WAN action=drop

Если позже основной WAN сменится с ether1 на PPPoE или LTE, достаточно изменить состав списка - сами правила firewall останутся без изменений. На больших конфигурациях это заметно упрощает сопровождение.

🟣Bridge Horizon - простой способ изолировать клиентов внутри одного L2-сегмента без отдельных VLAN:

/interface/bridge/port
set [find interface=ether2] horizon=1
set [find interface=ether3] horizon=1
set [find interface=ether4] horizon=1

Порты с одинаковым Horizon не смогут обмениваться трафиком напрямую, но доступ к шлюзу сохранится. Полезно для гостевых сетей, гостиниц, общежитий и Wi-Fi.

🟣Routing Rules - policy routing без mangle. Во многих случаях можно вообще не использовать маркировку пакетов:

/routing/table/add fib name=VPN

/routing/rule/add \
src-address=192.168.50.0/24 \
action=lookup \
table=VPN

Весь трафик указанной подсети сразу начинает использовать отдельную таблицу маршрутизации. Конфигурация получается проще, чем через firewall mangle, и её легче поддерживать.

Серверная Админа | Бункер Хакера | #Mikrotik

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

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

Сегодня про KillerScan - бесплатный сетевой сканер для Windows, который не ограничивается поиском устройств, а сразу пытается понять, что именно он нашёл.

🟣Зачем он: большинство сканеров показывают IP, MAC и открытые порты. Дальше администратору самому приходится разбираться, где принтер, где NAS, а где гипервизор. KillerScan автоматически собирает дополнительные признаки и классифицирует устройства.

🟣Как работает: сначала выполняется ARP и ping-обход сети. Затем инструмент проверяет популярные TCP-порты, получает HTTP-заголовки, SSH-баннеры, TLS-сертификаты, NetBIOS, SNMP, mDNS и SSDP. После этого все полученные данные оцениваются по весам, и устройству присваивается наиболее вероятный тип.

Например, если обнаружены:

• SSH + Linux banner
• OUI от Dell
• HTTPS с заголовком Proxmox VE

то устройство с высокой вероятностью будет определено как гипервизор, а не просто «хост с открытым 22-м портом».

🟣Что умеет:
1️⃣ARP + Ping - быстрый поиск устройств
2️⃣HTTP / SSH / TLS - активный fingerprinting
3️⃣NetBIOS и SNMP - получение информации о системе
4️⃣mDNS и SSDP - поиск принтеров, 5️⃣Chromecast, NAS, IoT и другой техники
6️⃣MAC Vendor Lookup - определение производителя по IEEE OUI

🟣Полезная возможность - можно сканировать сразу несколько сетей за один запуск:

192.168.1.0/24,
192.168.10.0/24,
10.0.0.15-10.0.0.80

Все найденные устройства объединяются в один список без дублей.

🟣Приятная мелочь: это один portable EXE без установки зависимостей. Есть экспорт результатов в CSV и HTML, быстрый запуск RDP, SSH или браузера прямо из контекстного меню, а также повторное глубокое сканирование выбранных устройств без повторного обхода всей сети.

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