घर और ऑफ़िस दोनों 192.168.1.x इस्तेमाल करते हैं: अब क्या करें?

चार जाँचें करें: नाम किस पते पर हल होता है, स्थानीय नेटवर्क कौन-सा प्रीफ़िक्स इस्तेमाल करता है, कर्नेल उस गंतव्य के लिए कौन-सा रूट चुनता है, और दूर के सिरे पर क्या जवाब देता है। VPN लॉगिन इनमें से एक नहीं है, क्योंकि यह इससे अलग कि कौन-सा नेटवर्क जीतता है, पूरा हो जाता है। जाँचें क्रम से करें और ओवरलैप चौथे चरण की बजाय दूसरे चरण में दिखने लगेगा।

सफल लॉगिन बताता है कि टनल चालू है; यह नहीं बताता कि कोई ख़ास पता कहाँ इंगित करता है।

एक पता, दो मशीनें

मेज़बान गंतव्य पते का उपयोग करके अपनी रूटिंग तालिका और नीति नियमों से एक रास्ता चुनता है। कोई चीज़ उसे नहीं बताती कि 192.168.1.20 हॉप पर अनुरोध बगल के कमरे के डिवाइस के लिए नहीं, बल्कि ऑफ़िस सर्वर के लिए है। जब दोनों नेटवर्क एक ही निजी रेंज में हों, तो सबसे विशिष्ट रूट जीतता है और बाक़ी सब इस पर निर्भर करता है कि रीकनेक्ट ने संयोग से कौन-सी एंट्री इंस्टॉल की। पते में ही ऐसा कुछ नहीं जो यह अंतर रखे।

ip route get 192.168.1.20

वह लुकअप कर्नेल द्वारा चुने गए इंटरफ़ेस और अगले हॉप का नाम बताता है, जो सूची में दूसरी जाँच है। कुछ और करने से पहले स्थानीय और दूर के प्रीफ़िक्स की तुलना करें। अगर स्थानीय LAN 192.168.1.0/24 है और दूर की साइट भी 192.168.1.0/24 है, तो ओवरलैप ही निष्कर्ष है, और कोई क्लाइंट विकल्प इसे ठीक नहीं करता।

जिस पक्ष को आप नियंत्रित करते हैं उसे फिर से नंबर दें

निजी राउटर आम तौर पर हटाने के लिए आसान पक्ष होता है। ऐसी रेंज चुनें जो उन दूर के नेटवर्क से टकराए नहीं जिन्हें आप वास्तव में इस्तेमाल करते हैं, और ध्यान दें कि 10.x.x.x भी अपने आप ख़ाली नहीं है, क्योंकि बहुत साइटें इसका उपयोग करती हैं। बदलाव की योजना बनाएँ: DHCP लीज़, आरक्षित पते, प्रिंटर कतारें और हार्डकोड किए गए पते वाली हर चीज़ पर ध्यान देना होगा। फिर से नंबर देना ऐसी अवधि में करें जब आप VPN के बिना राउटर वापस पा सकें।

दूर के प्रीफ़िक्स की सूची पहले जाँचें, बाद में नहीं। किसी दूसरी ऑफ़िस साइट से टकराने वाली नई रेंज चुनने पर वही समस्या ज़्यादा मेहनत के साथ पैदा होती है।

जब कोई भी पक्ष बदल न सके

अगर दोनों में से कोई नेटवर्क फिर से नंबर नहीं दिया जा सकता, तो बाक़ी विकल्प सर्वर पर रहते हैं। एक गेटवे दूर के नेटवर्क को VPN क्लाइंट के लिए दूसरे सबनेट में अनुवादित कर सकता है, नीति-आधारित NAT या द्विदिश प्रकार का उपयोग करके, ताकि क्लाइंट को अनोखा पता दिखे। यह गेटवे डिज़ाइन है, हर डेस्कटॉप क्लाइंट द्वारा दिया जाने वाला स्विच नहीं, और यह बदलता है कि उपयोगकर्ता कौन-सा पता लिखते हैं और कौन-से नाम मेल खाने चाहिए। किसी फ़ोरम से कॉपी किया गया रूट दो समान गंतव्यों में फ़र्क़ नहीं कर सकता।

निजी पता रेंज निजी ही रहती हैं; समस्या दोबारा उपयोग है, रेंजें ख़ुद नहीं।

साबित करें किस मशीन ने जवाब दिया

openssl s_client -connect 192.168.1.20:443 -servername office.example 2>/dev/null | openssl x509 -noout -subject

किसी भी बदलाव के बाद ऑफ़िस संसाधन और स्थानीय डिवाइस साथ में जाँचें। अगर ऑफ़िस सर्वर वहाँ होना चाहिए जहाँ कोई जाना-पहचाना घर का डिवाइस जवाब दे, या TLS प्रमाणपत्र ग़लत होस्ट का नाम बताए, तो रुकें और आगे बढ़ने से पहले गंतव्य की पहचान करें। उस पते से जवाब मिलना यह साबित नहीं करता कि किस मशीन ने भेजा। प्रमाणपत्र का विषय जाँचना उस समय उपलब्ध कुछ भरोसेमंद संकेतों में से एक है।

ऑफ़िस के निजी पतों को ऐसे मनमाने सार्वजनिक पतों से न बदलें जिन्हें आप नियंत्रित नहीं करते। इससे ओवरलैप की जगह रूटिंग और स्वामित्व की समस्या आती है, जो बदतर है और समझाना कठिन।

स्थानीय प्रीफ़िक्स, दूर का प्रीफ़िक्स और वह बदलाव लिखें जिसने इसे हल किया। अगला ओवरलैप अलग दिखेगा पर वही पैटर्न अपनाएगा।