Ինչու OpenVPN-ի հաճախորդի արգելափակման կանոնը երբեք չի հասնում FORWARD-ին

Նույն OpenVPN սերվերի երկու հաճախորդներ կարող են հասնել միմյանց, նույնիսկ այն բանից հետո, երբ դուք ավելացրել եք DROP կանոն նրանց փուլի համար։ Կանոնը նստած է FORWARD շղթայում, երթևեկությունը հստակ հոսում է, և այդ կանոնի հաշվիչը մնում է զրոյի վրա։ Բնական եզրակացությունն այն է, որ հրային պատը կոտրված է։ Ավելի հաճախ փաթեթը ընդհանրապես չի մտել շղթա։

Գոյություն ունի երկու ուղի, որոնցով գործընկերոջ փաթեթը կարող է անցնել OpenVPN սերվերով, և դրանք որոշվում են կոնֆիգուրացիայով, ոչ թե հրային պատով։ Իմանալը, թե որ ուղին է օգտագործվում, ասում է ձեզ՝ արդյոք հոսթի կանոնը նույնիսկ ճիշտ տեղում է։

Երկու ուղի, որոնցով կարող է անցնել գործընկերոջ փաթեթը

Երբ ներքին փոխանցման ընտրանքն անջատված է, A հաճախորդից փաթեթը հասնում է թունելի ինտերֆեյս՝ նշանակված հասցեի ներսում գտնվող նպատակակետով, որը պատկանում է B հաճախորդին։ Սերվերի երթուղային աղյուսակը հետ է ուղարկում այն նույն թունելի ինտերֆեյսով, քանի որ B-ի հասցեի երթուղին պատկանում է սերվերին։ Սա ներս-դուրս հոսք է հոսթի միջով, և այն գնահատում է IPv4 փոխանցման ուղին։

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

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

Երբ հաշվիչը երբեք չի շարժվում

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

Երրորդը դիրքն է։ Շղթայում ավելի վաղ կանոնը կարող է ընդունել հոսքը մինչև ձեր DROP-ի գնահատումը, իսկ ավելի ուշ կանոնը կարող է լինել այն, ինչն իրականում որոշում է արդյունքը։ Կարդացեք շղթան հերթականությամբ՝ տեսանելի հաշվիչներով, ապա ստուգեք, թե որ կանոնի հաշվարկն է աճում, երբ կրկնում եք փորձարկումը։

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

Ընտրել սահման, որը կարող է զտել

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

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

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

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

Մեկուսացման փորձարկում՝ կանոնին վստահելու փոխարեն

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

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

Մեկուսացումը դիտարկված արդյունքն է այն սահմանում, որն իրականում կրում է հոսքը։ Հոսթի ինչ-որ տեղ DROP կանոնը ապացույց չէ՝ ձախողված կապը և այն առաջացրած կանոնի շարժված հաշվիչը ապացույց են։