SSH फर्वार्डमार्फत VPN बाट मात्र उपलब्ध HTTPS साइटमा पुग्ने
VPN बाट मात्र उपलब्ध एक HTTPS सेवालाई स्थानीय SSH फर्वार्डसँग जोड्नुहोस्, --connect-to सँग वास्तविक होस्टनाम राख्नुहोस्, र एउटा TCP फर्वार्डले के समेट्न सक्दैन थाहा पाउनुहोस्।
एउटा मेसिनसँग पहिले नै स्वीकृत 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 इतिहासमा मात्र छ त्यो एउटा रिबुट टाढा दोहोरिएको अनुसन्धानमा पुग्छ, र अर्को व्यक्तिलाई तीन पूर्वशर्तमध्ये कुन पहिले नै जाँचिएको छ थाहा हुँदैन।