टिप्पणीको विस्तृत प्रतिक्रिया, साथै रूसी संघमा प्रदायकहरूको जीवनको बारेमा थोरै

मलाई यो पोस्ट गर्न प्रेरित गर्नुभयो यो टिप्पणी हो.

म यसलाई यहाँ उद्धृत गर्दछु:

kaleman आज 18:53 मा

म आज प्रदायक संग खुसी थिए। साइट अवरुद्ध प्रणालीको अद्यावधिक संगै, उनको मेलर mail.ru प्रतिबन्धित थियो। मैले बिहानै देखि प्राविधिक सहयोगलाई कल गर्दैछु, तर तिनीहरूले केहि गर्न सक्दैनन्। प्रदायक सानो छ, र स्पष्ट रूपमा उच्च श्रेणीका प्रदायकहरूले यसलाई रोक्छन्। मैले सबै साइटहरू खोल्ने क्रममा ढिलो पनि देखेँ, हुनसक्छ उनीहरूले कुनै प्रकारको कुटिल DLP स्थापना गरेका छन्? पहिले पहुँचमा कुनै समस्या थिएन। RuNet को विनाश मेरो आँखा अगाडि भइरहेको छ ...

तथ्य यो हो कि यस्तो देखिन्छ कि हामी उही प्रदायक हौं :)

र साँच्चै, kaleman मैले लगभग mail.ru मा समस्याहरूको कारण अनुमान गरे (यद्यपि हामीले लामो समयको लागि यस्तो कुरामा विश्वास गर्न अस्वीकार गर्यौं)।

निम्नलाई दुई भागमा विभाजन गरिनेछ:

1. mail.ru को साथ हाम्रो वर्तमान समस्याहरूको कारण र तिनीहरूलाई फेला पार्न रोमाञ्चक खोज
2. आजको वास्तविकतामा ISP को अस्तित्व, सार्वभौम RuNet को स्थिरता।

mail.ru को साथ पहुँच समस्याहरू

ओह, यो धेरै लामो कथा हो।

तथ्य यो हो कि राज्यको आवश्यकताहरू लागू गर्न (दोस्रो भागमा थप विवरणहरू), हामीले केही उपकरणहरू खरिद गर्यौं, कन्फिगर गर्यौं र स्थापना गर्यौं - निषेधित स्रोतहरू फिल्टर गर्न र कार्यान्वयन गर्नका लागि। NAT अनुवादहरू सदस्यहरू।

केहि समय पहिले, हामीले अन्ततः नेटवर्क कोरलाई यसरी पुनर्निर्माण गर्यौं कि सबै ग्राहक ट्राफिकहरू यस उपकरणबाट सही दिशामा कडाईका साथ पारित गरियो।

केही दिन पहिले हामीले यसमा प्रतिबन्धित फिल्टरिङ अन गर्यौं (पुरानो प्रणालीले काम गरिरहेको बेला) - सबै कुरा राम्ररी चलेको जस्तो देखिन्थ्यो।

त्यसपछि, तिनीहरूले बिस्तारै ग्राहकहरूको विभिन्न भागहरूको लागि यस उपकरणमा NAT सक्षम गर्न थाले। हेर्दा हेर्दा पनि सबै ठीकठाक छ जस्तो लाग्थ्यो ।

तर आज, ग्राहकहरूको अर्को भागको लागि उपकरणहरूमा NAT सक्षम गरेपछि, बिहानैदेखि हामीले अनुपलब्धता वा आंशिक उपलब्धताको बारेमा राम्रो संख्यामा गुनासोहरूको सामना गर्‍यौं। mail.ru र अन्य मेल रु समूह स्रोतहरू।

तिनीहरूले जाँच गर्न थाले: कतै केहि कहिलेकाहीं, कहिलेकाँही पठाउँछ TCP RST mail.ru नेटवर्कहरूमा मात्र अनुरोधहरूको प्रतिक्रियामा। यसबाहेक, यसले गलत रूपमा उत्पन्न (ACK बिना), स्पष्ट रूपमा कृत्रिम TCP RST पठाउँछ। यो के जस्तो देखिन्थ्यो:

