Azure S2S VPN সংযুক্ত কিন্তু ট্রাফিক নেই: IKE লগ পড়ুন

পোর্টালে লেখা Connected, টানেলের একটি আপটাইম কাউন্টার আছে, আর আপনার ভার্চুয়াল মেশিন থেকে নেওয়া trace দ্বিতীয় হপেই মরে যায়। সংযোগের অবস্থা IKE ও IPsec আলোচনাকে বর্ণনা করে, দুই পাশের পলিসি স্তর পেরিয়ে একটি প্যাকেটও টিকে আছে কি না তা নয়। এসব টিকেটের বেশিরভাগের কারণ দুটি ত্রুটি, আর Azure রুট বদলে কোনোটিই সারানো যায় না। দুটোই গেটওয়ে যে লগ তৈরি করেছে তাতে আগেই লেখা আছে, তাই আমি রুট টেবিলের বদলে সেখান থেকেই শুরু করি।

Connected আসলে কী প্রমাণ করে

একটি সংযুক্ত site-to-site সংযোগ মানে ফেজ 1 ও ফেজ 2 সম্পন্ন এবং সিকিউরিটি অ্যাসোসিয়েশনগুলো সক্রিয়। এটি আলোচনা সম্পর্কে একটি বক্তব্য: দুই পিয়ার একটি প্রস্তাবে একমত হয়েছে, কী বিনিময় করেছে এবং SA জোড়া ইনস্টল করেছে। আপনি যে সাবনেটগুলো সুরক্ষিত মনে করেন তার সঙ্গে ট্রাফিক সিলেক্টর মেলে কি না, কিংবা ডিক্রিপ্ট করার পর দূর পাশ প্যাকেটটি কোথাও রুট করবে কি না, সে সম্পর্কে এটি কিছুই বলে না। সপ্তাহের পর সপ্তাহ একটি টানেল চালু থাকতে পারে অথচ প্রতিটি গুরুত্বপূর্ণ ফ্লো ফেলে দিতে পারে, আর ঠিক এই ধরনের ঘটনাই মানুষকে সুস্থ গেটওয়ে নতুন করে বানাতে বাধ্য করে।

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

রুটে হাত দেওয়ার আগে এক্সপোর্ট করা লগ খুলুন

পোর্টালে ভার্চুয়াল নেটওয়ার্ক গেটওয়ে খুলে সংযোগটির উপর VPN troubleshoot চালান, তারপর যে বান্ডেল তৈরি হয় তা ডাউনলোড করে আনপ্যাক করুন। ভেতরে ফেজ 1 ও ফেজ 2 বিনিময়সহ একটি IKE লগ আছে, টাইমস্ট্যাম্প দেওয়া এবং সাধারণ টেক্সট হিসেবে পড়ার যোগ্য। উপর থেকে নিচে পড়ার বদলে এতে transform লাইনটি খুঁজুন, কারণ গুরুত্বপূর্ণ এন্ট্রিটি সাধারণত কয়েকশ লাইন পরে থাকে। পোর্টালে প্রবেশাধিকার না থাকলে ডায়াগনস্টিক সেটিংস চালু থাকা অবস্থায় একই ডায়াগনস্টিকস গেটওয়ের লগ গন্তব্যে দেখা যায়।

দুটি এন্ট্রি বেশিরভাগ মূল্য বহন করে। প্রথমটি প্রায় এমন: expected ESP with combined authentication and cipher, received AH. দ্বিতীয়টি IKE বিনিময়ের সময় invalid payload ত্রুটি, যার মানে সাধারণত ভুল গঠনের বা অসমর্থিত প্রস্তাব ফিল্ড।

দুটোই বর্ণনা করে অন-প্রিমাইজ ডিভাইস কী প্রস্তাব দিয়েছে, তাই দুটোই পিয়ার-পাশের সেটিং। সংযোগের Azure পাশ নতুন করে তৈরি করলে আপনার ফায়ারওয়াল যে প্রস্তাব পাঠায় তা বদলায় না, আর তা করাই এই কাজে সবচেয়ে বেশি নষ্ট হওয়া ঘণ্টা। পিয়ারে ফেজ 2-কে সম্মিলিত অথেন্টিকেশন ও সাইফারসহ ESP-তে সেট করুন এবং অ্যালগরিদম আলোচনা করতে দিন, তারপর দেখুন combined mode-এর মতো নামের কোনো ভেন্ডর চেকবক্স নিচে থেকে নীরবে AH প্রস্তাব বেছে নিচ্ছে কি না।

