VPN क्लाइन्टहरू सर्भरसम्म पुग्छन्, LAN सम्म पुग्दैनन्: कुन समाधान?

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

पहिले कुन दिशा बिग्रिएको छ निश्चित गर्नुहोस्

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

यदि LAN को होस्ट पहिले नै VPN सर्भरतिर संकेत गर्छ भने तपाईंको समस्या फायरवाल नियम वा MTU सीमा हो, फर्कने बाटो हराएको होइन। फिल्टर सुधार्न रुट नथप्नुहोस्।

पहिलो प्रश्न: के तपाईं टाढाको LAN को राउटर सम्पादन गर्न सक्नुहुन्छ?

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

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

सेवा होस्ट गर्ने NAS वा Layer 3 स्विचलाई पनि त्यही रुट चाहिन्छ, जबसम्म यसले सबै कुरा त्यो रुट भएको राउटरबाट पठाउँदैन। सबनेट अन्त्य गर्ने यन्त्र जाँच्नुहोस्, इन्टरनेटतिर फर्केको मात्र होइन। साना नेटवर्कमा प्रायः रुटिङबारे राय राख्ने तीन यन्त्र हुन्छन्।

दोस्रो प्रश्न: के LAN ले क्लाइन्ट ठेगाना देख्न छोड्न सक्छ?

राउटर अरू कसैको भए VPN सर्भरमा अनुवादलाई सहयोगको आवश्यकता पर्दैन। LAN को होस्टले सर्भरको LAN ठेगाना देख्छ, त्यसलाई जवाफ दिन्छ, र सर्भर फर्केर अनुवाद गर्छ। त्यसैले उपकरण र NAT आधारित टाढा पहुँच भूमिकाहरू यस्तो व्यवहार गर्छन्।

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

मूल्य श्रेय हो: प्रति क्लाइन्ट ठेगाना LAN का लगबाट हराउँछन्। LAN को होस्टमा कुनै पनि अनुमति सूचीले तब पूलको सट्टा सर्भरको नाम लिनुपर्छ।

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

तेस्रो प्रश्न: के सर्भर आफै अर्को टनेलको क्लाइन्ट हो?

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

त्यसपछि दुवै दिशा र दुवै आकार जाँच्नुहोस्

परिवर्तनपछि क्लाइन्टबाट LAN को होस्टमा र त्यसपछि LAN को होस्टबाट क्लाइन्टमा ping गर्नुहोस्। दोस्रो दिशा त्यही हो जो मानिसहरूले छोड्छन्, र त्यही अपूर्ण अनुवाद नियम उजागर गर्छ। दुवै नतिजा समय-छापसहित लेख्नुहोस् ताकि पछिको प्रतिगमन तुलनीय होस्।

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

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