स्वाभाविक रूपमा, पहिलो विचारहरू नयाँ उपकरणहरूको बारेमा थिए: डरलाग्दो DPI, यसमा कुनै विश्वास छैन, तपाईलाई थाहा छैन कि यसले के गर्न सक्छ - आखिर, TCP RST अवरुद्ध उपकरणहरू बीच एक सामान्य कुरा हो।

धारणा kaleman हामीले यो विचार पनि अगाडि राख्यौं कि कसैले "उच्च" फिल्टर गर्दैछ, तर तुरुन्तै खारेज गर्‍यौं।

पहिलो, हामीसँग पर्याप्त रूपमा सेन अपलिङ्कहरू छन् ताकि हामीले यसरी कष्ट भोग्नु पर्दैन :)

दोस्रो, हामी धेरैसँग जोडिएका छौं IX मस्कोमा, र mail.ru मा ट्राफिक तिनीहरू मार्फत जान्छ - र तिनीहरूसँग न त जिम्मेवारी छ न त यातायात फिल्टर गर्ने कुनै अन्य उद्देश्य।

दिनको अर्को आधा सामान्यतया शमनवाद भनिने कुरामा बित्यो - उपकरण विक्रेताको साथ, जसको लागि हामी उनीहरूलाई धन्यवाद दिन्छौं, उनीहरूले हार मानेनन् :)

• फिल्टरिङ पूर्ण रूपमा अक्षम थियो
• NAT नयाँ योजना प्रयोग गरी असक्षम गरिएको थियो
• परीक्षण पीसी एक अलग अलग पूल मा राखिएको थियो
• IP ठेगाना परिवर्तन भयो

दिउँसो, एक भर्चुअल मेसिन आवंटित गरिएको थियो जुन नियमित प्रयोगकर्ताको योजना अनुसार नेटवर्कमा जडान गरिएको थियो, र विक्रेताका प्रतिनिधिहरूलाई यसमा र उपकरणहरूमा पहुँच दिइयो। शमनवाद जारी रह्यो :)

अन्तमा, विक्रेताको प्रतिनिधिले विश्वस्तताका साथ भने कि हार्डवेयरसँग यसको कुनै सरोकार छैन: आरएसटीहरू उच्च कतैबाट आउँछन्।

भन्नुयस बिन्दुमा, कसैले भन्न सक्छ: तर परीक्षण पीसीबाट होइन, तर DPI माथिको राजमार्गबाट ​​डम्प लिन धेरै सजिलो थियो?

होइन, दुर्भाग्यवश, 40+ जीबीपीएस डम्प (र मात्र मिररिङ) लिनु कुनै पनि मामूली छैन।

यस पछि, साँझ, माथि कतै अनौठो छान्ने अनुमानमा फर्कनु बाहेक अरू केही बाँकी थिएन।

मैले कुन IX मार्फत MRG सञ्जालहरूमा ट्राफिक अब गुज्रिरहेको देखेँ र यसमा bgp सत्रहरू रद्द गरें। र - हेर र हेर! - सबै कुरा तुरुन्तै सामान्यमा फर्कियो 🙁

एकातिर, यो लज्जास्पद छ कि यो समस्याको खोजीमा पूरा दिन बित्यो, यद्यपि यो पाँच मिनेटमा समाधान भयो।

अर्कोतर्फ:

- मेरो सम्झनामा यो अभूतपूर्व कुरा हो। मैले पहिले नै माथि लेखेको जस्तै - IX वास्तवमा ट्रान्जिट ट्राफिक फिल्टर गर्ने कुनै अर्थ छैन। तिनीहरूसँग सामान्यतया सयौं गिगाबिट्स/टेराबिट्स प्रति सेकेन्ड हुन्छन्। मैले भर्खरै सम्म यस्तो केहि गम्भीरतापूर्वक कल्पना गर्न सक्दिन।

- परिस्थितिहरूको एक अविश्वसनीय रूपले भाग्यशाली संयोग: एक नयाँ जटिल हार्डवेयर जुन विशेष रूपमा विश्वसनीय छैन र जसबाट के आशा गर्न सकिन्छ भन्ने स्पष्ट छैन — TCP RST हरू सहित अवरुद्ध स्रोतहरूका लागि विशेष रूपमा अनुकूलित।

