একটি ল্যাব সার্ভার, তিনটি বিশ্বাস ভূমিকা, একটি ব্যর্থতা ডোমেইন

সবকিছু কাজ করে যতক্ষণ না বিল্ড রানার সেই একই হোস্ট সকেট চায় যা VPN অতিথি ব্যবহার করে, এবং তারপর কেউ ব্যাখ্যা করতে পারে না কেন একটি কাজ গেটওয়ের চাবি পড়তে পারে। সবকিছু একটি মেশিনে ইনস্টল করা হয়েছিল কারণ এটি ফিট হয়েছিল, এবং প্রত্যেক অতিথিকে ব্যাপক প্রবেশাধিকার দেওয়া হয়েছিল কারণ এটিই ছিল এটি চালু করার দ্রুততম উপায়। ফলাফল হল এমন একটি হোস্ট যার বিশ্বাস সীমা হল পাওয়ার কেবল। ভূমিকা ভাগ করা শোনার চেয়ে কম কাজ, এবং এটি তাদের নাম দেওয়া দিয়ে শুরু হয়।

তিনটি ভূমিকা যারা এই মুহূর্তে সবকিছু ভাগ করে

একটি VPN প্রবেশ, কিছু ব্যক্তিগত সেবা এবং একটি বিল্ড রানার ভিন্ন ভিন্ন জিনিস চায়। প্রথমটির দরকার একটি সার্বজনীন পোর্ট এবং ব্যক্তিগত দিকের একটি সংকীর্ণ নেটওয়ার্ক। দ্বিতীয়টির দরকার স্থায়ী স্টোরেজ এবং অ্যাপ্লিকেশন সিক্রেট। তৃতীয়টি এমন কোড চালায় যা অন্য কেউ লিখেছে।

তিনজনকেই একই প্রবেশাধিকার দেওয়াই উপসর্গটিকে বিভ্রান্তিকর করে তোলে, কারণ তখন তাদের যেকোনো একজন অন্যদের প্রভাবিত করতে পারে। যে বিল্ড কাজ হাইপারভাইজার সকেটে পৌঁছাতে পারে, সেটি এমন কাজ যা VPN বন্ধ করতে পারে। ম্যানেজমেন্ট নেটওয়ার্কে রুট আছে এমন একটি সেবা অতিথি সুইচ কনফিগারেশন বদলাতে পারে। বিশেষাধিকারগুলোই সমস্যা, এবং প্রসেস তালিকা কেবল সেই জায়গা যেখানে এটি দেখা যায়। আগে ভূমিকার নাম দিলে প্রতিটি বিশেষাধিকার বাস করার জায়গা পায়।

নিচের স্কেচটি সেই বিভাজনের একটি সূচনা বিন্দু, উচ্চ প্রাপ্যতার প্রতিশ্রুতি নয়। এটিকে যাচাই করার অনুমান হিসেবে ধরুন, চূড়ান্ত নকশা হিসেবে নয়।

তিনটি ভূমিকা ভাগ করুন, তিনটি প্রসেস নয়

একটি হোস্টে তিনটি অতিথি তিনটি বিশেষাধিকার সেট এবং তিনটি নেটওয়ার্ক অবস্থান দেয়। তারা তিনটি ব্যর্থতা ডোমেইন দেয় না, এবং নকশাটি তা স্পষ্টভাবে বলা উচিত।

বিভাজন কেবল তখনই সাহায্য করে যখন একজন অতিথির আপস অন্যদের স্বয়ংক্রিয়ভাবে বিশেষাধিকার দেয় না, এবং এটি হাইপারভাইজার সেটিং, নামকরণের রীতি নয়। একটি VM-কে গেটওয়ে নাম দিলে অন্য অতিথি হোস্টে পৌঁছানো থেকে বিরত থাকে না। হোস্টনামের বদলে ভার্চুয়াল সুইচ কনফিগারেশন পড়ুন, তারপর নিশ্চিত করুন প্রতিটি অতিথি সেখানে বসে যেখানে আপনি মনে করেন।

host
├─ vpn-gw      10.60.10.2/24   public 51820/udp only
├─ services    10.60.0.10/24   no route to the management network
└─ ci-runner   10.60.20.2/24   outbound only, no host socket

টপোলজি লিখে রাখুন এবং তারপর যেসব টুল এর মালিক সেগুলো দিয়ে যাচাই করুন। ভুল ব্রিজে উপস্থিত হওয়া অতিথি একটি বিবরণ নয়, একটি ফলাফল। যেকোনো সেবা কনফিগারেশন বদলানোর আগে নেটওয়ার্ক ঠিক করুন।

VPN অতিথিকে কেবল তার নিজের দরজা খুলতে দিন

