VPN पोर्ट खोल्दा ग्राहकहरू LAN सम्म पुग्दैनन्

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

दुई शृंखला, दुई फरक गन्तव्य

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

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

श्रोता नियमले वास्तवमा के अनुमति दिन्छ

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

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

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

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

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

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

फर्वार्डिङलाई एक होइन, तीन कुरा चाहिन्छ

कर्नेल फर्वार्डिङ सक्रिय हुनुपर्छ, फिल्टर नियमले प्रवाह स्वीकार्नुपर्छ, र गन्तव्यसम्म पुग्न सकिने र उत्तर फर्कने मार्ग हुनुपर्छ। तीनमध्ये एक नभए ग्राहकको दृष्टिकोणबाट त्यही मौनता हुन्छ।

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

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

कागजातमा दुवै नियम समूह छुट्टै राख्नुहोस्

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

हरेक प्रमाणित साथीलाई विश्वसनीय LAN सदस्य मान्नुको सट्टा आवश्यक ग्राहक दायरा र सेवाहरूका लागि साँघुरा नियम प्रयोग गर्नुहोस्। StrongSwan का फर्वार्डिङ टिप्पणीहरू ले त्यही सीमाको फिर्ता मार्ग र अनुवाद पक्ष वर्णन गर्छन्, जुन फेरि तेस्रो निर्णय हो।

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