ब्रिज गरिएका OpenVPN क्लाइन्टमा इन्टरनेट छैन? NAT नियम जाँच्नुहोस्

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

प्रमाण गणक हो, तालिकाको प्रविष्टि होइन

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

iptables -t nat -L POSTROUTING -v -n

पहिले इन्टरफेस मिलानको छेउको गणक पढ्नुहोस्। स्रोत दायरा ठीक र आउटपुट पक्ष गलत भए, सुधार नयाँ नियम होइन, नियमभित्रको एउटा शब्द हो।

कर्नेलले वास्तवमा कुन नाम रेकर्ड गर्छ भेट्नुहोस्

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

ip -brief link

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

सुरुङ यन्त्रविरुद्ध नियम पुनः लेख्नुहोस्

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

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

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

गणकसहित forward शृंखला पढ्न एउटै आदेश लाग्छ र अर्को नियम छुनुअघि बाँकी आधा सम्भावना त्यसैले हटाउँछ।

भौतिक कार्ड किन कहिल्यै मिल्दैन

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

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

यसलाई सुरुदेखि अन्त्यसम्म प्रमाणित गर्नुहोस्, त्यसपछि स्थायी बनाउनुहोस्

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

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

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