राउटरको VPN काम गर्छ, तर LAN क्लाइन्टहरूमा इन्टरनेट छैन

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

LAN होस्टबाट विफलता पढ्नुहोस्

असफल हुने यन्त्रबाट सुरु गर्नुहोस्, किनकि राउटरमा गरिएको निदानले अर्कै प्रश्नको उत्तर दिन्छ। क्लाइन्टको डिफल्ट गेटवे यही राउटर हो भनी पुष्टि गर्नुहोस्, त्यसको स्रोत ठेगाना र सबनेट नोट गर्नुहोस्, अनि राउटरको टनेल इन्टरफेसबाट के बाहिर जान्छ हेर्नुहोस्।

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

स्थानीय र फर्वार्ड हुने ट्राफिक फरक हुन्

Linux र अधिकांश राउटर फर्मवेयरले बाकसले आफैं उत्पन्न गरेका प्याकेटलाई त्यसबाट जाने प्याकेटभन्दा फरक तरिकाले व्यवहार गर्छन्। आउटपुट चेनले पहिलो प्रकार देख्छ, फर्वार्ड चेनले दोस्रो देख्छ, र राउटरको आफ्नै ट्राफिकका लागि मिलाइएको नीतिले फर्वार्डिङलाई छुनै नसक्ने छोड्न सक्छ.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

फिर्ता मार्ग पनि हुनुपर्छ

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

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

क्लाइन्टको DNS पनि त्यही समीक्षामा पर्छ। राउटरको रिजोल्भरले जवाफ दिन सक्छ, तर अर्को सर्भरतिर देखाइएको क्लाइन्टले केही पनि पाउँदैन।

एउटा अनुमति दिइएको र एउटा अस्वीकार गरिएको प्रवाह जाँच्नुहोस्

सुधारपछि राउटरको विद्यमान सत्रको सट्टा क्लाइन्टबाट नयाँ जडान परीक्षण गर्नुहोस्। त्यसपछि टनेल प्रयोग गर्न नहुने खण्डले अझै प्रयोग गर्दैन भनी पुष्टि गर्नुहोस्।

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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