टिप्पणीसाठी तपशीलवार प्रतिसाद, तसेच रशियन फेडरेशनमधील प्रदात्यांच्या जीवनाबद्दल थोडेसे

मला या पोस्टसाठी प्रॉम्प्ट केले ही टिप्पणी आहे.

मी ते येथे उद्धृत करतो:

कालेमन आज 18:53 वाजता

मी आज प्रदात्यावर खूश होतो. साइट ब्लॉकिंग सिस्टमच्या अद्यतनासह, त्याच्या मेलर mail.ru वर बंदी घातली गेली. मी सकाळपासून तांत्रिक समर्थनाला कॉल करत आहे, परंतु ते काहीही करू शकत नाहीत. प्रदाता लहान आहे आणि वरवर पाहता उच्च-रँकिंग प्रदाते त्यास अवरोधित करतात. मला सर्व साइट्स उघडण्यात मंदी देखील दिसली, कदाचित त्यांनी काही प्रकारचे कुटिल डीएलपी स्थापित केले असेल? पूर्वी प्रवेशात कोणतीही समस्या नव्हती. RuNet चा नाश माझ्या डोळ्यासमोर घडत आहे...

वस्तुस्थिती अशी आहे की असे दिसते की आम्ही तेच प्रदाता आहोत :)

आणि खरंच, कालेमन मी जवळजवळ mail.ru सह समस्यांचे कारण अंदाज लावले (जरी आम्ही बर्याच काळापासून अशा गोष्टीवर विश्वास ठेवण्यास नकार दिला).

खालील गोष्टी दोन भागात विभागल्या जातील:

1. mail.ru मधील आमच्या सध्याच्या समस्यांची कारणे आणि त्यांना शोधण्याचा रोमांचक शोध
2. आजच्या वास्तविकतेमध्ये ISP चे अस्तित्व, सार्वभौम रुनेटची स्थिरता.

mail.ru सह प्रवेशयोग्यता समस्या

अरे, खूप लांबची गोष्ट आहे.

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

काही काळापूर्वी, आम्ही शेवटी नेटवर्क कोर अशा प्रकारे पुन्हा तयार केला की सर्व ग्राहक रहदारी या उपकरणातून काटेकोरपणे योग्य दिशेने जाते.

काही दिवसांपूर्वी आम्ही त्यावर निषिद्ध फिल्टरिंग चालू केले (जुनी प्रणाली कार्यरत असताना) - सर्व काही व्यवस्थित चालले आहे असे दिसते.

पुढे, त्यांनी हळूहळू ग्राहकांच्या वेगवेगळ्या भागांसाठी या उपकरणांवर NAT सक्षम करण्यास सुरुवात केली. त्याच्या दिसण्यावरून, सर्व काही व्यवस्थित चालले आहे.

परंतु आज, ग्राहकांच्या पुढील भागासाठी उपकरणांवर NAT सक्षम केल्यामुळे, अगदी सकाळपासून आम्हाला अनुपलब्धता किंवा अंशतः उपलब्धतेच्या तक्रारींचा सामना करावा लागला. mail.ru आणि इतर मेल रु ग्रुप संसाधने.

ते तपासू लागले: कुठेतरी काहीतरी कधी कधी, कधीकधी पाठवते TCP RST केवळ mail.ru नेटवर्कच्या विनंतीला प्रतिसाद म्हणून. शिवाय, ते चुकीच्या पद्धतीने व्युत्पन्न केलेले (ACK शिवाय), स्पष्टपणे कृत्रिम TCP RST पाठवते. हे असे दिसते:

स्वाभाविकच, पहिले विचार नवीन उपकरणांबद्दल होते: भयंकर डीपीआय, त्यावर विश्वास नाही, ते काय करू शकते हे आपल्याला कधीच माहित नाही - शेवटी, ब्लॉकिंग टूल्समध्ये टीसीपी आरएसटी ही एक सामान्य गोष्ट आहे.

धारणा कालेमन कोणीतरी "श्रेष्ठ" फिल्टर करत आहे ही कल्पना देखील आम्ही पुढे मांडली, परंतु ती लगेच टाकून दिली.

प्रथम, आमच्याकडे पुरेशी समजूतदार अपलिंक्स आहेत जेणेकरून आम्हाला असा त्रास सहन करावा लागणार नाही :)

दुसरे म्हणजे, आम्ही अनेकांशी जोडलेले आहोत IX मॉस्कोमध्ये, आणि mail.ru ची रहदारी त्यांच्यामधून जाते - आणि त्यांच्याकडे ना जबाबदाऱ्या आहेत किंवा रहदारी फिल्टर करण्याचा इतर कोणताही हेतू नाही.

