SSH към отдалечен ASA през VPN на сайта: стъпка по стъпка

Насочвате SSH клиент към вътрешния адрес на отдалечения ASA и сесията умира при свързване. Защитната стена отговаря от собствения си сайт, тунелът се показва, а на порт 22 нищо не слуша. В повечето от тези случаи пакетът така и не достига до допускането за управление, защото тестваният път никога не е бил проектиран като път за управление. Проследете потока по-долу по ред и отказът спира да се мести.

Изберете адреса, който действително администрирате

Три проекта изглеждат сходни и се държат различно: достигане до публичния обърнат към VPN адрес на ASA, достигане до вътрешен интерфейс през IPsec и достигане до отделен интерфейс за управление. Запишете адреса на източника на администратора, точния адрес на местоназначението и TCP 22, преди да пипате разрешение. Всичко по-нататък зависи от тази двойка.

Тунел, който носи два VLAN на сървъри, може изобщо да не носи адреса на интерфейса на защитната стена или подмрежата за управление на администратора. Проверете списъка с интересен трафик за политиката сайт-към-сайт и потвърдете, че собственият адрес на ASA се появява като местоназначение, а не само подмрежите, които минават през него.

Тъй като местоназначението е самата защитна стена, допускането за управление е отделно от правилата за препратен трафик. ACL, който позволява на клиентите да достигат сървъри зад ASA, не включва самостоятелно SSH администриране на устройството и поправянето на правилото за препращане няма да премести този отказ.

management-access е специфична за интерфейса

Командата management-access казва на ASA да приема връзки за управление към посочен интерфейс, когато пристигат през VPN. Тя не създава маршрут, не добавя разрешение за SSH и не се прилага към всеки интерфейс наведнъж. Ако интерфейсът на местоназначението не е посоченият, връзката се изхвърля преди удостоверяване.

Тук има две изключения. Интерфейсите само за управление са извън този механизъм, а ръководството за управление на ASA 9.20 отбелязва, че стандартният стек CiscoSSH не поддържа SSH между интерфейси през VPN, докато стекът ASA SSH го поддържа. Потвърдете активния стек на внедрената версия, преди да отделите време за маршрути.

Четири порти преди подканата за вход

Между клиента и подканата за потребителско име стоят четири независими порти: съвпадение на маршрут и тунел за двойката за управление, ACL на интерфейса, който разрешава TCP 22 към адреса на ASA, разрешение ssh, обхващащо източника на администратора, и AAA удостоверяване за този потребител. Всяка от тях може да изхвърли пакета, без да каже на клиента коя порта се е затворила.

Използвайте packet-tracer, за да видите коя порта се проваля, преди да промените нещо: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Проследяването посочва ACL, етапа NAT и решението to-the-box, което обикновено е достатъчно, за да се отдели проблем с маршрутизация от проблем с допускане.

Напишете тясното разрешение, не широкото

Ограничете разрешението до одобрената административна подмрежа и интерфейса, който приема трафика на тунела: ssh 10.10.5.0 255.255.255.0 inside. Сдвоете го с метод за удостоверяване като aaa authentication ssh console LOCAL и именуван локален акаунт, вместо да отваряте всеки източник на външния интерфейс.

Поддържайте ACL на интерфейса и разрешението ssh съгласувани. Разрешение за подмрежа, която ACL блокира, пак се проваля, а ACL, който разрешава подмрежата без съответстващ запис ssh, се проваля на следващата порта. И двете твърдения описват един и същ път от различни слоеве, затова ги прегледайте заедно в текущата конфигурация.

Проверете от посочения хост, после стеснете отново

Отворете нова сесия от посочения хост за управление, а не от бюрото си, и потвърдете на ASA кой адрес на източника и кой интерфейс е използвала връзката. Проверете активните сесии и секцията SSH на текущата конфигурация, докато сесията е отворена, после я затворете и премахнете всяко временно разрешение, добавено за тестване. Ако сесията се появи, но падне веднага след влизане, останалият проблем е оторизация, а не достъпност. Запишете интерфейса и източника в записа за промени, за да не повтаря следващият човек диагностиката.

Дръжте конзола или друг независимо одобрен път за възстановяване наличен през цялата промяна. След като частният път работи, потвърдете, че публичните източници и несвързаните VPN потребители не са получили същия достъп, защото път за управление, който работи за всички, е различен проблем от този, с който сте започнали.