IPsec-ը IPsec-ի մեջ. ինչ հասցեներ պետք է կրի արտաքին թունելը

Բնադրված IPsec-ի մասին ավելի հեշտ է մտածել, երբ երկու շերտերն ավարտվում են տարբեր մեքենաներում։ Չորս դարպաս, երկու թունել և մեկ հարց, որը որոշում է՝ աշխատո՞ւմ է նախագիծը. ի՞նչ է իրականում տեսնում արտաքին թունելը, երբ ներքինն ավարտում է փաթեթի հետ։ Պատասխանեք դրան, և ընտրիչները, երթուղիները և խնդիրների լուծման հերթականությունը կհետևեն։ Սխալվեք, և մի ամբողջ օր կանցկացնեք տեխնիկապես միացած թունելի կարգաբերմամբ։

Չորս դարպասի մոդելը

Արտաքին A և B դարպասները կառուցում են առաջին թունելը երկու վայրերի միջև։ A-ի հետևում ներքին C դարպասն է՝ տարանցիկ հասցեով՝ 10.60.0.2, իսկ B-ի հետևում՝ ներքին D դարպասը՝ տարանցիկ հասցեով՝ 10.70.0.2։ Հավելվածների ցանցերը գտնվում են C-ից և D-ից հետո, և օրինակի յուրաքանչյուր հասցե դիտավորյալ չի համընկնում։

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Շերտերը չորս հոսթերի բաժանելը նշանակում է, որ յուրաքանչյուր մեքենա ապահովում է մեկ սահման։ Մեկ հոսթը, որը վարում է երկու շերտերը, պետք է համադրի երկու քաղաքականության հավաքածու, երկու երթուղային աղյուսակ և երկու խափանման ռեժիմ մեկ մեքենայում, ինչը հնարավոր է և շատ ավելի դժվար դիտարկելի։

Յուրաքանչյուր շերտ հեռացնում է միայն իր պաշտպանությունը

C-ն գաղտնագրում է հավելվածի փաթեթը D-ի համար։ Արդյունքը հասցեագրված է C-ից D, և հենց այն է հասնում A-ին։ Ամեն ինչ հետագայում կախված է այդ վերագրումից։

A-ն այն նորից գաղտնագրում է B-ի համար։ B-ն ապակոդավորում է արտաքին շերտը, տեսնում է C-ից D փաթեթ և փոխանցում այն դեռևս գաղտնագրված։ D-ն հեռացնում է ներքին պաշտպանությունը և հանձնում հավելվածի փաթեթը։

Այսպիսով՝ A-ն և B-ն տեսնում են ներքին վերջնակետերը և դրանց մետատվյալները, բայց նրանք չեն այն կողմերը, որոնք ապակոդավորում են հավելվածի բեռը։ Դա նախագծի իրական հատկությունն է, ոչ թե պնդում, որ C-ն, D-ն կամ հավելվածի հոսթերը վստահելի են։

Արտաքին ընտրիչները նշում են ներքին դարպասները

Այստեղ է, որ այս կառույցների մեծ մասը ձախողվում է։ Քաղաքականության վրա հիմնված արտաքին թունելի համար այն ընտրիչները, որոնք դուք բանակցում եք, պետք է պարունակեն այն հասցեները, որոնք A-ն և B-ն իրականում զբաղեցնում են՝ 10.60.0.2/32 և 10.70.0.2/32, ճիշտ տեղական և հեռավոր հերթականությամբ։

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

Մի՛ նեղացրեք արտաքին թույլտվությունը մինչև UDP 500։ Ներքին կապն ունի իր տվյալների ուղին, որն օգտագործում է ESP կամ UDP ինկապսուլյացիա՝ կախված նրանից, թե ինչ է բանակցել, և արտաքին քաղաքականությունը պետք է թույլատրի այդ արձանագրությունը։

Ստուգեք արդյունքը swanctl --list-sas ով յուրաքանչյուր դարպասում և համոզվեք, որ զավակ անվտանգության ասոցիացիաները հայտնում են ձեր նախատեսած հասցեները, ոչ թե ենթադրվածները։ Եթե ցանկը ցույց է տալիս հավելվածային ենթացանցերը, ապա արտաքին քաղաքականությունը գրված է սխալ շերտի համար։ Ուղղեք ընտրիչները նախքան երթուղավորումը կարգաբերելը, քանի որ երթուղավորումը լավ կերևա, իսկ հաշվիչները չեն շարժվի։

