Всем добрый день! Будем считать это памятной датой зарождения компании nethub.ru! Поздравляю причастных к этому маленькому событию!

Первая версия продуктовой презентации.

Когда пинг проходит, а доступ всё равно не работает
Одна из самых распространённых фраз при разборе сетевых инцидентов:

«У нас всё работает, пинг же проходит»

На первый взгляд звучит логично.
Если один сервер отвечает другому, значит между ними есть связность. Значит сеть работает. Значит проблему надо искать где-то в приложении.
Но в реальной инфраструктуре всё не так просто.

Ping — это ещё не доступ
Успешный ping показывает только то, что ICMP-пакеты смогли пройти от одной точки до другой.
Но прикладной трафик может обрабатываться совсем иначе.
Например:
🔹 ICMP проходит
🔹 TCP 443 блокируется
🔹 TCP 22 разрешён только с отдельной подсети
🔹 приложение попадает под отдельную security policy
🔹 после NAT меняется маршрут
🔹 на обратном пути трафик уходит через другое устройство
И в итоге получается классическая ситуация:
пинг есть, а сервис не открывается.

Типичный пример
Пользователь не может открыть внутреннее веб-приложение по HTTPS.
Начинается базовая проверка:
✅ пинг до сервера проходит
✅ маршрут на первый взгляд есть
✅ интерфейсы активны
✅ сервер отвечает
На этом этапе часто появляется вывод:

«С сетью всё нормально, пусть приложение смотрят»

Но дальше выясняется, что на одном из межсетевых экранов нет разрешения для TCP/443.
ICMP при этом проходит без проблем.
А прикладной трафик блокируется политикой безопасности.

Почему так происходит
Для успешного соединения недостаточно просто «видеть» удалённый узел.
Должна корректно сработать вся цепочка:
маршрут → интерфейс → зона → NAT → правило доступа → сервис → обратный маршрут
Если хотя бы один элемент этой цепочки не совпадает, соединение может не установиться.
Причём внешне всё может выглядеть исправно.
Ping проходит.
Traceroute показывает путь.
Сервер включён.
Но приложение всё равно недоступно.

Самые частые причины
На практике проблема часто оказывается не в самом сервере и не в приложении, а в одном из сетевых условий:
🟠 разрешён ICMP, но запрещён нужный TCP/UDP-порт;
🟠 NAT меняет адрес, а дальше нет маршрута до преобразованного IP;
🟠 обратный трафик возвращается другим путём;
🟠 правило есть, но не для той зоны или интерфейса;
🟠 трафик попадает под другое, более приоритетное правило;
🟠 объект в политике давно устарел или был изменён.

Как правильно диагностировать
Профессиональная диагностика начинается не с вопроса:

«Пингуется или нет?»

А с вопроса:

«Как именно должен пройти конкретный трафик от источника до назначения?»

Важно проверять не абстрактную связанность, а конкретный сценарий:
источник → назначение → протокол → порт → NAT → маршрут → политика безопасности
Только так можно понять, где именно соединение обрывается.

💡 Ping полезен как первая проверка, но он не доказывает, что доступ действительно разрешён.
💡 Для прикладного доступа важен не факт сетевой связанности, а полная цепочка прохождения трафика.

Что происходит с политикой безопасности через 5 лет эксплуатации

Практически любая политика безопасности выглядит аккуратно в день своего создания.
Есть понятная схема сети.
Известны владельцы сервисов.
У каждого правила есть обоснование.
Документация соответствует реальной инфраструктуре.
Кажется, что всё под контролем.

Но дальше начинается обычная жизнь инфраструктуры.
Через год появляется новое приложение — для него создают несколько дополнительных разрешений.
Через два года часть сервисов переезжает в другое расположение.
Через три года меняется команда сопровождения.
Через четыре года некоторые системы выводятся из эксплуатации, но связанные с ними правила остаются в политике.
А через пять лет кто-то открывает межсетевой экран и задаёт простой вопрос:

«Что произойдёт, если удалить это правило?»

И внезапно никто не может ответить уверенно.

Так появляется технический долг
На крупных устройствах политика может содержать тысячи правил.
Они создавались разными администраторами, в разное время и под разные задачи.
Часть правил давно потеряла актуальность.
Часть дублирует друг друга.
Часть вообще не используется, но продолжает оставаться в политике просто потому, что её страшно удалить.
И это уже не просто «лишние строки в конфигурации».
Это технический долг, который напрямую влияет на скорость изменений и уровень риска.

