तपाईंको VPN माथि SOCKS प्रोक्सीका रूपमा SSH गतिशील फर्वार्डिङ
SOCKS मात्र बोल्ने एपसँग सामान्य VPN मा प्रोक्सी इन्डपोइन्ट हुँदैन। दुई हप, एउटा लूपब्याक श्रोता र SSH सर्भरले आफै गर्नुपर्ने एक नाम खोज।
SOCKS मात्र बोल्ने एपसँग सामान्य VPN मा बोल्न केही हुँदैन, किनकि टनेलले प्याकेट बोक्छ र एपलाई प्रोक्सी इन्डपोइन्ट चाहिन्छ। पहुँचको मालिकले अनुमति दिएपछि OpenSSH त्यो इन्डपोइन्ट दिन सक्छ, किनकि गतिशील फर्वार्डिङले एउटा SSH सत्रलाई स्थानीय प्रोक्सीमा बदल्छ। त्यसपछि दुई हप अलग राख्नुपर्छ: SSH होस्टसम्म पुग्ने टनेल र त्यो होस्टले त्यसपछि खोल्ने जडान। तिनलाई अलग गर्दा यो व्यवस्था किन काम गर्छ र यसले कहिल्यै के गर्दैन भन्ने दुवै स्पष्ट हुन्छ।
SSH श्रोता के बन्छ र के बन्दैन
गतिशील फर्वार्डिङले SSH क्लाइन्टलाई स्थानीय रूपमा सुन्न र जो जोडिन्छ त्यससँग SOCKS4 वा SOCKS5 बोल्न बाध्य गर्छ। हरेक अनुरोधले एउटा गन्तव्यको नाम लिन्छ र SSH सर्भरले अर्को जडान खोल्छ, त्यसैले गन्तव्यको खोज परको छेउमा हुन सक्छ। यो एप तहको TCP फर्वार्डिङ हो, सिङ्गो उपकरणका लागि VPN होइन। यसले कुनै UDP संगठन, कुनै ICMP, र प्रोक्सी सेटिङ पूर्ण रूपमा बेवास्ता गर्ने एपका लागि केही पनि बोक्दैन। SSH सर्भरदेखि एपसम्मको हप पनि तपाईंको टनेलभित्र हुँदैन, गन्तव्यले जानिएका नेटवर्कबाट मात्र ट्राफिक लिने बेला यो महत्त्वपूर्ण हुन्छ।
पूर्वसर्त वास्तविक छन्: SSH होस्टसम्मको मार्ग, अधिकृत खाता, प्रमाणित सर्भर होस्ट कुञ्जी र फर्वार्ड गर्ने अनुमति। यीमध्ये कुनै पनि प्रोक्सीले बनाउँदैन, र अन्तिम सामान्यतया पहिले नै हराउँछ। अरू केही डिबग गर्नुअघि चारै पुष्टि गर्नुहोस्, किनकि क्लाइन्टबाट असफलता उस्तै देखिन्छ, जुन हराए पनि।
यसलाई स्पष्ट पोर्टसँग लूपब्याकमा सुरु गर्नुहोस्
नचलेको स्थानीय पोर्ट छान्नुहोस् र ठेगाना छाड्नुको सट्टा यसलाई स्पष्ट रूपमा लूपब्याकमा बाँध्नुहोस्। तलका तीन विकल्पमध्ये हरेक एउटा कारणले छ।
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N टाढाको आदेश छोड्छ र -T स्युडो-टर्मिनल छोड्छ, त्यसैले सत्र फर्वार्ड गर्न मात्र हुन्छ। ExitOnForwardFailure श्रोता बनाउन नसकिएपछि क्लाइन्टलाई बाहिर निस्कन दिन्छ, तपाईंले मागेको फर्वार्डिङ बिना चल्नुको सट्टा। ControlPath=none सत्रलाई आफ्नै फर्वार्डिङ थप्न सक्ने विद्यमान मल्टिप्लेक्स जडानबाट बाहिर राख्छ। लूपब्याक श्रोतालाई LAN बाहिर राख्छ, तर साझा मेसिनमा यो अधिकारको सीमा होइन, किनकि अन्य स्थानीय प्रक्रियाले पनि यससम्म पुग्न सक्छन्। OpenSSH क्लाइन्ट सन्दर्भ यी सबै फ्ल्यागको दस्तावेजीकरण गर्छ, र लूपब्याक चेतावनी सुन्ने सकेट के हो भन्नेबाट आउँछ।
नामहरू प्रोक्सीबाट पठाउनुहोस्, यसको वरिपरिबाट होइन
SOCKS5 क्लाइन्टले गन्तव्य आफै हल गर्न सक्छ वा प्रोक्सीलाई त्यसो गर्न भन्न सक्छ, र यही छनोटले कुन रिजोल्भर जवाफ दिने निर्धारण गर्छ। socks5h सँग curl होस्टनाम प्रोक्सीबाट पठाउँछ, त्यसैले खोज SSH सर्भरमा हुन्छ। साधारण socks5 सँग ल्यापटपले पहिले हल गर्छ र जडान मात्र जान्छ, नाम आन्तरिक हुँदा यसले उद्देश्य चुपचाप बिगार्छ। तलको अनुरोधले नो-प्रोक्सी सूची पनि खाली गर्छ, त्यसैले वंशज NO_PROXY मानले यसलाई प्रोक्सीको वरिपरिबाट लैजान सक्दैन।
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthप्रमाणपत्र प्रमाणीकरण र एपको आफ्नै लगइन अझै लागू हुन्छ, किनकि प्रोक्सीले दुवैमध्ये कुनैलाई बदल्दैन। दुई खोज बाँकी रहन्छ: ल्यापटपले अनुमत VPN र DNS मार्गबाट SSH होस्टसम्म पुग्नुपर्छ, र SSH सर्भरले एपको नाम आफै हल गर्नुपर्छ। दोस्रोलाई कुनै ट्राफिक प्रोक्सीबाट जानुअघि अलगै परीक्षण गर्न सकिन्छ।
ssh [email protected] getent hosts app.corp.exampleएउटा अनुमत गन्तव्य प्रमाणित गर्नुहोस्, त्यसपछि सत्र बन्द गर्नुहोस्
नीतिले अनुमति दिने गन्तव्य र यसले अस्वीकार गर्नुपर्ने गन्तव्य दुवै परीक्षण गर्नुहोस्, किनकि चल्ने फर्वार्डिङले श्रोता चल्छ भन्ने मात्र प्रमाणित गर्छ, त्यसभन्दा बढी केही होइन। एपले SSH सर्भरले छान्ने स्रोत ठेगाना देख्छ, र त्यो तपाईंको ल्यापटपको टनेल ठेगाना होइन। जहाँ परको छेउले जडानहरू स्रोतअनुसार लग गर्छ, त्यहाँ अनुरोध अस्वीकार हुँदा पहिले जाँच्नुपर्ने त्यही भिन्नता हो।
सत्रलाई यसको मालिक प्रक्रियाबाट रोक्नुहोस्, असम्बन्धित शेल मारेर होइन। त्यसपछि श्रोता गएको पुष्टि गर्नुहोस्, किनकि अझै जवाफ दिने पोर्ट भनेको तपाईंले साँच्चै बन्द नगरेको सत्र हो। यो अभ्यासले भित्र्याएको प्रोक्सी सेटिङ मात्र हटाउनुहोस्, र एप कन्फिगरेसनको बाँकी भाग जस्ताको तस्तै राख्नुहोस्। फर्वार्डिङ नियम बोकेको निगरानीविहीन टर्मिनल सेवा होइन, र स्थायी प्रोक्सीलाई स्वीकृत जीवनचक्र चाहिन्छ, बिर्सिएको विन्डो होइन।
ss -ltn | grep 1080यो व्यवस्थाले सुधार्न नसक्ने असफलता
केही लक्षणले माथिका सीमातिर सिधै संकेत गर्छन्, र तिनलाई चाँडै चिन्नुभयो भने प्रोक्सी डिबगिङको एक दिउँसो बच्छ। तालिकाले तपाईंले देख्ने कुरालाई यसको सामान्य अर्थसँग जोड्छ। अन्तिम स्तम्भमा जे पनि छ त्यो कन्फिगरेसन गल्ती होइन, डिजाइनको प्रश्न हो।
| What you see | What it usually means | Where to look |
|---|---|---|
| The app connects and nothing follows | It ignores proxy settings entirely | Its own network settings, not the SSH session |
| A name resolution error for the destination | The SSH server cannot resolve it | Server resolver and search domains |
| A UDP-only application fails | Dynamic forwarding carries TCP only | This arrangement cannot serve it |
| curl works, the browser does not | The browser is not using the socks5h endpoint | Browser proxy configuration |
| The listener answers after the session ended | Another process owns port 1080 | The ss output, then the owning process |
पहिलो तीन पङ्क्ति ती हुन् जसलाई मानिसले गलत निदान गर्छन्, किनकि हरेकले प्रोक्सीबारे त्रुटिको सट्टा जडान प्रयास उत्पन्न गर्छ। ल्यापटपमा हल हुने नामले सर्भरको रिजोल्भरबारे केही भन्दैन, र असफलता त्यसको सट्टा प्रमाणपत्र वा समयसीमा समस्या भनी पढिन्छ। UDP मात्र भएका एप डिजाइनभित्र बिग्रिएका होइनन्, बाहिर छन्, र कुनै अतिरिक्त ssh विकल्पले त्यो बदल्दैन। ब्राउजर पङ्क्ति प्रोक्सी सेटिङ हरेक एपका लागि छुट्टै हुन्छ भन्ने सामान्य सम्झना हो। अन्तिम पङ्क्ति बन्द गर्ने जाँच किन छ भन्ने बताउँछ: अझै सुन्दै गरेको पोर्ट भनेको अब अरू कुनैले यसको स्वामित्व लिएको हो।