SSH चे स्थानिक फॉर्वर्ड TCP OpenVPN सत्र कसे वाहते

येथे तीन ट्रान्सपोर्ट थर साचतात, आणि प्रत्येकाचे स्वतःचे फ्रेमिंग आहे। VPN पेलोड TLS सत्राच्या आत जातो, ते TLS सत्र लूपबॅक पोर्टकडे TCP जोडणीच्या आत जाते, आणि त्या जोडणीचे बाइट SSH च्या आत रिले होस्टकडे जातात, जो VPN श्रोत्याकडे खरे TCP जोडणी उघडतो। या रचनेत काहीही बदलत नाही ते OpenVPN काय प्रमाणित करतो, आणि त्यातील काहीही UDP श्रोत्याला TCP द्वारे पोहोचण्यायोग्य करत नाही। उर्वरित बाइट मार्गाचे वर्णन म्हणून वाचा, नेटवर्क नियंत्रण टाळण्याची कृती म्हणून नाही।

स्थानिक फॉर्वर्ड प्रत्यक्षात काय हलवते

SSH क्लायंट स्थानिक पोर्टवर ऐकतो। स्थानिक प्रक्रिया जोडली गेल्यावर, क्लायंट बाइट आपल्या एन्क्रिप्टेड चॅनेलमध्ये पॅक करतो, आणि सर्व्हर बाजू फॉर्वर्ड विनंतीत नाव दिलेल्या गंतव्याकडे नवीन TCP जोडणी उघडते।

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

SSH सत्र सुरू करणे केवळ हे सिद्ध करते की रिले पोहोचण्यायोग्य आणि प्रमाणित आहे। पुढील श्रोता सुरू आहे का, रिले आणि श्रोता यांच्यातील फायरवॉल जोडणी स्वीकारतो का, किंवा VPN तुमची प्रोफाइल स्वीकारेल का, हे ते सांगत नाही।

क्लायंट स्थानिक श्रोत्याकडे वळवा

घोषित उदाहरण: रिले gw.internal.example:443 वर TCP श्रोत्यापर्यंत पोहोचू शकतो, आणि उंच स्थानिक पोर्ट तो मार्ग केवळ या मशीनला उघडतो।

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

OpenSSH मॅन्युअल स्थानिक फॉर्वर्डचे वर्णन स्थानिकपणे TCP जोडण्या स्वीकारणे आणि दूरच्या बाजूने पुढील जोडणी उघडणे असे करते। श्रोत्याला सर्व इंटरफेसऐवजी लूपबॅकला बांधा, कारण नेटवर्कवरून पोहोचण्यायोग्य फॉर्वर्ड हा तुमच्या नावाचा उघडा रिले आहे। वाइल्डकार्ड बाइंड सामायिक मशीनवरील इतर कोणत्याही स्थानिक खात्यालाही पोर्ट उघडते।

नंतर VPN क्लायंट TCP मोडमध्ये ठेवा आणि 127.0.0.1:24011 कडे वळवा। प्रोफाइल UDP वापरत असल्यास, ही रचना मदत करू शकत नाही: फॉर्वर्ड बाइट स्ट्रीम वाहते, आणि त्यातून डेटाग्रामचा मार्ग नाही।

दोन्ही प्रमाणीकरणे वेगळी ठेवा

SSH रिले होस्ट प्रमाणित करते। OpenVPN अजूनही VPN सहकारी प्रमाणित करते, आणि लूपबॅक गंतव्य ती अट बदलत नाही। सॉकेट आता localhost कडे दाखवते म्हणून प्रमाणपत्र तपासण्या बंद करणे ही या रचनेतील सर्वात वाईट शॉर्टकट आहे। ती ट्रान्सपोर्ट रचना विश्वासाच्या रचनेत बदलते, आणि दुसऱ्याला कोणीही संमती दिली नाही।

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

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

बोगद्याखाली लूप बांधू नका

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

नेहमीचा उपाय म्हणजे बोगदा वर येण्यापूर्वी भौतिक इंटरफेसला पिन केलेला रिले पत्त्याकडे होस्ट मार्ग, शिवाय पुन्हा जोडणीनंतर मार्ग टिकतो याची तपासणी। क्रम बरोबर होता असे गृहीत धरण्याऐवजी रिले पत्त्यासाठी मार्ग लुकअपने ते पडताळा।

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

काम झाल्यावर श्रोता बंद करा

बोगद्याची गरज नसल्यावर SSH सत्र थांबवा, आणि स्थानिक पोर्ट मोकळा झाला याची खात्री करा। विसरलेला फॉर्वर्ड सामायिक होऊ शकणाऱ्या मशीनवर प्रमाणित मार्ग उघडा ठेवतो।

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