सर्भरको सार्वजनिक ठेगानामा SSH काम गर्न छोड्दा माथि उठ्ने सुरुङहरू सर्भरले जडान अस्वीकार गरेजस्तो देखिन्छ। Windows मा बढी सम्भावित कारण स्थानीय हो: पूरा सुरुङको AllowedIPs /0 हुँदा प्रतिबन्धात्मक फायरवाल नियमहरू सक्रिय हुन्छन्, जसले सुरुङको आफ्नै यातायात र धेरै थोरै अन्य कुरालाई अनुमति दिन्छ। त्यो ठेगानामा पुग्ने इन्क्रिप्ट गरिएका प्याकेटहरूले त्यही ठेगानामा छुट्टै TCP जडान बाहिर जान सक्छ कि भन्नेबारे केही भन्दैनन्।

पियर सूची छुनु अघि एन्डपोइन्टको सार्वजनिक ठेगानालाई यसको भित्री सुरुङ ठेगानाबाट अलग गर्नुहोस्। AllowedIPs सम्पादन गरेर यसलाई ठीक गर्ने लगभग हरेक प्रयासले मार्ग सही बनाउनुको सट्टा नीति कमजोर बनाउँछ।

रुटिङ अनुमति र फायरवाल अनुमति फरक हुन्

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

त्यसैले एन्डपोइन्टमा traceroute सफल हुन सक्छ जबकि SSH प्रयास असफल हुन्छ। पहिलोलाई अपवाद भएको सेवाले बोक्छ, दोस्रोलाई बोक्दैन।

Windows मा /0 ले के गर्छ

जब एउटै पियरको अनुमति दिइएका ठेगानाहरूले सम्पूर्ण IPv4 क्षेत्र ढाक्छन्, WireGuard for Windows ले प्रतिबन्धात्मक फायरवाल अवस्था लागू गर्छ जसले सुरुङबाहिर जाने ट्राफिक रोक्छ। सुरुङ सेवाको आफ्नै यातायातलाई अनुमति छ, किनकि अन्यथा VPN काम गर्न सक्दैनथ्यो। त्यही सार्वजनिक ठेगानामा जाने अर्को अनुप्रयोगले त्यस्तो अनुमति पाउँदैन, किनकि अपवाद यातायातको हो, ठेगानाको होइन। Windows नेटवर्किङ टिप्पणीहरू यो व्यवहार र सम्पादकमा रहेको सम्बन्धित नियन्त्रणको वर्णन गर्छन्।

ती नियमहरू kill switch भन्ने वाक्यांश पछाडिको संयन्त्र हुन्। तिनीहरू त्यो नामको चेकबक्सले होइन, कन्फिगरेसनको आकारले सक्रिय हुन्छन्।

अपवादहरूले सुरक्षा मोडेल बदल्छन्

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

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

तपाईंले छान्नुभएको व्यवस्थापन मार्ग परीक्षण गर्नुहोस्

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

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

भित्री ठेगानामा सफल SSH ले सुरुङले व्यवस्थापन ट्राफिक बोक्छ र सर्भरको आफ्नै फायरवालले यसलाई पियर दायराबाट स्वीकार गर्छ भन्ने प्रमाणित गर्छ। दुवै लक्ष्यमा असफलता Windows रुटिङको होइन, सर्भर-पक्ष वा कुञ्जीको समस्या हो। भित्री ठेगाना काम गर्छ र बाहिरी गर्दैन भने, स्थानीय फायरवाल अवस्था जे गर्न डिजाइन गरिएको थियो ठ्याक्कै त्यही गरिरहेको छ। प्रोफाइल सम्पादन गर्नु अघि तीनवटा नतिजा यही क्रममा पढ्नुहोस्।

व्यवस्थापन मार्ग, प्रयोग गरिएको ठेगाना र सुरुङ बन्द हुँदाको व्यवहार टिप्नुहोस्। पाँच मिनेट बचाउन बाइपास फराकिलो बनाउनबाट अर्को व्यक्तिलाई रोक्ने त्यही टिप्पणी हो।

सम्बन्धित लेखहरू