दिवसाचा पुढचा अर्धा भाग सामान्यतः ज्याला शमनवाद म्हणतात त्यावर घालवला - उपकरणे विक्रेत्यासह, ज्यासाठी आम्ही त्यांचे आभार मानतो, त्यांनी हार मानली नाही :)

• फिल्टरिंग पूर्णपणे अक्षम केले होते
• नवीन योजना वापरून NAT अक्षम करण्यात आले
• चाचणी पीसी वेगळ्या वेगळ्या पूलमध्ये ठेवण्यात आला होता
• IP पत्ता बदलला

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

सरतेशेवटी, विक्रेत्याच्या प्रतिनिधीने आत्मविश्वासाने सांगितले की हार्डवेअरचा त्याच्याशी काहीही संबंध नाही: आरएसटी कुठेतरी उंचावरून येतात.

शेराया टप्प्यावर, कोणीतरी म्हणेल: परंतु चाचणी पीसीवरून नाही तर डीपीआयच्या वरील महामार्गावरून डंप घेणे खूप सोपे होते?

नाही, दुर्दैवाने, डंप (आणि अगदी मिररिंग) 40+gbps घेणे अजिबात क्षुल्लक नाही.

यानंतर, संध्याकाळी, वर कुठेतरी विचित्र गाळणे गृहीत धरून परत येण्याशिवाय काहीच उरले नाही.

MRG नेटवर्क्सची रहदारी आता कोणत्या IX मधून जात आहे ते मी पाहिले आणि फक्त bgp सत्रे रद्द केली. आणि - पहा आणि पाहा! - सर्वकाही ताबडतोब सामान्य झाले 🙁

एकीकडे, ही लाजिरवाणी गोष्ट आहे की संपूर्ण दिवस समस्या शोधण्यात घालवला गेला, जरी ती पाच मिनिटांत सोडवली गेली.

दुसरीकडे:

- माझ्या आठवणीत ही एक अभूतपूर्व गोष्ट आहे. जसे मी आधीच वर लिहिले आहे - IX खरोखर ट्रान्झिट ट्रॅफिक फिल्टर करण्यात काही अर्थ नाही. त्यांच्याकडे सहसा शेकडो गिगाबिट्स/टेराबिट्स प्रति सेकंद असतात. मी अलीकडेपर्यंत यासारखे काहीतरी गंभीरपणे कल्पना करू शकत नाही.

— परिस्थितीचा एक आश्चर्यकारकपणे भाग्यवान योगायोग: एक नवीन जटिल हार्डवेअर ज्यावर विशेषतः विश्वास ठेवला जात नाही आणि ज्यातून काय अपेक्षित आहे हे स्पष्ट नाही — TCP RSTs सह, संसाधने अवरोधित करण्यासाठी विशेषतः तयार केले आहे

या इंटरनेट एक्सचेंजची एनओसी सध्या समस्या शोधत आहे. त्यांच्या मते (आणि मी त्यांच्यावर विश्वास ठेवतो), त्यांच्याकडे विशेषत: तैनात केलेली गाळण्याची प्रक्रिया प्रणाली नाही. पण, स्वर्गाचे आभार, पुढील शोध आता आमची समस्या नाही :)

स्वतःला न्याय देण्याचा हा एक छोटासा प्रयत्न होता, कृपया समजून घ्या आणि माफ करा :)

PS: मी मुद्दाम DPI/NAT किंवा IX च्या निर्मात्याचे नाव घेत नाही (खरं तर, मला त्यांच्याबद्दल कोणतीही विशेष तक्रार देखील नाही, मुख्य गोष्ट म्हणजे ते काय होते हे समजून घेणे)

इंटरनेट प्रदात्याच्या दृष्टिकोनातून आजचे (तसेच कालचे आणि परवाचे) वास्तव

लाइव्ह यूजर ट्रॅफिकवर लक्षणीय परिणाम होण्याच्या जोखमीसह, “नफ्यासाठी” अनेक फेरफार करत, नेटवर्कच्या कोरची पुनर्बांधणी करण्यासाठी मी गेल्या आठवडे लक्षणीयरीत्या खर्च केले आहेत. या सर्वांची उद्दिष्टे, परिणाम आणि परिणाम लक्षात घेता नैतिकदृष्ट्या हे सर्व कठीण आहे. विशेषतः - पुन्हा एकदा रुनेटची स्थिरता, सार्वभौमत्व इत्यादींचे संरक्षण करण्याबद्दल सुंदर भाषण ऐकणे. आणि असेच.

या विभागात, मी गेल्या दहा वर्षांत ठराविक ISP च्या नेटवर्क कोरच्या "उत्क्रांती" चे वर्णन करण्याचा प्रयत्न करेन.

दहा वर्षा पूर्वी.