Почему это становится проблемой
Каждое новое изменение начинает требовать всё больше проверок.
Администратор получает запрос на открытие доступа и вынужден разбираться:
❓ можно ли использовать уже существующее правило;
❓ не создаст ли новое правило перекрытие;
❓ какие сервисы используют нужный объект;
❓ кто владелец старого разрешения;
❓ что перестанет работать после удаления.
В молодой инфраструктуре такие вопросы часто решаются за несколько минут.
В зрелой сети с накопленным техническим долгом такая проверка может занимать часы или даже дни.

Самое неприятное
Политика при этом может продолжать работать.
Пользователи получают доступ.
Приложения функционируют.
Инцидентов может не быть.
Снаружи всё выглядит нормально.
Но внутри постепенно растёт сложность.
И чем дольше её не контролировать, тем дороже становится любое изменение.

Во время аудитов часто выясняется, что в политике есть:
🟠 неиспользуемые правила;
🟠 дублирующие разрешения;
🟠 устаревшие объекты;
🟠 временные доступы без срока действия;
🟠 правила, назначение которых уже невозможно восстановить.
Каждый такой элемент по отдельности может казаться незначительным.
Но вместе они делают политику всё менее управляемой.

Поэтому управление политиками безопасности — это уже давно не просто настройка правил на межсетевом экране.
Это непрерывный процесс:
контроль изменений → анализ зависимостей → поиск устаревших разрешений → оптимизация политики
Чем раньше организация начинает заниматься этим системно, тем проще поддерживать инфраструктуру в нормальном состоянии.

💡 Самая опасная политика безопасности — не та, в которой много рисков.
💡 Самая опасная политика безопасности — та, которую уже никто не понимает до конца.

NAT: самая недооценённая причина проблем с доступом
Есть типичная ситуация, с которой рано или поздно сталкивается любой сетевой инженер:
✔️ правило на МСЭ есть
✔️ маршруты настроены
✔️ сервис работает
✔️ связность подтверждается
А доступа всё равно нет.

В такие моменты обычно начинают проверять:
— политику безопасности
— маршрутизацию
— настройки приложения
И почти всегда в последнюю очередь смотрят на NAT.
И зря.

Почему NAT ломает логику
Проблема в том, что пакет по пути может несколько раз изменить свои параметры.
Адрес источника меняется на одном устройстве.
Адрес назначения — на другом.
В итоге сервер получает не тот трафик, который отправлял пользователь.

Простой пример
Пользователь идёт на сервис через внешний IP.
На МСЭ есть разрешение.
Настроен DNAT.
Всё выглядит корректно.

Но после трансляции:
👉 меняется адрес назначения
👉 меняется логика маршрутизации
👉 дальнейший путь строится уже по новому адресу
Если где-то в сети нет маршрута до этого адреса — соединение обрывается.
И при этом:
администратор видит «правильные» правила и не понимает, где проблема.

В распределённых сетях всё ещё хуже
Трафик может проходить через:
— несколько firewall
— балансировщики
— маршрутизаторы
И на каждом уровне может быть свой NAT.

В этот момент диагностика превращается в цепочку вопросов:
❓ какой был исходный адрес
❓ какой адрес после NAT
❓ где именно произошла трансляция
❓ какие маршруты используются дальше
❓ какие правила применяются уже после NAT

Ключевой момент
Во многих случаях проблема не в доступе.
Доступ есть.
Маршрут есть.
Но есть расхождение между ожидаемым и фактическим адресом.
И этого достаточно, чтобы всё перестало работать.

💡 Поэтому опытные инженеры анализируют не правило, а полный жизненный цикл пакета.
От источника до сервера.
Со всеми трансляциями по пути.

🎁 Для участников Jet Security Conference проводим розыгрыш призов
Принять участие:
https://forms.yandex.ru/cloud/6a203058eb61465cf73739e1

Когда правило есть, а доступ не работает
Один из типичных кейсов из практики.

Есть задача: открыть доступ к сервису.

На МСЭ правило добавили.
Маршруты проверили.
Сервис доступен.
Но пользователь всё равно не может подключиться.

