SSH फर्वार्डले वास्तवमा कुन एपको ट्राफिक बोक्छ?

टर्मिनल जोडिन्छ, प्रम्प्ट देखिन्छ, र सबै SSH पहुँच काम गर्छ भन्नेमा सहमत हुन्छन्। त्यसपछि ल्यापटपको डेटाबेस क्लाइन्ट अझै निजी होस्टसम्म पुग्न सक्दैन, र सत्रलाई दोष दिइन्छ। बनाइएको कुरा शेल थियो, र त्यो SSH ले दिन सक्ने चार पूर्ण रूपमा फरक इन्टरफेसमध्ये एक हो। पहिले इन्टरफेसको नाम भन्नुहोस्, त्यसपछि एपले साँच्चै त्यसको प्रयोग गर्छ कि भनी जाँच्नुहोस्। क्रम महत्त्वपूर्ण छ, किनभने हरेक इन्टरफेस आफ्नै तरिकाले असफल हुन्छ।

केही तुलना गर्नुअघि इन्टरफेसको नाम भन्नुहोस्

OpenSSH क्लाइन्ट म्यानुअल ले भ्रमित गर्न सजिलो चार संयन्त्र छुट्याउँछ। शेल वा टाढाको आदेश SSH होस्टमा चल्छ। स्थानीय फर्वार्डले क्लाइन्टमा सुन्ने सकेट खोल्छ र अर्को जडान टाढाको पट्टिबाट गर्छ। टाढाको फर्वार्डले उल्टो गर्छ, सर्भरको पट्टि सुन्दै। गतिशील फर्वार्डिङले त्यसलाई कसरी प्रयोग गर्ने थाहा भएका प्रोग्रामहरूलाई SOCKS अन्तिम बिन्दु दिन्छ।

• शेल: प्रोग्राम टाढाको मेसिनमा चल्छ, स्थानीय रूपमा केही पनि सुन्दैन।
• स्थानीय फर्वार्ड: तपाईंको ल्यापटपमा पोर्ट छ, टाढाको होस्टले बाहिर जाने जडान गर्छ।
• टाढाको फर्वार्ड: टाढाको पट्टि पोर्ट छ, ट्राफिक तपाईंतिर फर्कन्छ।
• गतिशील: क्लाइन्टमा SOCKS प्रोक्सी, प्रोक्सी बुझ्ने एपहरूले मात्र प्रयोग गर्छन्।

यीमध्ये कुनैले पनि मार्ग स्थापना गर्दैन। प्रोक्सी सेटिङ बेवास्ता गर्ने, वा UDP बोल्ने, वा नामहरू आफैँ समाधान गर्ने प्रोग्राम, सक्रिय SSH सत्रबाट प्रभावित हुँदैन। यो SSH मा दोष होइन; यो तपाईंले छानेको इन्टरफेसको दायरा हो।

स्थानीय, टाढाको र गतिशील फर्वार्ड को सुन्छ भन्नेमा फरक पर्छन्

अधिकांश अवस्था निर्धारण गर्ने भिन्नता भनेको सुन्ने सकेट कसको हो भन्ने हो। स्थानीय फर्वार्डमा क्लाइन्ट सुन्छ र टाढाको छेउले गन्तव्य डायल गर्छ, त्यसैले गन्तव्य ठेगाना सर्भरको दृष्टिकोणबाट समाधान हुन्छ। टाढाको फर्वार्डमा सर्भर सुन्छ र जडान तपाईंको पट्टि फर्काइन्छ, र यसरी तपाईंले स्थानीय सेवा सिधै प्रकाशित नगरी खोल्नुहुन्छ।

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

पहिलो आदेशले ल्यापटपमा पोर्ट 5432 बाँध्छ र बास्टियनबाट देखिने रूपमा डेटाबेसतिर फर्वार्ड गर्छ। दोस्रोले पोर्ट 1080 मा SOCKS प्रोक्सी बनाउँछ। तेस्रो आदेशले कुन प्रक्रियाहरू साँच्चै सुनिरहेका छन् भनी पुष्टि गर्छ, र पोर्ट द्वन्द्वका कारण चुपचाप असफल भएको होइन, फर्वार्ड अवस्थित छ भन्ने त्यही एक मात्र प्रमाण हो।