त्या आशीर्वादित काळात, प्रदाता नेटवर्कचा गाभा ट्रॅफिक जॅमइतका सोपा आणि विश्वासार्ह असू शकतो:

या अतिशय, अतिशय सोप्या चित्रात, ट्रंक, रिंग, ip/mpls राउटिंग नाहीत.

त्याचे सार हे आहे की वापरकर्ता रहदारी शेवटी कर्नल स्तरावर स्विचिंगवर आली - जिथून ते गेले बीएनजी, तेथून, एक नियम म्हणून, परत कोर स्विचिंगवर, आणि नंतर "बाहेर" - इंटरनेटच्या एक किंवा अधिक बॉर्डर गेटवेद्वारे.

अशी योजना L3 (डायनॅमिक राउटिंग) आणि L2 (MPLS) वर आरक्षित करणे खूप सोपे आहे.

तुम्ही कोणत्याही गोष्टीचा N+1 इन्स्टॉल करू शकता: अॅक्सेस सर्व्हर, स्विचेस, बॉर्डर - आणि एक मार्ग किंवा दुसरा त्यांना स्वयंचलित फेलओव्हरसाठी राखून ठेवा.

काही वर्षांनी रशियामधील प्रत्येकाला हे स्पष्ट झाले की यापुढे असे जगणे अशक्य आहे: इंटरनेटच्या हानिकारक प्रभावापासून मुलांचे संरक्षण करणे तातडीचे आहे.

वापरकर्ता रहदारी फिल्टर करण्यासाठी मार्ग शोधण्याची तातडीची गरज होती.

येथे भिन्न दृष्टिकोन आहेत.

फार चांगले नसलेल्या बाबतीत, काहीतरी "अंतर" ठेवले जाते: वापरकर्ता रहदारी आणि इंटरनेट दरम्यान. या “काहीतरी” मधून जाणार्‍या रहदारीचे विश्लेषण केले जाते आणि उदाहरणार्थ, पुनर्निर्देशित असलेले बनावट पॅकेट ग्राहकाकडे पाठवले जाते.

थोड्या चांगल्या बाबतीत - जर रहदारीची संख्या परवानगी असेल तर - तुम्ही तुमच्या कानाने एक छोटीशी युक्ती करू शकता: फक्त वापरकर्त्यांकडून येणारी रहदारी फिल्टर करण्यासाठी फक्त त्या पत्त्यांवर पाठवा ज्यांना फिल्टर करणे आवश्यक आहे (हे करण्यासाठी, तुम्ही एकतर IP पत्ते घेऊ शकता. तेथे रेजिस्ट्रीमधून निर्दिष्ट केले आहे, किंवा त्याव्यतिरिक्त रेजिस्ट्रीमधील विद्यमान डोमेनचे निराकरण करा).

एकेकाळी, या हेतूंसाठी, मी एक साधे लिहिले मिनी डीपीआय - जरी मी त्याला कॉल करण्याचे धाडस करत नाही. हे खूप सोपे आहे आणि फारसे उत्पादनक्षम नाही - तथापि, यामुळे आम्हाला आणि इतर डझनभर (शेकडो नसल्यास) प्रदात्यांना औद्योगिक डीपीआय सिस्टमवर लक्षावधींचा तात्काळ खर्च न करण्याची परवानगी दिली, परंतु अनेक अतिरिक्त वर्षे वेळ दिला.

तसे, तत्कालीन आणि वर्तमान डीपीआय बद्दलतसे, त्यावेळी बाजारात उपलब्ध असलेल्या DPI सिस्टीम विकत घेतलेल्या अनेकांनी त्या आधीच फेकून दिल्या होत्या. बरं, ते यासाठी डिझाइन केलेले नाहीत: शेकडो हजारो पत्ते, हजारो URL.

आणि त्याच वेळी, देशांतर्गत उत्पादक या बाजारपेठेत जोरदारपणे वाढले आहेत. मी हार्डवेअर घटकाबद्दल बोलत नाही आहे - येथे प्रत्येकाला सर्वकाही स्पष्ट आहे, परंतु सॉफ्टवेअर - DPI कडे असलेली मुख्य गोष्ट - कदाचित आज जगातील सर्वात प्रगत नसेल तर नक्कीच अ) वेगाने विकसित होत आहे, आणि ब) बॉक्स केलेल्या उत्पादनाच्या किंमतीवर - परदेशी प्रतिस्पर्ध्यांशी फक्त अतुलनीय.

मला अभिमान वाटेल, पण थोडेसे दुःखी आहे =)

आता सर्वकाही असे दिसत होते:

