Усмерите 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 корисници нису добили исти приступ, јер је пут управљања који ради за све други проблем од оног са којим сте почели.

Повезани чланци