समाचार: RETN रीढ़ प्रदाता, इस तथ्य के बावजूद कि यह रीढ़ है, DPI के माध्यम से ट्रैफ़िक को फ़िल्टर करता है। चूंकि ऑपरेटर एक बैकबोन ऑपरेटर है, और, विशेष रूप से, विदेशी ट्रैफिक के वितरण में लगा हुआ है, हमारे पास कई प्रदाताओं के लिए आउटपुट पर सेंसरशिप है, जिनमें वे "निषिद्ध सूचियों" के सभी प्रकार की जांच करना चाहते थे, लेकिन uplinks में RNN है।

डीपीआई प्रौद्योगिकियों का सामूहिक नाम है जिसमें उपकरण "ढोंगी" अंदर यातायात में है, अर्थात, यह न केवल विभिन्न स्तरों के हेडर पैकेट के लिए प्रतिक्रिया करता है, बल्कि सामग्री के लिए भी है।

हस्तक्षेप से बचने के लिए, कई शहरों से और कई प्रदाताओं से परीक्षण किया गया था, जिसने स्थानीय प्रदाता फ़िल्टरिंग के कारक को समाप्त कर दिया (दूसरा, अप्रत्यक्ष परीक्षण टीटीएल स्कैनिंग के उपयोग पर आधारित था, जो हमेशा आरईटीएन क्षेत्र को इंगित करता था)।

आइए देखें कि कैसे RETN DPI को लागू करता है, आत्महत्या करने वाले अश्लील बच्चों से ड्रग्स की रक्षा के लिए कानूनों को लागू करता है जो कॉपीराइट कानूनों का उल्लंघन करते हैं।

हम एक आधार के रूप में प्रसिद्ध पत्रिका Stervozinka लेते हैं (यह व्यापक रूप से केवल अवरुद्ध होने के लिए जाना जाता है, किसी प्रकार की असावधानी के लिए अवरुद्ध है, इसके अलावा, यह लंबे समय से अवरुद्ध है, और प्रतिबंध से बाहर नहीं होने वाला है)।

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

आइए समस्या के हर रोज़ लक्षणों को देखें:

wget -d --tries 1 stervozzinka.dreamwidth.og/15580.html

कंसोल के बगल में, tcpdump host stervozzinka.dreamwidth.og

 17: 17: 14.376828 आईपी लोकल.49510> ड्रीमगर्ल.ओग.एचटीपी: फ्लैग्स [पी।], सीक 1: 136, एक 1, 115 जीतने के लिए, विकल्प [एनओपी, एनओपी, टीएस वैल 111993449 ecr 1627034663], लंबाई 135
 17: 17: 17.924801 आईपी लोकल .49510> ड्रीमगर्ल.ओग.http: फ्लैग्स [पी।], Seq 1: 136, ack 1, 115 जीत, विकल्प [nop, nop, TS val 11200336 ecr 1627034663], लंबाई 135
 17: 17: 18.068805 आईपी लोकल ..49509> ड्रीमगर्ल.ओग.http: फ्लैग्स [पी।], Seq 1: 136, ack 2, 115 जीत, विकल्प [nop, nop, TS val 1170672 ecr 1627029045], लंबाई 135

वही seq ओवरस्किबड सेगमेंट का संकेत है। लेकिन हम यह नहीं समझ सकते कि वे कहाँ रोक रहे हैं (प्रतिक्रिया प्राप्त करने या अनुरोध भेजने पर)। लेकिन हम यह देख सकते हैं कि वे अवरुद्ध कर रहे हैं, क्योंकि बस टीसीपी सेगमेंट फिर से शुरू नहीं होता है।

जो कुछ भेजा जा रहा है उसे ठीक से नियंत्रित करने के लिए कुछ सरल से मास्टरगेट स्विच पर जाएँ:

echo -e "GET /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n"|nc stervozzinka.dreamwidth.og 80
यह हमें किसी भी तरह से आगे नहीं बढ़ाएगा, लेकिन यह हमें सुर्खियों के साथ प्रयोग करने की कुछ स्वतंत्रता देगा। निर्दिष्ट अनुरोध भी अवरुद्ध है।

लेकिन विविधताओं के लिए (जो कि RFC का उल्लंघन हैं, लेकिन स्वप्नदोष की ओर से वार्निश सामान्य रूप से संसाधित होते हैं), हम कुछ विशेषताएं देख सकते हैं:

• GET /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n" (GET के बाद दो स्थान) - शुरू
• GET /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n (HTTP / 1.1 से पहले दो स्थान) अनुमति नहीं देता है
• get /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n प्राप्त करें get /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n (छोटे अक्षरों में प्राप्त करें) - शुरू
• GET /15580.html HTTP/1.1\nIgnore:me\nHost: stervozzinka.dreamwidth.og\n (GET और HOST के बीच अतिरिक्त हेडर) - जाने नहीं देता

