VPN गेटवेलाई IP फर्वार्डिङ आवश्यक छ: के जाँच्ने

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

दुई भूमिकाहरू स्वतन्त्र छन्, र दुई ठेगाना परिवारहरू पनि।

आफ्नै ठेगानामा जवाफ दिनुले केही प्रमाणित गर्दैन

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

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

त्यही वाक्य फर्वार्डिङ निर्णयको अगाडिको फायरवालमा पनि लागू हुन्छ, जसको के फर्वार्ड गर्न सकिन्छ भन्नेबारे आफ्नै नीति छ।

प्रत्येक ठेगाना परिवार अलग-अलग जाँच्नुहोस्

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

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

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

फर्वार्डिङ चार आवश्यकतामध्ये एक हो

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

क्लाउड प्लेटफर्महरूले पाँचौँ विचार थप्छन्। केहीले इन्स्ट्यान्सहरूमा स्रोत र गन्तव्य जाँच लागू गर्छन्, जसले गेस्ट कर्नेल कसरी कन्फिगर भएको भए पनि फर्वार्ड गरिएका प्याकेटहरू खसाल्छ। त्यहाँ अधिकार प्लेटफर्मको आफ्नै नेटवर्किङ कागजातसँग छ, VM भित्रको sysctl आउटपुटसँग होइन।

गेटवेबाट होइन, क्लाइन्टबाट परीक्षण गर्नुहोस्

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

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

यदि प्याकेटहरू आए र सेवाले प्रयोगकर्तालाई अस्वीकार गर्‍यो भने, तपाईं नेटवर्किङभन्दा अगाडि बढिसक्नुभयो। फर्वार्डिङ नीति फेरि फराकिलो बनाउनुको सट्टा अनुप्रयोग प्राधिकरणसँग अगाडि बढ्नुहोस्।