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 не атрымалі такі ж доступ, бо шлях кіравання, які працуе для ўсіх, — гэта іншая праблема, чым тая, з якой вы пачалі.