दुवै छेउमा एउटै सबनेट: टाढाको LAN लाई खुला दायरामा म्याप गर्नुहोस्
ग्राहक-पक्षको ठेगाना म्यापिङले ओभरल्याप हुने टाढाको LAN खुला दायरामुनि प्रस्तुत गर्न सक्छ, तर केही ग्राहकले मात्र यसलाई लागू गर्छन् र फिर्ता मार्ग जसरी पनि हुनुपर्छ।
घर र अफिस दुवैले 192.168.1.0/24 चलाउँछन्, त्यसैले 192.168.1.1 मा गएको अनुरोधका दुई सम्भावित उत्तर हुन्छन् र ग्राहकले नसोधी एउटा छान्छ। चलिरहेको अफिस नेटवर्कलाई पुनःक्रमाङ्कन गर्नु विरलै लोकप्रिय हुन्छ, र राउटरका ठेगाना प्रायः प्रिन्टर, क्यामेरा र कागजातहरूमा गाडिएका हुन्छन्। ग्राहक-पक्षको ठेगाना म्यापिङले त्यसको सट्टा टाढाको नेटवर्कलाई खुला दायरामुनि प्रस्तुत गर्न सक्छ, र होस्ट भाग उही रहन सक्छ जसले गर्दा 192.168.1.20 लाई 10.203.41.20 देखिन्छ। पेच यो हो कि केही ग्राहकले मात्र यसलाई कार्यान्वयन गर्छन्, र यसले फिर्ता मार्गका लागि केही गर्दैन।
एउटै होस्टका दुई दृश्य
म्यापिङले होस्ट भाग राख्छ र नेटवर्क भाग मात्र बदल्छ। त्यसपछि त्यही मेसिनले तपाईं कहाँ उभिनुभएको छ भन्ने अनुसार दुई ठेगानामा जवाफ दिन्छ। केही कुरा कन्फिगर गर्नु अघि दुवै स्तम्भ लेख्नुले पछि लग र फायरवाल नियम गलत पढ्नबाट बचाउँछ।
| The application dials | The remote device is |
|---|---|
| 10.203.41.1 | 192.168.1.1 |
| 10.203.41.20 | 192.168.1.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 को सट्टा वास्तविक सेवा परीक्षण गर्नुहोस्। तेस्रो, स्थानीय राउटर र टाढाको स्रोत ग्राहकबाट छुट्याउन सकिने रहेको पुष्टि गर्नुहोस्, किनकि त्यही मूल लक्ष्य थियो।
ग्राहकले अनुवाद गर्न सक्दैन भने गेटवे पक्षसँग सहयोग माग्नुहोस् वा पुनःक्रमाङ्कन स्वीकार गर्नुहोस्। एउटै ठेगानाका लागि थप रुट जोड्नु कुनै डिजाइन होइन।