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

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

मैं उसे यहाँ लाता हूँ:

कलमन आज 18:53 पर

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

तथ्य यह है कि, ऐसा लगता है, हम बहुत प्रदाता हैं :(

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

आगे दो भागों में विभाजित किया जाएगा:

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

Mail.ru की उपलब्धता के साथ समस्याएं

ओह, यह एक बहुत लंबी कहानी है।

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

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

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

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

लेकिन आज, ग्राहकों के अगले भाग के लिए NAT उपकरण चालू होने से, सुबह हम मेल पते की अनुपलब्धता या आंशिक उपलब्धता और अन्य मेल आरयू समूह संसाधनों की अनुपलब्ध शिकायतों के बारे में एक सभ्य संख्या में आए।

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







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

कलमन की धारणा है कि कोई "श्रेष्ठ" को फ़िल्टर कर रहा है, हम भी आगे रखते हैं - लेकिन फिर त्याग दिया गया।

सबसे पहले, हमारे पास पर्याप्त सन्न अपलिंक हैं ताकि उस तरह से पीड़ित न हों :)

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

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

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

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

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


उसके बाद, शाम को, कुछ और करने के अलावा और कुछ नहीं था, ऊपर एक अजीब फ़िल्टरिंग की धारणा पर लौटने के लिए।

मैंने देखा कि IW ट्रैफिक अब IWGs के नेटवर्क पर जा रहा है और बस इसे करने के लिए bgp सेशन का भुगतान किया है। और - लो और निहारना! - सब कुछ तुरंत सामान्य हो गया :(

एक तरफ, यह दुर्भाग्यपूर्ण है कि पूरा दिन समस्या की खोज में लगा रहा, हालांकि इसे पांच मिनट में हल किया गया था।

दूसरी ओर:

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

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

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

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

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

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

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

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

दस साल पहले।

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



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

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

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

आप एन + 1 कुछ भी डाल सकते हैं: सर्वर, स्विच, बोर्डर्स का उपयोग करें - और किसी तरह उन्हें स्वचालित विफलता के लिए आरक्षित करें।

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

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

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

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

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

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


अब ऐसा लग रहा था:



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

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

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

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

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

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

• एनएटी प्रसारण से पहले SORM को उपयोगकर्ताओं के "ग्रे" पते देखने होंगे
• SORM के पास सीमित नेटवर्क इंटरफेस है

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

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



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

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

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

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

और आगे यारोव्य है।