यो इन्टरनेट एक्सचेन्जको NOC हाल समस्या खोजिरहेको छ। तिनीहरूका अनुसार (र म तिनीहरूलाई विश्वास गर्छु), तिनीहरूसँग कुनै विशेष तैनाथ गरिएको निस्पंदन प्रणाली छैन। तर, धन्यवाद स्वर्ग, अर्को खोज अब हाम्रो समस्या छैन :)

यो आफैंलाई न्याय दिने सानो प्रयास थियो, कृपया बुझ्नुहोस् र माफ गर्नुहोस् :)

PS: म जानाजानी DPI/NAT वा IX को निर्माताको नाम राख्दिन (वास्तवमा, मसँग तिनीहरूको बारेमा कुनै विशेष गुनासो पनि छैन, मुख्य कुरा यो के थियो भनेर बुझ्नु हो)

इन्टरनेट प्रदायकको दृष्टिकोणबाट आजको (साथै हिजो र हिजोको अघिल्लो दिन) वास्तविकता

मैले पछिल्लो हप्ताहरू सञ्जालको कोरलाई महत्त्वपूर्ण रूपमा पुनर्निर्माण गर्न खर्च गरेको छु, "नाफाको लागि" हेरफेरको गुच्छा प्रदर्शन गर्दै, प्रत्यक्ष प्रयोगकर्ता ट्राफिकलाई महत्त्वपूर्ण रूपमा असर गर्ने जोखिमको साथ। यी सबैको लक्ष्य, नतिजा र नतिजालाई विचार गर्दा नैतिक रूपमा यो धेरै गाह्रो छ। विशेष गरी - एक पटक फेरि Runet को स्थिरता, सार्वभौमिकता, आदि को रक्षा को बारे मा सुन्दर भाषण सुन्न। र यस्तै।

यस खण्डमा, म विगत दस वर्षमा एक विशिष्ट ISP को नेटवर्क कोरको "विकास" वर्णन गर्ने प्रयास गर्नेछु।

दश वर्षअघि ।

ती धन्य समयहरूमा, प्रदायक नेटवर्कको मूल ट्राफिक जाम जस्तै सरल र भरपर्दो हुन सक्छ:

यो धेरै, धेरै सरल चित्रमा, त्यहाँ कुनै ट्रंकहरू, घण्टीहरू, ip/mpls राउटिङहरू छैनन्।

यसको सार यो हो कि प्रयोगकर्ता ट्राफिक अन्ततः कर्नेल स्तर स्विचिङमा आयो - जहाँबाट यो गयो बीएनजी, जहाँबाट, एक नियमको रूपमा, कोर स्विचिङमा फर्कनुहोस्, र त्यसपछि "आउट" - इन्टरनेटमा एक वा बढी सीमाना गेटवेहरू मार्फत।

यस्तो योजना L3 (गतिशील मार्ग) र L2 (MPLS) मा दुवै रिजर्भ गर्न धेरै, धेरै सजिलो छ।

तपाईंले कुनै पनि कुराको N+1 स्थापना गर्न सक्नुहुन्छ: पहुँच सर्भरहरू, स्विचहरू, बोर्डरहरू - र एक तरिका वा अर्को तिनीहरूलाई स्वचालित फेलओभरको लागि आरक्षित गर्नुहोस्।

केही वर्षपछि यो रूस मा सबैलाई स्पष्ट भयो कि यो अब यस जस्तै बाँच्न असम्भव थियो: यो इन्टरनेट को हानिकारक प्रभाव देखि बच्चाहरु को रक्षा गर्न जरुरी थियो।

प्रयोगकर्ता ट्राफिक फिल्टर गर्ने तरिकाहरू खोज्न तत्काल आवश्यकता थियो।

यहाँ विभिन्न दृष्टिकोणहरू छन्।