Начинается классический разбор:
— проверяют правила
— смотрят маршрутизацию
— дергают админов приложения
— поднимают логи
Проходит время, а ответа нет.

Где был затык
В одном из таких кейсов проблема оказалась не в правиле.
И не в маршруте.
А в том, что трафик после NAT уходил по другому пути и попадал под другое правило.
В итоге:
✔️ нужное правило есть
❌ но до него трафик просто не доходит

Как это проверяется в НетХаб
Вместо ручной проверки всей цепочки можно просто смоделировать доступ:
источник → назначение → сервис
И посмотреть:
— через какие устройства пойдёт трафик
— какие правила реально применятся
— где именно он остановится

В этом кейсе сразу стало видно:
👉 где меняется адрес
👉 куда уходит трафик после NAT
👉 на каком устройстве он блокируется
Без перебора правил и ручного анализа всей сети.

Что в итоге
Проблему нашли за минуты.
Хотя до этого её пытались понять несколько часов.

💡 Основная ценность — не в том, чтобы видеть правила.
💡 А в том, чтобы понимать, как реально проходит трафик через сеть.

Встречаемся на Jet Security Conference
С 4 по 6 июня проходит Jet Security Conference — одна из крупнейших конференций по информационной безопасности в России, которая ежегодно собирает экспертов, заказчиков, вендоров и интеграторов для обсуждения актуальных вопросов кибербезопасности.

Если будете на мероприятии — заглядывайте на стенд НетХаб.
Будем рады познакомиться, обсудить ваши задачи, вопросы по сетевой безопасности, анализу политик МСЭ, моделированию сетевого доступа и просто пообщаться с коллегами.

🎁 Также для участников конференции проходит розыгрыш призов.
Принять участие можно по ссылке:
https://forms.yandex.ru/cloud/6a203058eb61465cf73739e1

До встречи на Jet Security Conference 🚀

🎁 Розыгрыш призов для участников Jet Security Conference

Jet Security Conference — это одна из крупных конференций по информационной безопасности, где обсуждают реальные кейсы и практику, а не только теорию.

Сейчас у них проходит розыгрыш призов для участников.

👉 Принять участие:
https://forms.yandex.ru/cloud/6a203058eb61465cf73739e1

Займёт пару минут.

👋 Привет, участники ИБТУСА!

Мы подготовили крутой мерч, который разыграем прямо на ИБТУСА! 🎁 Но получить его смогут только те, кто станет частью нашего комьюнити. Розыгрыш пройдет исключительно среди подписчиков нашего канала Нетхаб.
👉 Присоединяйтесь к каналу: @nethubru
📌 Как поучаствовать? Всё максимально просто:
Переходите по ссылке и подписывайтесь на Нетхаб.
Следите за обновлениями — пост для участия в розыгрыше будет опубликована прямо в канале!
Залетайте, чтобы не остаться без подарков и быть в курсе самых сочных IT-тем.

До встречи на мероприятии! 🔥

👋 Привет, участники ИБТУСА!
А вот и обещанный конкурс.
Нужно быть просто подписанным на канал Нетхаб и у тебя будет возможность выиграть одну из крутейших футболок (и еще немного нашего мерча)!

Всем привет!
Мы участвуем в КиберКемпе от наших Партнеров - Инфосистемы Джет.
И да, мы снова разыгрываем мерч за демонстрацию высоких скилов при решении задач в аркадных CFT автоматах.
Ждем всех на нашем стенде!

Кстати, для всех участников в нашем мерче, есть возможность получить еще немного подарков!

🔥 А мы-то думали, куда деть летний запас мерча и азарта!
Друзья, сегодня Нетхаб едет на «Лето в КиберКэмпе»! Будет жарко — и на солнце, и на нашем стенде 😎
Что мы приготовили:
🎁 Подарки за футболки. Надевай нашу фирменную майку — и приходи к нам за приятным бонусом. Просто так, без сложных условий.
🕹 Аркадные автоматы с CTF. Вспоминаем старые игры, но с крутым ИБ-замесом.
🏆 Победителей ждут реальные призы! Только попробуй уйти без них.
Ждём всех, кто застанет нас в движении.
Всё в лучших традициях Нетхаба: душевно, полезно и с подвохом!
📍 Подробности о фестивале и локации: https://cybercamp.su/leto2026