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 не отримали той самий доступ, бо шлях керування, що працює для всіх, — це інша проблема, ніж та, з якої ви почали.