धार के उदाहरण पर http-ट्रैफ़िक की फ़ाइलों का अवरोधन और संपादन

कुछ साल पहले, हमारे "होम" शहर नेटवर्क के उपयोगकर्ताओं के लिए एक स्थानीय बिटोरेंट रिट्रेकर बनाने के लिए विचार आया था, ताकि उपयोगकर्ता तेजी से डाउनलोड करें और हमारे पास कम ट्रैफ़िक हो। स्वयं रिट्रेकर की स्थापना अभी शुरू हुई थी, इसे किसी तरह डाउनलोड करने योग्य टोरेंट के लिए घोषित करना आवश्यक था। घोषणा के तरीकों और तंत्र का पता लगाने की प्रक्रिया में, मैं काफी सामान्य और सार्वभौमिक एल्गोरिथ्म में आया था, जिसे मैं जानने के लिए प्रस्तावित करता हूं।



तो पहले वाला:

क्या करें?

स्थानीय नेटवर्क पर ट्रैकर के अस्तित्व की घोषणा करने के तीन तरीके हैं:

• कुछ ट्रैकर्स द्वारा जोड़े गए retracker.local पते का उपयोग करें
• Isp.bep22 तंत्र का उपयोग करके एक स्थानीय ट्रैकर की घोषणा करें
• अवरोधक ने डाउनलोड की गई टोरेंट फाइलें डाउनलोड कीं और उन्हें संपादित किया, हमारे टोरेंट के पते को जोड़ते हुए, "फ्लाई पर"

उनमें से प्रत्येक के क्रमशः इसके फायदे और नुकसान हैं:

• .Local ज़ोन का उपयोग करते हुए RFC " मल्टीकास्ट DNS " के मसौदे का विरोधाभास करता है और zeroconf सेवाओं के संचालन में समस्याओं का कारण बनता है Linux और Apple; केवल कुछ ट्रैकर्स द्वारा जोड़ा गया
• Isp.bep22 काम करता है, जहाँ तक मुझे पता है, केवल bTorrent ग्राहक में है और यह डिफ़ॉल्ट रूप से बंद है
• एक सफल नेटवर्क के एकमात्र अनुभव को छोड़कर, सफलता की कहानियों के साथ यातायात अवरोधन का कोई उल्लेख नहीं है ।

शुरू करने के लिए, हमने पहले दो विकल्पों के लिए समर्थन किया, क्योंकि इसके लिए कोई विशेष प्रयास की आवश्यकता नहीं थी: DNS ( retracker.local IN A और retracker.smarthome.spb.ru _SRV_ ) में कुछ रिकॉर्ड जोड़ना सरल है। इस स्थिति में, आप zeroconf के साथ .local की असंगति पर अपनी आँखें बंद कर सकते हैं, क्योंकि आदर्श रूप से zeroconf के साथ क्लाइंट के DNS प्रश्न हमारे सर्वर तक भी नहीं पहुंचने चाहिए। अपडेट : कैडमी द्वारा एक महत्वपूर्ण टिप्पणी यह है कि उपयोगकर्ता और हमारे रिट्रैकर के लिए .local कार्यक्षमता के लिए, आपको एक क्षेत्र बनाने की आवश्यकता है जो कि थलोकल नहीं है, बल्कि .retracker.local है , जिससे दोनों विकल्पों को संयोजित करना संभव होगा।



लेकिन फिर भी, तीसरा विकल्प सबसे दिलचस्प और आकर्षक लग रहा था, इसलिए मैंने मक्खी पर डाउनलोड की गई फ़ाइलों को बदलने के लिए सामान्य तकनीक की जानकारी देखने का फैसला किया। सर्वर आवश्यकताएँ सरल थीं:

• FreeBSD पर काम करते हैं
• खुला स्रोत
• क्लाइंट के लिए काम की पारदर्शिता (अदर्शन)
• Http स्ट्रीम से लेवल 7 ट्रैफिक डिटेक्शन और फाइल रिकवरी
• इन फ़ाइलों को संपादन स्क्रिप्ट में स्थानांतरित करना और उन्हें वापस प्राप्त करना
• क्लाइंट को संपादित फ़ाइलों को स्थानांतरित करना

क्या करें?

मेरे आश्चर्य करने के लिए, मैंने पाया कि ऐसे अवरोधन और फ़ाइलों के संपादन के लिए व्यावहारिक रूप से कोई तकनीशियन और ओपन-सोर्स प्रोग्राम नहीं हैं। द्वारा और बड़े, उनमें से केवल दो हैं: यह प्रायोगिक आईसीएपी / ईसीएपी मॉड्यूल के साथ स्क्विड है और " मिडलमैन " नामक एक छद्म छद्म है, जिसका अंतिम विमोचन 2004 में वापस जारी किया गया था, लेकिन जो अभी भी बंदरगाहों में समर्थित है।



