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

मुझे इस पोस्ट के लिए प्रेरित किया यह टिप्पणी है.

मैं इसे यहां उद्धृत कर रहा हूं:

कालेमन आज 18 में: 53

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

सच तो यह है कि ऐसा लगता है कि हम वही प्रदाता हैं :)

सचमुच, कालेमन मैंने mail.ru के साथ समस्याओं के कारण का लगभग अनुमान लगा लिया था (हालाँकि हमने लंबे समय तक ऐसी किसी बात पर विश्वास करने से इनकार कर दिया था)।

निम्नलिखित को दो भागों में विभाजित किया जाएगा:

1. mail.ru के साथ हमारी वर्तमान समस्याओं के कारण और उन्हें खोजने की रोमांचक खोज
2. आज की वास्तविकताओं में आईएसपी का अस्तित्व, संप्रभु रूनेट की स्थिरता।

mail.ru के साथ अभिगम्यता संबंधी समस्याएँ

ओह, यह काफी लंबी कहानी है.

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

कुछ समय पहले, हमने अंततः नेटवर्क कोर को इस तरह से फिर से बनाया कि सभी ग्राहक ट्रैफ़िक इस उपकरण से सही दिशा में गुजरें।

कुछ दिन पहले हमने इस पर निषिद्ध फ़िल्टरिंग चालू कर दी थी (पुराने सिस्टम को चालू रखते हुए) - सब कुछ ठीक चल रहा था।

इसके बाद, उन्होंने धीरे-धीरे ग्राहकों के विभिन्न हिस्सों के लिए इस उपकरण पर NAT को सक्षम करना शुरू कर दिया। देखने से तो यह भी लग रहा था कि सबकुछ ठीक चल रहा है.

लेकिन आज, ग्राहकों के अगले हिस्से के लिए उपकरण पर NAT सक्षम करने के बाद, सुबह से ही हमें अनुपलब्धता या आंशिक उपलब्धता के बारे में अच्छी संख्या में शिकायतों का सामना करना पड़ा। mail.ru और अन्य मेल आरयू समूह संसाधन।

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

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

मान्यता कालेमन हमने यह विचार भी सामने रखा कि कोई "श्रेष्ठ" फ़िल्टर कर रहा है, लेकिन तुरंत इसे त्याग दिया।

सबसे पहले, हमारे पास पर्याप्त समझदार अपलिंक हैं ताकि हमें इस तरह का नुकसान न उठाना पड़े :)

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

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

• फ़िल्टरिंग पूरी तरह अक्षम थी
• नई योजना का उपयोग करके NAT को अक्षम कर दिया गया था
• परीक्षण पीसी को एक अलग पृथक पूल में रखा गया था
• आईपी ​​एड्रेसिंग बदल गई

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

अंत में, विक्रेता के प्रतिनिधि ने आत्मविश्वास से कहा कि हार्डवेयर का इससे कोई लेना-देना नहीं है: आरएसटी कहीं ऊपर से आते हैं।

नोटइस बिंदु पर, कोई कह सकता है: लेकिन परीक्षण पीसी से नहीं, बल्कि डीपीआई के ऊपर राजमार्ग से डंप लेना बहुत आसान था?

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

इसके बाद शाम को ऊपर कहीं अजीब छननी की धारणा पर लौटने के अलावा कुछ नहीं बचा।

मैंने देखा कि एमआरजी नेटवर्क पर ट्रैफिक अब किस IX से होकर गुजर रहा है और बस इसके बीजीपी सत्र रद्द कर दिए। और - देखो और देखो! - सब कुछ तुरंत सामान्य हो गया 🙁

एक ओर, यह शर्म की बात है कि समस्या को खोजने में पूरा दिन व्यतीत हो गया, हालाँकि इसे पाँच मिनट में हल कर दिया गया।

दूसरी ओर:

- मेरी स्मृति में यह एक अभूतपूर्व बात है। जैसा कि मैंने पहले ही ऊपर लिखा है - IX वास्तव में पारगमन यातायात को फ़िल्टर करने का कोई मतलब नहीं है। उनके पास आमतौर पर प्रति सेकंड सैकड़ों गीगाबिट्स/टेराबिट्स होते हैं। हाल तक मैं इस तरह की किसी चीज़ की गंभीरता से कल्पना भी नहीं कर सका था।

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

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

यह खुद को सही ठहराने का एक छोटा सा प्रयास था, कृपया समझें और क्षमा करें :)

पुनश्च: मैं जानबूझकर DPI/NAT या IX के निर्माता का नाम नहीं बताता (वास्तव में, मुझे उनके बारे में कोई विशेष शिकायत भी नहीं है, मुख्य बात यह समझना है कि यह क्या था)

एक इंटरनेट प्रदाता के दृष्टिकोण से आज की (साथ ही कल और परसों की भी) वास्तविकता

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

इस खंड में, मैं पिछले दस वर्षों में एक विशिष्ट आईएसपी के नेटवर्क कोर के "विकास" का वर्णन करने का प्रयास करूंगा।

दस साल पहले।

उन धन्य समयों में, प्रदाता नेटवर्क का मूल ट्रैफ़िक जाम जितना सरल और विश्वसनीय हो सकता था:

इस बहुत ही सरलीकृत चित्र में, कोई ट्रंक, रिंग, आईपी/एमपीएल रूटिंग नहीं है।

