SSH को स्थानीय फर्वार्डले TCP OpenVPN सत्र कसरी बोक्छ

यहाँ तीन ट्रान्सपोर्ट तह थुप्रिन्छन्, र प्रत्येकको आफ्नै फ्रेमिङ छ। VPN पेलोड TLS सत्रभित्र जान्छ, त्यो TLS सत्र लूपब्याक पोर्टतर्फ TCP जडानभित्र जान्छ, र त्यो जडानका बाइटहरू SSH भित्र रिले होस्टतर्फ जान्छन्, जसले VPN श्रोतातर्फ वास्तविक TCP जडान खोल्छ। यो व्यवस्थामा केही पनि बदल्दैन OpenVPN ले प्रमाणित गर्ने कुरा, र यसमा केही पनि UDP श्रोतालाई TCP मार्फत पुग्न सकिने बनाउँदैन। बाँकी कुरा बाइट मार्गको वर्णनका रूपमा पढ्नुहोस्, नेटवर्क नियन्त्रण छल्ने विधिका रूपमा होइन।

स्थानीय फर्वार्डले वास्तवमा के सार्छ

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

त्यो गन्तव्य रिलेले समाधान गर्छ, तपाईंको मेसिनले होइन, त्यसैले दूरको नेटवर्कभित्र मात्र रहेको नाम पनि अझै काम गर्छ। यसको अर्थ रिलेले VPN श्रोतासम्म पुग्न र त्यहाँ फर्कने मार्ग राख्नुपर्छ पनि हो। तपाईंको ल्यापटपमा समाधान हुने नामले रिलेले के देख्न सक्छ भन्नेबारे केही भन्दैन।

SSH सत्र सुरु गर्नुले रिले पुग्न सकिने र प्रमाणित छ भन्ने मात्र प्रमाणित गर्छ। अर्को श्रोता चालु छ कि छैन, रिले र श्रोताबीचको फायरवालले जडान स्वीकार्छ कि, वा VPN ले तपाईंको प्रोफाइल स्वीकार्छ कि भन्ने यसले भन्दैन।

क्लाइन्टलाई स्थानीय श्रोतातर्फ फर्काउनुहोस्

घोषित उदाहरण: रिले gw.internal.example:443 मा रहेको TCP श्रोतासम्म पुग्न सक्छ, र अग्लो स्थानीय पोर्टले त्यो मार्ग यही मेसिनलाई मात्र खोल्छ।

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

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

त्यसपछि VPN क्लाइन्टलाई TCP मोडमा राख्नुहोस् र 127.0.0.1:24011 तर्फ फर्काउनुहोस्। प्रोफाइलले UDP प्रयोग गर्छ भने, यो डिजाइनले सहयोग गर्न सक्दैन: फर्वार्डले बाइट स्ट्रिम बोक्छ, र त्यसबाट डेटाग्रामको मार्ग छैन।

दुई प्रमाणीकरण अलग राख्नुहोस्

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

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

रिलेलाई विश्वासको कथामा दोस्रो पक्ष मान्नुहोस्: यसको प्रशासकले जडान मेटाडेटा देख्न सक्छ र कन्फिगरेसन बदलिए फर्वार्ड घुमाउन सक्छ। यो व्यवस्थालाई रिले र VPN सेवाको मालिक दुवैको स्वीकृति चाहिन्छ, आज जसलाई आवश्यक छ त्यसको मात्र होइन।

सुरुङमुनि लूप नबनाउनुहोस्

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

सामान्य उपाय सुरुङ माथि आउनुअघि भौतिक इन्टरफेसमा पिन गरिएको रिले ठेगानातर्फको होस्ट मार्ग, साथै पुनः जडानपछि पनि मार्ग टिक्छ भन्ने जाँच हो। क्रम सही थियो भनी मान्नुको सट्टा रिले ठेगानाका लागि मार्ग खोजीबाट यसलाई प्रमाणित गर्नुहोस्।

यो थुप्रो सीधा जडानभन्दा ढिलो र नाजुक हुने अपेक्षा गर्नुहोस्, किनकि अब दुई क्रमबद्ध ट्रान्सपोर्ट र मर्मत गर्न अर्को अन्त्य बिन्दु छ। यो नेटवर्क सीमा तर्ने तरिका हो, कार्यसम्पादन प्रविधि होइन।

काम सकिएपछि श्रोता बन्द गर्नुहोस्

सुरुङको आवश्यकता नरहेपछि SSH सत्र रोक्नुहोस्, र स्थानीय पोर्ट खाली भएको पुष्टि गर्नुहोस्। बिर्सिएको फर्वार्डले साझा हुन सक्ने मेसिनमा प्रमाणित मार्ग खुला राख्छ।

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