Azure P2S VPN-এ ফিরতি ট্রাফিক কেবল এক দিকেই কাজ করে

টানেল আইকন সবুজ, NSG অনুমতিশীল দেখাচ্ছে, কার্যকর রুটগুলো ঠিক দেখাচ্ছে, তবুও VM সংযুক্ত ক্লায়েন্টের দিকে ফিরে একটি সংযোগ খুলতে পারছে না। স্বাভাবিক অনুমান হলো, কাজ করা point-to-site টানেল প্রতিসম: ক্লায়েন্ট যদি VM-এ পৌঁছায়, VM-ও ক্লায়েন্টে পৌঁছাবে। এই অনুমানটাই যুক্তির ভুল, কনফিগারেশনের নয়। একটি টানেল অনুরোধহীন প্রবাহের এক দিক বহন করে অন্যটি ফেলে দিতে পারে, আর সমাধান নির্ভর করে কোন স্তর এটি ফেলে দিচ্ছে তার উপর।

ভ্রান্ত ধারণা: সংযুক্ত টানেল মানেই দ্বিমুখী টানেল

VPN টানেল তার নয়, নীতি-পথ। প্রতিটি দিক সিলেক্টর, রুট ও ফিল্টারের সঙ্গে মেলানো হয়, এবং এদের যেকোনোটি এক দিক অনুমোদন করে অন্যটি আটকে দিতে পারে।

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

পৌঁছানোযোগ্যতা পরীক্ষা করার আগে দিক পরীক্ষা করুন

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

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

IKEv2 point-to-site ফিরতি পথই সাধারণ সন্দেহভাজন

এই নিবন্ধের পেছনের Azure প্রতিবেদনে, একটি ক্লায়েন্ট IKEv2-এর মাধ্যমে VM-এ পৌঁছাত, কিন্তু VM থেকে ক্লায়েন্টে ইনবাউন্ড ICMP ব্যর্থ হচ্ছিল যতক্ষণ না গেটওয়ের টানেল ধরন OpenVPN-এ বদলানো হয়। প্রতিবেদনকারী জানান, Microsoft IKEv2 point-to-site পথে একটি সীমাবদ্ধতা নিশ্চিত করেছে, যেখানে ক্লায়েন্ট সেশন শুরু না করলে VM থেকে ক্লায়েন্টে ফিরতি ট্রাফিক প্রতিসমভাবে রুট হয় না। IKEv2 ট্রাফিক সিলেক্টরের উপর নির্ভর করে, এবং গেটওয়ে সেই ক্ষেত্রে ফিরতি দিকটি মানেনি।

এতে OpenVPN সাধারণভাবে ভালো টানেল ধরন হয়ে যায় না। এতে এই কাজের চাপের জন্য পরীক্ষার ম্যাট্রিক্সে টানেল ধরন একটি চলক হয়ে যায়।

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

ভ্রান্ত ধারণা: ব্রডকাস্ট ডিসকভারি VNet সীমা অতিক্রম করে

দ্বিতীয় অনুমানটি অসম্পর্কিত কারণে ব্যর্থ হয়। Azure ভার্চুয়াল নেটওয়ার্ক ব্রডকাস্ট ট্রাফিক বহন করে না, তাই VM site-to-site বা point-to-site সংযোগে অন-প্রিমাইজ নেটওয়ার্ক থেকে ব্রডকাস্ট ফ্রেম পেতে পারে না। যে অ্যাপ্লিকেশন ব্রডকাস্টে সহকর্মী খুঁজে পায়, যেমন পুরোনো ফাইল ব্রাউজিং বা কিছু ডিভাইস-ডিসকভারি প্রোটোকল, রুট যেভাবেই লেখা হোক, দূরের দিকটি কখনও দেখবে না।

ব্রডকাস্ট ডিসকভারি DNS নাম, ডিরেক্টরি পরিষেবা বা স্পষ্ট সহকর্মী-তালিকা দিয়ে প্রতিস্থাপন করুন। অ্যাপ্লিকেশনের unicast বিকল্প না থাকলে, ডিজাইনে আরও চওড়া টানেল নয়, ভিন্ন ডিসকভারি প্রক্রিয়া দরকার।

কী বদলাবেন, আর কীভাবে প্রমাণ করবেন

দিক-পরীক্ষা কেবল IKEv2-তে ব্যর্থ হলে, গেটওয়ের টানেল ধরন, ক্লায়েন্ট ঠিকানা পুল এবং সঠিক ICMP বা TCP পরীক্ষা লিপিবদ্ধ করুন, তারপর আক্রান্ত ক্লায়েন্টদের জন্য অনুমোদিত OpenVPN প্রোফাইল মূল্যায়ন করুন। সব টানেল ধরনেই ব্যর্থ হলে, ফিরতি পথ নিয়ে কাজ করুন: ক্লায়েন্ট ঠিকানা VM সাবনেট থেকে রুটযোগ্য হতে হবে, ব্যবহারকারী-নির্ধারিত যেকোনো রুট বৈধ পরবর্তী হপে নির্দেশ করতে হবে, এবং ক্লায়েন্ট ফায়ারওয়ালকে ইনবাউন্ড প্রবাহ গ্রহণ করতে হবে। NSG ও রুটের প্রমাণ টিকিটে সংযুক্ত করুন।

অ্যাপ্লিকেশন দিয়ে যাচাই করুন, ping দিয়ে নয়। পরিবর্তনের পর সফল ICMP বিনিময় সেবা পোর্ট, তার প্রমাণীকরণ বা নাম-রেজোলিউশন সম্পর্কে কিছুই বলে না। পুনঃসংযোগের পর পরীক্ষাটি পুনরাবৃত্তি করুন, কারণ ভিন্ন পুল ঠিকানা পাওয়া ক্লায়েন্ট ফলাফল বদলে দিতে পারে। তারপর ক্লায়েন্ট ঘুমিয়ে জেগে ওঠার পর আরেকবার পুনরাবৃত্তি করুন, কারণ পুনরায় শুরু হওয়া সেশনেই একমুখী আচরণ প্রায়ই ফিরে আসে।