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

Պայմանագիրը փոքր է՝ նույնականացրեք ուղարկված հաշիվը, հարցրեք հաստատված ստուգիչին նախատեսված հարցը և ընդունեք միայն այդ ստուգիչի փաստաթղթավորված դրական արդյունքը տվյալ հարցման համար։ Մնացած ամեն ինչ ենթակառուցվածք է։

Երեք կարգավիճակները, որոնք փոխանցուղին կարող է վերադարձնել

auth-user-pass-verify համար OpenVPN 2.6 ձեռնարկը ելքի կոդ 0-ը սահմանում է որպես ընդունում, 1-ը՝ մերժում, իսկ 2-ը՝ հետաձգված նույնականացում։ Սրանք են միայն այն երեք պատասխանները, որ հասկանում է սերվերը, և յուրաքանչյուրն ունի տարբեր հետևանք կապի համար։ Սկրիպտը, որը դուրս է գալիս իր վերջին հրամանի կարգավիճակով, փաստորեն թույլ է տվել մատյանի կանչին կամ մաքրման քայլին քվեարկել։ Կարգավիճակը հստակ գրեք յուրաքանչյուր ճյուղում, ներառյալ այն ճյուղերը, որոնք երբեք չեն հասել ստուգիչին։

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

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

Կարդացեք վկայականի ֆայլը ճիշտ այնպես, ինչպես գրված է

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

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

Որոշեք, թե ինչ է նշանակում չդասակարգվող պատասխանը

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

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

Սերվերի կարգավորումը նույնպես կարևոր է այստեղ՝ օգտվողի կողմից սահմանված սկրիպտները հարգվում են միայն այն դեպքում, երբ ընթացիկ կարգավորումը թույլ է տալիս դրանք պահանջվող անվտանգության մակարդակում, և այդ պարամետրը գիտակցված ընտրություն է, ոչ թե բարձրացվող լռելյայն արժեք։

Ստուգեք դատողությունը, ոչ տպված տողը

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

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

Պահեք ստուգիչի արդյունքից ելքի կարգավիճակի քարտեզագրումը սկրիպտի կողքին պահոցում, որպեսզի հաջորդ ինժեները կարողանա կարդալ պայմանագիրը առանց կոդի հակադարձ ինժեներիայի։

Առնչվող հոդվածներ