VPN पर Dante SOCKS: पूर्ण टनल बनाम स्रोत-आधारित राउटिंग
केवल SOCKS प्रॉक्सी को टनल से भेजने के दो तरीके: डिफ़ॉल्ट रूट बदलना, या एक स्रोत पता को उसकी अपनी तालिका से जोड़ना। दोनों अलग तरह से विफल होते हैं।
आप चाहते हैं कि SOCKS प्रॉक्सी का ट्रैफ़िक VPN से बाहर जाए जबकि होस्ट का बाकी हिस्सा अपना सामान्य रास्ता बनाए रखे। दो डिज़ाइन ऐसा करते हैं, और वे इसमें भिन्न हैं कि कुछ गड़बड़ होने पर क्या टूटता है। एक टनल में डिफ़ॉल्ट रूट डालता है और फिर उसके चारों ओर से काम करता है; दूसरा मुख्य तालिका को अछूता छोड़कर एक स्रोत पता दूसरी तालिका में भेजता है। दूसरा अधिक साफ़ है, और उसके अपने जाल हैं।
दो डिज़ाइन, दो अलग नुकसान-त्रिज्याएँ
पूर्ण-टनल डिज़ाइन वही है जो अधिकांश VPN क्लाइंट डिफ़ॉल्ट रूप से करते हैं: डिफ़ॉल्ट रूट बदल दें ताकि सब कुछ टनल का अनुसरण करे, और फिर जो नहीं होना चाहिए उसे बाहर रखें। इसके बारे में सोचना आसान और इसे संकीर्ण रखना कठिन है, क्योंकि आप जो भी स्थानीय सेवा जोड़ते हैं वह टनल विरासत में पाती है जब तक आप उसे बाहर न रखें। विफलता का तरीका व्यापक है, क्योंकि एक गलत रूट होस्ट की अपनी कनेक्टिविटी भी ले जाता है।
स्रोत-चयनित डिज़ाइन उलटी दिशा में जाता है। मुख्य तालिका जैसी थी वैसी ही रहती है, और एक नीति नियम किसी विशेष स्थानीय पते से आने वाले पैकेट को टनल-डिफ़ॉल्ट वाली तालिका में भेजता है। और कुछ नहीं बदलता, यानी नुकसान-त्रिज्या एक पता है।
यही संकीर्णता बाधा भी है: डिज़ाइन तभी काम करता है जब प्रॉक्सी के बाहर जाने वाले पैकेट वास्तव में वह पता ले जाएँ।
Dante की external सेटिंग क्या करती है
external सेटिंग उन पतों को चुनती है जिन्हें प्रॉक्सी बाहर जाने वाले कनेक्शनों के लिए उपयोग करता है; यह कर्नेल की राउटिंग नीति को नहीं छूती। यही अलगाव दूसरे डिज़ाइन को संभव बनाता है, और यहीं लोग दस्तावेज़ को गलत पढ़ते हैं। external को टनल पते पर इंगित करने से प्रॉक्सी अपने कनेक्शन उस पते से उत्पन्न करता है, और फिर राउटिंग तालिका तय करती है कि वे पैकेट कहाँ जाएँ।
श्रोता एक अलग मामला है। internal को केवल उन क्लाइंट तक सीमित रखें जिन्हें प्रॉक्सी उपयोग करना चाहिए, प्रमाणीकरण अनिवार्य करें और पोर्ट को फ़ायरवॉल से बंद करें, क्योंकि खुला श्रोता VPN निकास की विशेषता नहीं है।
पुष्टि करें कि कॉन्फ़िगर किया गया पता वास्तव में प्रॉक्सी के नेटवर्क नामस्थान के भीतर टनल का है।
स्रोत-चयनित तालिका बनाना
10.90.0.2/24 के TUN पते, 10.90.0.1 पर पहुँचने योग्य पीयर, और ऐसी तालिका संख्या जिसका और कुछ उपयोग नहीं करता, के लिए व्यवस्था ऐसी दिखती है:
ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100अपहुँच्य रूट वह हिस्सा है जिसे लोग छोड़ देते हैं। इसके बिना, जिस तालिका का टनल रूट गायब हो जाता है वह सामान्य डिफ़ॉल्ट पर गिर जाती है और प्रॉक्सी चुपचाप WAN से बाहर निकल जाता है। इसके साथ, लुकअप विफल होता है, जो चुपचाप रिसाव की बजाय दृश्य विफलता है। नियम की प्राथमिकता भी उस स्रोत से मेल खाने वाली हर चीज़ से पहले होनी चाहिए।
ये मान एक टोपोलॉजी का वर्णन करते हैं। पॉइंट-टू-पॉइंट पीयर, net30 एड्रेसिंग और अलग प्रीफ़िक्स देने वाले क्लाइंट सभी को अपने-अपने रूट चाहिए, इसलिए पते नहीं, आकार की नकल करें।
स्रोत नियम कहाँ रिसता है
स्रोत पते से मेल खाने वाला नियम उसका उपयोग करने वाली हर प्रक्रिया को प्रभावित करता है, केवल प्रॉक्सी को नहीं। यदि कोई दूसरा डेमॉन वही पता बाँधता है, तो उसका ट्रैफ़िक भी टनल लेता है, और विफलता किसी असंबंधित सेवा की समस्या जैसी दिखेगी। प्रॉक्सी को ऐसा पता दें जिसका और कोई उपयोग न करे, या स्वीकारें कि दायरा प्रक्रिया नहीं, पता है।
DNS दूसरा रिसाव है। रिज़ॉल्वर सॉकेट ज़रूरी नहीं कि प्रॉक्सी के external डेटा-कनेक्शन स्रोत का उपयोग करे, इसलिए नाम खोज अब भी WAN से बाहर जा सकती है। कनेक्शन स्थापित करने से अलग रिज़ॉल्यूशन जाँचें, और तय करें कि वह परिणाम स्वीकार्य है या नहीं।
IPv6 को अपने नियम और रूट चाहिए, क्योंकि IPv4 की व्यवस्था उसके बारे में कुछ सिद्ध नहीं करती।
जिस विफलता को आप सह सकें उसके अनुसार चुनें
जब होस्ट को समग्र रूप से सुरक्षित रखना हो और आप अपवर्जन सूची बनाए रख सकें तो पूर्ण टनल चुनें। जब होस्ट को अपना रास्ता बनाए रखना हो और केवल एक सेवा को पुनर्निर्देशित करना हो तो स्रोत-आधारित राउटिंग चुनें। दोनों वैध हैं; गलती यह है कि एक चुनकर उसे दूसरे की तरह जाँचा जाए।
जो भी चुनें, दोनों ओर से सत्यापित करें: प्रॉक्सी के माध्यम से एक अनुरोध और होस्ट से सीधा अनुरोध, प्रत्येक के लिए देखा गया निकास पता दर्ज करते हुए।
यदि टनल गिर जाए, तो पहले से तय करें कि प्रॉक्सी को विफल होना चाहिए या पीछे हटना चाहिए, और राउटिंग तालिका को वह निर्णय व्यक्त करने दें।