तुमच्या LAN शी ओव्हरलॅप होणारा VPN पूल कोणताही रूट दुरुस्त करत नाही

अॅप म्हणते टनेल निरोगी आहे, तरीही तुम्हाला आवश्यक असलेली अर्धी गंतव्ये कधीही उत्तर देत नाहीत। पहिली प्रतिक्रिया रूट जोडणे किंवा मेट्रिक कमी करणे ही असते, आणि तीच प्रतिक्रिया ही पहिल्यांदा मारायची असलेली मिथक आहे। जेव्हा क्लायंटचे स्वतःचे LAN आणि टनेलचा पूल एकाच प्रीफिक्सचा दावा करतात, तेव्हा राउटिंग तक्ता दोन विसंगत तथ्ये धरून ठेवतो, आणि डीफॉल्ट रूट किंवा मेट्रिक यापैकी काहीही ती सोडवत नाही। दुरुस्ती ही पत्ता नियोजनाची निर्णय असते, आणि रूट संपादन त्याला पर्याय ठरत नाही।

अतिरिक्त रूट एक प्रीफिक्स का विभागू शकत नाही

रूट एका प्रीफिक्सवरील दोन दावे वेगळे करू शकत नाही, म्हणून योग्य रूट ओळ शोधणे थांबवणे हे शहाणपणाचे पाऊल आहे। स्टॅक जोडलेल्या रूटच्या पुढे एकसारखा प्रीफिक्स ठेवत नाही, आणि अधिक विशिष्ट नोंद पत्ता पकडते, पण तो असलेला स्थानिक होस्ट अगम्य करते। राउटिंग समस्या वाटणारी गोष्ट पत्ता टक्कर आहे, आणि दोन्ही दुरुस्त्या रूट नाही, पत्ते बदलतात। स्वीकारण्यापूर्वी तुमच्या स्वतःच्या मशीनवर हा दावा तपासा।

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

सिस्टमला एका पत्त्याबद्दल विचारा आणि ते कोणते इंटरफेस सांगते ते पहा। Linux, macOS आणि Windows प्रत्येकजण केवळ-वाचन शोधाने उत्तर देतात, जो काहीही न पाठवता निवडलेले इंटरफेस आणि पुढील हॉप कळवतो। टनेल सुरू असताना उत्तर भौतिक अडॅप्टरकडे दाखवत असेल, तर कर्नल पत्त्याला टनेल वाहून नेऊ शकेल अशी गोष्ट न मानता लिंकवर असलेले मानतो।

प्रदात्याने दिलेला प्रीफिक्स घरचा राउटर सेवा देत असलेल्या प्रीफिक्सच्या शेजारी ठेवा आणि त्यांची स्ट्रिंग म्हणून तुलना करा। अचूक जुळणी हे स्पष्ट प्रकरण आहे, आणि घरचे सबनेट असलेला मोठा प्रदाता पूलही त्याच पद्धतीने अयशस्वी होतो, फक्त तो चुकवणे सोपे आहे। फक्त सारखे दिसणारे दोन प्रीफिक्स टक्कर नाहीत, म्हणून काहीही बदलण्यापूर्वी दोन्ही लिहून ठेवा।

क्लायंटला प्रत्यक्षात मिळालेला पूल वाचा

क्लायंटला काय मिळाले ते वाचा, प्रदात्याचे मार्केटिंग पान नाही। OpenVPN क्लायंटच्या लॉगचा तपशील वाढवा आणि सर्व्हर पुढे ढकलणारे रूट त्यात दिसतील, जे टनेल प्रीफिक्स उघड करतात; इतरत्र पूल कनेक्शन तपशीलांमध्ये किंवा अडॅप्टरवरच दिसतो। प्रदात्याकडे तो वापरत असलेल्या सर्व खाजगी श्रेणींची संपूर्ण यादी मागा, कारण आजचा एक /24 उद्या दोन होऊ शकतो। नेहमीच्या RFC 1918 ब्लॉक्स टाळणे म्हणजे तुम्हाला प्रत्यक्षात मिळालेली वाटणी टाळणे नव्हे।

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

पुन्हा क्रमांकन हीच तुम्ही करू शकता अशी दुरुस्ती