धेरै राम्रो अवस्थामा छैन, केहि "अन्तरमा" राखिएको छ: प्रयोगकर्ता ट्राफिक र इन्टरनेट बीच। यस "केहि" मार्फत गुजरने ट्राफिक विश्लेषण गरिन्छ र, उदाहरणका लागि, रिडिरेक्टको साथ नक्कली प्याकेट ग्राहक तर्फ पठाइन्छ।

थोरै राम्रो अवस्थामा - यदि ट्राफिक भोल्युमले अनुमति दिन्छ भने - तपाइँ आफ्नो कानले सानो चाल गर्न सक्नुहुन्छ: फिल्टर गर्न आवश्यक ठेगानाहरूमा मात्र प्रयोगकर्ताहरूबाट उत्पन्न हुने ट्राफिकलाई फिल्टर गर्न पठाउनुहोस् (यस गर्नको लागि, तपाइँ या त आईपी ठेगानाहरू लिन सक्नुहुन्छ। त्यहाँ रजिस्ट्रीबाट निर्दिष्ट गरिएको छ, वा थप रूपमा रजिस्ट्रीमा अवस्थित डोमेनहरू समाधान गर्नुहोस्)।

एक समयमा, यी उद्देश्यहरूको लागि, मैले एउटा सरल लेखे मिनी डीपीआई - यद्यपि म उसलाई बोलाउने हिम्मत गर्दिन। यो धेरै सरल छ र धेरै उत्पादनशील छैन - तथापि, यसले हामीलाई र दर्जनौं (यदि सयौं होइन) अन्य प्रदायकहरूलाई तुरुन्तै औद्योगिक DPI प्रणालीहरूमा लाखौंलाई बाहिर निकाल्न अनुमति दियो, तर धेरै अतिरिक्त वर्षहरू दियो।

वैसे, तत्कालीन र वर्तमान DPI को बारे माजे होस्, त्यस समयमा बजारमा उपलब्ध DPI प्रणालीहरू खरिद गर्ने धेरैले तिनीहरूलाई पहिले नै फ्याँकिसकेका थिए। खैर, तिनीहरू यसको लागि डिजाइन गरिएको छैन: सयौं हजार ठेगानाहरू, दसौं हजार URL हरू।

र एकै समयमा, घरेलु उत्पादकहरू यस बजारमा धेरै बलियो रूपमा बढेका छन्। म हार्डवेयर कम्पोनेन्टको बारेमा कुरा गरिरहेको छैन - यहाँ सबैलाई सबै कुरा स्पष्ट छ, तर सफ्टवेयर - मुख्य कुरा जुन DPI मा छ - सायद आज, यदि संसारमा सबैभन्दा उन्नत छैन भने, त्यसपछि निश्चित रूपमा क) छलांग र सीमा द्वारा विकास, र ख) बक्स उत्पादनको मूल्यमा - विदेशी प्रतिस्पर्धीहरूसँग अतुलनीय।

म गर्व गर्न चाहन्छु, तर थोरै दुखी =)

अब सबै कुरा यस्तो देखिन्थ्यो:

अझै एक दुई वर्षमा सबैसँग पहिले नै लेखा परीक्षकहरू थिए; रजिस्ट्रीमा थप स्रोतहरू थिए। केही पुराना उपकरणहरूका लागि (उदाहरणका लागि, Cisco 7600), "साइड-फिल्टरिङ" योजना मात्र लागू नहुने भयो: 76 प्लेटफर्महरूमा रुटहरूको सङ्ख्या नौ लाखमा सीमित छ, जबकि IPv4 रुटहरूको सङ्ख्या आज मात्रै 800 पुगेको छ। हजार। र यदि यो ipv6 पनि हो... र पनि... कति छ? RKN प्रतिबन्धमा 900000 व्यक्तिगत ठेगानाहरू? =)

कसैले फिल्टरिङ सर्भरमा सबै ब्याकबोन ट्राफिकको मिररिङको साथ योजनामा ​​स्विच गर्यो, जसले सम्पूर्ण प्रवाहको विश्लेषण गर्नुपर्छ र, यदि केहि खराब फेला पर्यो भने, दुबै दिशाहरूमा (प्रेषक र प्राप्तकर्ता) RST पठाउनुहोस्।