इसका सार यह है कि उपयोगकर्ता ट्रैफ़िक अंततः कर्नेल स्तर पर स्विचिंग पर आया - जहाँ से वह गया था BNG, जहां से, एक नियम के रूप में, वापस कोर स्विचिंग, और फिर "आउट" - इंटरनेट के एक या अधिक बॉर्डर गेटवे के माध्यम से।

ऐसी योजना L3 (डायनामिक रूटिंग) और L2 (MPLS) दोनों पर आरक्षित करना बहुत आसान है।

आप किसी भी चीज़ का N+1 इंस्टॉल कर सकते हैं: एक्सेस सर्वर, स्विच, बॉर्डर - और किसी न किसी तरह से उन्हें स्वचालित विफलता के लिए आरक्षित कर सकते हैं।

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

उपयोगकर्ता ट्रैफ़िक को फ़िल्टर करने के तरीके खोजने की तत्काल आवश्यकता थी।

यहां अलग-अलग दृष्टिकोण हैं।

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

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

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

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

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

मैं गर्व करना चाहूंगा, लेकिन थोड़ा दुखी हूं =)

अब सब कुछ इस तरह दिखता था:

कुछ और वर्षों में सभी के पास पहले से ही लेखा परीक्षक थे; रजिस्ट्री में अधिक से अधिक संसाधन थे। कुछ पुराने उपकरणों (उदाहरण के लिए, सिस्को 7600) के लिए, "साइड-फ़िल्टरिंग" योजना बस अनुपयुक्त हो गई: 76 प्लेटफार्मों पर मार्गों की संख्या लगभग नौ लाख तक सीमित है, जबकि अकेले आईपीवी4 मार्गों की संख्या आज 800 के करीब पहुंच रही है। हज़ार। और अगर यह आईपीवी6 भी है... और भी... कितना है? आरकेएन प्रतिबंध में 900000 व्यक्तिगत पते? =)

किसी ने सभी बैकबोन ट्रैफ़िक को फ़िल्टरिंग सर्वर पर मिरर करने वाली एक योजना पर स्विच किया, जिसे पूरे प्रवाह का विश्लेषण करना चाहिए और, यदि कुछ बुरा पाया जाता है, तो दोनों दिशाओं (प्रेषक और प्राप्तकर्ता) में आरएसटी भेजें।

हालाँकि, जितना अधिक ट्रैफ़िक, यह योजना उतनी ही कम लागू होती है। यदि प्रसंस्करण में थोड़ी सी भी देरी होती है, तो प्रतिबिंबित ट्रैफ़िक बिना ध्यान दिए उड़ जाएगा, और प्रदाता को एक बढ़िया रिपोर्ट प्राप्त होगी।

अधिक से अधिक प्रदाताओं को राजमार्गों पर विश्वसनीयता की अलग-अलग डिग्री की डीपीआई प्रणाली स्थापित करने के लिए मजबूर किया जाता है।

एक या दो साल पहले अफवाहों के अनुसार, लगभग सभी एफएसबी उपकरणों की वास्तविक स्थापना की मांग करने लगे SORM (पहले, अधिकांश प्रदाता अधिकारियों से अनुमोदन के साथ प्रबंधन करते थे एसओआरएम योजना - कहीं कुछ खोजने की आवश्यकता होने पर परिचालन उपायों की एक योजना)

पैसे के अलावा (बिल्कुल अत्यधिक नहीं, लेकिन फिर भी लाखों), SORM को नेटवर्क के साथ कई और जोड़-तोड़ की आवश्यकता थी।

• SORM को नेट अनुवाद से पहले "ग्रे" उपयोगकर्ता पते देखने की आवश्यकता है
• SORM में सीमित संख्या में नेटवर्क इंटरफ़ेस हैं

इसलिए, विशेष रूप से, हमें कर्नेल के एक टुकड़े को बड़े पैमाने पर पुनर्निर्माण करना पड़ा - बस एक ही स्थान पर एक्सेस सर्वर पर उपयोगकर्ता ट्रैफ़िक एकत्र करने के लिए। इसे कई लिंक के साथ SORM में प्रतिबिंबित करने के लिए।

यानी, बहुत सरलीकृत, यह (बाएं) बनाम बन गया (दाएं):

अब अधिकांश प्रदाताओं को SORM-3 के कार्यान्वयन की भी आवश्यकता होती है - जिसमें अन्य चीजों के अलावा, नेट प्रसारण की लॉगिंग भी शामिल है।

इन उद्देश्यों के लिए, हमें ऊपर दिए गए चित्र में NAT के लिए अलग उपकरण भी जोड़ने पड़े (ठीक वही जो पहले भाग में चर्चा की गई है)। इसके अलावा, एक निश्चित क्रम में जोड़ें: चूंकि पते का अनुवाद करने से पहले SORM को ट्रैफ़िक को "देखना" चाहिए, ट्रैफ़िक को सख्ती से निम्नानुसार जाना चाहिए: उपयोगकर्ता -> स्विचिंग, कर्नेल -> एक्सेस सर्वर -> SORM -> NAT -> स्विचिंग, कर्नेल - > इंटरनेट. ऐसा करने के लिए, हमें वस्तुतः लाभ के लिए ट्रैफ़िक प्रवाह को दूसरी दिशा में "मोड़ना" पड़ा, जो काफी कठिन भी था।

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

मुझे लगता है कि इसे रूनेट को संप्रभु बनाने, इसकी रक्षा करने, इसे स्थिर करने और इसमें सुधार करने की वर्तमान पहलों के लिए काफी पारदर्शी तरीके से लागू किया जा सकता है :)

और यारोवाया अभी भी आगे है।

स्रोत: www.habr.com