SSH հեռավոր ASA-ին site 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 օգտատերերը չեն ստացել նույն հասանելիությունը, որովհետև բոլորի համար աշխատող կառավարման ուղին տարբեր խնդիր է, քան այն, որով սկսել եք։