आणखी एक दोन वर्षांत प्रत्येकाकडे आधीच ऑडिटर होते; नोंदणीमध्ये अधिकाधिक संसाधने होती. काही जुन्या उपकरणांसाठी (उदाहरणार्थ, Cisco 7600), “साइड-फिल्टरिंग” योजना लागू होऊ शकली नाही: 76 प्लॅटफॉर्मवरील मार्गांची संख्या नऊ लाखांपुरती मर्यादित आहे, तर एकट्या IPv4 मार्गांची संख्या आज 800 च्या जवळ आहे. हजार आणि जर ते ipv6 देखील असेल तर... आणि देखील... किती आहे? RKN बंदी मध्ये 900000 वैयक्तिक पत्ते? =)

कोणीतरी फिल्टरिंग सर्व्हरवर सर्व बॅकबोन ट्रॅफिकचे मिररिंग असलेल्या स्कीमवर स्विच केले आहे, ज्याने संपूर्ण प्रवाहाचे विश्लेषण केले पाहिजे आणि काहीतरी खराब आढळल्यास, दोन्ही दिशांना (प्रेषक आणि प्राप्तकर्ता) RST पाठवा.

तथापि, जितकी जास्त रहदारी तितकी ही योजना कमी लागू होईल. प्रक्रियेत थोडासा विलंब झाल्यास, मिरर केलेली रहदारी फक्त लक्ष न दिल्याने उडते आणि प्रदात्याला एक चांगला अहवाल प्राप्त होईल.

अधिकाधिक प्रदात्यांना महामार्गावर वेगवेगळ्या प्रमाणात विश्वासार्हतेची डीपीआय प्रणाली स्थापित करण्याची सक्ती केली जाते.

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

पैशांव्यतिरिक्त (नक्की जास्त नाही, परंतु तरीही लाखो), SORM ला नेटवर्कसह आणखी अनेक हाताळणी आवश्यक आहेत.

• SORM ला नेट भाषांतर करण्यापूर्वी "राखाडी" वापरकर्ता पत्ते पाहण्याची आवश्यकता आहे
• SORM मध्ये नेटवर्क इंटरफेस मर्यादित आहेत

म्हणूनच, विशेषतः, आम्हाला कर्नलचा एक तुकडा मोठ्या प्रमाणात पुन्हा तयार करावा लागला - फक्त एकाच ठिकाणी कुठेतरी ऍक्सेस सर्व्हरवर वापरकर्ता रहदारी गोळा करण्यासाठी. अनेक दुव्यांसह SORM मध्ये मिरर करण्यासाठी.

म्हणजेच, अतिशय सरलीकृत, ते (डावीकडे) वि बनले (उजवीकडे):

आता बर्‍याच प्रदात्यांना SORM-3 ची अंमलबजावणी देखील आवश्यक असते - ज्यामध्ये इतर गोष्टींबरोबरच, नेट ब्रॉडकास्टचे लॉगिंग समाविष्ट असते.

या हेतूंसाठी, आम्हाला वरील आकृतीमध्ये NAT साठी स्वतंत्र उपकरणे देखील जोडावी लागली (नक्की कशाची चर्चा पहिल्या भागात केली आहे). शिवाय, एका विशिष्ट क्रमाने जोडा: SORM ने पत्त्यांचे भाषांतर करण्यापूर्वी रहदारी "पाहणे" आवश्यक असल्याने, रहदारी खालीलप्रमाणे काटेकोरपणे जाणे आवश्यक आहे: वापरकर्ते -> स्विचिंग, कर्नल -> ऍक्सेस सर्व्हर -> SORM -> NAT -> स्विचिंग, कर्नल - > इंटरनेट. हे करण्यासाठी, आम्हाला फायद्यासाठी वाहतुकीचा प्रवाह अक्षरशः "वळवावा" लागला, जो खूप कठीण होता.

सारांश: गेल्या दहा वर्षांत, सरासरी प्रदात्याचे मूळ डिझाइन अनेक पटींनी अधिक जटिल झाले आहे, आणि अपयशाचे अतिरिक्त मुद्दे (उपकरणे आणि सिंगल स्विचिंग लाईन्सच्या स्वरूपात दोन्ही) लक्षणीय वाढले आहेत. वास्तविक, "सर्व काही पाहणे" या आवश्यकतेचा अर्थ हे "सर्व काही" एका बिंदूवर कमी करणे होय.

मला वाटते की हे रुनेटचे सार्वभौमीकरण करण्यासाठी, त्याचे संरक्षण करण्यासाठी, ते स्थिर करण्यासाठी आणि सुधारण्यासाठी सध्याच्या उपक्रमांमध्ये पारदर्शकपणे विस्तारित केले जाऊ शकते :)

आणि यारोवाया अजूनही पुढे आहे.

स्त्रोत: www.habr.com