Ինչու են ASA-ի TACACS+ հարցումները շրջանցում ձեր մասնաճյուղի VPN թունելը

Մասնաճյուղի թունելը աշխատում է, օգտատերերը նույնականացվում են հեռավոր TACACS+ սերվերի մոտ, սակայն firewall-ի սեփական մուտքը դեռ ժամանակով ավարտվում է: Պատճառը թունելի սխալը չէ. LAN-to-LAN թունելը տեղափոխում է այն երթևեկությունը, որը համապատասխանում է իր ընտրիչներին, իսկ ASA-ի կողմից իր մասին գեներացվող կառավարման երթևեկությունը առանձին հոսք է՝ իր աղբյուրի հասցեով: Թիմերի մեծ մասը դա հայտնաբերում է փոփոխության պատուհանի ընթացքում, երբ միակ ադմինիստրատորի հաշիվն է, որ ձախողվում է: ASA-ի սկսած AAA սեսիան դիտարկեք որպես հոսք, որը պետք է նախագծեք, և ոչ որպես արդեն աշխատող կապի կողմնակի ազդեցություն:

ASA-ն ինքն է հաճախորդը, և նրա սեփական երթևեկությանը պետք է իր ուղին

Երբ firewall-ը կապվում է TACACS+ սերվերի հետ, firewall-ը հաճախորդ է ինչպես ցանկացած այլը, բացի այն, որ ոչ ոք միտումնավոր երթուղի չի կարգավորել նրա համար: Նրա փաթեթները ծագում են սարքի ինտերֆեյսի հասցեից, դրանք գեներացվում են տեղում, ոչ թե փոխանցվում, և դրանք պետք է երթուղղվեն, թարգմանվեն և պաշտպանվեն քաղաքականությամբ ճիշտ ինչպես օգտատերերի երթևեկությունը: Տեղամասից տեղամաս թունելը, որը պաշտպանում է օգտատերերի ենթացանցը, ավտոմատ չի պաշտպանում այդ կառավարման աղբյուրը, որովհետև երթևեկության ընտրությունը հիմնված է հասցեների, ոչ թե մտադրության վրա:

Գրեք այն հասցեն, որը սպասում եք, որ սերվերը կտեսնի: Եթե չեք կարող այն ասել մեկ տողով, դեռ նախագիծ չունեք:

aaa-server տողի ինտերֆեյսը զարդարանք չէ

ASA-ում aaa-server հոսթի գրառումը վերցնում է ինտերֆեյսի կապակցում փակագծերում, և Cisco-ի AAA հոսթի հրամանների տեղեկագիրքը նկարագրում է այն որպես ինտերֆեյս, որտեղ գտնվում է նույնականացման սերվերը: Հենց այդ կապակցումն է կապում հարցումը ինտերֆեյսի և այդ ինտերֆեյսի կիրառած քաղաքականության հետ: Այն ընտրելով ինտերնետին նայող ցանկացած ինտերֆեյսով, կամ թողնելով այն, ինչ մնացել է վերջին միգրացիայից, ստանում եք աղբյուրի հասցե, որի համար հեռավոր սերվերն ու թունելը երբեք չեն կառուցվել:

inside-ը ճիշտ պատասխանն է միայն այն դեպքում, երբ նշված ինտերֆեյսն ունի այն հասցեն, որը ձեր նախագիծը մտադիր է օգտագործել որպես աղբյուր: Մասնաճյուղի սարքում դա հաճախ այդպես է. մի քանի մասնավոր սեգմենտ ունեցող սարքում գուցե ոչ:

Կապակցումը փոխելը նշանակում է գրառումը վերստեղծել

Նույն հրամանների տեղեկագիրքը փաստագրում է խմբագրման սահմանափակում, որը մարդկանց բռնում է անցումների ժամանակ. գոյություն ունեցող հոսթի ինտերֆեյսը փոխելը պահանջում է հեռացնել և վերստեղծել հոսթի գրառումը: Խմբագրված թվացող կոնֆիգուրացիան գուցե ուժի մեջ չի մտել, և հաջորդ մուտքի փորձը դեռ կմեկնի հին հասցեից: Դա պլանավորեք որպես ջնջում և ավելացում՝ բնօրինակ գրառումի պատճենը ձեր առջև, և ոչ որպես տեղում ուղղում:

Եթե սահմանված են մի քանի սերվեր, փոխեք մեկը և ստուգեք այն, նախքան մյուսներին դիպչելը, որպեսզի սխալը միանգամից չկողպի բոլոր վարչական ուղիները:

Ստուգեք ընտրիչները, թարգմանությունը և վերադարձի ուղին միասին

Երեք բան պետք է համընկնի, որպեսզի հարցումը հասնի: Թունելի երթևեկության ընտրիչները, կամ թունելի ինտերֆեյսի պաշտպանությունը, եթե այն օգտագործում եք, պետք է ներառեն ASA-ի սեփական աղբյուրը և սերվերի հասցեն. օգտատերերի ենթացանցերի համար կառուցված ընտրիչների ցանկը սովորաբար դա չի անի: Ուղու ցանկացած NAT կանոն պետք է հետևողականորեն թարգմանի այդ աղբյուրը, որովհետև սերվերը լիազորում է ցանցային սարքի ինքնություն, որը ներառում է իր տեսած հասցեն: Եվ վերադարձի ուղին պետք է գոյություն ունենա, ինչը քաղաքականության վրա հիմնված թունելում նշանակում է, որ հեռավոր ծայրն ունի համապատասխան ընտրիչ հակառակ ուղղությամբ:

Սերվերի կողմում առանձին հաստատեք սարքի ինքնությունը, ընդհանուր գաղտնիքը և վարչական քաղաքականությունը: TACACS+-ը նույնականացումը, լիազորումը և հաշվառումը պահում է որպես առանձին գործողություններ, ուստի ավարտված փոխանակումից հետո եկող մերժումը քաղաքականության պատասխան է, ոչ տրանսպորտի խափանում: Այն որպես ցանցային խնդիր կարդալը ձեզ կուղարկի սխալ տեղ փնտրելու:

Վրիպազերծման ընթացքում գաղտնիքը հեռու պահեք փաթեթների գրառումներից, տոմսերից և սղագրություններից, և հիշեք, որ սերվերի գրանցած աղբյուրի հասցեն այն է, որը ձեր նախագիծը պետք է բացատրի:

Կատարեք փոփոխությունը՝ չկողպելով ինքներդ ձեզ դուրս

Օգտագործեք վահանակ կամ անկախ կառավարման ուղի հեռավոր վարչական նույնականացումը փոխելիս, և պահեք հաստատված տեղական պահուստային տարբերակ, քանի դեռ նոր ուղին իրական մուտք չի տարել: Ապա ստուգեք նեղ՝ մեկ սերվեր, մեկ սարք, մեկ հաջող նույնականացում՝ աղբյուրի հասցեն երկու ծայրերում դիտարկված:

Գրանցեք հոսքը իր սեփական էջում՝ ծագման ինտերֆեյս և հասցե, հեռավոր սերվեր, պաշտպանված ուղի, և այն անձը, ում պատկանում է լիազորման քաղաքականությունը: Այնուհետև ավելի ուշ ինտերֆեյսի կամ թունելի փոփոխությունը կարելի է գնահատել առանց գուշակելու, թե երկու հոսքերից որի վրա է այն ազդում: