Ինչու OpenVPN երթուղին պարտվում է strongSwan-ի XFRM քաղաքականությանը
Կոնկրետ OpenVPN երթուղին չի վերացնում XFRM քաղաքականությունը․ կարդացեք երթուղին և քաղաքականության ընտրիչները, ապա նեղացրեք, բացառություն արեք կամ անցեք XFRM ինտերֆեյսի։
Փաթեթները կարող են հետևել OpenVPN երթուղուն և միևնույն ժամանակ ընկնել IPsec քաղաքականության տակ, և այդ համակցությունը բոլոր անկյուններից երթուղավորման սխալ է թվում, բացի ճիշտից։ Linux-ը լուծում է երթուղին, ապա դիմում առանձին անվտանգության քաղաքականությունների տվյալների բազային, ուստի ավելի կոնկրետ նպատակակետ երթուղին չի տեղահանում համապատասխան XFRM քաղաքականությունը։ Տեսանելի ախտանիշն այն երթևեկությունն է, որը լքում է հոսթը և երբեք չի հասնում, մինչդեռ երկու թունելներն էլ իրենց առողջ են հայտարարում։ Երեք տարբերակ լուծում է այն, և թե որն ընտրեք, կախված է նրանից, թե երկու ուղիներից որն է նախատեսված կրելու այդ նախածանցը։
Երկու որոշում, ոչ մեկը
Երթուղու ընտրությունը պատասխանում է նեղ հարցի․ ո՞ր հաջորդ ցատկը և աղբյուրի հասցեն պետք է կրեն այս փաթեթը։ Անվտանգության քաղաքականությունների բազան պատասխանում է մեկ այլ հարցի․ արդյո՞ք այս փաթեթը պահանջում է IPsec պաշտպանություն, և ո՞ր ընտրիչների ներքո։ Երկուսն էլ աշխատում են նույն փաթեթի համար, և առաջինը բավարարելը ոչինչ չի ասում երկրորդի մասին։ Այդ պատճառով մետրիկայի փոփոխությունը կամ ստատիկ երթուղու ավելացումը կարող է ախտանիշը թողնել անփոփոխ։
Լայն IPsec ընտրիչը սովորական պատճառն է։ 172.16.0.0/12-ը պաշտպանող քաղաքականությունը ծածկում է նաև 172.20.8.0/24-ը, ուր ադմինիստրատորը կարող է մտադիր լինել հասնել OpenVPN թունելով։ Մտադրությունը գոյություն ունի միայն երթուղային աղյուսակում, և քաղաքականությունների բազան երբեք չի իմացել դրա մասին։
Դիտեք դա որպես երկու կազմաձևված պաշտպանության ուղիների միջև հակամարտություն, ոչ որպես երկու մետրիկաների մրցույթ։ Ուղղումը պատկանում է այն բաղադրիչին, որը կազմաձևվել է սխալ ծածկույթով։
Կարդացեք այն երթուղին, որն իրականում ընտրում է միջուկը
Սկսեք այն որոնումից, որն անում է միջուկը, ներառյալ աղբյուրի հասցեն և ցանկացած քաղաքականության կանոն, որը կարող է այն շեղել այլ աղյուսակ։ Հիմնական աղյուսակի երթուղին կարող է երբեք չդիտարկվել, եթե ավելի վաղ կանոնը ընտրում է այլ աղյուսակ, և ամենաերկար նախածանցի համընկնումը գործում է միայն այն աղյուսակի ներսում, որն ընտրում է կանոնը։
ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15Վերջին հրամանն է կարևորը, քանի որ այն տպում է ընտրված երթուղին այն աղբյուրի հասցեի հետ, որը կօգտագործեր միջուկը։ Համեմատեք այդ ելքը այն ընտրիչի հետ, որին համապատասխանում է IPsec քաղաքականությունը։ Երբ երթուղին ուղղված է OpenVPN ինտերֆեյսին, և քաղաքականությունը դեռ համապատասխանում է նույն զույգին, դուք վերարտադրել եք հակամարտությունը առանց գուշակության։
Թողեք dumps-երը զերծ անկապ հասցեներից նախքան դրանք տոմսի հասնելը։ Արտադրական հոսթի երթուղային աղյուսակը կրում է ներքին տոպոլոգիա, և միայն հարցին պատասխանող տողերն են արժե փակցնել։
Կարդացեք նաև այն քաղաքականությունը, որը նույնպես գործում է
Քաղաքականությունների ցանկը ցույց է տալիս ուղղությունը, ընտրիչները և ձևանմուշը, որը որոշում է, թե ինչ է լինում համապատասխան փաթեթի հետ։ Սկզբում կարդացեք ելքային ուղղությունը, ապա մուտքային կողմը վերադարձի երթևեկության համար, քանի որ միակողմանի բացառությունը ստեղծում է միացում, որը սկսվում է և երբեք չի ավարտվում։
ip -s xfrm policy
swanctl --list-sasՀամեմատեք ցանկի ընտրիչները այն նախածանցերի հետ, որոնց շուրջ պայմանավորվել է միացումը։ strongSwan-ի երթուղիների տեղադրման անջատումը չի հեռացնում այդ քաղաքականությունները, և մետրիկայի փոփոխությունը չի փոխում, թե որ աղբյուր-նպատակակետ զույգն է պաշտպանում քաղաքականությունը։ Այս երկու կեղծ ուղղումները արժե վաղ բացառել, որովհետև մարդիկ սկզբում դրանք են փորձում։
Եթե ցանկում չկա քաղաքականություն սպասված նախածանցի համար, խնդիրը այլ տեղ է, և երթուղային աղյուսակը հավանաբար ճշմարտությունն է ասում։ Եթե այն պարունակում է ավելի լայն քաղաքականություն, որը ծածկում է նախածանցը, դուք գտել եք որսումը։
Երեք տարբերակ, երբ երկու ուղիներն էլ օրինական են
IPsec ընտրիչի նեղացումը ամենամաքուր տարբերակն է, երբ լայն նախածանցը հարմարավետություն էր, ոչ պահանջ։ Հեռավոր երթևեկության ընտրիչը կրճատելով այն ենթացանցերով, որոնք իսկապես պատկանում են IPsec-ի հետևում, հակամարտությունը հանվում է բոլոր հոսթերի համար միանգամից, և դա արժե բանալու վերաբանակցում, ոչ նոր բաղադրիչ։
Անցումային բացառությունը վիրաբուժական տարբերակն է, երբ լայն ընտրիչը պետք է մնա։ strongSwan-ը աջակցում է առանձին միացում, որի child-ը օգտագործում է pass ռեժիմ, ինչը միջուկին ասում է, որ համապատասխան երթևեկությունը չպետք է մշակվի IPsec-ով։ Loopback հեռավոր հասցեն պահում է այդ միացումը ընտրվելուց մուտքային գործընկերների համար, և ընտրիչները պետք է նկարագրեն իրական լիազորված զույգը, ոչ թե ամեն ինչ։
connections {
openvpn-exception {
remote_addrs = 127.0.0.1
children {
openvpn-exception {
local_ts = 10.44.7.0/24
remote_ts = 172.20.8.0/24
mode = pass
start_action = trap
}
}
}
}strongSwan-ի կազմաձևման օրինակները փաստագրում են այս քաղաքականության տեսակը և loopback գործընկերոջ կոնվենցիան։ Երրորդ տարբերակը երթուղային հիմքով դիզայն XFRM ինտերֆեյսներով է, որը քաղաքականությունը կապում է անվանված ինտերֆեյսով երթուղավորված երթևեկությանը՝ համաշխարհային ընտրիչի փոխարեն։ Դա միգրացիա է, ոչ կարգաբերում, և երթևեկությունը դեռ պետք է բավարարի պայմանավորված ընտրիչներին։
| Option | Use it when | Cost |
|---|---|---|
| Narrow the selector | The broad prefix was convenience | A rekey and a policy review |
| Passthrough child | The broad selector must stay | One exception per intended pair |
| XFRM interface | Policy should follow routing | A design migration |
Ապացուցեք բացառությունը՝ չթուլացնելով մնացածը
Փոփոխությունը բեռնելուց հետո փորձարկեք բացառությունը և սովորական նպատակակետ, որը պետք է մնա պաշտպանված։ Ստուգեք երկու ուղղությունները, ապա գցեք OpenVPN թունելը և հաստատեք, թե ինչ է լինում բացառված երթևեկության հետ։ Բացառություն, որը թունելն անջատված ժամանակ լուռ ուղարկում է այդ նախածանցը բաց տեսքով, քաղաքականության որոշում է, որը պետք է կայացնեք դիտավորությամբ, ոչ թե բացահայտեք միջադեպի ընթացքում։
Գրանցեք, թե որ նախածանցն որ ուղին է օգտագործում և ինչու։ Հակառակ դեպքում հաջորդ ինժեները, ով կտեսնի լայն ընտրիչ, նորից կբացի նույն հետաքննությունը, և պատասխանը կմնա commit հաղորդագրության մեջ, որը ոչ ոք չի կարդում։