strongSwan-ում լրիվ թունելը պահանջում է 0.0.0.0/0 երկու կողմերում

strongSwan-ի միացումը, որն աշխատում է մեկ մասնավոր ենթացանցի համար, չի փոխանցի ինտերնետային երթևեկություն միայն այն պատճառով, որ ինչ-որ մեկը փոխել է մեկ տող։ Լրիվ թունելը երկու կողմերի համաձայնությունն է այն մասին, թե որ հասցեներն է պաշտպանում child SA-ն, և յուրաքանչյուր կողմ մյուսին անվանում է իր նկատմամբ։ Մի կողմը ճիշտ դարձրեք, մյուսը՝ սխալ, և child SA-ն կամ չի բարձրանա, կամ կբարձրանա նախատեսվածից նեղ։ Ստորև բերված հինգ ստուգումները հետևում են այդ համաձայնությանը կլիենտից՝ դարպասով, դեպի ինտերնետ։

Նախ ստուգեք կլիենտի ընտրիչը

Կլիենտը նկարագրում է, թե ինչ է ուզում պաշտպանել հեռավոր կողմում, որպես remote_ts, և այն ամենը, ինչ ուղարկում է, գալիս է իր իսկ հատկացված հասցեից։ Ինտերնետային երթևեկության համար այդ արժեքը պետք է ծածկի այն նպատակակետերը, որոնց օգտատերը իրականում կհասնի, ինչը գործնականում նշանակում է ամբողջ IPv4 տարածությունը։ Կլիենտը, որը դեռ թվարկում է մեկ ենթացանց, բաժանված թունել է խնդրում, ինչպես էլ պրոֆիլը կոչվի միջերեսում։ Աղբյուրի կողմը սովորաբար dynamic է, քանի որ հասցեն հատկացվում է միանալու պահին։ Այնտեղ գրված ֆիքսված աղբյուրը կոտրվում է հենց որ հասցեների լողավազանը փոխվի։

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Այս հատվածը ամբողջական միացման ֆայլ չէ, և այն ենթադրում է, որ նույնականացումը, ինքնությունները և վիրտուալ հասցեների լողավազանը արդեն կարգավորված են։ Կլիենտի աղբյուրի ընտրիչը և սերվերի հատկացրած հասցեն դեռ պետք է համընկնեն, այլապես child SA-ն կբարձրանա այնպիսի ծավալով, որ ոչ մի կողմ չէր սպասում։ Բեռնեք այն swanctl --load-all-ով և կարդացեք ելքը՝ նախքան հաջողություն ենթադրելը։ Ֆայլը, որը վերլուծվում է, դեռ կարող է մերժվել ընտրիչի պատճառով, որը չի համընկնում մյուս կողմի առաջարկի հետ։

Ստուգեք դարպասի ընտրիչը նրա սեփական կողմում

Դարպասը նույն հասկացությունը կարդում է հակառակ ուղղությամբ։ Ինտերնետային նպատակակետերը դարպասի համար տեղական են, ուստի նրա local_ts-ը լայնն է, և remote_ts-ը նկարագրում է կլիենտների լողավազանը։ Այդ շրջումը լրիվ թունելի կարգավորման մեջ ամենատարածված սխալն է, և այն անցնում է վերանայումից, քանի որ երկու տողերն առանձին վստահելի են թվում։

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Կլիենտի հատվածը դարպասի ֆայլում պատճենելը ստեղծում է ընտրիչների զույգ, որը ոչ մի օգտակար բան չի նկարագրում, քանի որ երկու կողմերն էլ կհավակնեին նույն դերին։ strongSwan-ի փոխանցման ուղեցույցը բացահայտ փաստագրում է կլիենտի և դարպասի զուգավորումը, և արժե այն կարդալ միացման ֆայլի կողքին, ոչ թե ձախողումից հետո։ Դարպասի ֆայլին անհրաժեշտ է նաև այն լողավազանի սահմանումը, որին հղում է անում remote_ts-ը։ Անգոյություն լողավազան անվանող ընտրիչը բեռնվում է առանց բողոքի և ձախողվում է միանալիս։

Հին ipsec.conf-ը օգտագործում է ձախ և աջ դերեր տարբեր բանալիներով, և rightsubnet տողը swanctl արժեքի ուղղակի փոխարինում չէ։ Պահեք երկու շարահյուսությունները առանձին ֆայլերում՝ մեկը մյուսի մեջ տեղադրելու փոխարեն։ Դրանք մեկ պանակում խառնելը այն ճանապարհն է, որով աշխատող միացումը վերագործարկումից հետո լուռ հետ է վերադառնում։

Ստուգեք բանակցված child SA-ն, ոչ թե ֆայլը

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

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Առաջին հրամանը ցույց է տալիս, թե ինչ է բեռնել դեմոնը, երկրորդը՝ հաստատված child SA-ները, իսկ երրորդը՝ այն քաղաքականությունները, որոնք կկիրառի միջուկը։ Եթե ֆայլն ասում է 0.0.0.0/0, իսկ ցանկը ցույց է տալիս մեկ ենթացանց, բանակցությունը նեղացրել է ծավալը, և ֆայլը նորից կարդալը դա չի բացատրի։ Ավարտեք child-ը, վերսկսեք այն և նորից համեմատեք բոլոր երեք ելքերը։ Նույն նեղ ծավալով վերադարձող child-ը նեղացվում է հեռավոր կողմի, ոչ թե տեղական ֆայլի կողմից, և դա զրույց է մյուս ադմինիստրատորի հետ, ոչ տեղական փոփոխություն։

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

Ստուգեք փոխանցումը և վերադարձի ուղին

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

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

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

Ստուգեք, թե թունելը դեռ ինչ չի ծածկում

Ընտրիչների զույգը ծածկում է IPv4-ը և ոչ այլ բան։ IPv6-ը, DNS-ը և ցանկացած հավելվածային մակարդակի քաղաքականություն առանձին որոշումներ են, որոնք լայն IPv4 ընտրիչը լուռ անտեսում է։ Յուրաքանչյուր IPv4 փաթեթ կրող թունելը դեռ կարող է արտահոսել յուրաքանչյուր անվան որոնում։

Հստակ նշեք նախատեսված DNS ուղին, քանի որ լրիվ թունելը, որը դեռ լուծում է անունները տեղական լուծիչով, արտահոսում է հարցումները թունելից դուրս և կոտրում մասնավոր անունները։ Եթե կլիենտին IPv6 հասցե է հատկացվում, այդ հասցեների ընտանիքին նույն վերաբերմունքն է պետք, այլապես հոսթը կնախընտրի ուղի, որը թունելը չի պաշտպանում։ Փորձարկեք անունով, որին միայն մասնավոր կողմը կարող է պատասխանել, և հանրային պատասխանը համարեք արտահոսք։

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Հաստատեք շղթան այդ երկու հրամաններով և վերևի ցանկից բանակցված ընտրիչներով։ Եթե traceroute-ը ցույց է տալիս տեղական երթուղիչը որպես առաջին թռիչք, երթևեկությունը չի օգտագործում թունելը, ինչ էլ պնդեն ընտրիչները։ Ինտերնետ հասանելիությունը լրիվ է միայն այն ժամանակ, երբ ընտրված երթևեկությունը ընդունվում, փոխանցվում և վերադարձվում է նախագծված դարպասով։ 0.0.0.0/0-ը պրոֆիլում գտնելը այդ շղթայի սկիզբն է, ոչ թե ապացույցը։