गतिशील फर्वार्डिङ आफ्नै चेतावनीको योग्य छ: यसले SOCKS को आदर गर्ने एपहरूलाई मात्र समेट्छ। ब्राउजरलाई त्यतातिर देखाउन सकिन्छ, कमाण्ड-लाइन उपकरणलाई यसको प्रयोग गर्न भन्न सकिन्छ, तर आफ्नै जडान स्ट्याक भएको डेटाबेस ड्राइभरले सामान्यतया सक्दैन। मेसिनको हरेक प्रोग्रामले अब टनेल प्रयोग गर्छ भन्ने मान्यता यो सम्पूर्ण क्षेत्रको सबैभन्दा सामान्य गल्ती हो।

टनेल-यन्त्र मोड नै एक मात्र वास्तविक नेटवर्क अपवाद हो

OpenSSH ले -w टनेल-यन्त्र फर्वार्डिङ पनि समर्थन गर्छ, जसले TCP श्रोताको सट्टा पोइन्ट-टु-पोइन्ट इन्टरफेस पास गर्छ। त्यो साँचो नेटवर्क टनेल हो, र यो जानाजान कन्फिगर गरिन्छ, शेल खोल्ने साइड इफेक्ट होइन।

sudo ssh -w 0:0 [email protected]
ip addr show tun0

यसलाई दुवै छेउमा उपलब्ध सम्बन्धित इन्टरफेस नम्बर, सर्भरमा सही कन्फिगरेसन र यन्त्र बनाउन क्लाइन्टमा पर्याप्त विशेषाधिकार चाहिन्छ। यसलाई ठेगाना र राउटिङ योजना पनि चाहिन्छ, किनभने नाङ्गो इन्टरफेसले कुन गन्तव्यहरूले यसको प्रयोग गर्नुपर्छ भन्ने कुनै नीति बोक्दैन।

त्यसो भए पनि टनेल टाढाको होस्टमा अन्त्य हुन्छ। SSH यातायातले दिएको जुनसुकै सुरक्षा त्यहीँ अन्त्य हुन्छ, र अर्को जडान छुट्टै फड्को हो। VPN गेटवेको सीमाको पनि त्यही आकार हुन्छ, त्यसैले तुलना कुन उपकरण बलियो छ भन्नेमा होइन, दायरा र अन्त्यमा हुनुपर्छ। त्यो सीमालाई ठूलो स्वरले नाम दिनुले टनेल «सबै कुरा इन्क्रिप्ट गर्छ» भन्ने बहस पनि टुंग्याउँछ, किनभने यसले स्पष्ट रूपमा गर्दैन।

तपाईंको एपले तपाईंले बनाएको इन्टरफेस प्रयोग गर्छ कि भनी जाँच्नुहोस्

प्रमाणीकरण हरेक एपको लागि हो, सत्रको लागि होइन। काम गर्ने फर्वार्डले पोर्ट बाँधिएको छ र टाढाको छेउले डायल गर्न सक्छ भनी प्रमाणित गर्छ; तपाईंलाई महत्त्वपूर्ण प्रोग्राम त्यसबाट जोडियो भनी प्रमाणित गर्दैन।

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

पहिलो आदेशले होस्टनाम टाढाबाट समाधान गर्दै SOCKS अन्तिम बिन्दुबाट अनुरोध पठाउँछ, र दोस्रोले TLS अझै आवश्यक रहेको अवस्थामा फर्वार्ड गरिएको डेटाबेस पोर्ट प्रयोग गरेर हेर्छ। फर्वार्ड रोकेको अवस्थामा ती उही परीक्षणहरू चलाएर तिनीहरू असफल हुन्छन् भनी पुष्टि गर्नुहोस्, किनभने दुवै तरिकाले उत्तीर्ण हुने परीक्षणले कहिल्यै टनेल प्रयोग गरेको थिएन।

त्यसपछि राउटेड VPN सँग महत्त्वपूर्ण आयामहरूमा मात्र तुलना गर्नुहोस्: कुन गन्तव्यहरू समेटिएका छन्, कुन प्रोटोकलहरू चल्छन्, सुरक्षा कहाँ अन्त्य हुन्छ र पहुँच कसले स्वीकृत गर्नुपर्छ। एउटै सेवाको फर्वार्ड साँघुरो र राम्रो उत्तर हुन सक्छ, जबकि धेरै एपलाई एउटै नेटवर्क मार्ग चाहिँदा VPN सही आकार हो। दुवैले आफ्नो टाढाको अन्तिम बिन्दुबाट पुग्न सकिने सबै दिँदैनन्।