तपाईंको घरको LAN मा पूर्वनिर्धारित राउटरको रूपमा FRITZ!Box छ र त्यसको छेउमा सानो Linux बक्सले VPN को काम गर्छ। बक्स कार्यालय नेटवर्कमा पुग्छ, तर FRITZ!Box पछाडिको ल्यापटप पुग्दैन। स्थिर रुटले यसलाई तीन फिल्डमा ठीक गर्छ, र साँचो एकमात्र कठिनाई गेटवे फिल्डमा टनेल ठेगाना नराख्नु हो। गेटवे तपाईंको आफ्नै LAN को अर्को राउटर हो, र सधैं त्यही थियो।

इन्टरफेस खोल्नु अघि तीन फिल्ड लेख्नुहोस्

LAN 192.168.50.0/24, FRITZ!Box 192.168.50.1, र स्थिर ठेगाना 192.168.50.2 भएको VPN बक्स लिनुहोस्, जसलाई पहिले नै 10.40.0.0/16 सम्म काम गर्ने सुरक्षित बाटो छ। रुट भन्छ: त्यो टाढाको प्रिफिक्सका लागि प्याकेट स्थिर LAN ठेगानाको यन्त्रलाई दिनुहोस्। टाढाको VPN सर्भरको सार्वजनिक एन्डपोइन्ट र त्यसको भित्री टनेल ठेगाना दुवै यहाँ अप्रासंगिक छन्, किनकि FRITZ!Box ले तिनीहरूलाई कहिल्यै सिधै केही पठाउँदैन।

फिल्डमानयसले के नाम दिन्छ
IPv4 नेटवर्क10.40.0.0टाढाको गन्तव्य नेटवर्क
सबनेट मास्क255.255.0.0त्यो गन्तव्य कति ठूलो छ
गेटवे192.168.50.2घरको LAN को अर्को राउटर

त्यो LAN ठेगाना DHCP पूल बाहिर आरक्षित राख्नुहोस्, नत्र तपाईंले कन्फिगर गरेको गेटवे एक दिन फोनको हुनेछ।

FRITZ!Box ले रुट कहाँ राख्छ

FRITZ! ले गृह नेटवर्क, त्यसपछि नेटवर्क, त्यसपछि नेटवर्क सेटिङ्स अन्तर्गत IPv4 रुट नियन्त्रण खोल्छ, ठ्याक्कै लेबल र नेस्टिङ मोडेल र FRITZ!OS संस्करणमा निर्भर हुन्छ। रुट तालिका लुकेको छ भने उन्नत दृश्य सक्षम गर्नुहोस्, माथिका मानहरूसँग एउटा प्रविष्टि थप्नुहोस् र लागू गर्नुहोस्। तपाईंको निर्दिष्ट मोडेलको गाइडमा एक पटक हेर्न लायक छ, किनकि त्यही कार्य संस्करणहरूबीच एक पटकभन्दा बढी सरेको छ। तपाईंले सुरक्षित गर्दै गरेको प्रविष्टिको ठ्याक्कै शब्द ध्यान दिनुहोस्, किनकि तालिकाको प्रविष्टिले कुन स्क्रिनले बनायो भनी विरलै भन्छ।

यो FRITZ!Box आफैले VPN अन्त्य गर्ने त्यही सुविधा होइन। रुट अर्को यन्त्रतर्फ देखाउँछ; अन्तर्निहित VPN त्यही यन्त्र हो।

गेटवेले रुट गर्नुपर्छ, मात्र पुग्नु होइन

टाढाको नेटवर्कमा पुग्ने होस्ट आफैं बाँकी LAN का लागि राउटर बन्दैन। VPN बक्सलाई IP फर्वार्डिङ सक्षम चाहिन्छ, LAN इन्टरफेस र टनेलबीच फर्वार्डिङ अनुमति दिने फायरवाल नीति चाहिन्छ, र जवाफ आफ्नै पूर्वनिर्धारित मार्गबाट बाहिर नपठाई LAN मा फर्काउने रुट चाहिन्छ। फर्वार्डिङ खोलेर फायरवाल नियम बिर्सनु सबैभन्दा सामान्य आधा उपाय हो, र क्लाइन्टको तर्फबाट यो रुटिङ विफलता जस्तो देखिन्छ।

FRITZ!Box तर्फबाट VPN बक्सको LAN ठेगानामा पिंग गरेर जाँच्नुहोस्, त्यसपछि क्लाइन्टबाट टाढाको ठेगानासम्म ट्रेस गरेर दोस्रो हप त्यही बक्स हो भनी पुष्टि गर्नुहोस्।

फर्कने बाटो र ओभरल्यापिङ दायरा

टाढाको पक्षलाई 192.168.50.0/24 का लागि टनेलबाट फर्कने रुट चाहिन्छ, तपाईंले VPN बक्समा जानाजान स्रोत अनुवाद नगरेसम्म। जोगाउनु र अनुवाद गर्नु फरक नीति हुन्, फरक लग र फरक पहुँच नियमसहित, र भर्खरै थपेको स्थिर रुटले तिनीहरूबीच छनोट गर्दैन। ओभरल्यापिङ दायरा कठिन समस्या हो: यदि तपाईंको LAN र टाढाको नेटवर्कले एउटै प्रिफिक्स साझा गर्छन् भने एउटा होस्ट रुटले तिनलाई छुट्याउन सक्दैन, र ठेगाना योजना बदल्नुपर्छ।

LAN मा अन्यत्र थप विशिष्ट रुट थप्नु, वा ल्यापटपमा दोस्रो VPN क्लाइन्ट राख्नु, FRITZ!Box को प्रविष्टिलाई चुपचाप पराजित गर्नेछ।

सामान्य क्लाइन्टबाट परीक्षण गर्नुहोस्, त्यसपछि विफलता परीक्षण गर्नुहोस्

परीक्षण VPN बक्सबाट होइन, LAN को सामान्य अधिकृत मेसिनबाट गर्नुहोस्, किनकि बक्स पहिले नै काम गरिरहेको थियो र केही प्रमाणित गर्दैन। टाढाको सेवामा पुगेर जवाफ जाँच्नुहोस्, त्यसपछि असम्बन्धित इन्टरनेट गन्तव्यहरूले अझै पूर्वनिर्धारित रुट लिन्छन् र टनेलबाट तानिँदैनन् भनी पुष्टि गर्नुहोस्। एउटा सबनेटमा पुग्न पूर्वनिर्धारित रुट बदल्नु तपाईंले सुरु गरेको तीन फिल्डको प्रविष्टिभन्दा धेरै ठूलो परिवर्तन हो।

अन्तमा, VPN विच्छेद गर्नुहोस् र के हुन्छ हेर्नुहोस्। गेटवेले सुरक्षित बाटो गुमाए पनि स्थिर रुट तालिकामा रहन्छ, त्यसैले ट्राफिक इन्टरनेटमा फर्किनुको सट्टा बक्समा असफल हुन्छ, र फलब्याक ट्राफिक रोक्ने कुनै पनि आवश्यकता सुरक्षित रुटमा होइन, बक्सको आफ्नै नीतिमा पर्छ।

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