एपले टनेल स्वस्थ रहेको दाबी गर्छ, तैपनि तपाईंलाई चाहिने आधा गन्तव्यहरूले कहिल्यै जवाफ दिँदैनन्। पहिलो प्रतिक्रिया रुट थप्ने वा मेट्रिक घटाउने हो, र त्यही प्रतिक्रिया नै पहिले मार्नुपर्ने मिथक हो। जब क्लाइन्टको आफ्नै 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 छान्नेछ, र ठोक्किने घटना उसैसँग फर्केर आउनेछ।

सम्बन्धित लेखहरू