VPN क्लाइन्टहरू जोडिन्छन् तर इन्टरनेट छैन: तीन हराएका भाग

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

काम गर्ने टनेललाई अझै बाहिर जाने बाटो किन छैन

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

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

त्यसैले क्लाइन्ट नभई तीन तहको परीक्षण गर्नुहोस्, र नतिजाको अर्थ हुनका लागि एक पटकमा एउटा मात्र बदल्नुहोस्।

फर्वार्डिङ कर्नेल स्विच हो जसलाई स्थायी बनाउनुपर्छ

परिवर्तन गर्नु अघि हालको मान जाँच्नुहोस्, त्यसपछि सेट गर्नुहोस् र परिवर्तन लागू भएको पुष्टि गर्नुहोस्।

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

पहिलो आदेशले हालको मान जनाउँछ, दोस्रोले यसलाई रनटाइममा सेट गर्छ, र तेस्रोले लेखन काम गरेको प्रमाणित गर्छ। रनटाइम मान अर्को रिबुटमा हराउँछ, त्यसैले काम गरिरहेको सत्र मर्मतपछि कुनै पनि कन्फिगरेसन परिवर्तन बिना बिग्रन सक्छ।

यसलाई /etc/sysctl.d/ अन्तर्गतको फाइलमा स्थायी बनाउनुहोस्, त्यसपछि थाहा पाउन रिबुट गर्नुको सट्टा त्यो फाइल लागू गर्नुहोस्। FreeBSD मा समान net.inet.ip.forwarding हो, र स्थायित्वका लागि rc.conf मा gateway_enable=YES। फर्वार्डिङ बन्द भएको जनाउने यन्त्रले «प्याकेटहरू आउँछन् र केही फर्कँदैन» भन्ने सम्पूर्ण वर्गका रिपोर्टहरू व्याख्या गर्छ। प्रत्येक अपग्रेडपछि पनि सेटिङ जाँच्नुहोस्, किनकि पुनः निर्मित कर्नेल वा परिवर्तित यन्त्र इमेजले कसैलाई नभनी यसलाई रिसेट गर्न सक्छ।

masquerade वा एउटा स्थिर अनुवाद ठेगाना छान्नुहोस्

गतिशील बाहिरी ठेगानासँग masquerading सबैभन्दा सरल सही रूप हो। टनेल सबनेटलाई स्रोत र बाहिरी इन्टरफेसलाई निकास भनी नाम दिनुहोस्।

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

स्थिर सार्वजनिक ठेगानासँग स्रोतको अनुवाद ठ्याक्कै त्यही ठेगानामा बढी अनुमानयोग्य र जाँच्न सजिलो हुन्छ।

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

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

फिल्टर तालिका तेस्रो ढोका हो

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

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

ब्रिज गरिएको टनेललाई फरक जवाफ चाहिन्छ। ठेगाना भौतिक पोर्टको होइन, ब्रिजको हो, त्यसैले इन्टरफेसलाई दास बनाउँदा यसको अघिल्लो ठेगाना हट्छ र ब्रिज आफैंले ठेगाना नपाएसम्म होस्ट अगम्य देखिन्छ, जुन dhclient br0 ले दिन सक्छ। त्यो असफलता VPN समस्या जस्तो देखिन्छ र दोस्रो तहको समस्या हो। फायरवाल छुनु अघि ब्रिजको आफ्नै ठेगाना जाँच्नुहोस्, किनकि फिल्टर परिवर्तनले पठाउन ठेगाना नभएको होस्ट सुधार्न सक्दैन।

पृष्ठ कहिल्यै लोड नभएमा कहाँ हेर्ने

टनेल अवस्थित छ भनी प्रमाणित गर्न सर्भरको टनेल ठेगानामा ping गर्नुहोस्। त्यसपछि क्लाइन्टबाट सार्वजनिक ठेगानासम्म traceroute चलाएर कहाँ रोकिन्छ पढ्नुहोस्: सर्भरमा प्याकेट पुग्छ तर फर्वार्ड वा अनुवाद हुँदैन; सर्भरपारि समस्या माथिल्लो तहमा छ र तपाईंको हातमा छैन।

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

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

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

यदि टाढाका क्लाइन्टहरूले सर्भरको LAN का होस्टहरूसम्म पनि पुग्नुपर्ने भए, LAN लाई टनेल सबनेटसम्म फर्कने मार्ग चाहिन्छ भनी सम्झनुहोस्। यो अनुवाद होइन, राउटिङ हो, र इन्टरनेट मार्ग अन्ततः काम गरेपछि सबैभन्दा बढी बिर्सिने चरण यही हो।