একাধিক NIC সহ GCP VM: উত্তরগুলো কেন ভুল ইন্টারফেস দিয়ে বের হয়

Compute Engine VM-এ দ্বিতীয় ইন্টারফেস যোগ করলে সেটি আরেকটি নেটওয়ার্ক সংযুক্তি পায়, প্রতিসম ফেরত পথ নয়। গেস্ট এখনও নিজের রুট ও নিয়ম থেকেই ইন্টারফেস আর উৎস ঠিকানা বেছে নেয়। এরপর Google Cloud প্যাকেট যে ইন্টারফেস দিয়ে বেরিয়েছে তার চারপাশে VPC রাউটিং ও ফায়ারওয়াল নীতি প্রয়োগ করে। যখন এই দুই সিদ্ধান্ত মেলে না, অনুরোধ এক NIC-এ পৌঁছে আর উত্তর বের হয় অন্যটি দিয়ে, ফলে ব্র্যাঞ্চ অর্ধ-খোলা কথোপকথন দেখে।

পাঁচ ধাপে পথটি অনুসরণ করুন, নীতি নিয়ম লেখার আগেই অসঙ্গতিটি দেখা যাবে।

ধাপ 1: ক্লাউড NIC-গুলোকে গেস্ট ডিভাইসের সঙ্গে মেলান

ক্লাউড ইন্টারফেসের নাম দেয় nic0, nic1 ইত্যাদি, আর গেস্ট এমন ডিভাইস নাম দেখে যেগুলো মিলতে হয় না। আর কিছু করার আগে ইনস্ট্যান্স মেটাডেটা বা ইন্টারফেসের নিজের ঠিকানা থেকে ম্যাপিংটি নির্ধারণ করুন। DHCP-প্রদত্ত সাধারণ ডিফল্ট রুট nic0-এর সঙ্গে যুক্ত, তাই ইন্টারনেটমুখী পথটি এত প্রায়ই দুর্ঘটনাক্রমে জিতে যায়। অনুমান করা ডিভাইস নাম ধরে নীতি লেখা মানেই সঠিক নিয়মটি ভুল ইন্টারফেসে গিয়ে পড়া।

ঠিকানা, ডিভাইস নাম আর প্রতিটি যে VPC-তে অন্তর্ভুক্ত তা লিখে রাখুন। সেই তিন-কলামের ম্যাপ প্রতিটি পরবর্তী ধাপের ইনপুট।

ধাপ 2: দুটি রুট সিদ্ধান্তের নাম দিন

প্রথম সিদ্ধান্ত গেস্টের: এই প্যাকেটের জন্য কোন ইন্টারফেস আর কোন উৎস ঠিকানা। দ্বিতীয়টি ক্লাউডের: ঐ ইন্টারফেসের চারপাশে VPC-র রুট ও ফায়ারওয়াল নীতি কী অনুমোদন করে।

VPN-মুখী VPC-তে দৃশ্যমান কোনো রুট সেই NIC বেছে নেওয়া গেস্ট রুট হয়ে যায় না। ক্লাউড রুট বলে নেটওয়ার্ক কী পৌঁছে দিতে পারে, আর গেস্ট রুট ঠিক করে প্যাকেটটি কী করবে।

ধাপ 3: ফেরত পথের নীতি বেছে নিন

ব্র্যাঞ্চ প্রিফিক্সের ছোট, স্থির সেটের জন্য গেস্টে স্পষ্ট গন্তব্য রুটই সরলতম প্রকাশ: ঐ প্রিফিক্সগুলোর উত্তর VPN-মুখী ইন্টারফেস দিয়ে বের হয়। যখন একাধিক সেবা ইচ্ছাকৃতভাবে ভিন্ন স্থানীয় উৎস ঠিকানা ব্যবহার করে, প্রতি ইন্টারফেসের জন্য টেবিল বেছে নেওয়া উৎসভিত্তিক নিয়ম প্রতিটি উত্তর সঠিক প্রসঙ্গে রাখে। একাধিক ইন্টারফেসের ডকুমেন্টেশন NIC-র নামকরণ আর ডিফল্ট-রুট আচরণ বর্ণনা করে যার উপর এই নকশাগুলো নির্ভর করে।

প্রতিটি টেবিলের দরকার বৈধ সংযুক্ত রুট ও পরবর্তী হপ, সঙ্গে যে গন্তব্যগুলো এর কাছে চাওয়া হবে। অসম্পূর্ণ টেবিলের দিকে নির্দেশ করা নিয়ম কোনো ফেরত-পথ নকশা নয়। সাবনেটের চেহারা দেখে Ethernet গেটওয়ে বানানোর বদলে ঐ NIC-এর জন্য ডকুমেন্টেড গেটওয়ে ব্যবহার করুন।

ধাপ 4: গেস্টের নিজের ফিল্টার পরীক্ষা করুন

সার্ভার কোথায় শোনে আর উত্তরে কোন স্থানীয় উৎস থাকে তা পরীক্ষা করুন। সব ঠিকানায় শোনা লিসেনার রাউটিং নীতি বাতিল করে না, তাই সব ঠিকানায় বাঁধলে উত্তর যে ইন্টারফেস দিয়ে বের হয় তা বদলায় না।

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

ধাপ 5: প্রতিটি পথে একটি প্রবাহ পরীক্ষা করুন

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

দুটি পরীক্ষা আপনার নোটে আলাদা রাখুন, কারণ তারা ভিন্ন রুট আর ভিন্ন ফায়ারওয়াল নিয়ম ব্যবহার করে।

দ্বিতীয় NIC যা দেয় না

দ্বিতীয় ইন্টারফেস একটি নেটওয়ার্ক সংযুক্তি আর আরেকটি ঠিকানা যোগ করে। এটি স্বয়ংক্রিয় প্রতিসম রাউটিং যোগ করে না এবং ফায়ারওয়াল নীতি এড়িয়েও যায় না। এটিকে রাউটিং সমাধান ভাবাই একাধিক NIC-র নকশায় এমন নিয়ম জমার কারণ যা পরে কেউ ব্যাখ্যা করতে পারে না।

যদি VM-কে অন্য মেশিনের ট্রাফিক ফরওয়ার্ড করতে হয়, তবে সেই রাউটার ভূমিকা স্পষ্টভাবে পরিকল্পনা করুন, যার মধ্যে ফরওয়ার্ডিং অনুমোদনকারী ক্লাউড সেটিং আর তার সঙ্গে যাওয়া গেস্ট ফিল্টারও আছে।