VPN চালু হওয়ার পর Azure VM IMDS বা WireServer-এ পৌঁছাতে পারে না

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

উপসর্গটি ভাঙা এজেন্টের মতো দেখায়

নিচের দুটি ঠিকানাই সমাধান হিসেবে প্রস্তাব করা হয়, অথচ তারা একই সেবা নয়। একটির জন্য /32 কপি করা কারণ সেটি অন্যটির জন্য কাজ করেছিল—এভাবেই সাময়িক উপায় এমন স্থায়ী কনফিগারেশন হয়ে যায় যা কেউ সরাতে সাহস করে না।

যে ক্রমটি কাজ করে তা হলো: ব্যর্থ কলটি আসলে কোন ঠিকানায় যাচ্ছে তা নিশ্চিত করুন, তারপর গেস্ট কীভাবে সেটি রিজলভ করে তা পড়ুন। এর বাইরে সবই বাড়তি ধাপ ও দীর্ঘতর পরিবর্তন উইন্ডোসহ অনুমান।

168.63.129.16 কোনো পাবলিক গন্তব্য নয়

168.63.129.16 হলো Azure-এর বিশেষ ভার্চুয়াল প্ল্যাটফর্ম ঠিকানা, এবং এর একটি ভূমিকা WireServer, যা VM এজেন্ট ফ্যাব্রিকের সঙ্গে কথা বলতে ব্যবহার করে। Microsoft ডকুমেন্ট করে যে TCP পোর্ট 80 এবং 32526-এ এজেন্টের ট্রাফিক উপলব্ধ থাকতে হবে। এটি সাধারণ ইন্টারনেট হোস্ট নয়, এবং পূর্ণ-টানেল VPN-এর উচিত এটি দূরবর্তী এক্সিটে বহন করা নয়। তাই দেখতে সুস্থ একটি টানেলও এজেন্টকে খাদ্যহীন করে দিতে পারে।

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

যদি এজেন্টই সমস্যার কথা জানায়, তবে কিছু পুনঃইনস্টল করার আগে সেবার অবস্থা এবং ওই ঠিকানার পথ পরীক্ষা করুন।

169.254.169.254-এর নিজস্ব নিয়ম আছে

169.254.169.254 হলো Azure Instance Metadata Service-এর link-local ঠিকানা। এর প্রতি অনুরোধের নিজস্ব শর্ত আছে: প্রাথমিক NIC ও প্রাথমিক IP, ঠিকানাটি সমর্থনকারী DHCP কনফিগারেশন, এবং যেকোনো HTTP প্রক্সি বাইপাস। দূরবর্তী VPN এক্সিট বা ইচ্ছামতো ইন্টারনেট গেটওয়ে দিয়ে সেগুলো পাঠানো Microsoft-এর বর্ণিত অ্যাক্সেস মডেল নয়।

এই প্রক্সি শর্তটি তাদের ধরে যারা রুট ঠিক করেছে তবুও ব্যর্থতা দেখে। গেস্ট HTTP প্রক্সি IMDS ভাঙতে পারে, অথচ ip route get ঠিক আপনার প্রত্যাশিত ইন্টারফেসই ফেরত দেয়, তাই রুটের পাশাপাশি প্রক্সি বাদ দেওয়ার তালিকাও দেখুন।

এটি ডিবাগ করার সময় মেটাডেটা উত্তর সাপোর্ট টিকিটে পেস্ট করবেন না। সেগুলোতে এমন ক্রেডেনশিয়াল ও ইনস্ট্যান্স বিবরণ থাকতে পারে যা ঘটনার চেয়ে বেশি দিন টিকে থাকে।

গেস্টের পলিসি রাউটিং পড়ুন, শুধু মেইন টেবিল নয়

Linux গেস্টে তিনটি রিড-ওনলি কমান্ড স্তরগুলো আলাদা করে: পলিসি নিয়মের জন্য ip -4 rule show, তারপর কার্নেল আসলে যে সিদ্ধান্ত নেয় তার জন্য ip -4 route get 168.63.129.16 এবং ip -4 route get 169.254.169.254। VPN সংযুক্ত হওয়ার আগে ও পরে সেগুলো চালান। ওই দুটি আউটপুটের পার্থক্যই আপনার পরিবর্তন-সেট, এবং ক্লায়েন্ট কী করেছে তা নিয়ে যেকোনো অনুমানের চেয়ে এটি বেশি কাজে দেয়।

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

পুরনো গেটওয়ে দিয়ে দুটি /32 রুটই যোগ করার রেসিপির বিরুদ্ধে দাঁড়ান। Link-local প্ল্যাটফর্ম পথ আর সাধারণ WAN নেক্সট হপ আলাদা বস্তু, এবং সর্বজনীন ব্যতিক্রম আসল পলিসি সংঘর্ষ লুকিয়ে রাখে।

প্রশাসন ও পুনরুদ্ধার আলাদা রাখুন

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

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

অনুমোদিত ব্যতিক্রমটি গেস্ট নেটওয়ার্ক ও VPN কনফিগারেশনের মালিকের অধীনে লিখুন, পুনঃসংযোগ ও রিস্টার্টে কী ঘটবে তা সহ। Azure UDR গেস্টের রুট টেবিল নয়, এবং সেগুলো সম্পাদনা করলে স্থানীয় পলিসি নিয়ম ঠিক হবে না।