Փոխանցումը և ռեկուրսիայի թակարդը

Ընտրիչները չեն փոխարինում երթուղավորմանը։ A-ն և B-ն պետք է փոխանցեն երթևեկությունը C-ի և D-ի միջև երկու ուղղություններով, ինչը նշանակում է միացված IP փոխանցում, թունելին ուղղված երթուղիներ և հակառակ կողմում գոյություն ունեցող վերադարձի ուղի։

Եթե արտաքին թունելը օգտագործում է XFRM ինտերֆեյսներ, երթուղիներն ընտրում են ինտերֆեյսը, մինչ բանակցված քաղաքականությունները դեռ սահմանափակում են, թե ինչ է այն կրում։ Ինտերֆեյսը չի ընդլայնում պաշտպանվածը. այն միայն փոխում է, թե ինչպես է միջուկը վերցնում փաթեթը։

Թակարդը ռեկուրսիան է։ A-ի երթուղին դեպի B-ի արտաքին վերջնակետ պետք է հետևի ստորին ցանցին, ոչ թե A-ի կառուցած թունելին, հակառակ դեպքում ինկապսուլյացիան փորձում է ճանապարհորդել ինքն իր մեջ, և կապը երբեք չի ավարտվում։

Ուսումնասիրեք թարգմանությունը նախքան շերտեր ավելացնելը

Նայեք A-ի և B-ի ցանկացած աղբյուր NAT-ին նախքան որևէ այլ բան կարգավորելը։ Կանոնը, որը վերագրում է C-ի հասցեն նախքան IPsec քաղաքականության կիրառվելը, կարող է կոտրել համաձայնեցված ընտրիչները, և կարող է նաև փոխել, թե ինչ է D-ն ստանում մյուս կողմում։

Լայն քողարկումը երկու շերտ ունենալուց ավելի ապահով չի դառնում։ Այն թաքցնում է, թե որ հասցեն է տեսնում հեռավոր կողմը, և դա հենց այն տեղեկությունն է, որ ձեզ պետք է, երբ թունելը միացած է, իսկ հավելվածը՝ ոչ։

Եթե NAT կանոնն իսկապես անհրաժեշտ է, գրեք՝ յուրաքանչյուր կողմն ինչ հասցեի հետ է կարծում, որ խոսում է։ Այդ մեկ տողը լուծում է վեճերի մեծ մասը՝ թունե՞լն է մեղավոր, թե՞ թարգմանությունը։ Այն նաև ասում է հաջորդ ինժեներին, թե որտեղ նայի, երբ կանոնը մեկ տարի անց հեռացվի։ Ping-ը դրանցից ոչ մեկը չի անի։

Ապացուցեք fail-closed-ը և ստուգեք MTU-ն

Երթուղու անհետանալն ինքնին fail-closed քաղաքականություն չէ։ Մեկ այլ աղյուսակ, լռելյայն երթուղի կամ քաղաքականության կանոն կարող են լուռ ապահովել այլընտրանք, և իմանալու միակ ճանապարհը արտաքին թունելն իջեցնելն ու դիտելն է, թե ինչ է անում հավելվածի երթևեկությունը։ Արեք դա դիտավորյալ, պատուհանում, փոխարենը պատահաբար հայտնաբերելու։

Փորձարկեք երեք վիճակ՝ արտաքին թունելն իջեցված, ներքինը՝ իջեցված, և վերականգնումը երկուսի վերադառնալուց հետո։ Օգտագործեք քաղաքականության հաշվիչներ յուրաքանչյուր դարպասում, քանի որ երկու հաստատված IKE սեսիաները միայն ապացուցում են, որ կառավարման հարթության բանակցությունը հաջողվել է։

Հաշվարկեք երկու ինկապսուլյացիաներն էլ։ Աշխատող IKE-ն փոքր փաթեթների արդյունք է, և լրիվ չափի հավելվածային փաթեթները դեռ կարող են ձախողվել, երբ ավելանում են երկու վերնագիր. փորձարկեք հայտնի բեռի չափով իրական ուղու վրա՝ փոխարենը ենթադրելու, որ թվերը գումարվում են։ Թվաբանությունը հեշտ է, ուղին՝ ոչ։