Вопрос о том, могут ли пользователи VPN попадать на серверы, не проходя через промежуточный хост, — это вопрос политики в сетевой одежде. Если бастион выполняет обязательный контроль, то подключение к VPN должно вести к нему, а не в обход. Если промежуточный хост лишь соединял сегмент, который раньше был недоступен, узкий прямой путь может быть честной заменой. Выполните проверки ниже по порядку и остановитесь на первой неудачной, потому что именно этот ответ решает остальное.

Проверьте, чем бастион на самом деле управляет

Начните с доказательств о настоящем, а не с диаграммы из проектного документа. Посмотрите на конфигурацию SSH и фильтр пакетов цели: если входящий порт 22 принимается только с адреса бастиона, промежуточный хост — это принудительный контроль. Если тот же порт принимает подключения со всего пула VPN, бастион был удобством, а принуждение живёт совсем в другом месте. История заявок обычно подтверждает, что из двух возникло первым.

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

Проверьте, различает ли цель пути

Правила адреса источника работают только пока оба пути приходят с разными адресами источника. VPN-шлюз, маскирующий трафик к подсети серверов, стирает это различие, и тогда каждое подключение к порту 22 выглядит так, будто приходит со шлюза. Проверка локальна на цели и занимает мгновение: перечислите установленные сессии SSH и прочитайте адрес партнёра для каждой.

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

Проверьте, что на самом деле хранит каждая запись

Три разных журнала описывают три разных события, и ни один не заменяет другой. Запись подключения VPN показывает, что некая идентичность вошла в сетевой периметр. Запись пересылки бастиона показывает TCP-канал, покидающий его в сторону назначения и порта. Журнал аутентификации цели показывает, что учётная запись вошла по SSH. Именно совместное чтение даёт хронологию; чтение одного даёт догадку.

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

Проверьте, где политика действительно применяется

Клиентская настройка вроде ProxyJump — это запрос, а не ограничение. OpenSSH охотно откроет прямое подключение, когда назначение достижимо, поэтому файлы конфигурации на ноутбуках описывают намерение, а межсетевые экраны решают исход. Принуждение относится к разрешённым назначениям VPN-шлюза и к собственным правилам доступа цели, и ни то, ни другое пользователь не может изменить. Одновременно проверьте альтернативные пути: второй интерфейс, публичный слушатель, mesh-слой или старый туннель между площадками могут каждый восстановить только что закрытый обходной путь.

Всё же настройте ProxyJump, потому что это делает одобренный маршрут лёгким и не даёт рутинной работе порождать исключения. Подтвердите, что именно клиент разрешает, прежде чем ему доверять.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

Подтвердите намеренной прямой попыткой

Политика, которую никогда не проверяли, — это надежда. С клиента, подключённого к VPN, попробуйте путь, который теперь должен быть отклонён, затем попробуйте одобренный и сохраните оба результата. Отклонённая попытка — это доказательство того, что изменение вступило в силу.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

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

Похожие статьи