एक Mac स्क्रीन के लिए स्थानीय SSH फ़ॉरवर्ड या पूरा VPN?

आपको अपनी मशीन से एक Mac की स्क्रीन देखनी है, Mac ऐसे होस्ट के पीछे है जिसमें आप पहले से SSH कर सकते हैं, और सवाल यह है कि क्या यह VPN के लायक है। आमतौर पर नहीं। एक स्थानीय फ़ॉरवर्ड आपके पास पहले से मौजूद SSH सत्र के ज़रिए एक TCP पोर्ट ले जाता है, और एक ही होस्ट पर एक स्क्रीन के लिए यह पूरे नेटवर्क को रूट करने से छोटी और अधिक जाँचने योग्य व्यवस्था है।

तीन शर्तें इसे तय करती हैं, और इनमें से कोई भी आपको प्रबंधित VPN की ओर धकेल सकती है।

तीन शर्तें इसे तय करती हैं

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

अगर जवाब «एक», «हाँ» और «मैं, फ़िलहाल» हैं, तो फ़ॉरवर्ड सही औज़ार है। अगर कोई भी जवाब बदलता है, तो समर्थित दूरस्थ पहुँच डिज़ाइन एक साल में बिना दस्तावेज़ वाली सुरंग के बाद आने वाली घटना-समीक्षा से सस्ता पड़ता है।

एक पोर्ट फ़ॉरवर्ड करें, नेटवर्क नहीं

स्थानीय फ़ॉरवर्ड आपकी मशीन पर एक श्रोता खोलता है और हर कनेक्शन को SSH सर्वर के ज़रिए ऐसे गंतव्य तक भेजता है जहाँ वह सर्वर पहुँच सके। ऐसे Mac के लिए जिसकी स्क्रीन-शेयरिंग सेवा TCP 5900 पर सुनती है, और ऐसे बैस्टियन के लिए जो mac.corp.example हल कर सके, आदेश छोटा और जानबूझकर संकीर्ण है। इसमें हर विकल्प व्यवस्था को छोटा रखने के लिए है: कोई शेल नहीं, सभी इंटरफ़ेस पर श्रोता नहीं, कोई डेमॉन नहीं। इसे नुस्खे की तरह नहीं, दायरे के बयान की तरह पढ़ें।

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]

श्रोता को 127.0.0.1 से बाँधना उसे हर दूसरे इंटरफ़ेस से दूर रखता है। यह औपचारिकता नहीं है: सभी इंटरफ़ेस से बँधा फ़ॉरवर्ड आपके लैपटॉप को उसी कैफ़े Wi-Fi पर किसी के भी लिए कॉर्पोरेट नेटवर्क में खुला रिले बना देता है। अगर पोर्ट पहले से उपयोग में है, तो दूसरा ऊँचा पोर्ट चुनें और व्यूअर अपडेट करें; उदाहरण फ़िट करने के लिए किसी असंबंधित सेवा को न रोकें।

बैस्टियन पर खाते को भी उस गंतव्य तक फ़ॉरवर्ड करने की अनुमति चाहिए। कुछ सख़्त SSH कॉन्फ़िगरेशन पोर्ट फ़ॉरवर्डिंग को पूरी तरह बंद कर देते हैं, और कुछ इसे permit-listen या permit-open निर्देश से सीमित करते हैं। यह मानने से पहले कि अस्वीकृत चैनल का मतलब पासवर्ड ग़लत था, सर्वर नीति पढ़ें।

SSH क्या एन्क्रिप्ट करता है, और कहाँ रुकता है

SSH सत्र आपके Mac से बैस्टियन तक ट्रैफ़िक की रक्षा करता है, और फ़ॉरवर्ड उस सत्र के भीतर VNC प्रोटोकॉल को समझे बिना ले जाता है। जैसे ही कनेक्शन बैस्टियन छोड़कर लक्ष्य की ओर जाता है, वह अब आपके SSH सत्र के भीतर नहीं है। उस अंतिम छलांग पर जो भी सुरक्षा है, वह लक्ष्य प्रोटोकॉल और निजी नेटवर्क के अपने नियंत्रणों की है।

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

लक्ष्य पर प्रमाणीकरण फिर अलग बात है। SSH खाता macOS लॉगिन नहीं देता, और स्क्रीन-शेयरिंग सेवा अब भी अपने स्वयं के क्रेडेंशियल माँगती है और अब भी अपनी स्वयं की एक्सेस सूची लागू करती है। कनेक्शन स्वीकार करने वाला स्थानीय श्रोता इस बारे में कुछ सिद्ध नहीं करता कि दूरस्थ सेवा सत्र स्वीकार करेगी या नहीं।

कब पूरा VPN सही निर्णय है

VPN चुनें जब कार्य को एक से अधिक पोर्ट चाहिए: Apple Remote Desktop के प्रबंधन और रिपोर्टिंग फ़ंक्शन अतिरिक्त TCP और UDP ट्रैफ़िक का उपयोग करते हैं जो एक TCP फ़ॉरवर्ड नहीं ले जाएगा। फ़ॉरवर्ड पूरे उत्पाद का आंशिक कार्यान्वयन नहीं है; यह अलग, छोटा औज़ार है।

इसे तब चुनें जब कई प्रशासक बदलती जगहों से जुड़ते हैं, क्योंकि प्रबंधित प्रोफ़ाइल हर व्यक्ति को कमांड लाइन बनाए बिना रूट, क्रेडेंशियल और नीति वितरित करती है। इसे तब चुनें जब ऑडिट ट्रेल को दिखाना हो कि कौन किससे जुड़ा, क्योंकि प्रति-उपयोगकर्ता SSH सत्र और साझा स्थानीय फ़ॉरवर्ड बहुत अलग रिकॉर्ड छोड़ते हैं।

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

फ़ॉरवर्ड को ज़ोर से विफल होने दें

ExitOnForwardFailure=yes का उपयोग करें ताकि असफल बाइंड सत्र को रोक दे, बजाय ऐसा शेल छोड़ने के जो जुड़ा दिखता है और कुछ फ़ॉरवर्ड नहीं करता। होस्ट-की सत्यापन चालू रखें, और पासवर्ड से की या एजेंट को प्राथमिकता दें। फिर वह सटीक URL जाँचें जो व्यूअर उपयोग करेगा, क्योंकि काम करता SSH सत्र और काम करता स्क्रीन कनेक्शन दो अलग परिणाम हैं।

macOS पर मूल क्लाइंट के लिए, व्यूअर तक स्थानीय URL से पहुँचा जाता है: open "vnc://127.0.0.1:15900"। अगर विंडो खुलती है और दूरस्थ होस्ट प्रमाणीकरण अस्वीकार करता है, तो सुरंग ठीक है और समस्या लक्ष्य पर है। अगर विंडो कभी नहीं खुलती, तो समस्या श्रोता या पोर्ट में है।

काम पूरा होने पर सत्र रोकें, और पोर्ट, बैस्टियन, लक्ष्य और खाता नीति लिख लें। जिस फ़ॉरवर्ड को किसी ने दस्तावेज़ नहीं किया, छह महीने बाद उसे बैकडोर से अलग नहीं पहचाना जा सकता, और यही उसे छोटा, नामित और अस्थायी रखने का सबसे मज़बूत तर्क है।