तपाईंको VPN सुरुङ ठेगानाले इनबाउन्ड पोर्ट किन खोल्दैन
सुरुङ ठेगानाले तपाईंको क्लाइन्टलाई त्यहाँ मार्गनिर्देशन गर्न सक्ने सहकर्मीहरूसामु पहिचान गर्छ, र कहिल्यै श्रोता बनाउँदैन। बाइन्ड, फिर्ती मार्ग र त्यसपछि नीति जाँच्नुहोस्।
कार्यालयको VPN मा जोडिनुहोस्, पोर्ट 8443 मा सानो सेवा सुरु गर्नुहोस्, सुरुङ ठेगाना सहकर्मीलाई पठाउनुहोस् र क्लाइन्टले अझै जोडिएको जनाइरहँदा जडान असफल हुने देख्नुहोस्। सुरुङमा केही बिग्रिएको छैन: ठेगाना दिइएको छ, सत्र सक्रिय छ, र उत्तर बोक्ने प्याकेटहरू कहिल्यै स्वीकार गरिँदैनन्। तलका तीन जाँच क्रममा गर्नुहोस् र जुन असफल हुन्छ त्यहीँ रोकिनुहोस्, किनकि प्रत्येकको उपाय फरक छ र तीमध्ये एउटा मात्र VPN सँग सम्बन्धित छ।
सकेट वास्तवमा कहाँ बाइन्ड भएको छ त्यसबाट सुरु गर्नुहोस्
केही मार्गनिर्देशन हुनुअघि, कल गर्नेले पुग्न सक्ने ठेगानामा केही सुनिरहेको हुनुपर्छ। विकास सर्भरहरू सामान्य दोषी हुन्, किनकि तीमध्ये धेरै पूर्वनिर्धारित रूपमा loopback मा बाइन्ड हुन्छन् र एउटै मेसिनबाट आउने जडान मात्र स्वीकार गर्छन्। सुरुङ ठेगानाले त्यो बाइन्डिङ बदल्दैन, र अपरेटिङ सिस्टमले VPN संलग्न हुनुभन्दा धेरै अघि जडान अस्वीकार गर्नेछ।
ss -ltnp | grep 8443
netstat -ano | findstr 8443स्थिति होइन, स्थानीय ठेगाना स्तम्भ पढ्नुहोस्। 127.0.0.1:8443 भन्नाले loopback मात्र, र उपाय 0.0.0.0 वा सुरुङ ठेगानामै बाइन्ड गर्नु हो। 0.0.0.0:8443 सबै इन्टरफेसमा स्वीकार गर्छ, जुन मेसिनमा सार्वजनिक ठेगाना पनि हुँदा धेरैले सोचेभन्दा फराकिलो हुन्छ; 10.64.7.15:8443 सहकर्मी पुग्न सक्ने ठाउँमा मात्र सुन्ने साँघुरो संस्करण हो। त्यही आउटपुटमा प्रक्रियाको नाम पनि हेर्नुहोस्, किनकि अघिल्लो परीक्षणबाट बाँकी रहेको अनाथ इन्स्ट्यान्स पोर्ट खुला देखिने र गलत सामग्रीसँग जवाफ दिने सामान्य कारण हो।
त्यसपछि त्यो ठेगानामा केही मार्गनिर्देशन गर्न सक्छ कि भनी सोध्नुहोस्
सुरुङ ठेगानाको अर्थ त्यो प्रिफिक्स सुरुङमा पठाउन कन्फिगर गरिएका सहकर्मीहरूका लागि मात्र हुन्छ। सहकर्मीको मेसिनको आफ्नै तालिका छ, र सुरुङ सबनेटको लागि मार्ग नभए प्याकेट पूर्वनिर्धारित गेटवेतिर जान्छ र ठेगाना अवस्थित छ भन्ने थाहा नभएको ठाउँमा मर्छ। यो कल गर्नेको पक्षको मार्गनिर्देशन प्रश्न हो, तपाईंको पक्षको अनुमति होइन।
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
दुई क्लाइन्टबीचको सर्भर पनि उत्तिकै महत्त्वपूर्ण छ। सामान्य टाढा पहुँच डिजाइनमा प्रत्येक क्लाइन्टले गेटवेतिर बाहिर जाने जडान खोल्छ र गेटवेले ती प्रवाहको स्थिति राख्छ, त्यसैले उत्तरहरू उसले पहिले नै चिनेको बाटोबाट फर्कन्छन्। एउटा क्लाइन्टबाट अर्कोमा जाने जडान गेटवेले स्वीकार गरी अगाडि पठाउनुपर्ने नयाँ प्रवाह हो, र धेरै तैनाथीहरूले क्लाइन्टहरूलाई एकअर्काबाट अलग राख्न यसलाई जानाजान बन्द राख्छन्। उपभोक्ता VPN सेवाहरू सामान्यतया पूर्वनिर्धारित रूपमा अलग राख्छन्; कर्पोरेट गेटवेहरू कहिलेकाहीँ समूह अनुसार अनुमति दिन्छन्।
होस्टमा केही बदल्नुअघि दिशा जाँच्नुहोस्। यदि सुरुङ ठेगानाले गेटवे आफैंबाट जवाफ दिन्छ तर सहकर्मीबाट दिँदैन भने फरक गेटवेको क्लाइन्ट-देखि-क्लाइन्ट सेटिङ हो, र स्थानीय फायरवालको कुनै पनि सम्पादनले त्यसको ठाउँ लिन सक्दैन।
अन्तमा, प्रवाहलाई अनुमति दिने नीति खोज्नुहोस्
मार्गनिर्देशित प्याकेट र जवाफ दिने सेवाबीच नीतिका तीन तह हुन्छन्: VPN सर्भरको अग्रेषण निर्णय, होस्ट फायरवाल, र इन्स्ट्यान्सअगाडि रहेको कुनै पनि क्लाउड सुरक्षा समूह। तीनै एकमत हुनुपर्छ, र ती फरक-फरक तरिकाले असफल हुन्छन्, त्यसैले माथिको तालिकाको लक्षण ब्राउजरको त्रुटि सन्देशभन्दा उपयोगी हुन्छ।
सफल बाइन्डपछि मानिसहरूले बिर्सने तह होस्ट फायरवाल हो, किनकि LAN इन्टरफेसमा पोर्टलाई अनुमति दिने नियमले सुरुङ इन्टरफेसमा स्वतः अनुमति दिँदैन। इन्टरफेस-सीमित नियमहरू सही डिजाइन हुन् र कार्यालयबाट चल्ने तर घरबाट नचल्ने सेवाको सामान्य कारण पनि हुन्। नियमको पोर्ट नम्बर होइन, त्यसको दायरा पढ्नुहोस्।
स्थिति-आधारित फिल्टरिङले उल्टो अवस्था व्याख्या गर्छ। तपाईंको ल्यापटपबाट बाहिर जाने जडानले स्थिति बनाउँछ, र त्यसका उत्तरहरू इनबाउन्ड नियमबिना स्वीकारिन्छन्। सहकर्मीको जडान पछाडि स्थिति नभएको पूर्ण नयाँ प्रवाह हो, त्यसैले यसलाई स्पष्ट अनुमति चाहिन्छ। यही असमानता नै तपाईंको आफ्नै मेसिनमा चल्ने ब्राउजर सत्रले सेवा बाहिरबाट पुग्न सकिन्छ कि भन्नेबारे केही नभन्नुको पूरा कारण हो।
एउटा जाँच असफल भएमा सुरुङ होइन, डिजाइन बदल्नुहोस्
यदि आवश्यकता सहकर्मीले तपाईंको स्थानीय सेवा खोल्नु हो भने, इमानदार उत्तर सामान्यतया इनबाउन्ड पहुँचका लागि बनाइएको संयन्त्र हो। उल्टो SSH सुरुङ सबैभन्दा सानो हो: तपाईंको मेसिन बाहिरतिर सहकर्मी पहिले नै पुग्न सक्ने होस्टमा जोडिन्छ, र श्रोता त्यही होस्टमा हुन्छ।
ssh -N -R 8443:127.0.0.1:8443 [email protected]रिलेलाई आफ्नो SSH सर्भर कन्फिगरेसनमा GatewayPorts clientspecified चाहिन्छ, नत्र अगाडि पठाइएको श्रोता रिलेमा loopback मा बाँधिन्छ र सहकर्मीले अघिको जस्तै अस्वीकार सामना गर्छ। दिउँसोभन्दा लामो समय टिक्ने जुनसुकै कुराका लागि स्वास्थ्य जाँच र प्रकाशित नामको प्रमाणपत्रसहितको लोड ब्यालेन्सर वा ingress राम्रो साधन हो, र दुई सञ्जालले साँच्चै कुरा गर्नुपर्दा दुवै सबनेटका लागि मार्ग भएको साइट-देखि-साइट सुरुङ सही उत्तर हो।
यी डिजाइनमध्ये प्रत्येकले एक्सपोजरलाई स्पष्ट बनाउँछ, र त्यही मुख्य कुरा हो। VPN ले प्याकेटलाई तपाईंले पहिले नै प्रयोग गर्न अधिकृत सञ्जालहरूबीच सार्छ; यसले सेवा प्रकाशित गर्दैन र ल्यापटपलाई इन्टरनेटतिर फर्केको होस्टमा बदल्दैन। तीन तहमध्ये कुन बदल्ने भन्ने निर्णय गर्नु काम हो, र सुरुङ तीमध्ये विरलै एक हुन्छ।