NAT प्रदाता के लिए DDOS से छिपा हुआ

UPD यह विचार पूरी तरह से स्पष्ट नहीं है, टिप्पणियों में विस्तृत व्याख्या।

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

लेख बताता है कि इस अवसर का लाभ कैसे उठाया जाए, जो, इसके अलावा, पूरी तरह से नि: शुल्क प्रदान किया जाता है, और अपनी कार्यक्षमता को संरक्षित करते हुए अपने सर्वर को हमलों से बचाने के लिए।

हम आदर्श रूप से क्या प्राप्त कर सकते हैं:
- पूरी तरह कार्यात्मक क्लाइंट-सर्वर अनुप्रयोग;
- डीडीओएस से मुक्त संरक्षण, बाढ़ यातायात को अवशोषित करने में सक्षम, प्रदाता के ट्रंक चैनल की चौड़ाई के लिए मात्रा में तुलनीय;
- नेटवर्क के बुनियादी ढांचे में बदलाव की आवश्यकता के बिना सॉफ्टवेयर कार्यान्वयन।



तो, आप NAT प्रदाता के पीछे हैं और आपके पास एक ग्रे IP है। आपके कंप्यूटर को एक बाहरी आईपी प्राप्त नहीं है। सिद्धांत रूप में, यह सुनिश्चित करने के लिए पर्याप्त है कि आपका सर्वर डीडीओएस से सुरक्षित है।

लेकिन आप पूछते हैं: लेकिन सम्मानित उपयोगकर्ताओं के बारे में क्या मेरे सर्वर से कनेक्ट होगा? यह बाहर से दुर्गम है ... वास्तव में, ग्राहक की पहल पर एक कनेक्शन स्थापित करने में विफल हो जाएगा। लेकिन यहां से मस्ती शुरू होती है।

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

लेकिन सर्वर को कैसे पता चलता है कि वे इससे जुड़ना चाहते हैं?

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

यहाँ कुछ उदाहरण हैं:
- मेल सर्वर;
- Google Apps;
- एफ़टीपी सर्वर;
- मुफ्त होस्टिंग (स्टैटिक्स सहित);
- कोई भी सेवा जो एपीआई प्रदान करती है और जिसके माध्यम से आप सूचनाओं का आदान-प्रदान कर सकते हैं।

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

इसलिए, हमने क्या हासिल करने का प्रबंधन किया।

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

प्रस्तावित विधि के नुकसान क्या हैं?
- विधि केवल पूर्ण क्लाइंट-सर्वर अनुप्रयोगों के लिए उपयुक्त है;
- विधि छोटी परियोजनाओं के लिए उपयुक्त है;
- NAT प्रदाता के पीछे होना सुनिश्चित करें;
- ग्रे आईपी वाले ग्राहक कनेक्ट नहीं हो पाएंगे।

अंत में, मैं कहना चाहता हूं कि वर्णित विचार व्यक्तिगत रूप से मेरा है। और मुझे हाबरा निवासियों के साथ इस पर चर्चा करने की बहुत इच्छा है :) मैं आपके सवालों का जवाब देने के लिए तैयार हूं ...