tun0 չկա՞ — համապատասխանեցրե՛ք ապակոդավորված IPsec-ը nftables-ում meta ipsec-ով

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

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

Երկու փաթեթ, մեկ ինտերֆեյս

Պատկերացրե՛ք ներթափանցող ուղղությունը։ Գալիս է ESP-ով կամ UDP-ով փաթաթված փաթեթ, միջուկը գտնում է համապատասխան քաղաքականությունը, ապակոդավորում է այն և մաքուր փաթեթը հանձնում է փոխանցման ուղուն։ Կանոնը, որը նայում է միայն ինտերֆեյսի անվանը, չի կարող այդ փաթեթը տարբերել նույն լարով եկող ցանկացած այլ երթևեկությունից։

Այն առանձնացնում է փաթեթին կցված ներթափանցող անվտանգության ուղու համատեքստը։ nftables-ը ցուցադրում է այն որպես meta ipsec exists, որը ճիշտ է, երբ փաթեթը եկել է IPsec անվտանգության ուղով։ Միավորե՛ք այն հաճախորդների լողավազանի, նպատակակետի և ծառայության հետ, և կանոնը դառնում է բավական կոնկրետ՝ անվտանգ լինելու համար։

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

Գրե՛ք փոխանցման կանոնը

Ենթադրե՛ք նույնականացված IPv4 հեռավոր մուտքի ծառայություն՝ 10.90.0.0/24-ում հաճախորդներով և մեկ հաստատված նպատակակետ 203.0.113.40-ում։ Այդ հոսքի համար կանոնի հատվածը այսպիսին է։

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

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

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

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

Ներթափանցող համատեքստը ելքային համատեքստ չէ

Նույն արտահայտությունների ընտանիքը ծածկում է մյուս ուղղությունը rt ipsec-ով, որը նկարագրում է այն ելքային անվտանգության ասոցիացիան, որը փաթեթը կօգտագործի։ Այն պատասխանում է այլ հարցի՝ ոչ թե որտեղից է եկել այս փաթեթը, այլ արդյոք այն պաշտպանված կլինի իր հաջորդ հատվածում։

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

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

NAT-ը հրադատարի որոշում չէ

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

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

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

Ստուգե՛ք ճշգրիտ ներքին ծառայությունը

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

nftables-ի տեղեկատուն փաստագրում է meta ipsec-ը, rt ipsec-ը և ուղղությանը հատուկ արտահայտությունները, և հենց այնտեղ է, որ պետք է ստուգել շարահյուսությունը ձեր տեղադրված տարբերակի հետ։ Եվ պահե՛ք ընդգրկույթը բացահայտ՝ սա IPv4-ի օրինակ է, այն ոչինչ չի ասում IPv6-ի մասին և կամայական հանրային պորտերի փոխանցումը VPN ծառայության մաս չի դարձնում։