Azure IP ফ্লো ভেরিফাই বলছে অনুমোদিত, তবুও VPN ব্যর্থ হচ্ছে

সাইট-টু-সাইট টানেল সংযুক্ত, VM সুস্থ, কিন্তু অন-প্রিমাইজ ক্লায়েন্ট কিছুই পাচ্ছে না। আপনি Network Watcher খুলে IP ফ্লো ভেরিফাই চালান, এটি বলে Access allowed, তাই টিকিটটি VPN সমস্যা হিসেবে বন্ধ হয়ে যায়। এই ফলাফল দেখতে যা মনে হয় তা নয়, কারণ IP ফ্লো ভেরিফাই আপনার বর্ণিত ফ্লোর নিরাপত্তা নিয়মগুলি মূল্যায়ন করে এবং Azure-এর আপনার অন-প্রিমাইজ প্রিফিক্সে কোনো রুট আছে কি না তা কখনও পরীক্ষা করে না।

ফিল্টারিং প্রশ্ন ও রাউটিং প্রশ্ন আলাদা, এবং Network Watcher ভিন্ন ভিন্ন টুল দিয়ে এদের উত্তর দেয়। আপনি কোনটি জিজ্ঞাসা করেছেন তা জানাই ডায়াগনোসিসের বড় অংশ।

IP ফ্লো ভেরিফাই আসলে কী নির্ধারণ করে

IP ফ্লো ভেরিফাই একটি VM, একটি নেটওয়ার্ক ইন্টারফেস, একটি দিক, পঞ্চ-টুপল মান ও একটি প্রোটোকল নেয়, তারপর সেই ফ্লোর জন্য NSG ও সিকিউরিটি-অ্যাডমিন নিয়মের সিদ্ধান্ত জানায়। এটি TCP ও UDP-তে কাজ করে, তাই এটি ICMP নিয়ম পরীক্ষক নয় এবং ব্লক করা ping আপনার সার্ভিস সম্পর্কে কিছুই প্রমাণ করে না। অনুমানের বদলে এটিকে আসল ফ্লো দিন। অন-প্রিমাইজ থেকে ডেটাবেস পোর্টে ইনবাউন্ড সংযোগ, VM যে আউটবাউন্ড সংযোগ শুরু করে তার চেয়ে ভিন্ন বর্ণনা।

গেটওয়ে ঠিকানা অনুবাদ করলে, আপনি যে সীমা মূল্যায়ন করছেন সেখানে পৌঁছানো সোর্স ঠিকানা ব্যবহার করুন, ক্লায়েন্ট কনফিগে থাকাটি নয়। ফলাফলকেও যেমন আছে তেমন পড়ুন। Access allowed মানে ফিল্টার স্তর প্যাকেটটি এলে অনুমতি দিত, আর কিছু নয়।

এটি আপনাকে যা বলতে পারে না তা হলো Azure কোন রুট নির্বাচন করেছে, গেস্ট ফায়ারওয়াল পোর্টটি অনুমোদন করে কি না, বা কিছু শুনছে কি না। সেগুলি অন্য স্তরে থাকে।

নেক্সট হপ ও কার্যকর রুট কী যোগ করে

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

Microsoft-এর IP ফ্লো ভেরিফাই ওভারভিউ সরাসরি ফিল্টারিং পরিসর উল্লেখ করে, আর নেক্সট-হপ ও রুট-ডায়াগনোসিস পাতাগুলি ফরওয়ার্ডিং দিকটি কভার করে। ফলাফল লিখার সময় সঠিক পাতাটি উদ্ধৃত করুন।

কমান্ডগুলি শেল থেকে চালানোর জন্য যথেষ্ট ছোট। az network nic show-effective-route-table ইন্টারফেসে প্রযোজ্য রুটগুলি তালিকাভুক্ত করে। az network watcher show-next-hop সোর্স ও গন্তব্য দিলে নির্বাচিত হপ ফেরত দেয়। আপনার প্রয়োজনীয় প্রিফিক্সকে সেই টেবিলের সঙ্গে মিলিয়ে দেখুন, তারপর কোন এন্ট্রি জেতে তা নিশ্চিত করুন।

VM NIC থেকে ফেরার পথ হাঁটুন

এটি লক্ষ্য VM-এর NIC থেকে, অন-প্রিমাইজ ক্লায়েন্ট প্রিফিক্সের জন্য করুন, ইন্টারনেটের জন্য নয়। ফেরার পথেই সাইট-টু-সাইট ত্রুটি লুকিয়ে থাকে, কারণ টানেল-স্ট্যাটাস পরীক্ষা কেবল জানায় যে সিকিউরিটি অ্যাসোসিয়েশনগুলি চালু আছে।

প্রত্যাশিত রুট না থাকলে, গেটওয়ে কনফিগারেশন যে রিমোট প্রিফিক্স দেয়, VNet সংযোগের নকশা এবং যেকোনো রুট-প্রচার সেটিং দেখুন। লোকাল নেটওয়ার্ক গেটওয়ে অবজেক্ট অন-প্রিমাইজ দিক বর্ণনা করে; এর অস্তিত্ব প্রমাণ করে না যে প্রতিটি প্রয়োজনীয় প্রিফিক্স NIC-এ আছে ও অগ্রাধিকার পাচ্ছে। এগুলি আলাদা তথ্য, এবং পোর্টাল সারাংশে এর একটিই দেখা যায়।

উদাহরণ কপি না করে নেক্সট-হপ ধরন পড়ুন

ম্যানেজড VPN গেটওয়ে পথ সাধারণত নেক্সট-হপ ধরন হিসেবে VirtualNetworkGateway দেখায়। VirtualAppliance ভিন্ন ফরওয়ার্ডিং নকশা বর্ণনা করে, সাধারণত একটি ফায়ারওয়াল বা নেটওয়ার্ক ভার্চুয়াল অ্যাপ্লায়েন্স।

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

যে সীমা এখনও ব্যর্থ হচ্ছে সেখানে যান

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

অনুমোদিত একটি অ্যাপ্লিকেশন অনুরোধ ও দুই প্রান্তের পর্যবেক্ষণ দিয়ে শেষ করুন। একটি allow ফলাফল ও সঠিক নেক্সট হপ দুটি প্রমাণের টুকরো, সংযোগ সফল হয়েছে তার প্রমাণ নয়।