Windows पर WireGuard सर्वर के सार्वजनिक IP पर SSH विफल रहता है

जो सुरंगें तब उठती हैं जबकि सर्वर के सार्वजनिक पते पर 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 रूटिंग की नहीं बल्कि सर्वर-पक्ष या कुंजी की समस्या है। अगर भीतरी पता काम करता है और बाहरी नहीं, स्थानीय फ़ायरवॉल रुख ठीक वही कर रहा है जिसके लिए उसे बनाया गया था। प्रोफ़ाइल संपादित करने से पहले तीनों परिणाम इसी क्रम में पढ़ें।

प्रबंधन पथ, प्रयुक्त पता और सुरंग बंद होने पर व्यवहार दर्ज करें। यही नोट अगले व्यक्ति को पाँच मिनट बचाने के लिए बायपास चौड़ा करने से रोकता है।