SSH бастион или директен достъп през VPN: коя политика важи?

Въпросът дали 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

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