Transmission Linux-ում. ելքային երթևեկի սահմանափակումը պրոցեսի սեփականատիրոջ կողմից

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

Անվանեք գործընթացը, որին պատկանում է փոխանցումը

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

systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemon

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

Առանձնացրեք լսելու դաշտերը երթուղուց

Transmission 4.x-ը փիրերի լսելու հասցեները փաստաթղթավորում է rpc-bind-address կարգավորումից առանձին, և այդ տարբերությունը կարևոր է։ RPC կարգավորումը կառավարում է միայն հեռակա կառավարման լսողը, ուստի դրա փոփոխությունը փիրերի երթևեկի համար երթուղի չի ընտրում։ Երկու կարգավորումները որպես մեկ կարդալը ամենատարածված պատճառն է, թե ինչու արտաքուստ զգույշ կոնֆիգուրացիան դեռ արտահոսում է։ Նույն փաստաթուղթը նկարագրում է պահուստային տարբերակ, երբ փիրի լսելու հասցեն անվավեր է, այսինքն անհասանելի հասցեն փաստաթղթավորված պահուստային դեպք է, ոչ թե երաշխավորված մերժում։

grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.json

Օգտագործեք հաճախորդի կառավարման միջոցները իրենց նպատակով, իսկ երաշխիքը դրեք firewall-ի մեջ։ Լսելու կարգավորումը դեռ կարող է օգտակար լինել, բայց այն չի ապացուցում, որ թրեքերների հետ կապը, տեղական հայտնաբերումը կամ պատվիրակված որոնումը բոլորը դուրս են գալիս թունելով։ Երբ այս երկուսը հակասում են, firewall-ն է որոշում։

Գրեք սեփականատիրոջ համընկնումը ճիշտ շղթայում

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

iptables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner transmission -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
ip6tables -A OUTPUT -m owner --uid-owner transmission -j REJECT

Հերթականությունը նույնքան կարևոր է, որքան համընկնումը։ Շղթայի վերևում լայն թույլատրումը չեղարկում է ներքևում ճշգրիտ արգելքը, ուստի վերանայեք ամբողջ շղթան՝ փոխարենը կանոն ավելացնելու և հույս դնելու։ Ներառեք երկու հասցեային ընտանիքները, եթե հոսթը աշխատում է IPv6-ով, որովհետև միայն v4 քաղաքականությունը բաց է թողնում ուղի, որը ոչ ոք չի հսկում։ Պահեք կանոնները տեղադրված թե՛ հաճախորդի, թե՛ թունելի վերագործարկումների ընթացքում։

Որոշեք, թե ինչ է պատահում, երբ tun0-ն անհետանում է

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

ip link show tun0
iptables -S OUTPUT

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

Ծածկեք ուղիները, որոնք կանոնը չի տեսնում

Անունների լուծումը կարող է կատարվել առանձին լուծիչ գործընթացի կողմից, իսկ անվանատարածքը կամ առանձնացված դարպասը կարող են տալ ևս մեկ սահման, եթե նրանց համօգտագործման և բեռնման ուղիները նախատեսված են դրա համար։ Որոշեք, թե որ բաղադրիչն է տիրապետում DNS-ին և արդյոք այն հետևում է նույն ելքային կանոնին։ Ապա նայեք RPC-ին. եթե օգտագործվում է rpc-whitelist, ապա հաստատված կառավարման ցանցը պայմանագրի մասն է, իսկ լայն RFC1918 տիրույթը՝ ոչ։

ss -tunp | grep -i transmission

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

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