ifconfig-push: net30 में पीयर पता या subnet में नेटमास्क?

गतिशील क्लाइंट जुड़ते हैं और राउटिंग ठीक चलती है, लेकिन स्थिर पते वाला एकमात्र क्लाइंट सर्वर तक बिल्कुल नहीं पहुँचता। फ़ायरवॉल में कुछ नहीं बदला, और CCD पंक्ति विश्वसनीय लगती है। सामान्य कारण सर्वर जो TUN टोपोलॉजी चला रहा है उससे भिन्न के लिए लिखा गया दूसरा आर्ग्युमेंट है। विफलता शांत है: क्लाइंट पते के साथ ऊपर आता है और सर्वर कनेक्शन स्वीकार करता है, फिर भी कोई ट्रैफ़िक नहीं गुज़रता।

net30 में वह फ़ील्ड पीयर पता है; subnet में वह नेटमास्क है। दोनों रूप विकल्प हैं, कभी क्रम नहीं।

दोनों रूप, साथ-साथ

पारंपरिक net30 परिनियोजन में प्रत्येक क्लाइंट के पास एक /30 ब्लॉक होता है: एक नेटवर्क पता, दो उपयोगी पते और एक ब्रॉडकास्ट पता। ifconfig-push क्लाइंट का पता और पीयर पता लेता है, और पीयर उसी ब्लॉक का दूसरा उपयोगी पता है, जिसे पॉइंट-टू-पॉइंट लिंक का सर्वर पक्ष उपयोग करता है।

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

topology subnet के अंतर्गत क्लाइंट सर्वर के साथ एक subnet साझा करता है, और वही निर्देश एक पता और एक नेटमास्क लेता है। सर्वर का अपना पता server निर्देश से आता है, दूसरे फ़ील्ड से नहीं। रूपों को मिलाने से ऐसा क्लाइंट बनता है जो मानता है कि वह पॉइंट-टू-पॉइंट लिंक पर है, जबकि सर्वर उसे subnet होस्ट के रूप में राउट करता है, या इसका उलटा। इसीलिए नेटमास्क को कभी net30 के साथ नहीं जोड़ना चाहिए।

ब्लॉक की दोनों पंक्तियाँ CCD फ़ाइल के लिए अलग पंक्तियाँ हैं। प्रत्येक क्लाइंट को उनमें से ठीक एक मिलती है।

सर्वर वास्तव में जो टोपोलॉजी चला रहा है उसे पढ़ें

पैकेज के डिफ़ॉल्ट के बजाय चल रहा कॉन्फ़िगरेशन पढ़ें, क्योंकि टोपोलॉजी वर्षों पहले सेट होकर आगे कॉपी की गई हो सकती है। topology subnet या उसकी अनुपस्थिति खोजें, फिर जाँचें कि server पंक्ति पते कैसे आवंटित करती है। जो कॉन्फ़िगरेशन कभी टोपोलॉजी का उल्लेख नहीं करता वह subnet सेट करने वाले के समान नहीं है।

फिर क्लाइंट को मिली सेटिंग्स पढ़ें। जो पता, मास्क और पीयर वह बताता है वे बताते हैं कि सर्वर ने कौन-सी व्याख्या लागू की।

स्थिर पते को गतिशील पूल से बाहर रखें

स्थिर पता गतिशील पूल से बाहर होना चाहिए, नहीं तो दो क्लाइंट को एक ही पता मिल सकता है। subnet टोपोलॉजी के साथ, server पंक्ति पर nopool स्वचालित पूल को दबाता है, और स्पष्ट ifconfig-pool श्रेणी तय करती है कि गतिशील क्लाइंट को क्या मिलता है।

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

सर्वर अपने लिए 10.99.0.1 लेता है, और स्थिर क्लाइंट पता पूल श्रेणी से बाहर रहता है। CCD फ़ाइल का नाम प्रोफ़ाइल फ़ाइल के नाम पर नहीं, प्रभावी क्लाइंट पहचान पर रखा जाता है, और इसे कोई अतिरिक्त एक्सटेंशन नहीं मिलता। यदि username-as-common-name सक्रिय है, तो प्रमाणित उपयोगकर्ता नाम वह पहचान है जिसे मिलाना है। एक ही पहचान साझा करने वाले दो उपकरण स्थिर पता भी साझा करेंगे, जो राउटिंग नहीं बल्कि नीति की समस्या है।

क्लाइंट को वास्तव में मिला आवंटन सत्यापित करें

कुछ और जाँचने से पहले इच्छित क्लाइंट को फिर से जोड़ें और पुष्टि करें कि कौन-सी CCD फ़ाइल चुनी गई। फिर पता, मास्क या पीयर, और सर्वर तक वापसी मार्ग सत्यापित करें। subnet परिनियोजन में पीयर पता दिखाने वाला क्लाइंट अभी भी गलत रूप का उपयोग कर रहा है।

टोपोलॉजी बदलना हर क्लाइंट और हर ओवरराइड को प्रभावित करता है, इसलिए इसे एक क्लाइंट की मरम्मत नहीं बल्कि माइग्रेशन मानें। स्थिर पंक्ति को पहले से प्रयुक्त टोपोलॉजी से मिलाने के लिए सुधारना आमतौर पर छोटा बदलाव है। server-options संदर्भ सहायक और क्लाइंट-विशिष्ट ओवरराइड का दस्तावेज़ीकरण करता है।