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ఇంటర్‌ఫేస్ కౌంటర్లు పరిశీలనకు మద్దతు ఇవ్వగలవు, కానీ ఏ ప్రక్రియ బైట్‌లను ఉత్పత్తి చేసిందో రుజువు చేయలేవు. వదిలివేయడానికి అనుమతి ఉన్న బదిలీ చేయండి: మొదట పని చేసే మార్గంలో, తర్వాత ప్రారంభంలో టన్నెల్ లేకుండా, ఆపై అంతరాయం, పునఃకనెక్షన్ మరియు కొత్తగా సృష్టించిన ఇంటర్‌ఫేస్ ద్వారా. కొత్త ప్రయత్నాన్ని మరియు ఇప్పటికే తెరిచి ఉన్న కనెక్షన్‌ను రెండింటినీ పరీక్షించండి, ఎందుకంటే నియమం పాత సాకెట్‌కు వర్తించకపోవచ్చు. తేదీ, ఖాతా మరియు ఫలితాన్ని పరీక్షతో పాటు నమోదు చేయండి.
మొత్తం గొలుసును శుభ్రపరిచే ఉదాహరణను అతికించడం ఒక రంధ్రాన్ని అనేక రంధ్రాలతో మారుస్తుంది, కాబట్టి నియమాలను తుడిచివేయడం బదులు జోడించండి. ఐదు తనిఖీలు దాటితే, హామీ స్పష్టం: క్లయింట్ ట్రాఫిక్ టన్నెల్ ద్వారా బయటకు పోతుంది లేదా అసలు పోదు, మరియు దానిని అమలు చేసే నియమం టన్నెల్ యొక్క సొంత వైఫల్యాన్ని సైతం తట్టుకుంటుంది.