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-এ হাত না দিয়েই প্রথমটিকে বদলে দিতে পারে।

রানবুক তখনই সম্পূর্ণ, যখন অন্য কেউ এই দুটি যাচাই পুনরাবৃত্তি করে একই উত্তর পায়।