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 सही आकार है जब कई ऐप्स को वही नेटवर्क पथ चाहिए। इनमें से कोई भी अपने दूरस्थ एंडपॉइंट से पहुँच योग्य सब कुछ नहीं देता।