Բաժանված թունելավորումը հանրային հոսթին չի ազատում ASA-ի NAT կանոններից

Բաժանված թունելավորումը սովորաբար նկարագրվում է որպես կորպորատիվ երթևեկությունը թունելի ներսում, իսկ ինտերնետի մնացած մասը՝ firewall-ից դուրս պահելու միջոց։ Այդ նկարագրության երկու կեսերն էլ նույն կերպ սխալ են։ Բաժանված թունելավորումը կլիենտի կայացրած երթուղու որոշումն է, և երթուղու որոշումը ոչինչ չի ասում այն մասին, թե ինչ է պատահում փաթեթին headend-ին հասնելուց հետո։

Հանրային հասցեով մեկ գործընկեր ծառայություն, որը պնդում է տեսնել ձեր գլխամասի հասցեն, բավական է պատմությունը կործանելու համար։

Առասպելը. բաժանված թունելը firewall-ը հանում է ուղուց

Հավատն այն է, որ մասնավոր տիրույթներից դուրս ցանկացած նպատակակետ մնում է տեղական ինտերնետ կապի վրա, ուստի firewall-ը երբեք չի տեսնում այն և երբեք կանոն չի պահանջում դրա համար։ Դա ճիշտ է միայն այնքան ժամանակ, քանի դեռ նպատակակետը թունելի ցանկում չէ։ Այն պահին, երբ օպերատորը հանրային հոսթ է ավելացնում split-include ACL-ում, կլիենտը այդ երթևեկն ուղարկում է թունել, և ASA-ն պետք է այն երթուղավորի, զտի և թարգմանի ինչպես ցանկացած այլ ապակոդավորված հոսք։ Կլիենտի վրա ոչինչ չի փոխվել, բացի նպատակակետերի ցանկից։

Կլիենտը երթուղիչ չդարձավ։ Այն հետևեց ձեր տված քաղաքականությանը։

Ինչ է իրականում անում split-include երթուղին

Cisco ASA հեռահար մուտքի կարգավորումում խմբային քաղաքականությունը կրում է split-tunnel-policy tunnelspecified և split-tunnel-network-list, որը նշում է ստանդարտ ACL։ Այդ ACL-ի յուրաքանչյուր permit տող նպատակակետ է, որը կլիենտը պետք է ուղարկի թունել, իսկ մնացած ամեն ինչ շարունակում է օգտագործել տեղական լռելյայն երթուղին։

Մեկ հոսթ ավելացնելը մեկ տող է, և դա փոփոխության այն միակ մասն է, որը կլիենտը կարող է տեսնել՝ access-list RA-SPLIT standard permit host 203.0.113.20։

Դրանից հետո նորից միացրեք կլիենտը։ Քաղաքականությունը փոխանակվում է միանալու պահին, ուստի հաստատված սեսիան պահում է հին ցանկը և փոփոխությունը ցույց է տալիս այնպես, կարծես ոչինչ չի արել։

Փաթեթը գալիս և գնում է նույն ինտերֆեյսով

Այժմ հետևեք հոսքին ապակոդավորումից հետո։ Փաթեթը VPN թունելով մտել է արտաքին ինտերֆեյս, նրա նպատակակետը հանրային հասցե է, և երթուղային աղյուսակը այն հետ է ուղարկում նույն արտաքին ինտերֆեյսով դեպի ինտերնետ։ Մեկ ինտերֆեյս մտնող և դուրս եկող երթևեկը դեն է նետվում, եթե ASA-ին թույլ չի տրվել, և հենց դա է անում same-security-traffic permit intra-interface-ը։ Առանց դրա կապը ձախողվում է այնպես, ինչը նման է երթուղային խնդրի և այդպիսին չէ։

Այդ կարգավորումը գլոբալ է։ Այն թույլ է տալիս hairpinning ցանկացած հոսքի համար, որին դա պետք է, ոչ միայն այս գործընկեր հոսթի, ուստի այն տեղ ունի վերանայված փոփոխության մեջ, ոչ թե արագ փորձարկման։

Ինչու նպատակակետով սահմանափակված PAT-ը պարտադիր է

Ապակոդավորված փաթեթի աղբյուրի հասցեն դեռ կլիենտի VPN հասցեն է՝ սովորաբար 10.77.0.0/24-ի նման փուլից։ Այդ հասցեն հանրային ինտերնետում երթուղի չունի, ուստի գործընկերը կամ երբեք չի պատասխանում, կամ պատասխանում է ոչ մի տեղ։

Թարգմանությունը ուղղում է աղբյուրը և անփոփոխ է թողնում նպատակակետը։ Քանի որ օբյեկտներն արդեն սահմանված են այլ տեղ, այս նպատակակետով սահմանափակված ձեռքով կանոնը այս տեսքն ունի՝

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

destination static մասը կարևոր է։ Այն բաց թողնելու դեպքում կանոնը դառնում է լայն թարգմանություն, որը կարող է համընկնել շատ ավելի երթևեկի հետ, քան նախատեսված էր, և հերթականությամբ ավելի վաղ գտնվող լայն identity կանոնը կարող է ամբողջությամբ հաղթել սրան։ Ստուգեք show nat detail-ը և բաժինների հերթականությունը նախքան ենթադրելը, որ ձեր կանոնն է համընկնողը։

Ինտերֆեյսի PAT-ը նաև նշանակում է, որ գործընկերը տեսնում է ASA-ի ինտերֆեյսի հասցեն, որը կարող է կրկին թարգմանվել վերևում։ Եթե պայմանագիրը նշում է հասցե, հաստատեք այն ծայրից ծայր, ոչ թե մեկ ցատկով։

Ապացուցեք ճիշտ փորձարկման նպատակակետով

Օգտագործեք հենց գործընկեր հոսթը, ոչ թե ընդհանուր what-is-my-ip էջ։ Այդ էջը գրեթե անշուշտ split ցանկից դուրս է, ուստի այն հայտնում է ձեր տեղական ինտերնետ հասցեն և ոչինչ չի ասում այս ուղու մասին։ Բացեք նոր կապ գործընկեր ծառայության հետ և հարցրեք, թե ինչ աղբյուր են նրանք տեսել, կամ գործարկեք packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed-ը և տող առ տող կարդացեք NAT-ի և երթուղավորման փուլերը։ Կլիենտից traceroute-ը ավելի թույլ ստուգում է, որովհետև ցույց է տալիս արդեն տեղի ունեցած ուղին, ոչ թե այն քաղաքականությունը, որն ընտրել է այն։

Այնուհետև ստուգեք, թե ինչ չպետք է փոխվի։ Սովորական կայքը դեռ պետք է դուրս գա տեղական կապից, իսկ թունելի ցանկում գտնվող մասնավոր ռեսուրսը դեռ պետք է հասանելի մնա։ Փոփոխությունը, որը շտկում է գործընկերոջը և կոտրում այդ երկուսից մեկը, այլ սխալ է։

Այս ձևավորման աշխատող տարբերակը կարճ է՝ մեկ հոսթ split ACL-ում, hairpin թույլտվություն, մեկ նպատակակետով սահմանափակված PAT կանոն։ Պատմության մեջ մնացած ամեն ինչ առասպելն է։