एका Mac स्क्रीनसाठी स्थानिक SSH फॉरवर्डिंग की पूर्ण VPN?

तुम्हाला तुमच्या स्वतःच्या मशीनवरून एका Mac ची स्क्रीन पाहायची आहे, Mac तुम्ही आधीच SSH करू शकता अशा होस्टच्या मागे आहे, आणि प्रश्न असा आहे की यास VPN लायक आहे का। सहसा नाही। एकच स्थानिक फॉरवर्डिंग तुमच्याकडे आधीच असलेल्या SSH सत्रातून एक TCP पोर्ट वाहून नेते, आणि एका होस्टवरील एका स्क्रीनसाठी संपूर्ण नेटवर्क राउट करण्यापेक्षा ही लहान व अधिक तपासण्यायोग्य व्यवस्था आहे।

तीन अटी हे ठरवतात, आणि त्यांपैकी कोणतीही एक तुम्हाला व्यवस्थापित VPN कडे ढकलू शकते।

तीन अटी हे ठरवतात

पहिली व्याप्ती आहे: एका होस्टवर एक सेवा, की अनेक होस्ट आणि अनेक पोर्ट। दुसरी अशी आहे की बास्टियन आणि लक्ष्य यांच्यातील प्रत्येक उडी आधीच विश्वासार्ह आहे का, कारण SSH फक्त जो भाग तो संपवतो त्याचेच संरक्षण करते। तिसरी अशी आहे की हे बांधल्यानंतर ही व्यवस्था कोणाला सांभाळावी लागेल, कारण हाताने बनवलेली बोगदा ती समजून घेणाऱ्या व्यक्तीपेक्षा जास्त काळ टिकते। सुरुवात करण्यापूर्वी त्या व्यक्तीचे नाव घ्या, आणि आदेश त्याला सापडेल अशा ठिकाणी लिहा। दस्तऐवज नसलेले फॉरवर्डिंग ही पुढे ढकललेल्या सुरुवातीच्या तारखेची भविष्यातील घटना आहे।

उत्तरे «एक», «होय» आणि «मी, सध्या» असतील तर फॉरवर्डिंग हे योग्य साधन आहे। कोणतेही उत्तर बदलल्यास, समर्थित दूरस्थ प्रवेश रचना वर्षभरात दस्तऐवज नसलेल्या बोगद्यानंतर येणाऱ्या घटना पुनरावलोकनापेक्षा स्वस्त पडते।

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

स्थानिक फॉरवर्डिंग तुमच्या मशीनवर श्रोता उघडते आणि प्रत्येक कनेक्शन SSH सर्व्हरमधून त्या सर्व्हरला पोहोचता येईल अशा गंतव्यस्थानाकडे पाठवते। स्क्रीन शेअरिंग सेवा TCP 5900 वर ऐकणाऱ्या Mac साठी आणि 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 सत्राच्या आत नसते। त्या शेवटच्या उडीवर जे संरक्षण असेल ते लक्ष्य प्रोटोकॉलचे आणि खाजगी नेटवर्कच्या स्वतःच्या नियंत्रणांचे असते।

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

लक्ष्यावरील प्रमाणीकरण पुन्हा वेगळी बाब आहे। SSH खाते macOS लॉगिन देत नाही, आणि स्क्रीन शेअरिंग सेवा अजूनही स्वतःची ओळखपत्रे मागते आणि अजूनही स्वतःची प्रवेश सूची लागू करते। कनेक्शन स्वीकारणारा स्थानिक श्रोता दूरस्थ सेवा सत्र स्वीकारेल का याबद्दल काहीही सिद्ध करत नाही।

पूर्ण VPN कधी योग्य निर्णय असतो

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

अनेक प्रशासक बदलत्या ठिकाणांवरून जोडले जातात तेव्हा ते निवडा, कारण व्यवस्थापित प्रोफाइल प्रत्येकाने आदेश ओळ शोधल्याशिवाय मार्ग, ओळखपत्रे आणि धोरण वितरित करते। ऑडिट नोंद कोण कोणाशी जोडले गेले हे दाखवायचे असेल तेव्हा ते निवडा, कारण प्रति-वापरकर्ता SSH सत्र आणि सामायिक स्थानिक फॉरवर्डिंग खूप वेगळ्या नोंदी सोडतात।

शेवटी, संस्थेच्या स्वतःच्या प्रवेशद्वाराशिवाय लॅपटॉपवरून लक्ष्य नेटवर्कला अजिबात पोहोचता येऊ नये असे वाटत असेल तेव्हा ते निवडा। वैयक्तिक फॉरवर्डिंग रचनेनुसारच ते प्रवेशद्वार टाळते, आणि म्हणूनच ते शेल इतिहासात नाही तर बदल नोंदीत येते।

फॉरवर्डिंग मोठ्याने अपयशी होऊ द्या

अपयशी बाइंडिंगने सत्र थांबावे, जोडलेले दिसणारे पण काहीही फॉरवर्ड न करणारे शेल सोडू नये म्हणून ExitOnForwardFailure=yes वापरा। होस्ट-की पडताळणी सुरू ठेवा, आणि पासवर्डपेक्षा की किंवा एजंटला प्राधान्य द्या। नंतर पाहणी वापरणारी नेमकी URL तपासा, कारण चालणारे SSH सत्र आणि चालणारे स्क्रीन कनेक्शन या दोन वेगळ्या निकाल आहेत।

macOS वरील मूळ क्लायंटसाठी, पाहणीपर्यंत स्थानिक URL ने पोहोचता येते: open "vnc://127.0.0.1:15900"। खिडकी उघडली आणि दूरस्थ होस्टने प्रमाणीकरण नाकारले तर बोगदा ठीक आहे आणि समस्या लक्ष्यावर आहे। खिडकी कधीच उघडली नाही तर समस्या श्रोता किंवा पोर्टमध्ये आहे।

काम झाल्यावर सत्र थांबवा, आणि पोर्ट, बास्टियन, लक्ष्य आणि खाते धोरण लिहून ठेवा। कोणीही दस्तऐवज न केलेले फॉरवर्डिंग सहा महिन्यांनंतर मागील दारापासून वेगळे करता येत नाही, आणि ते लहान, नामांकित आणि तात्पुरते ठेवण्याचा हा सर्वात मजबूत युक्तिवाद आहे।