Ինչու IPsec անվտանգության քաղաքականությունը երթուղային աղյուսակի գրառում չէ

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

Սկսեք որոնումից, ոչ աղյուսակից

Հարցրեք միջուկին, թե իրականում ինչ կանի՝ ip route get 10.20.0.5-ը տպում է ընտրված երթուղին, ելքային ինտերֆեյսը և այն աղբյուրի հասցեն, որը կօգտագործի։ Նախածանցը, քաղաքականության կանոնը, նշանը կամ նախընտրելի աղբյուրը կարող են փոխել այդ պատասխանը, այդ պատճառով կենդանի որոնումը գերազանցում է աղյուսակը աչքով կարդալուն։

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

Համապատասխանեցրեք ընտրիչները երկու կողմերում

Քաղաքականության տվյալների բազան ունի իր գրառումները, և յուրաքանչյուրը նշում է ուղղություն, աղբյուր, նպատակակետ և արձանագրություն, ապա ասում, թե ինչ պետք է պատահի համապատասխան փաթեթներին։ Օգտագործեք ip xfrm policy-ն դրանք թվարկելու համար՝ դրոշները ցույց են տալիս՝ գործողությունը պաշտպանություն է, շրջանցում, թե արգելափակում։ Քաղաքականությունը, որի ընտրիչները ավելի լայն կամ նեղ են, քան ձեր փորձնական հոսքը, չի համապատասխանի դրան, և փաթեթը դուրս է գալիս անպաշտպան։ Դա այն խափանումն է, որ փնտրում եք, ոչ թե բացակայող երթուղի։

Համեմատեք փաստացի արժեքները՝ աղբյուր, նպատակակետ, արձանագրություն և նավահանգիստներ։ Եթե որոնումը լուծել է հասցեների մի զույգ, մինչդեռ քաղաքականության գրառումը ծածկում է մյուսը, երկու տեսակետները նկարագրում են տարբեր երթևեկություն։ Նորից գործարկեք երկուսն էլ նույն բազմությամբ՝ նախքան եզրակացություն անելը, այլապես կխմբագրեք քաղաքականություն, որը երբեք ուղու վրա չի եղել։

Քաղաքականության համընկնումը տեղադրված վիճակ չէ

Համապատասխան քաղաքականությունը միայն ասում է, որ փաթեթը պետք է պաշտպանվի՝ միջուկին դեռ պետք է անվտանգության ասոցիացիա՝ պաշտպանությունն իրականացնելու համար։ Թվարկեք դրանք ip xfrm state-ով, կամ swanctl --list-sas-ով, երբ strongSwan-ն է բանակցում, և կարդացեք յուրաքանչյուր գրառման ընտրիչներն ու հաշվիչները։

Երբ քաղաքականությունը համապատասխանում է, և ոչ մի ասոցիացիա չի ծածկում նույն ընտրիչները, փաթեթը դեն է նետվում՝ բաց տեքստով ուղարկելու փոխարեն։ Սա այն նետումն է, որը պետք է փնտրել, երբ թունելը բարձրացված է, բայց մեկ ենթացանց ձախողվում է։ Հաշվիչները ասում են մնացածը՝ ասոցիացիան, որը երբեք չի աճում, երբեք չի ընտրվել, մինչդեռ այն, որն աճում է և այնուամենայնիվ ավարտվում է նետումով, մատնանշում է հեռավոր կողմը։ Ընտրիչների ուղղումը և բանալիների նորացումը տարբեր վերանորոգումներ են, ուստի որոշեք, թե որն է ձեզ պետք, նախքան կարգավորումներին դիպչելը։

Ինչ է դեռ պահանջում երթուղու վրա հիմնված թունելը

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

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

Պարզաբանեք սեփականությունը՝ նախքան որևէ բան խմբագրելը

Հոսթի հրապատը ավելացնում է երրորդ որոշում, որի մասին երկու տվյալների բազաներից ոչ մեկը չգիտի։ Ճիշտ երթուղին գումարած համապատասխան քաղաքականությունը գումարած տեղադրված ասոցիացիան դեռ կարող են ավարտվել նետված փաթեթով, և հավելվածը հայտնում է միայն ժամանակի սպառման մասին։ Հաստատեք, որ հրապատը թույլ է տալիս պաշտպանված երթևեկությունը, նախքան IPsec-ին մեղադրելը։ Թունելի սարքի և ֆիզիկական ինտերֆեյսի վրա որսալը ցույց է տալիս, թե գաղտնագրման որ կողմում փաթեթն անհետացավ։

Կարգավորման սեփականությունը որոշում է՝ ձեր ուղղումը կհաղթահարի՞ վերագործարկումը։ Մի բաղադրիչ կարող է վիճակ տեղադրել, մինչ մյուսը ղեկավարում է երթուղիները, և երկրորդի ձեռքով խմբագրումը վերագրվում է հաջորդ անգամ, երբ թունելը բարձրանա։ Փոխեք սեփականատեր կարգավորումը, ապա նորից կարդացեք երկու տեսակետները՝ RFC 4301-ը երկու տվյալների բազաները առանձին է պահում, երբ պետք է բացատրեք այդ բաժանումը մեկ ուրիշին։