दोन्ही टोकांना एकच सबनेट: दूरचे LAN मोकळ्या श्रेणीवर मॅप करा

घर आणि कार्यालय दोन्ही 192.168.1.0/24 वापरतात, त्यामुळे 192.168.1.1 वरच्या विनंतीला दोन संभाव्य उत्तरे असतात आणि क्लायंट न विचारता एक निवडतो। चालू कार्यालयीन नेटवर्कचे पुनर्क्रमांकन क्वचितच लोकप्रिय असते, आणि राउटरचे पत्ते अनेकदा प्रिंटर, कॅमेरे आणि कागदपत्रांमध्ये रुजलेले असतात। क्लायंट-साइड पत्ता मॅपिंग त्याऐवजी दूरचे नेटवर्क मोकळ्या श्रेणीखाली सादर करू शकते, आणि होस्ट भाग तसाच राहू शकतो जेणेकरून 192.168.1.20 10.203.41.20 म्हणून दिसते। अडचण अशी आहे की फक्त काही क्लायंट ते अंमलात आणतात, आणि ते परतीच्या मार्गासाठी काहीही करत नाही।

एकाच होस्टची दोन दृश्ये

मॅपिंग होस्ट भाग ठेवते आणि फक्त नेटवर्क भाग बदलते। मग तेच यंत्र तुम्ही कुठे उभे आहात त्यानुसार दोन पत्त्यांवर उत्तर देते। काहीही कॉन्फिगर करण्यापूर्वी दोन्ही स्तंभ लिहून ठेवल्यास नंतर लॉग आणि फायरवॉल नियम चुकीचे वाचणे टळते।

घरातील स्थानिक उपकरणे त्यांचे स्वतःचे 192.168.1.x पत्ते ठेवतात, आणि हाच या सरावाचा उद्देश आहे। शेजारच्या खोलीतील प्रिंटर पोहोचण्यायोग्य राहतो तर कार्यालय अशा श्रेणीखाली दिसते जी टकरत नाही।

आर्ग्युमेंट्सचा क्रम हीच संपूर्ण युक्ती

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

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

नवीन श्रेणीसाठी क्लायंटची पॅकेट टनेलमध्ये पाठवणारा मार्ग हा रूट आहे; भाषांतर वाटेत गंतव्य पुन्हा लिहिते। 192.168.1.20 वरून येणारे उत्तर 10.203.41.20 वर परत लिहिले जाते जेणेकरून क्लायंटवरील सॉकेट सुसंगत राहते। एकच होस्ट पूर्ण लांबीच्या मास्कसह त्याच प्रकारे काम करतो, जोपर्यंत रूट आणि मॅपिंग एकच पत्ता वर्णन करतात।

हे पत्ता मॅपिंग आहे, पोर्ट मॅपिंग नाही। एका होस्टवरील दोन सेवा याने वेगळ्या करता येत नाहीत, आणि जो प्रोटोकॉल आपल्या पेलोडमध्ये IP पत्ते अंतर्भूत करतो तो तरीही खरे पाहील।

मॅपिंग परतीचा मार्ग तयार करत नाही

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

सर्व्हर-साइड नियमांनी भाषांतरानंतर सर्व्हरवर असलेल्या पत्त्यांचे वर्णन करावे, क्लायंटला दिसणाऱ्या श्रेणीचे नाही। उपनाव परवानगी नियमात कॉपी करणे दुपारचे नुकसान करते, कारण त्या बाजूचे कोणतेही पॅकेट ते वाहत नाही।

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

नावे आणि पेलोड भाषांतरातून टिकून राहतात

खऱ्या 192.168.1.20 वर रिझॉल्व्ह होणारे होस्टनेम ब्राउझरला दूरच्याऐवजी स्थानिक उपकरणाकडे पाठवते, राउटिंग तक्ता काहीही सांगो। खाजगी DNS चे उत्तर क्लायंटला दिसणाऱ्या श्रेणीकडे निर्देश करावे लागते, तर TLS प्रमाणपत्र अजूनही अनुप्रयोग अपेक्षित नाव घेऊन जाते। पत्त्याऐवजी नावाने चाचणी करा, कारण पत्ता काम करू शकतो तर नाव शांतपणे चुकीच्या दिशेने रिझॉल्व्ह होते। दूरचा गेटवे त्या झोनचीही सेवा देत असेल तर त्याच्या स्वतःच्या रेकॉर्डलाही क्लायंटला दिसणारी श्रेणी लागते।

रीडायरेक्ट, एम्बेडेड URL आणि आपला पत्ता पेलोडमध्ये देणाऱ्या अनुप्रयोगांची कोणत्याही पॅकेट मॅपिंगने दुरुस्त करता येणार नाही अशा प्रकारे तडफड होऊ शकते। त्यांना अनुप्रयोगाची समस्या माना आणि पुनर्क्रमांकन अनावश्यक आहे असे आश्वासन देण्यापूर्वी प्रयत्न त्यानुसार मोजा।

वचनबद्ध होण्यापूर्वी तीन तपासण्या

प्रथम, क्लायंटची अंमलबजावणी निश्चित करा। Community OpenVPN हा पर्याय समर्थित करते; OpenVPN 3 कोडबेस त्याला असमर्थित वैशिष्ट्यांमध्ये सूचीबद्ध करतो, त्यामुळे Connect शैलीच्या क्लायंटकडे ढकललेली प्रोफाइल त्याकडे दुर्लक्ष करू शकते। स्वीकारला जातो पण कधीही लागू होत नाही असा निर्देश त्रुटीपेक्षा वाईट असतो, कारण टनेल निरोगी दिसतो।

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

क्लायंट भाषांतर करू शकत नसल्यास गेटवे बाजूकडून मदत मागा किंवा पुनर्क्रमांकन स्वीकारा। एकाच पत्त्यासाठी अधिक रूट जोडणे हे रचना नाही।