একটি Azure VPN VM-এ দুটি পাবলিক IP: কোনটি কী করে

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

সিদ্ধান্ত 1: টানেল কোথায় শেষ হয়

একটি Azure পাবলিক IP NIC-এর একটি প্রাইভেট IP কনফিগারেশনের সঙ্গে যুক্ত থাকে; এটি গেস্ট অপারেটিং সিস্টেমের ভেতরে আপনি যোগ করা ঠিকানা নয়। অনুমান না করে ম্যাপিংটি পড়ুন: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'। ওই কোয়েরি যে প্রাইভেট ঠিকানা ফেরত দেয়, সেটিই সেই ঠিকানা যা গেস্টকে প্রকৃতপক্ষে ধারণ করতে হবে।

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

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

সিদ্ধান্ত 2: ফরোয়ার্ড করা ক্লায়েন্ট কোন উৎস ব্যবহার করে

গেটওয়ে ক্লায়েন্টের অনুরোধ ডিক্রিপ্ট করার পর যে প্যাকেটটি ফরোয়ার্ড করে তা VPN লিসেনারে আসা প্যাকেট থেকে আলাদা। গেস্টের ফরওয়ার্ডিং সক্রিয় থাকা, প্রবাহ অনুমোদনকারী ফায়ারওয়াল পলিসি এবং ক্লাউড ডিজাইনে অনুমোদিত উৎস ঠিকানা প্রয়োজন। আপনি যদি ভেতরের ক্লায়েন্ট ঠিকানা অনুবাদ করেন, Azure সেই অনূদিত উৎসটিই মূল্যায়ন করবে, ক্লায়েন্টের ভেতরের ঠিকানা নয়।

সংকীর্ণ SNAT নিয়ম গেস্ট-প্রাইভেট উৎস বেছে নিতে পারে, কিন্তু পরবর্তী Azure অনুবাদকে অগ্রাহ্য করতে পারে না। VM-এর ভেতরে প্রতি-ক্লায়েন্ট জবাবদিহিতা দরকার হলে SNAT বেছে নিন; সাবনেটের আউটবাউন্ড ডিজাইন ইতিমধ্যে স্থিতিশীল পাবলিক উৎস দিলে এবং দ্বিতীয় অনুবাদ কেবল স্টেট যোগ করবে, তখন এটি বাদ দিন।

সিদ্ধান্ত 3: কোন Azure আউটবাউন্ড পদ্ধতি জেতে

Microsoftআউটবাউন্ড অগ্রাধিকার ক্রমনথিভুক্ত করে: অ্যাপ্লায়েন্স বা গেটওয়েতে প্রযোজ্য রুট অগ্রাধিকার পায়, এবং প্রাসঙ্গিক পথে সাবনেট NAT Gateway সংযোগ ইনস্ট্যান্স-স্তরের পাবলিক IP-এর চেয়ে অগ্রাধিকার পায়। এই ক্রমের কারণেই 10.20.0.5-এ অনুবাদ করলে প্রমাণ হয় না যে ওয়েবসাইট 198.51.100.20 দেখবে। নির্গমন ডিজাইন গ্রহণ করার আগে কার্যকর রুট টেবিল, NAT Gateway সংযোগ ও NIC-এর পাবলিক IP একসঙ্গে পড়ুন।

রাখুনAzure NIC ফরওয়ার্ডিং সেটিংLinux ফরওয়ার্ডিং থেকে আলাদা। ক্লাউড ফ্ল্যাগ এমন প্যাকেট অনুমোদন করে যার উৎস বা গন্তব্য NIC-তে নির্ধারিত নয়; এটি net.ipv4.ip_forward সক্রিয় করে না, এবং গেস্ট সেটিং ক্লাউডের অনুমতি দেয় না।

টানেল সকেটের নিজস্ব উৎস সিদ্ধান্ত আছে

wg-quick-এর অধীনে WireGuard-এর Address WireGuard ইন্টারফেসে একটি ঠিকানা নির্ধারণ করে; এটি বাইরের UDP বাইন্ড নির্দেশ নয়। এনক্রিপ্টেড সকেটের উৎস রাউটিং টেবিল অনুসরণ করে, তাই একটি পলিসি রুট বা দ্বিতীয় ডিফল্ট ইন্টারফেস ঠিকানায় হাত না দিয়েই এটি সরাতে পারে।OpenVPN-এর local অপশন ও UDP multihome একইভাবে আচরণ করে: তারা লিসেনার ও তার উত্তর সম্পর্কে, প্রতিটি ফরোয়ার্ড করা ক্লায়েন্টের ইন্টারনেট উৎস সম্পর্কে নয়।

টানেল বহনকারী আন্ডারলে রুট সংরক্ষণ করুন এবং নিশ্চিত করুন যে ক্লায়েন্ট প্রত্যাশিত প্রবেশ বিন্যাস থেকে এখনো প্রমাণিত উত্তর পাচ্ছে। ঠিকানা তালিকার ক্রমকে স্থায়ী উৎস-নির্বাচন নীতি হিসেবে ভরসা করবেন না, কারণ NIC-তে যোগ করা পরবর্তী ঠিকানা কোনটি জিতবে তা বদলে দিতে পারে।

কী গ্রহণ করবেন, আর কোন ক্রমে

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

সফল টানেল কেবল প্রথম অংশ প্রমাণ করে। নতুন প্রবাহ দিয়ে নির্গমন পরীক্ষা করুন, কারণ ক্যাশে করা সংযোগ রুট বদলের অনেক পরে পুরোনো উৎস ব্যবহার চালিয়ে যেতে পারে।