OpenVPN client-connect-ի ձախողում. արդյո՞ք disconnect-ի մաքրումը երաշխավորված է
Մերժված հաճախորդը հետ չի վերցնում firewall-ի կանոնը կամ գրված գրառումը։ Համեմատեք callback-ի պայմանագիրը այն վերադարձի հետ, որը ձեր hook-ը պետք է ինքնուրույն կատարի։
Երբ client-connect սկրիպտը ավարտվում է ոչ զրոյական կոդով, OpenVPN-ը մերժում է հաճախորդին, և օպերատորները սովորաբար ենթադրում են, որ համապատասխան client-disconnect սկրիպտը կարգի կբերի ամեն ինչ։ Հաճախ այն ընդհանրապես չի գործարկվում, որովհետև disconnect-ի մշակումը կախված է նրանից, ինչ connect փուլը կարողացել է ավարտին հասցնել։ Մերժումն ու վերադարձը որպես մեկ մեխանիզմ դիտարկելն է այն, ինչ ձախողված մուտքը վերածում է արտահոսած firewall-ի կանոնի կամ որբ գրառման։ Դրանք երկու առանձին պարտավորություններ են, և դրանցից միայն մեկն է ավտոմատ։ Կարդացեք hook-ի սեփական ելքի ուղին նախքան սերվերին մեղադրելը վիճակ թողնելու համար։
Ոչ զրոյական ելքը մերժում է հաճախորդին, բայց չի չեղարկում ձեր աշխատանքը
client-connect-ի ելքի կարգավիճակը ընդունման որոշում է։ Զրոն նշանակում է ընդունել, ցանկացած այլ արժեք նշանակում է քանդել օրինակը մինչև այն ամբողջությամբ հաստատվելը։ Այդ պայմանագրում ոչինչ չի ստուգում, թե սկրիպտն ինչ է արդեն արել արտաքին աշխարհում։ Եթե սկրիպտը ավելացրել է iptables-ի կանոն, գրել է տող կամ ավելացրել հաշվիչ, այդ փոփոխությունները գոյատևում են մերժումից հետո։
Նույն անհամաչափությունը վերաբերում է պլագիններին, որտեղ մեկ օրինակի համար կարող են գործարկվել մի քանի connect ֆունկցիաներ։ Ավելի ուշ ձախողումը հետադարձ ուժով չի չեղարկում ավելի վաղ հաջողությունը, և ավելի վաղ ֆունկցիան որևէ կերպ չի կարող իմանալ, որ քույր ֆունկցիան ձախողվել է։
Մերժումն ավտոմատ է, մաքրումը՝ ոչ
OpenVPN 2.6-ի ձեռնարկը client-disconnect-ի մշակումը կապում է նախորդ connect-ի մշակման հաջողության հետ։ Փաստագրված բացառությունը վերաբերում է կասկադային շղթաներին. եթե connect-ի մի քայլ արդեն հաջողություն է վերադարձրել, համապատասխան disconnect քայլերը դեռ գործարկվում են օրինակը քանդելիս, նույնիսկ եթե ավելի ուշ connect քայլը ձախողվել է։ Այդ բացառությունը նեղ է և կախված է նրանից, թե քանի callback է կարգավորված, դրա համար էլ մեկ shell սկրիպտի փորձարկումը ձեզ ոչինչ չի ասում շղթայի մասին։
Քարտեզագրեք իրական կոնֆիգուրացիան նախքան դրա շուրջ ձևավորելը. որ սկրիպտը, որ պլագինը և ինչ հերթականությամբ են գործարկվում։ Ստորև բերված աղյուսակը թվարկում է, թե ինչ է թողնում կիսատ կարգավորումը։
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
Յուրաքանչյուր տող ավարտվում է նույն կերպ հաճախորդի և այլ կերպ հյուրընկալողի համար։ Հաճախորդը չի կարող ասել, թե դրանցից որն է տեղի ունեցել, ուստի hook-ը պետք է հետ վերցնի արվածը նախքան ձախողման կարգավիճակը վերադարձնելը։
Փոխհատուցեք ձախողված սկրիպտի ներսում
Ստուգեք այն ամենը, ինչ հնարավոր է, նախքան ընդհանուր վիճակին դիպչելը. վկայագրի դաշտերը, հասցեի հասանելիությունը, այն խումբը, որին պատկանում է հաճախորդը։ Ամենաէժան մերժումը այն է, որը տեղի է ունենում ցանկացած բաշխումից առաջ։ Երբ կարգավորումն ընդգրկում է մի քանի արտաքին գործողություններ, գրանցեք, թե որոնք ավարտվեցին, և ձախողման կարգավիճակը վերադարձնելուց առաջ հետ վերցրեք դրանք հակառակ հերթականությամբ։
Կոնկրետ դեպք. սկրիպտը ստեղծում է յուրաքանչյուր հաճախորդի համար firewall-ի գրառում, ապա չի կարողանում գրել այն նկարագրող վիճակի տողը։ Ձախողվող ճյուղը պետք է հեռացնի հենց նոր ստեղծած գրառումը և ապա դուրս գա ոչ զրոյական կոդով։ Սպասելը disconnect իրադարձությանը, որը գուցե երբեք չնշանակվի, հենց այն ձևն է, որով կանոնը գոյատևում է այն սեսիայից ավելի, որի համար նախատեսված էր։
Դարձրեք փոխհատուցումը իդեմպոտենտ և սեփականատեր ունեցող
Մաքրումը պետք է անվտանգ լինի երկու անգամ գործարկելու համար և ճշգրիտ այն հարցում, թե ինչ կարող է ջնջել։ Ավելի վաղ փորձի ուշ իրադարձությունը չպետք է հեռացնի ավելի նոր սեսիայի բաշխումը միայն այն պատճառով, որ երկուսն էլ ունեն ընդհանուր անուն կամ վերամշակված թունելի հասցե։ Գրանցեք կոնկրետ բռնակը կամ գործողության id-ն ռեսուրսի հետ և ջնջեք այդ բանալիով, ոչ թե անունով։ Տվյալների բազայի տրանզակցիաները օգնում են միայն տվյալների բազայի սեփական փոփոխություններին. այդ սահմանից դուրս firewall-ի կանոնը պահանջում է բացահայտ փոխհատուցման քայլ։
Ենթադրեք, որ գործընթացը կարող է մահանալ փոփոխության և մաքրման միջև, և ավելացրեք հաշտարար, որը ժամանակացույցով համեմատում է արտաքին վիճակը ընդունված հաճախորդների ցանկի հետ։
Փորձարկեք երեք ուղիները, որոնք իրոք տարբերվում են
Փորձարկեք երեք դեպք. մերժում նախքան որևէ բաշխում, մերժում մասնակի բաշխումից հետո, և սովորական ընդունված սեսիա, որն ավելի ուշ ավարտվում է։ Այդ երեքը տալիս են տարբեր լոգի տողեր և տարբեր մնացորդներ։ Ստուգեք արտաքին վիճակը յուրաքանչյուրից հետո, ոչ միայն հաճախորդի ձախողման հաղորդագրությունը, որովհետև հաճախորդի ձախողումը երեքից երկուսում սպասված արդյունքն է։
Գրանցեք hook-ի փուլը, ելքի կարգավիճակը և ինչ է բաշխվել կամ ազատվել, առանց հավատարմագրերի։ Hook-ի լոգը, որը նշում է իր ստեղծած ռեսուրսը, հենց այն է, ինչը արտահոսած կանոնը դարձնում է գտնելի վեց ամիս անց։