Արգելափակել մեկ նպատակակետային միջակայք յուրաքանչյուր VPN հաճախորդի լողավազանի համար
nftables-ի մեկ կանոնը կարող է մերժել նպատակակետային նախածանցը թույլատրված VPN լողավազանի համար՝ չշոշափելով դարպասի սեփական տրաֆիկը: Համապատասխանեցրեք hook-ը և դիրքը:
Մեկ կանոնը կարող է հեռու պահել թույլատրված VPN լողավազանը նպատակակետային միջակայքից՝ չխանգարելով դարպասի մյուս աշխատանքին: Կանոնն ինքնին կարճ է. դրա աշխատելը որոշում են այն hook-ը, որում այն ապրում է, և դիրքը շղթայում: Այս երկուսը սխալ որոշելու դեպքում ստանում եք հրամուր, որը ճիշտ է թվում և անհետևողական վարվում: Սկսեք նրանից, թե ինչ է անում փաթեթը, երբ կանոնը տեսնում է այն:
Ինչի հետ է իրականում համապատասխանում կանոնը
Կանոնը միաժամանակ համապատասխանում է երեք բանի՝ մուտքային ինտերֆեյս, աղբյուրի նախածանց և նպատակակետային նախածանց: Երեքն էլ պետք է ճշմարիտ լինեն մինչև drop-ի կիրառումը, և դա է այն նեղ պահում: Այն որպես մեկ արտահայտություն կարդալն ավելի հեշտ է, քան որպես երեք առանձին քաղաքականություն:
Ինտերֆեյսի համապատասխանությունն այն է, ինչը տարբերում է փոխանցված հաճախորդային տրաֆիկը դարպասի սեփական միացումներից: Առանց դրա՝ միայն աղբյուրի լողավազանը նշող կանոնը կազդի նաև այն փաթեթների վրա, որոնք դարպասն ինքն է ստեղծում այդ հասցեից, եթե դա երբևէ տեղի ունենա: Աղբյուրի նախածանցը քաղաքականությունը սահմանափակում է թույլատրված հաճախորդներով, իսկ նպատակակետային նախածանցը՝ մեկ միջակայքով: Կարդացեք կանոնը որպես հատում, ոչ թե ցանկ:
Գրանցեք երեք արժեքները նախքան որևէ բան խմբագրելը՝ թունելի ինտերֆեյսի անունը, սերվերի բաժանած լողավազանը և այն նախածանցը, որը մտադիր եք մերժել: Դրանցից որևէ մեկում տառասխալը ստեղծում է կանոն, որը մաքուր վերլուծվում է և ոչինչ չի պաշտպանում: Պահեք այդ երեք արժեքները փոփոխության գրառման մեջ՝ կանոնի կողքին:
hook-ը որոշում է, թե ում վրա է տարածվում կանոնը
netfilter շղթան կցված է hook-ին, և hook-ն է որոշում, թե որ փաթեթներն է շղթան ընդհանրապես տեսնում: forward hook-ը տեսնում է դարպասով երթուղավորված տրաֆիկը, և դա հենց հաճախորդից նպատակակետ տրաֆիկն է: Շղթայի մնացած ամեն ինչ ուղղված է այլ լսարանին:
input hook-ը տեսնում է հենց դարպասին ուղղված տրաֆիկը, ուստի այնտեղ տեղադրված կանոնը կառավարում է նրա սեփական ծառայությունների հասանելիությունը, ոչ թե տրանզիտը: output hook-ը տեսնում է դարպասի ստեղծած տրաֆիկը, ինչը հակառակն է այն բանի, ինչ պետք է հաճախորդի լողավազանի քաղաքականությանը: Շղթաների անունները կամայական պիտակներ են, որոնք ընտրել է կանոնների հավաքածուն գրողը, ուստի hook-ը մի եզրակացրեք անունից: Ստուգեք, թե որտեղ է կցված շղթան, նախքան ենթադրելը, թե ինչի հետ այն կարող է համապատասխանել:
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
Կցվածքը կարդալը մեկ տողով ստուգում է, որը թույլ չի տալիս կանոնին հայտնվել շղթայում, որը երբեք չի տեսնում փաթեթը:
Տեղադրեք կանոնը լայն accept-ից առաջ
Կանոնները գնահատվում են հերթականությամբ, և առաջին վճիռը հաղթում է: Շղթայում ավելի վաղ լայն accept-ը ավարտում է գնահատումը իր համապատասխանող փաթեթների համար, ուստի հետո ավելացված drop-ը նրանց համար երբեք չի գործարկվում: Այդ հերթականության կանոնը ճիշտ տեսք ունեցող կանոնի անազդեցության ամբողջ պատճառն է:
Տեղադրեք կանոնը accept-ից առաջ, այլ ոչ թե վերջում ավելացրեք: Եթե շղթայում արդեն կա թունելի ինտերֆեյսի ընդհանուր accept, նոր կանոնը պետք է նախորդի դրան, հակառակ դեպքում այն միայն զարդարանք է: Ստուգեք ստացված հերթականությունը, ոչ թե ձեր խմբագրած ֆայլը, քանի որ մի քանի ֆայլից հավաքված կանոնների հավաքածուն կարող է չհամապատասխանել դրանցից ոչ մեկին: Ապա հաստատեք լողավազանից եկած փորձնական փաթեթով:
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.confԵրրորդ հրամանը վերլուծում է ֆայլը՝ առանց կիրառելու, ինչը բռնում է շարահյուսական սխալները նախքան դրանք ընդհատման վերածվելը: Կիրառեք հետադարձ պլանով, քանի որ forward շղթայում սխալ կանոնը կարող է կտրել այն թունելը, որի վրայով աշխատում եք:
Գոյություն ունեցող հոսքերը չեն հոգում ձեր նոր կանոնի մասին
Մինչև կանոնի գոյությունը ստեղծված conntrack գրառումը շարունակում է համապատասխանել ավելի վաղ accept-ին: Դրա համար է, որ նոր drop-ը երբեմն աշխատում է թվում նոր միացումների համար և ոչինչ չի անում այն միացման համար, որը փորձարկվում է:
Կարդացեք վիճակի համապատասխանությունը շղթայի սկզբում: Եթե այն ընդունում է established և related տրաֆիկը ձեր կանոնից առաջ, ապա յուրաքանչյուր ընթացող հոսք շարունակում է հոսել մինչև փակվելը: Սովորաբար հենց դա եք ուզում արտակարգ կանոնի համար, և դա շփոթեցնում է, երբ ակնկալում եք անմիջական կտրվածք: Որոշեք, թե ինչ ազդեցություն եք ուզում, նախքան տեղակայելը: Բաց միացումը վերօգտագործող փորձարկումը ձեզ սխալ պատմություն կպատմի:
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'Առաջին հրամանը ցույց է տալիս՝ կա արդյոք հոսք, իսկ երկրորդը՝ շարունակո՞ւմ է արդյոք վաղ վիճակի կանոնն ընդունել այն: Երկուսն էլ միայն ընթերցման են և անվտանգ՝ միջադեպի ընթացքում:
Ինչ չէ այս կանոնը
Կանոնը տիրույթների սև ցուցակ, IPv6 քաղաքականություն կամ առանձին հավելվածի հաշվի սահմանափակում չէ:
Դրանցից յուրաքանչյուրը պահանջում է իր մեխանիզմը: Տիրույթի արգելափակումը պետք է լուծի անուններ, ինչը փաթեթային զտիչը չի անում: IPv6 տրաֆիկը պահանջում է իր համապատասխանությունը, քանի որ ip արտահայտությունը ոչինչ չի ասում ip6 փաթեթների մասին: Հավելվածի մակարդակի սահմանափակումը պատկանում է ծառայությանը կամ նույնականացված պրոքսիին, ոչ թե նախածանցի համապատասխանությանը: Հենց այդ պահանջները առանձին պահելն է խանգարում մեկ նեղ կանոնից չորս աշխատանք պահանջել:
Պայմանագիրը, որ տալիս է այս կանոնը, ճշգրիտ է. թույլատրված լողավազանից մեկ նպատակակետային նախածանց ուղղված տրաֆիկը մերժվում է, մինչ դարպասի չկապված տրաֆիկը պահպանում է իր գործող քաղաքականությունը: Գրեք այդ նախադասությունը կանոնի կողքին, և հաջորդ մարդը կիմանա, թե ինչի համար էր այն: