OpenVPN में प्रति क्लाइंट स्थिर IP: ifconfig-push, ipp.txt नहीं

ipp.txt में एक पंक्ति संपादित करना पता आरक्षित करने जैसा लगता है, और ऐसा नहीं है। वह फ़ाइल, जिसका नाम ifconfig-pool-persist से आता है, दर्ज करती है कि साझा नाम के पास पिछली बार कौन-सा पता था, ताकि पूल सुविधाजनक होने पर वही पता लौटा सके। इसमें कुछ भी अगले कनेक्शन को उस संख्या से नहीं बाँधता।

नीचे दी गई जाँचें क्रम से चलाएँ। हर जाँच या तो तंत्र की पुष्टि करती है या आपको रुककर किसी इनपुट को ठीक करने को कहती है।

स्थायित्व फ़ाइल किस काम की है

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

यदि आपको किसी विशेष क्लाइंट के लिए विशेष पता चाहिए, तो प्रलेखित तंत्र ifconfig-push है, और यह उस कॉन्फ़िगरेशन में जाता है जो उस क्लाइंट का स्वामी है।

जाँचें कि सही क्लाइंट चुना गया है

स्पष्ट आवंटन क्लाइंट के साझा नाम से खोजा जाता है, इसलिए गलत पहचान के नाम पर रखी फ़ाइल कभी पढ़ी ही नहीं जाती। पुष्टि करें कि सर्वर उस क्लाइंट का नाम क्या मानता है, विशेष रूप से जहाँ username-as-common-name प्रमाणीकरण के बाद उसे बदलता है। फिर पुष्टि करें कि फ़ाइल का नाम उस मान से ठीक मेल खाता है, अक्षरों के बड़े-छोटे रूप सहित।

यहाँ रहते हुए समवर्तीता पर विचार करें। यदि duplicate-cn की अनुमति है, तो कई डिवाइस एक ही पहचान प्रस्तुत कर सकते हैं, और एक स्थिर पता उन सबके लिए अद्वितीय नहीं हो सकता। तय करें कि उस पहचान के लिए समवर्ती सत्र अस्वीकार करना स्थिर पते के लायक है या नहीं, क्योंकि ये दोनों आवश्यकताएँ एक साथ पूरी नहीं की जा सकतीं।

जाँचें कि संख्याएँ टोपोलॉजी से मेल खाती हैं

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

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

पते को हर उस चीज़ के विरुद्ध जाँचें जो उसका स्वामी हो सकती है: कोई दूसरा स्पष्ट आवंटन, गतिशील पूल की सीमा, और कोई भी स्थिर मार्ग जो निश्चित होस्ट मानता है। पूल से टकराने वाला पता तब तक काम करेगा जब तक पूल उसे किसी और को न दे दे, और वह विफलता यादृच्छिक लगेगी।

नए कनेक्शन पर परिणाम जाँचें

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

साक्ष्य साथ रखें: क्लाइंट का नाम, जो फ़ाइल मेल खाई, आवंटित पता और वह पूल जिससे वह आया।

अंत में, स्थिर टनल पता डिवाइस का क्रेडेंशियल नहीं है। यह पता योजना में एक स्थान दर्शाता है, जबकि प्रमाणीकरण अब भी प्रमाणपत्र और खाते पर टिका है। दोनों को मिलाने से पता टकराव ऐसी सुरक्षा धारणा बन जाता है जिसे किसी ने लिखा नहीं।