Linux પર Transmission: પ્રક્રિયાના માલિક મુજબ બહાર જતો ટ્રાફિક લાગુ કરો

Transmission નું આવતું પોર્ટ અવરોધવું એ VPN નીતિ નથી. ટોરેન્ટ ક્લાયન્ટ પીઅર્સ અને ટ્રેકર્સ તરફ બહાર જતા જોડાણો ખોલે છે, નામો ઉકેલે છે અને દૂરસ્થ નિયંત્રણ માટે શ્રોતા ખોલી શકે છે, અને આમાંથી દરેક તમે ઇચ્છ્યું ન હોય તેવા ઇન્ટરફેસ દ્વારા બહાર જઈ શકે છે. પાંચેય તપાસ ક્રમમાં કરો અને સીમા તરીકે ફાયરવોલ નિયમને, ક્લાયન્ટની સેટિંગ્સને નહીં, ગણો. છેલ્લી બે તપાસ એ છે જે લોકો છોડી દે છે, અને ટનલ પડે ત્યારે ગેરંટી ટકે છે કે નહીં તે એ જ નક્કી કરે છે.

જે પ્રક્રિયા સ્થાનાંતરણની માલિક છે તેનું નામ આપો

ડેસ્કટોપ એપ્લિકેશન અને સિસ્ટમ ડેમન અલગ ખાતા હેઠળ ચાલે છે, અને માલિક આધારિત નિયમ પ્રોગ્રામના નામને બદલે ખાતાને અનુસરે છે. કોઈપણ નિયમ લખતા પહેલા શોધો કે આમાંથી કોણ ચાલી રહ્યું છે. સમર્પિત સેવા ખાતું નીતિને સચોટ વિષય આપે છે, જ્યારે ડેસ્કટોપ વપરાશકર્તા પોતાની ઓળખ બ્રાઉઝર, સંપાદકો અને સત્રની બીજી દરેક વસ્તુ સાથે વહેંચે છે. 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

ક્લાયન્ટના નિયંત્રણોને જે છે તે માટે વાપરો અને ગેરંટી ફાયરવોલમાં મૂકો. સાંભળવાની સેટિંગ હજી ઉપયોગી હોઈ શકે, પણ તે સાબિત કરતી નથી કે ટ્રેકર્સ સાથેનો સંપર્ક, સ્થાનિક શોધ કે પ્રતિનિધિત્વ કરેલી શોધ બધા ટનલ દ્વારા બહાર જાય છે. જ્યારે બંનેમાં મતભેદ હોય, ફાયરવોલ નિર્ણય કરે છે.

માલિક મેળ યોગ્ય સાંકળમાં લખો

માલિક મેળ વિશે Netfilterની પુસ્તિકા સમજાવે છે કે સ્થાનિક રીતે બનેલા પેકેટ સોકેટ ફાઇલના માલિક વપરાશકર્તા કે જૂથને કેવી રીતે આરોપિત થાય છે. આ આરોપણ આગળ મોકલેલા ટ્રાફિક સુધી ફેલાતું નથી, અને વધારાના જૂથોના મેળ માટે સ્પષ્ટ વિકલ્પ જરૂરી છે. તમે ખરેખર વાપરી રહ્યા છો તે એક્સ્ટેન્શનની પુસ્તિકા વાંચો, નહીં કે મળેલું પહેલું ઉદાહરણ.

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

ઇન્ટરફેસ કાઉન્ટર અવલોકનને ટેકો આપી શકે છે, પણ કઈ પ્રક્રિયાએ બાઇટ બનાવ્યા તે સાબિત કરી શકતા નથી. એવું સ્થાનાંતરણ કરો જે છોડવાની પરવાનગી હોય: પહેલા કામ કરતા માર્ગ પર, પછી શરૂઆતમાં ટનલ વિના, પછી વિક્ષેપ, પુનઃજોડાણ અને નવા બનાવેલા ઇન્ટરફેસ દ્વારા. નવો પ્રયાસ અને પહેલેથી ખુલ્લું જોડાણ બંને પરખો, કારણ કે નિયમ જૂના સોકેટ પર લાગુ ન થયો હોઈ શકે. તારીખ, ખાતું અને પરિણામ પરીક્ષણ સાથે નોંધો.

આખી સાંકળ સાફ કરતું ઉદાહરણ પેસ્ટ કરવું એ એક છિદ્રને બદલે ઘણાં છિદ્રો આપે છે, તેથી નિયમ ભૂંસવાને બદલે ઉમેરો. જ્યારે પાંચેય તપાસ પાસ થાય, ગેરંટી સ્પષ્ટ છે: ક્લાયન્ટનો ટ્રાફિક ટનલ દ્વારા બહાર જાય છે અથવા બિલકુલ જતો નથી, અને જે નિયમ તેને લાગુ કરે છે તે ટનલની પોતાની નિષ્ફળતાને પણ ઝીલી લે છે.