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 हा योग्य आकार आहे। दोन्हीपैकी कोणीही आपल्या दूरस्थ एंडपॉइंटवरून पोहोचता येणारे सर्व देत नाही।