রাউটারে টানেল পোর্ট প্রকাশ করুন, আর কিছু নয়। অতিথি প্রশাসন পোর্ট ম্যানেজমেন্ট পথে থাকে, ইন্টারনেটে নয়, এবং হাইপারভাইজারের নিজস্ব ইন্টারফেসও সেখানেই থাকে।

ব্যক্তিগত দিকের নেটওয়ার্ক দূরবর্তী ব্যবহারকারীদের প্রয়োজনীয় সেবাগুলোতে পৌঁছানো উচিত এবং সেখানেই থামা উচিত। অ্যাপ্লিকেশন প্রমাণীকরণ চালু থাকে, কারণ টানেল পরিবহন, লগইন নয়। VPN অতিথির রাউটিং টেবিল এক বাক্যে বর্ণনা করার মতো ছোট রাখুন। যদি আপনি এত সহজভাবে বর্ণনা করতে না পারেন, সীমা ইতিমধ্যে ঝাপসা হয়ে গেছে।

virsh net-list --all
virsh net-dumpxml lab-private
sudo nft list ruleset | grep -n -E '51820|10.60'

হোস্টে যা শুনছে এবং ম্যানেজমেন্টের জন্য প্রয়োজন নেই তা আদৌ শোনা উচিত নয়। এর মধ্যে হাইপারভাইজার API রয়েছে, যা সার্বজনীন ইন্টারফেসে খোলা রাখা সহজ।

বিল্ড কাজের জন্য ভিন্ন ধরনের সীমা দরকার

একটি CI কাজ রিপোজিটরি-নিয়ন্ত্রিত কমান্ড চালায়, তাই এর বিশ্বাস নির্ভর করে কে কোড পুশ করতে পারে তার উপর। একটি শেল এক্সিকিউটর সেই কমান্ডগুলো হোস্টে রানারের ব্যবহারকারী হিসেবে চালায়, এবং এটি সবচেয়ে প্রশস্ত সীমা।

কনটেইনার এক্সিকিউটরগুলো সংকীর্ণ, এবং বিশেষাধিকারী কনটেইনার সংকীর্ণগুলোর একটি নয়। রানারকে নিজস্ব নেটওয়ার্ক পরিধিসহ নিজস্ব অতিথিতে রাখুন, এবং তাকে কেবল আর্টিফ্যাক্ট ও ডিপ্লয়মেন্ট প্রবেশাধিকার দিন যা কাজগুলোর দরকার। নিষ্পত্তিযোগ্য ওয়ার্কার ধরে রাখা অবস্থা কমায়; তারা পৌঁছানোর ক্ষমতা বা সিক্রেট প্রকাশ কমায় না। দুটোরই এখনও স্পষ্ট সীমা দরকার।

সেবা অতিথি ডেটার মালিক, তাই তার ব্যাকআপ পরিকল্পনাই এমন যা কাজ করতেই হবে। রিপোজিটরি, আপলোড এবং ডাটাবেস একই সময়সূচিতে রাখুন। কাজের অবস্থা পড়ার বদলে পুনরুদ্ধার পরীক্ষা করুন।

তিনজনের ভাগ করা ব্যর্থতার জন্য পরিকল্পনা করুন

একটি হোস্ট একটি ব্যর্থতা ডোমেইন। একটি রিবুট একই মুহূর্তে টানেল এবং প্রতিটি ব্যক্তিগত সেবা সরিয়ে দেয়, এবং ঠিক তখনই ভেতরে যাওয়ার পথ সবচেয়ে বেশি গুরুত্বপূর্ণ।

কনসোল প্রবেশাধিকার রাখুন যা VPN অতিথির উপর নির্ভর করে না, তা ভৌত কনসোল, আউট-অব-ব্যান্ড ম্যানেজমেন্ট ইন্টারফেস বা প্রদানকারীর কনসোল যাই হোক। একই ডিস্কে সংরক্ষিত স্ন্যাপশট স্বাধীন কপি নয়, এবং যে ব্যাকআপ অতিথির ভেতরে চলে যা সে রক্ষা করে সেটিও নয়। তারপর কোল্ড স্টার্ট চেকলিস্ট নয়, ক্রম হিসেবে পরীক্ষা করুন: হোস্ট, ভার্চুয়াল নেটওয়ার্ক, টানেল পথ এবং সাধারণ অ্যাকাউন্টে একটি নামকৃত অ্যাপ্লিকেশন।

virsh list --all
systemctl is-active libvirtd
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://10.60.0.10/
ss -ltnp | grep -E ':51820|:443'

প্রসেস শুরুর ক্রম রুট এবং DNS সম্পর্কে কিছুই প্রমাণ করে না, তাই ইউনিট অবস্থার বদলে পথ পরীক্ষা করুন। পথই দূরবর্তী ব্যবহারকারীর প্রকৃত প্রয়োজন।