strongSwan-ի trap ռեժիմը. ինչու է IPsec թունելը սպասում տրաֆիկին

Կարգավիճակի արտածման մեջ CHILD SA չի հայտնվում, թունելը մեռած է թվում, և հետո հեռավոր ենթացանցին ուղղված ping-ը բարձրացնում է այն։ Ըստ պահանջի IPsec կարգավորումում այս հաջորդականությունը նախագիծն է, ոչ թե խափանում։ Trap քաղաքականությունը տեղադրում է ընտրիչ և սպասում, և հենց առաջին համապատասխան փաթեթն է սկսում IKE-ն և CHILD SA բանակցությունը։

Շփոթմունքի մի մասը բառապաշարն է. «up»-ը օգտագործվում է երկու տարբեր վիճակների համար։ Կոնֆիգուրացիան բեռնված է, և միջուկի քաղաքականությունը գոյություն ունի, իսկ տվյալների միավորումը՝ ոչ։ Մոնիտորը, որը հաշվում է միայն ակտիվ SA-ներ, առողջ կայքը կհայտարարի անջատված, քանի դեռ ոչ ոք տրաֆիկ չի ուղարկում դրան։

Անգործուն ըստ պահանջի թունելը CHILD SA չունի ցուցադրելու

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

Հենց այդ հաջորդականությունն է լոգերը ընթեռնելի դարձնում։ Սկզբում գալիս է acquisition-ը, հետո՝ IKE_SA_INIT-ը և IKE_AUTH-ը, ապա՝ CHILD SA-ն։ Եթե լոգն ավարտվում է acquisition-ից անմիջապես հետո, գործարկիչն աշխատել է։ Բանակցությունը ձախողվել է, և հաջորդ հարցը վերաբերում է հավատարմագրերին, առաջարկներին կամ հասանելիությանը, ոչ թե trap-ին։

Linux միջուկի backend-ով կարող եք տեսնել քաղաքականությունը մինչև որևէ SA-ի գոյությունը։ Գործարկեք ip xfrm policy և փնտրեք out ուղղությամբ և միացմանը ցուցմունք տվող ձևանմուշով ընտրիչը։ Այդ գրառումը ըստ պահանջի վիճակն է, և դրա առկայությունը առաջին բանն է, որ պետք է հաստատել։

start_action-ը որոշում է, թե արդյոք ընդհանրապես ինչ-որ բան կսպասի

Յուրաքանչյուր child swanctl.conf ֆայլում start_action. start սկսվում է կոնֆիգուրացիայի բեռնման ժամանակ, trap տեղադրում է քաղաքականությունը և սպասում, իսկ none մեկնարկը թողնում է մեկ այլ բանի։ Միայն trap է առաջացնում վերևում նկարագրված «ping, և այն բարձրանում է» վարքը։

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Երկու տրաֆիկի ընտրիչները սահմանում են, թե ինչն է համարվում հետաքրքիր, և այդ նախադիրներից դուրս գտնվող հոսթից եկած փաթեթը trap-ը չի գործարկում. այն երթուղվում է սովորականի պես։ Ընտրիչների լայնացումը՝ գործարկիչն ավելի պատրաստակամ դարձնելու համար, լայնացնում է նաև այն շրջանակը, որը թունելը պնդում է, թե պաշտպանում է, ուստի դրանք բխեցրեք այն տրաֆիկից, որը իսկապես մտադիր եք գաղտնագրել։

Այստեղ swanctl.conf-ի տեղեկատուն թվարկում է ընդունված արժեքները՝ առանձին close և DPD գործողությունների հետ միասին, որոնք կարգավորում են, թե ինչ է լինում SA-ի գոյությունից հետո։

Պարզեք՝ արդյոք գործարկիչն ընդհանրապես գործարկվել է

