Azure P2S VPN স্ট্যাটিক IP: ক্লায়েন্ট ঠিকানা কেন বদলে যায়
Azure point-to-site প্রতিবার সংযোগের সময় পুল থেকে পরবর্তী খালি ঠিকানা দেয়, তাই নির্দিষ্ট ক্লায়েন্ট IP নেই। পরিবর্তে রেঞ্জ বা পরিচয়ের ভিত্তিতে অ্যাক্সেস নিয়ন্ত্রণ করুন।
প্রতিটি Azure point-to-site ক্লায়েন্ট প্রমাণীকরণের সময় পুল থেকে একটি ঠিকানা পায় এবং কেবল সেই সংযোগের আয়ুষ্কাল পর্যন্ত তা ধরে রাখে। কোনো রিজার্ভেশন টেবিল নেই, প্রতি-ব্যবহারকারী ম্যাপিং নেই, আর কোনো গেটওয়ে সেটিং নেই যার অর্থ “এই ব্যক্তিকে সবসময় 172.16.0.10 দিন”। এই একক প্রক্রিয়াই পরে মানুষের যে দুটি উপসর্গে পড়ে, তা ব্যাখ্যা করে: এমন একটি NSG নিয়ম যা আগে যে ব্যবহারকারীর সঙ্গে মিলত এখন আর মেলে না, এবং এমন একটি অনুমোদিত তালিকা যা চুপচাপ এমন একটি মেশিন ঢুকতে দেয় যা কেউ ইচ্ছাকৃতভাবে যোগ করেনি। নিয়মটিকে আরও চতুর IP নিয়ম দিয়ে বদলালে কোনোটিই সারায় না, কারণ নিয়মটি যে জিনিসের নাম নেয় তা এমন সময়সূচিতে পুনরায় বরাদ্দ হয় যা আপনার নিয়ন্ত্রণে নেই।
পুল হলো ধারণক্ষমতা, পরিচয় নয়। এটি আছে যাতে একসঙ্গে চলা টানেল ইউনিক ঠিকানা পায়, আর লিজ শেষ হওয়ার মুহূর্তেই এটি সেগুলি পুনর্ব্যবহার করে। এটা স্পষ্ট হলে উপকারী প্রশ্নটা আর “এই ক্লায়েন্টকে কীভাবে পিন করব” থাকে না, হয়ে যায় “গেটওয়ে যে জিনিস পুনর্ব্যবহার করবে না, তার বিরুদ্ধে আমি কী নিয়ম লিখতে পারি”।
ক্লায়েন্ট সংযোগ করলে গেটওয়ে আসলে কী করে
গেটওয়ে কনফিগার করা ক্লায়েন্ট ঠিকানা পুলটি রাখে এবং এটিকে লিজ টেবিল হিসেবে ব্যবহার করে। সংযোগের সময় এটি পরবর্তী খালি ঠিকানা নেয়, বাস্তবে সবচেয়ে কম উপলব্ধটি, এবং ক্লায়েন্ট সংযোগ বিচ্ছিন্ন না হওয়া বা লিজ শেষ না হওয়া পর্যন্ত তা টানেল অ্যাডাপ্টারে বরাদ্দ করে। সিদ্ধান্ত নেয় ক্রম, পরিচয় নয়: শান্ত সময়ের পরে যে আগে পুনরায় সংযোগ করে, সে সেই মুহূর্তে ঘটনাক্রমে খালি থাকা সবচেয়ে কম ঠিকানাটি পায়।
পুলের আকার আচরণটিকে লুকায়। পরীক্ষকদের সংখ্যার চেয়ে এক-দুটি ঠিকানা বড় ল্যাব পুল নির্ধারক মনে হয়, কারণ একই ল্যাপটপ প্রতিদিন সকালে একই ক্রমে পুনরায় সংযোগ করতে ঝোঁক রাখে। তৃতীয় মেশিন যোগ করুন, পুলের আকার বদলান, বা দুপুরের খাবারের সময় একটি সেশন সংযুক্ত রেখে দিন — প্যাটার্নটি ভেঙে যায়। ঠিকানাটি কখনোই স্থির ছিল না; সারিটি স্থির ছিল।
point-to-site কনফিগারেশনের যেকোনো পরিবর্তন লিজ স্পেসও রিসেট করে। ভিন্ন প্রমাণীকরণ ধরন, আকার বদলানো পুল, নতুন পুল রেঞ্জ, বা ভেঙে নতুন করে তৈরি করা গেটওয়ে — সবই ক্লায়েন্টদের এমন পুলে ফেরত পাঠায় যা আর তাদের পুরনো ঠিকানার সঙ্গে মেলে না। সেই পরিবর্তনের কোনো কিছুই আপনার NSG-তে হাত দেয় না, তাই ভাঙনটি আকস্মিক মনে হয়।
প্রায় এক মিনিটে এটি ঘটতে দেখতে পারেন। সংযোগ করুন, ক্লায়েন্টের সংযোগ বিবরণে টানেল ঠিকানাটি লিখে নিন, সংযোগ বিচ্ছিন্ন করুন, দ্বিতীয় মেশিন সংযোগ করুন, তারপর প্রথমটি আবার সংযোগ করুন। যে ঠিকানা ফিরে পাবেন তা নির্ভর করে দ্বিতীয় মেশিন কী ধরে আছে তার উপর, আর কোনো পোর্টাল সেটিং চাহিদামতো আগেরটি ফিরিয়ে দেবে না।
ক্লায়েন্ট IP-ভিত্তিক NSG আসলে সংযোগের ক্রম নিয়ে একটি নিয়ম
মানুষ প্রথমে যে নিয়মটি লেখে তা সুস্পষ্ট: ম্যানেজমেন্ট VM-এর NIC বা তার সাবনেটে একটি ইনবাউন্ড নিয়ম, উৎস হিসেবে VPN ক্লায়েন্টের অভ্যন্তরীণ ঠিকানা। এটি ছোট, লেখার দিনই পরীক্ষায় পাস করে, আর পুলে একটির বেশি খালি ঠিকানা থাকলেই ব্যর্থ হয়।
এর থেকে দুটি ব্যর্থতার ধরন আসে, আর তাদের একটিই বাগের মতো দেখায়। একজন বৈধ ব্যবহারকারী বঞ্চিত হন কারণ নিয়মটি যে ঠিকানার নাম নেয় তা এখন অন্য কেউ ধরে আছে, আর এটি বিরক্তিকর সাপোর্ট টিকিট হিসেবে আসে। অথবা একজন অপ্রত্যাশিত ব্যবহারকারীকে অনুমতি দেওয়া হয় কারণ তিনি এমন একটি ঠিকানা উত্তরাধিকারে পেয়েছেন যা নিয়মটি এখনো বিশ্বাস করে, আর এটি কিছুই হিসেবে আসে না যতক্ষণ না কেউ অ্যাক্সেস নিরীক্ষা করে।
যেহেতু নিয়মটি লিজ অনুসরণ করে, কার্যকর নীতি পড়া যায় “যে আগে সংযোগ করে সে ম্যানেজমেন্ট অ্যাক্সেস পায়”। এটি সংযোগের ক্রমের একটি বর্ণনা যা উদ্দেশ্যের পোশাক পরে আছে, আর কোনো নিয়ম-পরিচ্ছন্নতা এটিকে উদ্দেশ্য প্রকাশ করতে পারে না।
ক্লায়েন্ট লিজ আর গেটওয়ে ঠিকানা দুটি ভিন্ন বস্তু
বেশিরভাগ বিভ্রান্তি একটি শব্দ থেকে আসে। গেটওয়ের একটি পাবলিক IP আছে যা তুলনামূলকভাবে স্থির; ক্লায়েন্টদের পুল থেকে আসা প্রাইভেট ঠিকানা আছে যা স্থির নয়। জোন-রিডান্ড্যান্ট নয় এমন VPN গেটওয়ের জন্য পাবলিক IP গতিশীলভাবে বরাদ্দ হয়, তবে এটি রিসাইজ, রিসেট এবং রুটিন রক্ষণাবেক্ষণ কাটিয়ে ওঠে — এটি বদলায় যখন গেটওয়ে নিজেই মুছে নতুন করে তৈরি হয়। জোন-রিডান্ড্যান্ট ও জোনাল গেটওয়ে SKU একটি Standard SKU পাবলিক IP ব্যবহার করে, আর সেই বরাদ্দ স্থির হতে হবে।
এই স্থিরতাই অন-প্রিমাইজেস পার্টনারের কনফিগারেশনে দরকার, আর এটি একজন আলাদা ক্লায়েন্ট চেনার বিষয়ে কিছুই বলে না। অংশীদার জিজ্ঞাসা করলে কোন ঠিকানা দেখবে, উত্তর হলো site-to-site-এ গেটওয়ের পাবলিক IP, বা একটি শেয়ার্ড NAT রেঞ্জ — ল্যাপটপের টানেল লিজ কখনোই নয়।
গ্রুপ পুল আপনাকে এমন রেঞ্জ দেয় যার বিরুদ্ধে নিয়ম লেখা সার্থক
Virtual WAN point-to-site ব্যবহারকারী গ্রুপ সমর্থন করে, আর প্রতিটি গ্রুপকে নিজস্ব ক্লায়েন্ট ঠিকানা পুল বরাদ্দ করা যায়। সদস্যপদ পরিচয় দ্বারা নির্ধারিত হয়, তাই ক্লায়েন্ট যে রেঞ্জে পড়ে তা অনুমানযোগ্য হয়: অপারেশন এক রেঞ্জে, ঠিকাদার অন্য রেঞ্জে, আর রেঞ্জটি এমন জিনিস যা ফায়ারওয়াল বা NSG নিয়ম অনুমান ছাড়াই নাম নিতে পারে।
ফলে যে নিয়ম-সমষ্টি তৈরি হয় তার একটি আকৃতি আছে যা পর্যালোচনা করা যায়:
- প্রতি শ্রোতার জন্য একটি পুল, মাথার সংখ্যা নয় বরং সর্বোচ্চ একসঙ্গে চলা সেশনের জন্য মাপা;
- গ্রুপ সদস্যপদ পরিচয় দিয়ে পরিচালিত, কেউ যোগ দিলেই নিয়ম সম্পাদনা করে নয়;
- NSG বা Azure Firewall নিয়ম পুল রেঞ্জের বিরুদ্ধে লেখা, কখনোই আলাদা লিজের বিরুদ্ধে নয়;
- যে শ্রোতারা কখনোই একটি রেঞ্জ ভাগ করবে না তাদের জন্য আলাদা হাব বা গেটওয়ে।
| Rule target | Survives a reconnect | What it still cannot express |
|---|---|---|
| Client tunnel address | No | Follows connection order and admits whoever holds the address next |
| Whole client pool | Yes | Grants every connected client identical access |
| Virtual WAN group pool | Yes | Only as reliable as group membership |
| Gateway public IP | Until the gateway is recreated | Identifies the site, not the person |
পুরো পুলকে অনুমোদিত তালিকায় রাখা সৎ কিন্তু মোটা: সেই রেঞ্জের প্রতিটি সংযুক্ত ক্লায়েন্ট একই অ্যাক্সেস পায়। এটি একটি নীতি-সিদ্ধান্ত যা পর্যালোচনার সময় আবিষ্কার করার বদলে জোরে বলা উচিত। যেকোনো কিছু যার এখনো প্রতি-ব্যক্তি উত্তর দরকার তা রোল অ্যাসাইনমেন্টের মাধ্যমে রিসোর্সের কাছে থাকা উচিত, প্যাকেট ফিল্টারের কাছে নয়।
যখন ডিপ্লয়মেন্ট Virtual WAN-এ যেতে পারে না
অনেক গেটওয়ে সাধারণ VPN গেটওয়ে-ই থাকে, আর Virtual WAN-এ যাওয়া হালকা পরিবর্তন নয়। বাস্তব উত্তর হলো প্রতি-ব্যবহারকারীর সিদ্ধান্ত প্যাকেট ফিল্টার থেকে সরিয়ে এমন কিছুতে নেওয়া যা ইতিমধ্যেই জানে ব্যবহারকারী কে।
রিসোর্স-স্তরের পরিচয় সবচেয়ে সস্তা সংস্করণ। Storage, SQL ও Key Vault সবই প্রতি-ব্যবহারকারী বা প্রতি-গ্রুপ রোল অ্যাসাইনমেন্টসহ Entra ID প্রমাণীকরণ সমর্থন করে, তাই VPN-কে কেবল নেটওয়ার্ক পৌঁছানোর প্রমাণ দিতে হয়। নামযুক্ত অ্যাকাউন্টসহ একটি জাম্প হোস্ট প্রশাসনিক কাজের জন্য একই কাজ করে, কারণ হোস্ট মানুষটিকে রেকর্ড করে আর টানেল কেবল প্যাকেট বহন করে। ক্লায়েন্টদের DNS-এ নিবন্ধন করে নম্বরের বদলে নামটি অনুমোদিত তালিকায় রাখা নিয়মটিকে এক স্তর উপরে নেয়। অ্যাপ্লিকেশন-স্তরের পরিচয় — একটি সার্টিফিকেট সাবজেক্ট, একটি টোকেন দাবি, একটি গ্রুপ সদস্যপদ — তখন কাজ করে যখন সিদ্ধান্ত নিতে বলা হয় অ্যাপ্লিকেশনকে, নেটওয়ার্ককে নয়।
যে অংশীদার নির্দিষ্ট উৎস ঠিকানায় জোর দেয়, তার জন্য উত্তর হলো নির্ধারিত পিয়ার প্রিফিক্সসহ site-to-site বা ExpressRoute। তারা পিয়ার প্রিফিক্সটি অনুমোদিত তালিকায় রাখে, তাদের দিকে যে ঠিকানা দেখা যায় তা গেটওয়ের, আর কেউ ল্যাপটপ রিবুট করলে তা বদলায় না।
আরেকটি অনুমোদিত তালিকা সম্পাদনার আগে পুলটি যাচাই করুন
পুলের দুটি বৈশিষ্ট্য মানুষের ক্লায়েন্টকে যে দোষ দেয় তার বেশিরভাগের কারণ। খুব ছোট পুল লিজ দ্রুত পুনর্ব্যবহার করে, তাই ঠিকানাগুলো ক্রমাগত সরে যেতে দেখা যায় এবং ঠিকানা-ভিত্তিক যেকোনো নিয়ম স্বভাবতই অস্থির মনে হয়। যে পুল অন-প্রিমাইজেস রেঞ্জ বা ভার্চুয়াল নেটওয়ার্ক স্পেসের সঙ্গে ওভারল্যাপ করে তা রাউটিং দ্ব্যর্থতা তৈরি করে যা কোনো ফায়ারওয়াল নিয়ম সারায় না।
কোনো নিয়মে হাত দেওয়ার আগে তিনটি জিনিস এক পাতায় রাখুন: point-to-site পুল, ভার্চুয়াল নেটওয়ার্ক ঠিকানা স্পেস, এবং অন-প্রিমাইজেস রেঞ্জ। এগুলি ওভারল্যাপ করা চলবে না, আর পুলে প্রতিটি একসঙ্গে চলা ক্লায়েন্টের জন্য জায়গা দরকার এবং পুনঃসংযোগের জন্য কিছু মার্জিন।
তারপর এই ক্রমে চক্রটি বন্ধ করুন:
- দুটি মেশিন থেকে উভয় ক্রমে সংযোগ করে ঠিকানাগুলো মেলান; যদি তারা বদলাতে পারে, তবে ঠিকানা-ভিত্তিক কোনো নিয়ম নিরাপদ নয়।
- গেটওয়ে Virtual WAN কি না দেখুন; যদি হয়, প্রতি-ঠিকানা নিয়মের বদলে গ্রুপ পুল ব্যবহার করুন।
- জিজ্ঞাসা করুন কোনো নিয়ম ভুল ব্যক্তির সঙ্গে মিললে কী হয়; উত্তর যদি অ্যাক্সেস-সংক্রান্ত ঘটনা হয়, তবে নিয়ন্ত্রণ পরিচয়ের কাছে সরান।
- কোন রেঞ্জ কোন গ্রুপের, তা NSG সংজ্ঞার একই ভাণ্ডারে লিখে রাখুন।
- পুল, প্রমাণীকরণ বা গেটওয়ে পরিবর্তনের পরে আবার পরীক্ষা করুন, কারণ সেই পরিবর্তনগুলি না জানিয়েই ম্যাপিংটি নতুন করে লেখে।