SSH फ़ॉरवर्ड के ज़रिए केवल VPN से उपलब्ध HTTPS साइट तक पहुँचना

एक मशीन के पास पहले से स्वीकृत VPN पहुँच है, दूसरी मशीन को ठीक एक निजी HTTPS सेवा चाहिए, और एक स्थानीय SSH फ़ॉरवर्ड दूसरी मशीन को टनल दिए बिना यह अंतर भर सकता है। फ़ॉरवर्ड पूरे नेटवर्क के बजाय एक TCP गंतव्य ले जाता है, और यही सीमा मुख्य बात है। नीचे दिए पाँच चरणों को क्रम से पूरा करें, क्योंकि हर एक अलग कारण से विफल होता है और बाद का चरण पहले की कमी नहीं सुधार सकता। यदि कोई पूर्वशर्त गायब है, तो यह रचना उसे हल नहीं करती और कमांड की कोई भी ट्यूनिंग मदद नहीं करेगी।

चरण एक: तीन पूर्वशर्तों की पुष्टि करें

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

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

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

चरण दो: loopback पोर्ट बाइंड करें और सत्र को जीवित रखें

क्लाइंट एप्लिकेशन चलाने वाली मशीन पर निजी सेवा के लिए स्थानीय फ़ॉरवर्ड खोलें। इसे स्पष्ट रूप से loopback से बाइंड करें ताकि यह स्थानीय नेटवर्क पर प्रकाशित न हो, और ऐसा ऊँचा पोर्ट चुनें जिसे कोई स्थानीय सेवा पहले से न रोक रही हो। काम करते समय सत्र चालू रखें, क्योंकि इसे बंद करने से श्रोता बंद हो जाता है। ExitOnForwardFailure अस्वीकृत बाइंड या अधिकृत पोर्ट को फ़ॉरवर्ड के बिना चलते रहने वाले सत्र के बजाय तत्काल निकास में बदल देता है, और यही विफलता का तरीका सबसे अधिक समय बर्बाद करता है।

निजी कनेक्शन जंप होस्ट से बनता है, इसलिए उस होस्ट का DNS, रूट, VPN नीति और सेवा पहुँच सभी को काम करना चाहिए। SSH सत्र वह पहुँच नहीं बनाता जो जंप होस्ट के पास नहीं है, और वह उस रूट को ठीक नहीं कर सकता जिसे VPN ने कभी नहीं भेजा। कमांड की चुप्पी पर भरोसा करने के बजाय श्रोता को वहाँ सत्यापित करें जहाँ वह वास्तव में है।

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

चरण तीन: सॉकेट स्थानीय होने पर HTTPS नाम रखें

https://127.0.0.1:9443/ पर ब्राउज़ करने से TLS सर्वर नाम और एप्लिकेशन प्राधिकार बदल जाता है। portal.lab.example के लिए जारी प्रमाणपत्र loopback पते के विरुद्ध मान्य नहीं होगा, और परिणामी त्रुटि फ़ॉरवर्डिंग शॉर्टकट के बजाय टूटे प्रमाणपत्र जैसी दिखती है। कमांड-लाइन परीक्षण के लिए असली URL रखें और केवल सॉकेट गंतव्य बदलें। --connect-to यही करता है, और curl मैनुअल नीचे प्रयुक्त चार-फ़ील्ड रूप का दस्तावेज़ीकरण करता है।

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

नाम URL में, TLS हैंडशेक में और Host हेडर में रहता है, जबकि TCP कनेक्शन स्थानीय श्रोता तक जाता है। नो-प्रॉक्सी विकल्प परीक्षण को इसी फ़ॉरवर्ड पर रखता है, कॉन्फ़िगर किए गए HTTP प्रॉक्सी को उसे रोकने देने के बजाय, और प्रमाणपत्र सत्यापन चालू रखना ही परिणाम को अर्थपूर्ण बनाता है।

चरण चार: जानें कि एक फ़ॉरवर्ड क्या कवर नहीं कर सकता

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

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

चरण पाँच: सफ़ाई करें और दर्ज करें

परीक्षण पूरा होने पर सत्र रोकें और पुष्टि करें कि श्रोता चला गया। यदि चुना गया पोर्ट पहले से अधिकृत था, तो संख्या मुक्त करने के लिए किसी असंबंधित स्थानीय सेवा को रोकने के बजाय दूसरा अप्रयुक्त loopback पोर्ट चुनें और URL, परीक्षण कमांड तथा नोट—सभी को साथ में अद्यतन करें। लैपटॉप पर फ़ॉरवर्ड खुला छोड़ना निदान को अनियंत्रित सेवा में बदल देता है।

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