SSH до оддалечена ASA преку site VPN: чекор по чекор

Насочувате SSH клиент кон внатрешната адреса на оддалечената ASA и сесијата умира при поврзување. Firewall-от одговара од своето site, тунелот се појавува, а сепак ништо не слуша на порта 22. Во повеќето од овие случаи пакетот никогаш не стигнува до приемот за управување, бидејќи патеката што се тестира никогаш не била проектирана како патека за управување. Поминете го текот подолу по ред и дефектот престанува да се преместува.

Изберете ја адресата што навистина ја администрирате

Три дизајни изгледаат слично и се однесуваат различно: достигнување на јавната адреса на ASA свртена кон VPN, достигнување на внатрешен интерфејс преку IPsec и достигнување на посветен интерфејс за управување. Запишете ја изворната адреса на администраторот, точната адреса на дестинацијата и TCP 22 пред да допрете која било дозвола. Сето понатаму зависи од тој пар.

Тунел што носи две серверски VLAN мрежи може воопшто да не ја носи адресата на интерфејсот на firewall-от или подмрежата за управување на администраторот. Проверете ја листата на интересен сообраќај за политиката site-to-site и потврдете дека сопствената адреса на ASA се појавува како дестинација, а не само подмрежите што поминуваат низ неа.

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