ভার্চুয়াল নেটওয়ার্কের অ্যাড্রেস স্পেস নিশ্চিত করুন

গেটওয়ে আশা করে ভার্চুয়াল নেটওয়ার্ক প্রাইভেট রেঞ্জে থাকবে। পাবলিক ব্লকে নম্বর দেওয়া নেটওয়ার্ক, যেমন 111.x দিয়ে শুরু হওয়া, টানেল তুলতে পারে অথচ Azure সেই স্পেসকে অভ্যন্তরীণ হিসেবে ধরতে অস্বীকার করে, ফলে সংযোগ সুস্থ দেখায় আর কোনো ফ্লো গ্রহণ করা হয় না। সিলেক্টর নিয়ে দুপুর নষ্ট করার আগে অ্যাড্রেস স্পেস নিশ্চিত করুন। নম্বরায়ন যদি পুরোনো বরাদ্দ থেকে আসা কঠিন শর্ত হয়, তবে সমাধান ভিন্ন গেটওয়ে নয়, অ্যাড্রেস প্ল্যান বদলানো।

অ্যাড্রেস স্পেস ব্লেডে থাকার সময়েই অন-প্রিমাইজ রেঞ্জগুলোর সঙ্গে ওভারল্যাপ লিখে রাখুন, কারণ ওভারল্যাপিং প্রিফিক্স ভিন্ন ধরনের ব্যর্থতা তৈরি করে যা ক্লায়েন্টের দিক থেকে একই রকম দেখায়।

দুই দিকেই প্রিফিক্স যাচাই করুন

লোকাল নেটওয়ার্ক গেটওয়ে রিসোর্স অন-প্রিমাইজ প্রিফিক্সগুলো ধরে রাখে, আর সেগুলোকে দূরের ডিভাইস সত্যিই যে সাবনেট সুরক্ষিত করে তার সঙ্গে মিলতে হবে। ডিভাইস যে ঠিকানাগুলো ফেলে দেয় সেগুলোসহ একটি সারাংশ কিছু ফ্লো পার করাবে আর কিছুতে ব্যর্থ হবে, যা কনফিগারেশন মিল না থাকার বদলে মাঝেমধ্যে হওয়া রাউটিং ত্রুটির মতো পড়া যায়। দূর পাশও দেখুন: এক প্রান্ত /16 তালিকা করছে আর অন্য প্রান্ত তার ভেতরে তিনটি /24 তালিকা করছে — এটাই চিরাচরিত আংশিক ব্যর্থতা। কোনো তালিকাই একা কর্তৃত্বপূর্ণ নয়, তাই যে তালিকা আপনি দেখতে পাচ্ছেন তাতে ভরসা না করে দুটো পাশাপাশি মিলিয়ে দেখুন।

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

ping নয়, পথ পরীক্ষা করুন

কোন টানেল কাজ করছে আর কোন রুট কাজ করছে তা আলাদা করা trace দেখতে এমন: প্রথম হপ অন-প্রিমাইজ গেটওয়ে, তারপর কয়েকটি সাড়া না দেওয়া হপ, তারপর দূরের হোস্ট উত্তর দেয়। trace যদি কখনো হোস্টে না পৌঁছায়, অ্যাপ্লিকেশনটি সত্যিই যে TCP পোর্ট ব্যবহার করে তা পরীক্ষা করুন, কারণ ICMP যথেষ্ট নিয়মিত ফিল্টার হয় যে ব্যর্থ ping খুব কমই কিছু প্রমাণ করে। একই trace দূরের হোস্ট থেকে Azure-এর একটি ভার্চুয়াল মেশিনের দিকে চালান। দুই ফলাফলের মধ্যে অসামঞ্জস্যই অনুপস্থিত রিটার্ন রুট বা কেবল এক দিক অনুমোদনকারী নিয়ম খোঁজার দ্রুততম উপায়।

পিয়ার প্রস্তাব, দুই অ্যাড্রেস স্পেস এবং সংযোগ তৈরির সময় টিকেটে লিখুন, যাতে পরের ইঞ্জিনিয়ার জানেন কোন মানগুলো নতুন করে বানানো হয়েছে আর কোনগুলোয় হাতই দেওয়া হয়নি।

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