Ինչու nftables-ը չի տեսնում OpenVPN-ի հաճախորդների միջև երթևեկությունը
Գործընկերների միջև երթևեկությունը հանձնվում է VPN գործընթացի ներսում, ուստի փոխանցման հաշվիչները երբեք չեն շարժվում։ Այն հաշվելու համար պետք է ընտրել միջուկի ուղին ու գործընթացի ուղին։
Մեկ սերվերի վրա երկու հաճախորդ ֆայլեր են փոխանակում, փոխանցումը հաջողվում է, և թունելին ուղղված յուրաքանչյուր փոխանցման կանոն զրո փաթեթ է հաղորդում։ Կանոնները կոտրված չեն, և շղթան սխալ տեղում չէ։ Երբ գործընկերների միջև փոխանցումը միացված է, փաթեթը հանձնվում է սերվերի գործընթացի ներսում, և հյուրընկալողի կույտը երբեք չի դառնում երթուղիչ, ուստի միջուկի պատնեշին հաշվելու բան չի մնում։ Այդ բաժանումը հասկանալը որոշում է՝ պահում եք կարճ ուղին, թե վերակառուցում եք ուղին միջուկի միջով։
Հետևեք մեկ փաթեթի սերվերի միջով
Երթուղավորված թունելում դեմոնը յուրաքանչյուր հաճախորդի ապակոդավորված փաթեթը հանձնում է թունելի սարքին։ Այնտեղից հյուրընկալողը երթուղավորում է այն, գործում է փոխանցման կեռը, և թունելի սարքին համապատասխանող կանոնը կարող է հաշվել կամ գցել երթևեկությունը։ Սա այն ուղին է, որը ենթադրում են պատնեշի օրինակների մեծ մասը։
| Forwarding path | Who decides | What the host firewall sees |
|---|---|---|
| Kernel routing between clients | Host routing table and forward rules | Every inner packet, with interface names |
| Peer forwarding inside the server process | The VPN daemon's own peer table | Only the outer encrypted transport |
Կարճ ուղին հանում է հյուրընկալողին մեջտեղից։ Մեկ նստաշրջանի ապակոդավորված փաթեթը հանձնվում է մեկ այլ նստաշրջանի դեմոնի ներսում, և ներքին փաթեթը երբեք չի արտանետվում թունելի սարքի վրա և չի երթուղավորվում հյուրընկալողի կողմից։ Ինկապսուլացված երթևեկությունը դեռ հատում է ֆիզիկական ինտերֆեյսը, ուստի արտաքին գրառումը զբաղված է թվում, մինչ ներքին կանոնները լուռ են մնում։ Թունելի սարքի վրա արված գրառումը ընդհանրապես ոչինչ չի ցույց տալիս, ինչը զարմացնում է բոլորին, ովքեր սպասում են այնտեղ տեսնել փոխանցումը։ Այդ ասիմետրիան դեմոնից դրսից կարճ ուղին ճանաչելու ամենաարագ ձևն է։
Հաշվիչի փորձարկումը, որը որոշում է՝ որ ուղին է անցել
Կցեք հաշվիչ այն կանոնին, որը պետք է գործի, գործարկեք փոխանցում երկու հաճախորդների միջև, որոնց այդ կանոնը պետք է արգելափակի, և հետո կարդացեք հաշվիչը։
sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forwardԵթե փոխանցումը հաջողվում է, և հաշվիչը մնում է զրոյի վրա, միջուկը երբեք չի մշակել այդ փաթեթները, և կանոնների ոչ մի խմբագրում դա չի փոխի։ Կրկնեք նույն փորձարկումը հենց սերվերի ծառայության դեմ, որովհետև այդ հոսքը իսկապես անցնում է հյուրընկալողի կույտով, և դրա հաշվիչը շարժվում է։ Երկու արդյունքների համեմատումն է, որ տալիս է պատասխանը։
Երկու մանրամասն կանխում է սխալ ընթերցումը։ Շղթայի պիտակի մեջ գրված ինտերֆեյսի անունն ինքնին ոչինչ չի զտում, որովհետև համընկնումը կատարվում է կանոնների ներսի ինտերֆեյսի դաշտերում։ Իսկ կամրջված 2-րդ շերտի նախագիծն այլ կերպ է վարվում՝ այնտեղ հաճախորդները կիսում են մեկ հեռարձակման տիրույթ, ուստի գործընկերների հայտնաբերումը սպասելի է, ոչ թե երթուղավորման խափանում։
Անջատիչը մուտքի ցուցակ չէ
Սա այն մասն է, որն արժե կես օր։ Գործընկերների միջև փոխանցումը մեկ միացված-անջատված կարգավորում է, և քանի դեռ այն միացված է, դեմոնը փոխանցման միակ կետն է։ Հյուրընկալողի պատնեշը չի կարող արտահայտել, թե ով ում կարող է հասնել, և յուրաքանչյուր հաճախորդի ֆայլերը անջատիչը քաղաքականության մատրից չեն դարձնում։
Եթե ձեզ պետք են կանոններ յուրաքանչյուր գործընկերոջ համար, ընտրությունը կարճ ուղուց հրաժարվելու և հյուրընկալողի պատնեշից որպես կառավարման միջոց հրաժարվելու միջև է։ Այն անջատելը վերականգնում է միջուկի փոխանցումը, ինչը պահանջում է IP փոխանցման միացում սերվերի վրա և հստակ կանոններ ցանկալի հոսքերի համար։ Միացված թողնելը նշանակում է, որ քաղաքականությունն ապրում է դեմոնի կարգավորումներում, ինչը գործնականում բոլոր գործընկերներն են կամ ոչ մեկը։
Առանձին սերվերային գործընթացներն իրենց հասցեների լողավազաններով ու պորտերով աշխատունակ միջին ուղին են։ Յուրաքանչյուր գործընթաց կրում է ուղիղ մեկ մուտքի որոշում, ուստի երկու խումբ կարող են տարբեր կանոններ ունենալ առանց քաղաքականության մատրիցի։ Հյուրընկալողը կարող է երթուղավորել լողավազանների միջև, երբ դա է նպատակը, և այդ ժամանակ պատնեշը տեսնում է այդ հոսքերը, որովհետև դրանք հատում են հյուրընկալողին։ Գինը լրացուցիչ պորտերն են, լրացուցիչ վկայագրերը և պրոֆիլը յուրաքանչյուր խմբի համար։
Փոխանցման կետի ընտրությունը
Ընտրեք միջուկի փոխանցումը, երբ պատնեշը քաղաքականության շարժիչն է, երբ ձեզ պետք է գրանցում յուրաքանչյուր հոսքի համար, կամ երբ հաշվառումը կարևոր է։ Գինը հյուրընկալողի կույտով թողունակությունն է և ավելի շատ կանոններ պահպանելը։ Առավելությունն այն է, որ յուրաքանչյուր գոյություն ունեցող գործիք՝ հաշվիչներից մինչև հոսքերի արտահանիչներ, կրկին նկարագրում է երթևեկությունը։ Փոքր սերվերի վրա այդ գինը անտեսանելի է, զբաղված ռելեի վրա՝ ոչ։
Ընտրեք գործընթացի ներսում փոխանցումը, երբ գործընկերների միջև երթևեկությունը կամ ամբողջովին թույլատրված է, կամ ամբողջովին արգելված, և սերվերը չափված է դրա համար։ Գինը այն է, որ հաշվիչները, հերթերի կարգապահությունը և կապերի հետևումը այլևս չեն նկարագրում ներքին հոսքերը՝ դա ընդունելի է միայն այն դեպքում, երբ հետագայում ոչ ոք դրանց չի հենվում։
Ինչ էլ ընտրեք, գրեք այն պատնեշի կանոնների կողքին։ Կանոնների հավաքածուն, որը կարծես թույլատրում է գործընկերների միջև երթևեկությունը, մինչ դեմոնը միևնույն է որոշում է, մոլորեցնում է հաջորդ մարդուն, ով կվրահանգավորի ձախողված փոխանցումը։ Ով կարդա միայն կանոնները, կենթադրի, որ միջուկն է դարպասը։
Ինչ ստուգել կանոնները փոխելուց առաջ
Կարդացեք այն կարգավորումը, որը սերվերը իրականում բեռնել է, ոչ թե այն ֆայլը, որը հիշում եք, թե խմբագրել եք, և հաստատեք՝ արդյոք գործընկերների ընտրանքը կա։ Եթե փոխել եք այն, համոզվեք, որ ծառայությունը վերաբեռնվել է, այլ ոչ թե պարզապես ֆայլ է վերագրվել սկավառակի վրա։
Ապա կրկնեք փորձարկումը հաճախորդից սերվեր հոսքով՝ ապացուցելու, որ կանոնն ընդհանրապես համընկնում է, և ստուգեք ուղարկված երթուղիները, որովհետև բացակայող երթուղին հաճախորդի կողմից ճիշտ նույնն է թվում, ինչ պատնեշի արգելափակումը։ Փոխեք կանոնների հերթականությունը միայն այն բանից հետո, երբ իմանաք, թե որ փոխանցման կետն է տիրում որոշմանը։