यद्यपि, अधिक ट्राफिक, यो योजना कम लागू हुन्छ। यदि प्रशोधनमा थोरै ढिलाइ भयो भने, मिरर गरिएको ट्राफिकले ध्यान नदिई उडान गर्नेछ, र प्रदायकले राम्रो रिपोर्ट प्राप्त गर्नेछ।

अधिक र अधिक प्रदायकहरू राजमार्गहरूमा विभिन्न डिग्रीको विश्वसनीयताका DPI प्रणालीहरू स्थापना गर्न बाध्य छन्।

एक–दुई वर्षअघिको कुरा हो अफवाहहरू अनुसार, लगभग सबै FSB ले उपकरणको वास्तविक स्थापनाको माग गर्न थाले SORM (पहिले, अधिकांश प्रदायकहरूले अधिकारीहरूबाट स्वीकृति लिएर व्यवस्थित गर्थे SORM योजना - कतै केहि फेला पार्न आवश्यक परेमा परिचालन उपायहरूको योजना)

पैसाको अतिरिक्त (वास्तवमा अत्यधिक छैन, तर अझै लाखौं), SORM लाई नेटवर्कसँग धेरै हेरफेर आवश्यक छ।

• SORM ले नेट अनुवाद गर्नु अघि "ग्रे" प्रयोगकर्ता ठेगानाहरू हेर्न आवश्यक छ
• SORM सँग नेटवर्क इन्टरफेसहरूको सीमित संख्या छ

त्यसकारण, विशेष गरी, हामीले कर्नेलको एउटा टुक्रालाई ठूलो मात्रामा पुनर्निर्माण गर्नुपर्‍यो - केवल एकै ठाउँमा पहुँच सर्भरहरूमा प्रयोगकर्ता ट्राफिक सङ्कलन गर्न। धेरै लिङ्कहरूसँग SORM मा मिरर गर्न।

त्यो हो, धेरै सरलीकृत, यो (बायाँ) बनाम (दायाँ) भयो:

अहिले धेरै प्रदायकहरूलाई SORM-3 को कार्यान्वयन आवश्यक छ - जसमा अन्य चीजहरू बीच, नेट प्रसारणहरूको लगिङ समावेश छ।

यी उद्देश्यहरूका लागि, हामीले माथिको रेखाचित्रमा NAT का लागि छुट्टै उपकरणहरू पनि थप्नुपर्ने थियो (ठीक रूपमा के पहिलो भागमा छलफल गरिएको छ)। यसबाहेक, एक निश्चित क्रममा थप्नुहोस्: SORM ले ठेगानाहरू अनुवाद गर्नु अघि ट्राफिक "हेर्नु" पर्ने हुनाले, ट्राफिक कडाईका साथ निम्नानुसार जानुपर्छ: प्रयोगकर्ताहरू -> स्विचिङ, कर्नेल -> पहुँच सर्भरहरू -> SORM -> NAT -> स्विचिङ, कर्नेल - > इन्टरनेट। यो गर्नको लागि, हामीले शाब्दिक रूपमा नाफाको लागि अर्को दिशामा ट्राफिक प्रवाह "टर्न" गर्नुपर्‍यो, जुन पनि धेरै गाह्रो थियो।

संक्षेपमा: विगत दश वर्षहरूमा, औसत प्रदायकको मूल डिजाइन धेरै गुणा जटिल भएको छ, र असफलताको अतिरिक्त बिन्दुहरू (दुवै उपकरणको रूपमा र एकल स्विचिङ लाइनहरूको रूपमा) उल्लेखनीय रूपमा बढेको छ। वास्तवमा, "सबै कुरा हेर्नु" को आवश्यकताले यो "सबै कुरा" लाई एक बिन्दुमा घटाउनु हो।

मलाई लाग्छ यो Runet को सार्वभौमीकरण गर्न, यसलाई सुरक्षित गर्न, यसलाई स्थिर गर्न र यसलाई सुधार गर्न हालको पहलहरूमा पारदर्शी रूपमा एक्स्ट्रापोलेट गर्न सकिन्छ :)

र Yarovaya अझै अगाडि छ।

स्रोत: www.habr.com