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 ला स्पर्श न करता पहिले बदलू शकते.

दुसरा कोणी ही दोन्ही तपासण्या पुन्हा करून तेच उत्तर मिळवू शकतो तेव्हा रनबुक पूर्ण होते.