प्रारंभिक निष्कर्ष उबाऊ और आदिम सटीक मिलान है। यदि हां, तो यह कैसे समझ में आता है कि पैकेज की सामग्री क्या है और क्या नहीं है?

इसलिए ...

echo -e "GET /15580.html\n\nHost: stervozzinka.dreamwidth.og\n"|nc stervozzinka.dreamwidth.og 80 - शुरू नहीं होता है।

जिन लोगों को समझ नहीं आया - मैंने GET के बाद दो लाइन फीड लगाई, यानी, होस्ट पहले से ही शरीर को संदर्भित करता है, और हेडर को नहीं। मैंने HTTP / 1.1 को भी हटा दिया है, अर्थात यह प्लेन HTTP 1.0 है, जिसमें होस्ट हेडर नहीं है, अर्थात, हमने होस्टनाम निर्दिष्ट किए बिना सर्वर से /15580.html का अनुरोध किया है।

ध्यान दें कि होस्टनाम के बिना एक अनुरोध काम करता है: GET /15580.html \n\n

दूसरे शब्दों में, हम देखते हैं कि डीपीआई कुछ पूरी तरह से बाहर की जाँच करता है - बॉडी में मेजबान की उपस्थिति। परिणामस्वरूप, उन अनुरोधों को छोड़ दिया जाता है जिनका अवरुद्ध साइट से कोई लेना-देना नहीं है।

चलिए प्रयोग को जटिल करते हैं:
echo -e "POST / \ n \ n और क्या आप जानते हैं कि वे सामग्री पर प्रतिबंध लगाते हैं? उदाहरण के लिए: GET /15580.html \n\nHost: stervozzinka.dreamwidth.og\n"|nc stervozzinka.dreamwidth.og 80

ओह, ओह, ओह। हमें निर्दोष सामग्री के साथ POST भेजने पर प्रतिबंध लगा दिया गया था। यह POST सर्वर तक नहीं पहुंचा। नहीं हो सकता?

आइए अधिक सांस्कृतिक विधियों के साथ पोस्ट की जांच करें और पोस्ट करें:

curl -d "GET /15580.html \n\nHost: stervozzinka.dreamwidth.og\n" dreamwidth.og

हमारी धारणा यह है कि फ़िल्टर को एक पैकेज में दोनों लाइनों की आवश्यकता होती है और इसकी वैधता की जांच नहीं करता है:

curl --connect-timeout 10 -d "GET /15580.html\n`seq 1 10000`\nHost: stervozzinka.dreamwidth.og\n" 69.174.244.50

इससे जाता है। इसका मतलब है कि पैकेट में दोनों हेडर होने चाहिए। (हाँ, अगर हम होस्ट करने वाले सर्वर के लिए ऐसा अनुरोध लिखते हैं: हेडर में, यह एक अलग पैकेज में जाएगा, तो शायद हम सेंसरशिप के माध्यम से तोड़ सकते हैं।

एक और जाँच: क्या लोग पोर्ट नंबर की जाँच करते हैं?
echo -e "GET /\nHost: stervozzinka.dreamwidth.og\n"|nc dreamwidth.og 443
(खाली उत्तर)

echo -e "GET /15580.html\nHost: stervozzinka.dreamwidth.og\n"|nc dreamwidth.og 443
(समाप्त)

नहीं। 443 वें पोर्ट पर ट्रैफ़िक को उसी सफलता के साथ फ़िल्टर किया जाता है (वे सामान्य को छोड़ते हैं, "निषिद्ध" को छोड़ते हैं)।

एक और जांच: क्या वे आईपी द्वारा फ़िल्टर किए गए हैं? हमें पड़ोसी (एक ही खंड से) खुले आईपी का पता चलता है जो कि पोर्ट 80 पर प्रतिक्रिया करता है। इसे जाने दो।

परिणाम

पैकेज ड्रॉप के लिए शर्तें:

• किसी भी TCP पोर्ट पर (UDP की जाँच नहीं की गई थी)
• किसी भी झंडे के साथ
• लाइनों की पैकेज (किसी भी क्रम में) में वास्तविक उपस्थिति से
  • / 15580.html प्राप्त करें
  • होस्ट: stervozzinka.dreamwidth.og
• Src_IP सूची में प्रतिबंध के साथ मेल खाता है

इस प्रकार, यह पैकेट पैकेट में regexps के बिना हस्ताक्षर के लिए एक खोज के साथ एक पैकेट फ़िल्टर की तरह अधिक है, और एक वास्तविक डीपीआई बिल्कुल नहीं है।