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 मार्गदर्शनाची नाही तर सर्व्हर-बाजू किंवा कीची समस्या आहे। आतील पत्ता काम करत असेल आणि बाहेरील नसेल, स्थानिक फायरवॉल भूमिका जे करण्यासाठी ती आखली गेली तेच करत आहे। प्रोफाइल संपादित करण्यापूर्वी तीन निकाल याच क्रमाने वाचा।

व्यवस्थापन मार्ग, वापरलेला पत्ता आणि सुरंग बंद असतानाचे वर्तन नोंदवा। पाच मिनिटे वाचवण्यासाठी बायपास रुंदावण्यापासून पुढच्या व्यक्तीला रोखणारी तीच नोंद आहे।