मैंने लगभग तुरंत स्क्वीड का उपयोग करने से इनकार कर दिया: एक बार में ट्रैफ़िक के साथ काम करने के लिए दो प्रयोगात्मक मॉड्यूल की उपस्थिति के बावजूद, समाधान अत्यधिक "टेढ़ा" हो गया और स्थापना और कॉन्फ़िगरेशन में भी अस्थिर था, काम का उल्लेख नहीं करना।



बिचौलिया के पास ले जाया गया। आश्चर्यजनक रूप से, तथ्य यह है कि पुराना कार्यक्रम आधुनिक स्क्वीड राक्षस की तुलना में अधिक कार्यात्मक और अधिक सुविधाजनक निकला। संक्षेप में, यह उपयोगकर्ता के लिए पूर्ण पारदर्शिता को छोड़कर, सभी आवश्यकताओं को पूरा करता है - उपयोगकर्ता के स्रोत आईपी को प्रॉक्सी के साथ सर्वर आईपी में स्थानांतरित किया जाता है। मैं ध्यान देता हूं कि लिनक्स के तहत केवल TPROXY मॉड्यूल के साथ स्क्विड में सोर्स आईपी छोड़ने की क्षमता है। इसके अलावा, इसका एक अनूठा विकल्प है - जब कस्टम प्रतीक्षा समय समाप्त हो जाता है, तो प्रॉक्सी उपयोगकर्ता को अपरिवर्तित स्रोत फ़ाइल देता है।

कैसे करें?

1. सबसे लोकप्रिय टोरेंट सर्वर की परिभाषा

शुरू करने के लिए, मैंने एक छोटी सी पर्ल स्क्रिप्ट लिखी है जो pcap के माध्यम से 80 पोर्ट को सुनता है और सामग्री-प्रकार: एप्लिकेशन / x-बिटटोरेंट से अनुरोध किए गए आईपी पते एकत्र करता है। यह सभी http-ट्रैफ़िक को बाधित करने के लिए आवश्यक नहीं है, बल्कि केवल वह है जो बड़े ट्रैकर्स से संबंधित है।



फिर, सरल जोड़तोड़ द्वारा, इन आईपी-पतों को आईपीएफडब्ल्यू तालिका में दर्ज किया जाता है, जिसका उपयोग हमारे प्रॉक्सी को रीडायरेक्ट करते समय किया जाता है:



${ipfw} add fwd ${proxy_ip}, ${proxy_port} tcp from $lan_customers to 'table(15)' dst-port 80 in via ${int_if}

2. मिडिलमैन प्रॉक्सी कॉन्फ़िगरेशन

संपादन स्क्रिप्ट को फ़ाइलें देने के लिए जिम्मेदार अनुभाग को mman.xml में बाहरी कहा जाता है।

3. "बाहरी" स्क्रिप्ट का संपादन

Mypatcher.pl स्क्रिप्ट को माइम प्रकार "एप्लिकेशन / x-बिटटोरेंट" के साथ फ़ाइलें प्राप्त होती हैं, यह इसमें एक स्थानीय ट्रैकर रिकॉर्ड जोड़ता है (यदि यह है तो retracker.local को हटाता है, जो zeroconf के साथ क्लाइंट समस्याओं को हल करता है और प्रॉक्सी पर वापस सामग्री स्थानांतरित करता है। , साथ ही, फ़ाइल को डिस्क में सहेजने के लिए, इस रूप में:



#for i in `find /home/torrents/patched/ -type d`; do echo -n "$i" && ls -1 $i| wc -l; done | awk '{print $2" "$1}' | sort -rn | head -n 10



24103 /home/torrents/patched/dl.rutracker.org

7817 /home/torrents/patched/dl.torrents.ru

6184 /home/torrents/patched/tfile.ru

3744 /home/torrents/patched/kinozal.tv

2928 /home/torrents/patched/rutor.org

2872 /home/torrents/patched/torrents.thepiratebay.org

2583 /home/torrents/patched/www.tfile.ru

2582 /home/torrents/patched/www.torrentino.ru

2531 /home/torrents/patched/pornolab.net

1032 /home/torrents/patched/www.rutor.org









परिणाम: NAT पर प्रदर्शन करने वाले सर्वर पर, 3,000 उपयोगकर्ताओं के नेटवर्क को आकार देना और मार्ग बनाना, mman loading बिल्कुल भी ध्यान देने योग्य नहीं है। लगभग 200-400 फाइलें अब प्रति दिन इस तरह संपादित की जाती हैं। लगभग एक साल के काम के लिए कोई शिकायत नहीं थी, हर कोई खुश है।



अपडेट १ । "डिस्क पर फ़ाइलों को सहेजना" केवल उपर्युक्त रूप में अज्ञात आंकड़ों को एकत्र करने के लिए है। खैर, मैं बस इस स्क्रिप्ट डिबगिंग तंत्र को अक्षम करना भूल गया। :) कैडम