SSH к удалённой ASA через VPN площадки: шаг за шагом

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

Выберите адрес, которым вы действительно управляете

Три схемы выглядят похоже и ведут себя по-разному: достижение публичного адреса ASA, обращённого к VPN, достижение внутреннего интерфейса через 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 не получили тот же доступ, потому что путь управления, работающий для всех, — это другая проблема, нежели та, с которой вы начали.