IPsec को Shadowsocks से बदलने से पहले गुम होने वाले काम लिख लें

तीन सेवाएँ, एक सुरंग: एक वेब ऐप, एक डेटाबेस और एक फ़ाइल शेयर। कोई IPsec को Shadowsocks से बदलने का सुझाव देता है, क्योंकि इसे चलाना सरल है। उसके बाद का एन्क्रिप्शन बहस मूल बात चूक जाता है, क्योंकि सुरंग एक साथ कई काम कर रही है और उनमें से केवल एक ही सिफ़रों से जुड़ा है। उत्पादों की तुलना करने से पहले वे काम लिख लें। सूची छोटी है, और इसका कोई भी एक मद बदलाव को अमान्य कर सकता है।

शुरू इससे करें कि ट्रैफ़िक कैसे पकड़ा जाता है

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

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

हर गंतव्य और प्रोटोकॉल का नाम लें

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

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

एन्क्रिप्शन अनुमोदन नहीं है

Shadowsocks में दर्ज AEAD विधियाँ प्रमाणित एन्क्रिप्शन देती हैं, इसलिए पूरे परिवार को असुरक्षित कहकर खारिज करना ग़लत है। उस तथ्य को पहुँच के सवाल का जवाब बनने देना भी उतना ही ग़लत है। किसी को तय करना होगा कि कौन किस सेवा तक पहुँचता है, किसी के जाने पर पहुँच कैसे हटाई जाती है, रहस्य कहाँ रखे जाते हैं और कौन-सा घटक सीमा लागू करता है। एक साझा रहस्य हर धारक को समान पहुँच देता है, और एक व्यक्ति को बाहर करना सबके लिए रोटेशन बन जाता है।

मौजूदा IPsec सेटअप को उसी कसौटी पर परखें। उसका लेबल साबित नहीं करता कि उसके नियम सही हैं, और एक डिज़ाइन के चमकाए हुए संस्करण की तुलना दूसरे के धुँधले संस्करण से करने से कुछ तय नहीं होता।

आज दोनों ओर मौजूद नियंत्रणों की सूची बनाएँ, फिर तय करें कि किन कमियों के साथ आप रह सकते हैं।

संचालन का काम गिनें

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

एक वेब ऐप के लिए संकरा प्रॉक्सी काफ़ी हो सकता है। हर व्यक्ति के लिए अनुमतियों सहित पूरे नेटवर्क तक पहुँच के लिए अतिरिक्त हिस्से आम तौर पर उस सुरंग से अधिक महँगे पड़ते हैं जिसे उन्होंने बदला था।

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