Սկսեք swanctl --list-conns-ով և հաստատեք, որ child-ը բեռնված է ձեր նախատեսած գործողությամբ։ Այնուհետև մեկ փաթեթ ուղարկեք local_ts-ի ներսում գտնվող հոսթից remote_ts-ի ներսում գտնվող հասցեին և հետևեք swanctl --list-sas-ին։ Եթե արտածումը չի փոխվում, ոչ մի acquisition չի հասել դեմոնին։

Լուռ trap-ի երկու սովորական պատճառ. փաթեթը source-NAT-վել է մինչև քաղաքականությանը հանդիպելը և այլևս չի համապատասխանում local_ts-ին, կամ կապը երբեք չի բեռնվել շարահյուսության կամ հավատարմագրերի սխալի պատճառով։ Կրկին գործարկեք swanctl --load-all-ը և կարդացեք դրա արտածումը նախքան ընտրիչներին դիպչելը։ Չբեռնված կապը քաղաքականություն չի տեղադրում, ուստի տրաֆիկի գործարկելու բան չկա։

Ուղղությունը նույնպես կարևոր է. ելքային տրաֆիկի համար տեղադրված trap-ը չի սկսվում մուտքային փաթեթով։ Եթե հեռավոր կողմը պետք է բարձրացնի թունելը, նրան պետք է սեփական trap, կամ այս կողմին պետք է start.

Առաջին փաթեթին սպասելը միշտ չէ, որ ճիշտ փոխանակում է

Ինտերակտիվ սեանսները զգում են տեղադրման արժեքը։ Առաջին հարցումը վճարում է IKE փոխանակության և CHILD բանակցության համար, և կարճ ժամկետ ունեցող հաճախորդը կարող է հանձնվել մինչև SA-ի գոյությունը։ start նախաձեռնողականը վերացնում է այդ առաջին փաթեթի ուշացումը։ Բայց այն թունելը բաց է պահում տրաֆիկի համար, որը գուցե երբեք չգա։

Երեք փաստ է որոշում ընտրությունը. որքան հաճախ է օգտագործվում ուղին, արդյոք առաջին հարցումն ունի խիստ ժամկետ, և արդյոք գործընկերը հասանելի է բեռնման պահին։ Առիթից առիթ խմբաքանակային տրաֆիկը և բեռնման պահին հնարավոր է օֆլայն գործընկերը երկուսն էլ նպաստում են trap-ին։ Հապաղման նկատմամբ զգայուն հաճախորդը և միշտ հասանելի գործընկերը նպաստում են start-ին։ Եթե երկու կողմերն էլ կարող են սկսել, պայմանավորվեք, թե ով է տիրում գործարկիչին, որպեսզի կրկնակի բանակցություններ չլինեն։

Տեղադրված քաղաքականությունը նույնպես արտահոսքից ապահով երաշխիք չէ։ Եթե պահանջը fail-closed է, հրդեպատը պետք է դեն նետի առանց SA տրաֆիկը, և այդ կանոնը ապրում է child-ի սահմանումից դուրս։

Գրառեք երեք տողերը, որոնք կավարտեն հաջորդ վեճը

Գրեք ընտրիչները, մեկնարկի գործողությունը և հրամանի արտածումը, որը ցույց է տալիս քաղաքականության առկայությունը առանց SA-ի։ Այդ երեք տողերը բաժանում են «ըստ պահանջի և անգործուն» վիճակը «չի բեռնվում» վիճակից հաջորդ անգամ, երբ ինչ-որ մեկը թունելը անջատված կհայտարարի։ Դրանք գրանցելը մեկ րոպե է տևում։ Առանց դրանց նույն հետաքննությունը սկսվում է զրոյից։

Փորձարկեք հոսթից, որն իսկապես ընտրիչի ներսում է։ Ռոուտերից արված ping-ը հաճախ այլ ուղի է անցնում և ոչինչ չի ապացուցում նրա հետևում գտնվող ենթացանցը պաշտպանող քաղաքականության մասին։