Ինչու ASA-ի հեռավոր օգտվողը հասնում է ենթացանցին, բայց ոչ հավելվածին
Երթուղիները վկայում են, որ թունելը աշխատում է, ոչ թե այն, որ օգտվողը կարող է բացել հավելվածը: Կարդացեք զտիչը, որը ստացել է սեսիան, ապա փորձարկեք թույլատրված և մերժված միացում։
Ձեր օգտվողը միանում է, ստանում հասցե, փինգում է սերվեր հավելվածի ենթացանցում և այնուամենայնիվ չի կարողանում բացել դրա վրա գտնվող ծառայությունը։ Այդ համակցությունը սովորական է ASA-ում, որովհետև հաջող թունելը և օգտագործելի թույլտվությունը որոշվում են տարբեր կարգավորումներով։ Բաժանված թունելի ցանկն ընտրում էր, թե որ նպատակակետերն են մտնում թունել. VPN զտիչը և նպատակակետի սեփական մուտքի կանոնները որոշում են, թե ապակոդավորված հարցումը ինչին կարող է հասնել։ Անցեք երեք որոշումները հերթականությամբ, երթուղիների ցանկը լայնացնելու փոխարեն, մինչև ինչ-որ բան փոփոխվի։
Երեք որոշում, որոնք հեշտ է շփոթել
Ընդունումը պատասխանում է, թե արդյոք օգտվողն ընդհանրապես կարող է կառուցել թունելը. նույնականացման տվյալներ, վկայական և ցանկացած երկրորդ գործոն։ Երթուղու ընտրությունը պատասխանում է, թե որ նպատակակետերն է հաճախորդն ուղարկում այդ թունել։ Իսկ լիազորումը պատասխանում է, թե արդյոք ապակոդավորված հարցումը կարող է հասնել ծառայությանը։ Միայն երրորդն է առաջացնում այն սխալը, որը հաղորդում է օգտվողը։
Նրանց տարբերելու արագ ձևը հարցնելն է, թե ինչ կկոտրի փոփոխությունը։ Բաժանված ցանկից երթուղի հեռացնելը կանգնեցնում է դեպի այդ ենթացանց երթևեկությունը՝ առանց որևէ բան տրամադրելու. VPN զտիչին ACE ավելացնելը նպատակակետ է տրամադրում՝ առանց փոխելու, թե ինչ է թունելավորում հաճախորդը։
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
Կարդացեք զտիչը, որը սեսիան իրականում ստացել է
Սկսեք գործող սեսիայից, ոչ թե այն կոնֆիգուրացիայից, որը կարծում եք թե գործում է։ show vpn-sessiondb detail anyconnect տպում է նշանակված խմբային քաղաքականությունը և այդ սեսիային կցված զտիչի անունը։ Եթե դաշտը դատարկ է, ոչ մի զտիչ ոչինչ չի պարտադրում, և արգելափակումը գալիս է այլ տեղից։
Այնուհետև կարդացեք այն քաղաքականությունը, որին պատկանում է արժեքը, ներառյալ լռելյայն արժեքները, որովհետև զտիչը կարող է ժառանգված լինել, այլ ոչ թե գրված լինել այնտեղ, որտեղ նայում եք.
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Համեմատեք սեսիայի զտիչի անունը ձեր հենց նոր խմբագրած ACL-ի հետ։ Նման անունով ACL-ը, որը օգտվողը երբեք չի ստացել, չի կարող փոխել այդ սեսիայի ռեսուրսային քաղաքականությունը, և սա է ամենատարածված պատճառը, թե ինչու ճիշտ թվացող փոփոխությունը ազդեցություն չի ունենում։
Առաջնահերթությունը բացատրում է մնացածը։ Զտիչի կարգավորման համար DAP գրառումը գերազանցում է օգտվողի անվան ատրիբուտներին, իսկ օգտվողի անվան ատրիբուտները գերազանցում են խմբային քաղաքականությանը։ Երբ սեսիան ցույց է տալիս անսպասելի զտիչ, նախքան խմբին դիպչելը փնտրեք այդ օգտվողին համապատասխանող DAP քաղաքականություն։
Բաժանված ցանկը և զտիչը առանձին դաշտեր են
ASA 9.x-ում խմբային քաղաքականությունը պահում է split-tunnel-network-list և vpn-filter որպես տարբեր կարգավորումներ, և 9.22 խմբային քաղաքականության ուղեցույցը հենց այդ պատճառով դրանք փաստագրում է առանձին։ Ցանցի ցանկը երթուղային ակնարկ է հաճախորդի համար. զտիչը մուտքի վերահսկման ցանկ է, որը կիրառվում է ապակոդավորված երթևեկության վրա։
Այդ տարբերությունը կարևոր է, երբ օգտվողին ենթացանցում մեկ HTTPS ծառայություն է պետք։ Տեղադրեք ենթացանցը բաժանված ցանկում, որպեսզի փաթեթները մտնեն թունել, ապա զտիչում թույլատրեք միայն այդ ծառայությունը։ Երթուղիների ցանկի ընդլայնումը ոչինչ չի լիազորում, իսկ նեղացումը կիրարկման մեխանիզմ չէ։
Ստուգեք՝ արդյոք ինտերֆեյսի ACL-ն ընդհանրապես ուղու վրա է
Ապակոդավորված հեռահար մուտքի երթևեկությունը միշտ չէ, որ անցնում է արտաքին ինտերֆեյսի ACL-ով այնպես, ինչպես մարդիկ ենթադրում են։ Այնտեղ, որտեղ sysopt connection permit-vpn միացված է, ASA-ն կիրառում է իր փաստագրված VPN շրջանցումը այդ երթևեկության համար, մինչդեռ կիրառելի VPN զտիչները դրանից հետո էլ գործում են։ Ստուգեք կարգավորումը show run all sysopt հրամանով, տոպոլոգիայի գծապատկերից դատելու փոխարեն։
Ինչպես էլ լինի, նպատակակետ հոսթի սեփական ֆայրվոլը և հավելվածի լիազորումը մնում են ուղու վրա։ TCP 443-ը թույլատրող ASA կանոնը չի ստիպում հավելվածին ընդունել օգտվողին։
Ընդունեք փոփոխությունը նաև մերժված միացումով
Միայն թույլատրված փորձարկումը շատ քիչ բան է ապացուցում, որովհետև աշխատող թունելն առաջացնում է նույն առաջին փաթեթը՝ անկախ զտիչի առկայությունից։ Բացեք նախատեսված ծառայությունը հաճախորդից, ապա փորձեք նպատակակետ, որը պետք է փակ մնա, և հաստատեք, որ այն ձախողվում է ճիշտ պատճառով։
Տոմսը փակելիս գրանցեք չորս փաստ. ընդունված ինքնությունը, քաղաքականությունը և զտիչը, որոնք սեսիան իրականում ստացել է, բաժանված ցանկի նպատակակետերը և այն ռեսուրսը, որին օգտվողին թույլատրվել է հասնել։ Այս չորսը բացատրում են, թե որտեղ է վերահսկվում երթևեկությունը՝ առանց երթուղիների ցանկը ֆայրվոլի վերածելու։
Եթե զտիչի թույլատրելուց հետո էլ ծառայությունը մերժում է, անցեք հոսթին. լսող հասցե, հոսթի ֆայրվոլ և հավելվածի սեփական օգտվողների քարտեզագրում։ Այդ պահին թունելն արեց իր գործը, և ASA-ի հետագա փոփոխությունները միայն ռիսկ են ավելացնում։