जर VPN सर्व्हर बदलण्यासारखा तुमचा नसेल, घरचे LAN हलवणे ही एकमेव उपलब्ध दुरुस्ती आहे, आणि व्यावसायिक प्रदात्यासोबत हीच नेहमीची स्थिती आहे। प्रदात्याच्या पूलच्या बाहेर आणि नंतर लागू शकणाऱ्या श्रेणींच्या बाहेर श्रेणी निवडा, आणि टनेलमधून तुम्ही पोहोचता त्या प्रत्येक साइटविरुद्ध ती तपासा। थोडा व्यत्यय आणि विसरलेल्या उपकरणांची लांब शेपटी अपेक्षा करा: जुनाला पत्ता धरून असलेले उपकरण गेटवेची गरज लागेपर्यंत काम करत असल्यासारखे वाटते।

1. आधी यादी: राउटरचा स्वतःचा पत्ता, DHCP व्याप्ती, आरक्षणे, पोर्ट फॉरवर्डिंग आणि हाताने पत्ता टाइप केलेले कोणतेही उपकरण।
2. मग देखभाल विंडोमध्ये राउटरचा LAN प्रीफिक्स आणि DHCP व्याप्ती एकत्र बदला, आणि वायर्ड लीज वायरलेसच्या आधी नूतनीकरण करा।
3. त्यानंतर स्थिर पत्ते दुरुस्त करा: प्रिंटर, नेटवर्क स्टोरेज, कठोरपणे लिहिलेला गेटवे असलेले सर्व।
4. शेवटी, VPN क्लायंट पुन्हा जोडा आणि टनेलचा पत्ता यापुढे LAN शी टकरात नाही याची खात्री करा।

पत्ते एकत्र नाही, त्याच क्रमाने हाताळा, आणि जुनी श्रेणी काही काळ दस्तऐवजीत ठेवा जेणेकरून जुने उपकरण रहस्यमय नाही तर ओळखता येईल। कधीही नूतनीकरण न करणारे उपकरण गेटवेपर्यंत न पोहोचता स्वतःची जाहिरात करते, आणि हा सपोर्ट कॉलपेक्षा खूप चांगला सुगावा आहे। राउटर एका दिवसापेक्षा जास्त लीज देत असेल, तर विंडोच्या कालावधीसाठी त्या लहान करा।

उपनाम काय करू शकते आणि काय करू शकत नाही

सर्व्हर तुमचा असेल, तर क्लायंटवर पत्त्यांचे भाषांतर दूरचा प्रीफिक्स रिकाम्या स्थानिक श्रेणीत उघड करू शकते, त्यामुळे तोच होस्ट दुसऱ्या पत्त्यावर उत्तर देतो। समुदाय OpenVPN हे करते client-nat, आणि तो निर्देश केवळ त्या क्लायंटसाठी आहे, ज्या व्यावसायिक आणि मोबाइल क्लायंटशी लोक सहसा तुलना करतात त्यात तो नाही। या रचनेला भाषांतराशी जुळणारा रूट, उपनामासाठी रिकामी श्रेणी आणि क्लायंटच्या अनुवादित न झालेल्या पत्त्याला उत्तर देण्यास तयार सर्व्हर लागतो। क्लायंट तुम्ही संरचीत करू न शकणाऱ्या व्यवस्थापित प्रदात्याचा असेल तर यातील काहीही उपयोगी पडत नाही।

बदल लागू झाल्यावर प्रथम पत्त्याने आणि नंतर नावाने स्थानिक होस्ट आणि दूरच्या होस्टपर्यंत पोहोचा, आणि सिस्टम प्रत्येक वेळी कोणता रूट निवडते ते नोंदवा। नाव अजूनही जुन्या श्रेणीत सुटू शकते, म्हणून पत्ते आणि नावे स्वतंत्र तपासणीस पात्र आहेत। बदलाच्या काळात काही सुरू राहिले असेल तर एक क्लायंट आणि सर्व्हर बाजूचे एक उपकरण पुन्हा सुरू करा, कारण कॅशे केलेल्या शेजारी नोंदी संपादनापेक्षा जास्त जगतात।

तुम्ही ठरवलेले प्रीफिक्स लोक प्रत्यक्षात पाहतात तिथे लिहा: नेटवर्क नोट्स, राउटरचे स्वतःचे टिप्पणी क्षेत्र, स्वागत पान। कोणीतरी पुन्हा 192.168.1.0/24 निवडेल, आणि टक्कर त्याच्यासोबत परत येईल।