आफ्नो LAN मा भएका सबै उपकरणसँग एउटै VPN जडान साझा गर्नुहोस्

एउटा ल्यापटपले टनेल समात्छ, घरको बाँकी भागलाई त्यही पहुँच चाहिन्छ, र पहिलो प्रयास सबै कुरा जोडिएको मेसिनतिर पठाउनु हो। यो VPN सँग कुनै सम्बन्ध नभएका कारणले असफल हुन्छ: प्राप्त गर्ने होस्टले प्याकेट अगाडि पठाउनुपर्छ, यसको स्रोत पुनः लेख्नुपर्छ र जवाफहरूले फर्किने बाटो भेट्टाउने सुनिश्चित गर्नुपर्छ। तीनमध्ये एउटा पनि छुट्यो भने जोडिएको ल्यापटप काम गरिरहन्छ, तर अरू हरेक उपकरणले जवाफ पाउँदैन। समाधान रुटिङको डिजाइन हो, क्लाइन्टको सेटिङ होइन।

उपकरणहरू होस्टतिर पठाउनु किन असफल हुन्छ

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

सेटिङहरू अनियमित रूपमा खोल्ने र बन्द गर्ने सट्टा त्यही क्रममा निदान गर्नुहोस्। हरेक छुटेको भागले अलि फरक लक्षण उत्पन्न गर्छ।

होस्टमा फर्वार्डिङ र ठेगाना अनुवाद सक्रिय गर्नुहोस्

जोडिएको होस्टमा दुई परिवर्तनले पहिलो दुई भाग ढाक्छन्: IPv4 फर्वार्डिङ खोल्नुहोस् र LAN ट्राफिकलाई टनेल इन्टरफेसमा अनुवाद गर्नुहोस्।

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

sysctl मान /etc/sysctl.d मुनिको फाइलमा राख्नुहोस्, र रिबुटपछि masquerade नियम फेरि जाँच्नुहोस्, किनकि फायरवालका अगाडिका भागहरूले अनुकूल चेनहरू खाली गर्न सक्छन्। विन्डोजमा साझा गर्ने सुविधाले दुवै चरण गर्छ, तर यसले LAN एडाप्टरलाई स्थिर सबनेटमा पुनः ठेगाना दिन्छ र यसको गेटवे मेटाउँछ, जसले स्थिर ठेगाना र पोर्ट फर्वार्डिङ बिगार्छ। साझा गर्नु असफल भयो भन्ने निष्कर्षमा पुग्नुअघि राउटरको होस्टसम्मको मार्ग यसको नयाँ ठेगानामा पुनर्स्थापित गर्नुहोस्। त्यसपछि दोस्रो उपकरणले ट्राफिक पठाउँदा नियमका काउन्टर बढेको हेर्नुहोस्।

LAN लाई रिबुटपछि टिक्ने मार्ग दिनुहोस्

अरू उपकरणलाई टाढाको प्रिफिक्ससम्म मार्ग चाहिन्छ, र यो दिने दुई तरिका प्रभावको दायरामा फरक छन्।

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

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

टनेललाई दोष दिनुअघि MTU हेर्नुहोस्

टनेलहरूले उपयोगी प्याकेट आकार घटाउँछन्, र दोस्रो उपकरणलाई यसबारे केही थाहा हुँदैन। ठूला स्थानान्तरण र TLS ह्यान्डसेक अड्किन्छन्, तर साना अनुरोध सफल हुन्छन्।

ping -M do -s 1400 10.8.0.5

एउटा जवाफले त्यो आकार मार्गबाट नटुक्रिकन जान्छ भनी प्रमाणित गर्छ; समय सकिनु भनेको इन्क्याप्सुलेसनको भारले प्याकेटलाई टनेलको MTU भन्दा पर धकेलेको हो। साझा गर्ने इन्टरफेसमा MTU घटाउनुहोस् वा अगाडि पठाउने उपकरणमा अधिकतम सेग्मेन्ट आकार सीमित गर्नुहोस्, त्यसपछि त्यही परीक्षण दोहोर्याउनुहोस्। पहिले त्यही आकार LAN पट्टि परीक्षण गर्नुहोस्, किनकि स्थानीय असफलताले टनेल नभई LAN संकेत गर्छ। काम गर्ने आकार टिप्नुहोस्, किनकि पछि प्रदायक वा टनेल परिवर्तनले यसलाई सार्न सक्छ।

एउटा थप उपकरणका लागि होस्टबाट साझा गर्नु पर्याप्त छ। घरका लागि मार्ग राउटरमा राख्नुहोस्। ल्यापटप तपाईंसँग जाँदा पनि पहुँच टिकिरहनुपर्ने भए, टनेल स्वयं समर्पित गेटवेमा हुनुपर्छ।