sshuttle बनाम पूर्ण VPN: इसकी विधि वास्तव में क्या कवर करती है
sshuttle केवल वही ले जाता है जो उसकी अग्रेषण विधि समर्थित करती है: पहले TCP, DNS और UDP कवरेज, आवश्यक स्थानीय विशेषाधिकार और दूरस्थ सहायक जाँचें।
sshuttle इसलिए चुना जाता है कि SSH पहले से काम करता है और क्रिप्टोग्राफी परिचित लगती है, और यह तर्क उस एकमात्र प्रश्न को छोड़ देता है जो तय करता है कि यह उपयुक्त है या नहीं। कौन से पैकेट मशीन छोड़ते हैं, दूसरी ओर कौन-सा खाता उन्हें ले जाता है, और उपकरण कितना स्थानीय विशेषाधिकार माँगता है। ये तीन उत्तर अग्रेषण विधि के अनुसार बदलते हैं, इसलिए एक अनुप्रयोग के लिए काम करने वाला सेटअप अगले के लिए चुपचाप विफल हो सकता है। नीचे की समीक्षा उस प्रोटोकॉल से शुरू होती है जिसकी अनुप्रयोग को वास्तव में आवश्यकता है।
उस प्रोटोकॉल से शुरू करें जिसकी अनुप्रयोग को आवश्यकता है
sshuttle 2.0 में प्रोटोकॉल समर्थन उस विधि पर निर्भर करता है जिसे आप चुनते हैं। Linux की NAT और nft विधियाँ TCP और DNS संभालती हैं, और TPROXY सामान्य UDP जोड़ती है। हर प्लेटफ़ॉर्म और विधि की अपनी सीमाएँ हैं, और macOS पूरी तरह भिन्न तंत्र से अवरोधन करता है। कुछ भी चुनने से पहले स्थापित संस्करण, चुनी गई विधि और अनुप्रयोग को आवश्यक प्रोटोकॉल लिख लें।
इसलिए काम करने वाला TCP अनुरोध UDP अनुप्रयोग या हर DNS लुकअप के बारे में बहुत कम सिद्ध करता है। sshuttle TCP को पूरे IP पैकेट टनल करने के बजाय धाराओं के रूप में देखता है, इसलिए सामान्य VPN से लिया गया थ्रूपुट निष्कर्ष यहाँ लागू नहीं होता। आप जो तंत्र वास्तव में चलाते हैं उसकी तुलना उस भार से करें जो वास्तव में आपके पास है।
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
क्लाइंट को स्थानीय रूप से क्या चाहिए
प्रलेखित क्लाइंट व्यवस्था को root या sudo चाहिए, क्योंकि यह टनल इंटरफ़ेस बनाने के बजाय स्थानीय अवरोधन नियम स्थापित करती है। यह एक तथ्य सुरक्षा की कहानी बदल देता है: उस विशेषाधिकार वाली प्रक्रिया पूरी मशीन का ट्रैफ़िक मोड़ सकती है, केवल एक अनुप्रयोग का नहीं। विशेषाधिकार को डिज़ाइन का हिस्सा मानें, स्थापना का विवरण नहीं।
पुष्टि करें कि उपकरण ने कौन से नियम स्थापित किए और वे बाहर निकलते समय गायब हो जाते हैं। दुर्घटनाग्रस्त सत्र जो अवरोधन नियम छोड़ देता है, ऑपरेटर के कनेक्शन जाने का मानने के बहुत बाद तक ट्रैफ़िक को काले छिद्र में भेज सकता है, और लक्षण बचे हुए नियम जैसा नहीं, नेटवर्क विफलता जैसा दिखता है।
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeपहला आदेश सामान्य आह्वान का रूप है, उस उपसर्ग के साथ जो वास्तव में आपको चाहिए। दूसरा दिखाता है कि उपकरण ने क्या स्थापित किया, और तीसरा पुष्टि करता है कि कोई टनल इंटरफ़ेस नहीं आया, जो इस डिज़ाइन के लिए अपेक्षित परिणाम है।
दूरस्थ पक्ष क्या चलाता है
दूरस्थ पक्ष एक अधिकृत SSH खाता और एक संगत Python सहायक वातावरण है। प्रतिबंधित शेल के अंतर्गत सफल लॉगिन उस सहायक को चलाने की अनुमति स्वतः नहीं देता, और सहायक चला सकने वाला खाता स्वतः हर लक्ष्य सेवा तक नहीं पहुँचता। दोनों तथ्य समस्या-निवारण टिप्पणियों में नहीं, पहुँच अनुरोध में आते हैं।
होस्ट पहचान सत्यापन और खाते के प्रमाणीकरण की रक्षा करें। पहला कनेक्शन काम कराने के लिए अज्ञात होस्ट कुंजी स्वीकार करना यह जाँच हटा देता है कि दूरस्थ पक्ष वही मशीन है जिसका आपने इरादा किया था, और यहाँ यह एक-उद्देश्य अग्रेषण से अधिक मायने रखता है।
दूरस्थ खाते को उन सेवाओं तक सीमित करें जिनकी कार्यप्रवाह को आवश्यकता है, और वह दायरा होस्ट चलाने वालों के साथ तय करें। वे विश्वास संबंध का हिस्सा हैं, और क्लाइंट पक्ष की कोई सेटिंग इसे नहीं बदलती।
विश्वास सीमा कहाँ है
SSH के माध्यम से निजी API कनेक्शन अग्रेषित करना हर API क्रिया को अधिकृत नहीं करता। अनुप्रयोग का TLS और अनुप्रयोग में लॉगिन अभी भी लागू हैं, और उपकरण बिना प्रमाणीकरण वाली सेवा को सुरक्षित नहीं बना सकता। दूरस्थ होस्ट से अगली छलाँग भी स्वतः SSH चैनल जैसा वही संरक्षित खंड नहीं है, क्योंकि वह दूसरा कनेक्शन दूरस्थ होस्ट की जो भी नीति है उसी का पालन करता है।
सीमा को एक वाक्य में लिखें: इन उपसर्गों तक ट्रैफ़िक उस होस्ट पर इस खाते से बाहर जाता है। यदि वाक्य को अपवादों का एक अनुच्छेद चाहिए, तो डिज़ाइन अपने प्रलेखन के दावे से अधिक कर रहा है और उत्पादन तक पहुँचने से पहले दूसरी नज़र का हकदार है।
हर प्रोटोकॉल पर सिद्ध करें, फिर उपकरण चुनें
हर आवश्यक प्रोटोकॉल को हानिरहित अनुरोध से जाँचें, रिज़ॉल्वर पथ और अनुप्रयोग जो पता परिवार उपयोग करता है उन सहित। परीक्षण में डिस्कनेक्ट भी शामिल करें, ताकि अनुप्रयोग का अनुमत विफलता व्यवहार घटना के समय आश्चर्य नहीं बल्कि ज्ञात परिणाम बने। चालू रहते समय सही अग्रेषण करने वाला सत्र गिरने के बाद क्या होता है, इस पर कुछ नहीं कहता।
स्पष्ट रूप से नामित कुछ सेवाओं के लिए साधारण स्थानीय अग्रेषण का स्वामित्व और अंकेक्षण आसान है। जो अनुप्रयोग ट्रैफ़िक इसकी विधि से मेल खाता है, उसके लिए sshuttle वैध मध्य मार्ग देता है। जब आवश्यकता व्यापक IP कनेक्टिविटी हो, तो VPN डिज़ाइन ईमानदार उत्तर है, और चुनाव एन्क्रिप्शन एल्गोरिदम की रैंकिंग नहीं, कवरेज और परिचालन ज़िम्मेदारी का पालन करता है।