SSH फॉरवर्ड, VPN किंवा RD Gateway: एका RDP डेस्कटॉपसाठी कोणता मार्ग?

तिन्ही पर्याय RDP वाहतात, त्यामुळे प्रोटोकॉल निर्णायक घटक नाही। खरा प्रश्न असा आहे की एका वापरकर्त्याला किती पोहोच मिळावी आणि ती देणारी गोष्ट कोण चालवते। फॉरवर्ड केलेला TCP पोर्ट, राउटेड खाजगी नेटवर्क आणि डेस्कटॉप गेटवे या प्रश्नाचे उत्तर तीन वेगवेगळ्या आकारांत देतात। आधी आकार निवडा आणि उत्पादन मागे येईल।

प्रश्न प्रोटोकॉल नाही, व्याप्ती आहे

वापरकर्त्याला प्रत्यक्षात कशाला स्पर्श करायचा आहे ते लिहा। उत्तर एक डेस्कटॉप असल्यास, सबनेट देणारी रचना खूप रुंद आहे। उत्तर डेस्कटॉप अधिक फाइल शेअर्स अधिक प्रशासन कन्सोल असल्यास, एक पोर्ट फॉरवर्ड करणारी रचना पुढील महिन्यात आणखी दोन फॉरवर्डसाठी परत येईल। गंतव्यांची यादी हीच गरज आहे; बाकी सर्व अंमलबजावणी आहे।

प्रवेश ओळख डेस्कटॉपवर साइन इन करणाऱ्या Windows खात्यापासून वेगळी ठेवा। खालील प्रत्येक रचनेत दोन्ही आहेत, आणि ती एकत्र करणे म्हणजे जंप होस्ट खात्याला कोणीही हेतू केला होता त्यापेक्षा जास्त अधिकार मिळण्याचा मार्ग।

एक फॉरवर्ड केलेली TCP सेवा

मंजूर SSH जंप होस्ट स्थानिक श्रोत्याला तो पोहोचू शकणाऱ्या RDP सेवेकडे फॉरवर्ड करू शकतो। तो श्रोता केवळ वापरकर्त्याच्या स्वतःच्या मशीनसाठी असेल तेव्हा त्याला loopback ला बांधा, हा स्थानिक फॉरवर्डचा नेहमीचा हेतू आहे। फॉरवर्ड एका व्यक्तीसाठी सोय आहे, संघासाठी सेवा नाही।

SSH लॉगिन फॉरवर्डिंग मार्गातील प्रवेशाचे प्रमाणीकरण करते, त्यापेक्षा जास्त काही नाही। Windows प्रमाणीकरण आणि RDP अधिकृतता अजूनही गंतव्यस्थानीच होतात, त्यामुळे वैध जंप खाते वैध डेस्कटॉप सत्र नाही। हे दोन स्वतंत्र दरवाजे आहेत आणि दोन्ही उघडावे लागतात।

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

राउटेड खाजगी वर्कस्पेस

VPN खाजगी DNS आणि एकत्र वापरल्या जाणाऱ्या अनेक सेवांमध्ये प्रवेश देते, आणि हेच त्याचे खरे मूल्य आहे। एक डेस्कटॉप पोर्ट लपवणे हा दुष्परिणाम आहे, तो बांधण्याचे कारण नाही। VPN अस्तित्वात का आहे असे कोणी विचारले तेव्हा हा फरक महत्त्वाचा ठरतो।

मार्ग आणि संसाधन परवानग्या इच्छित गंतव्यांपुरत्या मर्यादित करा। जोडलेला वापरकर्ता आपोआप संपूर्ण LAN ला पात्र नाही, आणि गंतव्याचा फायरवॉल अधिक Windows साइन-इन हक्क VPN बदलत नाही अशा स्वतंत्र सीमा राहतात।

ही व्यवस्था आधीच स्थापित व्यवस्थापित वर्कस्पेससाठी सोयीची आहे। खर्च असा की ऑनबोर्डिंग, उपकरणांच्या आवश्यकता, रिझॉल्व्हरचे वर्तन आणि कनेक्शन धोरण वापरकर्त्याच्या कार्य वातावरणाचा भाग होतात, आणि कोणीतरी त्यांचे मालक असले पाहिजे। VPN स्वस्त पर्याय आहे असे गृहीत धरण्यापूर्वी त्या खर्चाची गेटवेच्या परवान्याशी तुलना करा।

RDP-विशिष्ट गेटवे

Remote Desktop Gateway नेटवर्क सीमेऐवजी RDP-विशिष्ट सीमा देते। त्याचे कनेक्शन अधिकृतता धोरण कोण जोडू शकते हे ठरवते, आणि त्याचे संसाधन अधिकृतता धोरण त्या मार्गाने कोणत्या अंतर्गत संसाधनांपर्यंत पोहोचू शकतात हे ठरवते। दोन्ही धोरणे उत्पादनाचा भाग आहेत, पर्यायी अतिरिक्त नाहीत।

प्रमाणपत्रे, ओळख एकात्मता आणि आवश्यक वाहतूक एकत्र नियोजित करा। गेटवे अनामिक TCP रिले नाही, आणि ते तसे उपयोजित करणे त्याला न्याय्य ठरवणारी धोरणे वगळते। एका फॉरवर्ड केलेल्या पोर्टकडे नसलेल्या परवाना आणि कार्यान्वयन आवश्यकताही तो वाहतो। डिझाइन पुनरावलोकनापूर्वी त्यांचे बजेट ठेवा, नंतर नाही।

जिथे संघ आधीपासून केंद्रीय डेस्कटॉप प्रवेश चालवतो, तिथे तो अतिरिक्त खर्च आधीच दिला गेला आहे। जिथे एका व्यक्तीला एक मशीन हवी असते, तिथे लहान कामासाठी मोठी मशीन खरेदी करावी लागते।

तिन्हींना अजून काय हवे

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

धोरण मागेल तिथे प्रवेश बिंदूवर MFA लागू करा, आणि गंतव्याचे खाते नियंत्रण ठेवा। दोन्ही पूरक आहेत: पहिले कोण दारापर्यंत पोहोचू शकते, दुसरे कोण ते उघडू शकते हे ठरवते। यापैकी एकही सोडल्यास पूर्ण दिसणारी पण नसलेली रचना राहते।

कामाशी आणि तुमच्याकडे प्रत्यक्षात असलेल्या कार्यान्वयन मॉडेलशी जुळणारी सीमा निवडा। RDS भूमिकांचा आढावा सत्र होस्ट आणि इतर घटकांमधील गेटवेचे स्थान वर्णन करते, आणि त्याचा खर्च वाचनीय करणारा संदर्भ हाच आहे।