ब्रिज किए गए 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 नियम का उपयोग करना पड़े, और काउंटर फिर पढ़ें: उसे इस परीक्षण के लिए हिलना चाहिए, पिछले के लिए नहीं। टनल डिवाइस पर लिया गया कैप्चर एक साथ दिखाता है कि फ़्रेम कहाँ दिखता है और कौन-सा पता ले जाता है।

अंतिम चरण: जो नियम काम करते हैं उन्हें उस कॉन्फ़िगरेशन में रखें जिसे रीस्टार्ट पढ़ता है, और उस डिवाइस का नाम नोट करें जो इस होस्ट का ब्रिज वास्तव में उपयोग करता है। हाथ से टाइप किया गया सब कुछ रीबूट के बाद चला जाता है, और वही खराबी बिना किसी व्याख्या के लौट आती है।

यदि फिर से लिखने के बाद भी काउंटर नहीं हिलता, तो नियम की स्रोत श्रेणी की तुलना उस पते से करें जो क्लाइंट को वास्तव में मिला था, क्योंकि ब्रिज किया गया सर्वर ऐसी श्रेणी से पते दे सकता है जिसका आपने इरादा नहीं किया।