Docker: VPN सत्र के दौरान कोई पूर्वनिर्धारित पता पूल शेष नहीं

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

कुछ भी बदलने से पहले पुष्टि करें कि क्या विफल हुआ

नीचे दिए गए चरण उसी होस्ट से चलाएँ जो डेमॉन चलाता है। दूरस्थ संदर्भ से बात करता कोई शेल किसी दूसरी मशीन का वर्णन कर रहा है, और अकेली यह गलती एक घंटा बर्बाद कर सकती है।

उसी समय टिकट में Engine संस्करण भी दर्ज करें। इस रनबुक के शेष भाग की हर अनुमान-विधि संस्करण-सीमित है, और संस्करण के बिना कोई दावा अफवाह है।

आपके पास पहले से मौजूद आवंटन गिनें

नेटवर्क की सूची बनाएँ, फिर महत्वपूर्ण लोगों का निरीक्षण करें: docker network ls, उसके बाद docker network inspect NETWORK_NAME। उनके IPAM सबनेट और प्रत्येक से जुड़े कंटेनर पढ़ें। कई Compose प्रोजेक्ट अपने कंटेनर-गणना से संकेतित होने से अधिक ब्लॉक उपभोग करते हैं, क्योंकि हर प्रोजेक्ट अपना स्वयं का डिफ़ॉल्ट नेटवर्क बनाने की प्रवृत्ति रखता है। रुका हुआ कंटेनर अपने नेटवर्क का आवंटन जारी नहीं करता।

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

गिनती लिख लें। यही आधार-रेखा है जो बताती है कि अगले बदलाव से मदद मिली या नहीं।

डेमॉन रूटों को कैसे देखता है, इसकी तुलना करें

VPN उम्मीदवार चयन को प्रभावित कर सकता है, परंतु कैसे, यह सटीक कार्यान्वयन तय करता है। Linux पर Moby 28.2.2 में, InferReservedNetworks नेमसर्वर पते और कुछ ऑन-लिंक IPv4 रूट एकत्र करता है, और यह हर तालिका से हर रूट को सरलता से आरक्षित नहीं करता। एकत्रित लिंक रूट अनिर्दिष्ट गंतव्य पता भी बाहर रखते हैं, इसलिए अकेला 0.0.0.0/1 रूट सभी पतों को आरक्षित नहीं करता। कोई दूसरा विस्तृत ऑन-लिंक प्रीफ़िक्स, जैसे 128.0.0.0/1, परिचित 172 और 192 उम्मीदवार श्रेणियों को काट सकता है।

VPN जुड़ने से पहले और बाद में ip -4 route show table all की डेमॉन के होस्ट पर तुलना करें। अंतर ही प्रमाण है, और संस्करण ही दावे का विस्तार है।

एक संस्करण की अनुमान-विधि को सभी संस्करणों पर सामान्यीकृत न करें। इसी तरह कोई फ़ोरम उत्तर नीति परिवर्तन बन जाता है।

वह सबसे छोटा सुधार चुनें जो काम करे

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

default-address-pools बदलना भविष्य के आवंटनों के बारे में व्यापक नीति है। कोई असंघर्षी आधार और उपयुक्त आवंटित आकार चुनें, इसे मौजूदा डेमॉन सेटिंग्स के साथ मिलाएँ, और प्रलेखित पुनःआरंभ प्रभाव की योजना बनाएँ। मौजूदा नेटवर्क चुपचाप पुनःक्रमांकित नहीं होते।

आवंटन सफल करने के लिए कंपनी के रूट पुश बंद न करें। कोई स्पष्ट पता योजना सामान्यतः अनिवार्य नीति को कमजोर किए बिना स्थानीय समस्या हल कर देती है।

आवंटन और रूटिंग को अलग-अलग स्वीकारें

बदलाव के बाद, Docker ने वास्तव में जो सबनेट बनाया उसका निरीक्षण करें और एप्लिकेशन की VPN व स्थानीय निर्भरताओं का परीक्षण करें। सफल आवंटन और रनटाइम पर सही रूटिंग दो अलग स्वीकृति जाँचें हैं, और पहली पास करना दूसरी के लिए प्रमाण नहीं है। यदि ऐप टनल के पीछे के संसाधन तक नहीं पहुँच पाता, तो आपकी रूटिंग समस्या है जिसे पूल त्रुटि छिपा रही थी। दोनों परिणाम टिकट में दर्ज करें।

रूट अंतर और पूल गिनती को परिवर्तन रिकॉर्ड के साथ रखें, क्योंकि अगला VPN क्लाइंट अपडेट Docker को छुए बिना पहले को बदल सकता है।

रनबुक तब पूर्ण होता है जब कोई और इन दो जाँचों को दोहराकर वही उत्तर पा सके।