NAT-এর পিছনে পিয়ার সহ Azure সাইট-টু-সাইট VPN: চেকলিস্ট

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

ধাপ 1: পিয়ার আদৌ NAT-এর পিছনে আছে কি না নিশ্চিত করুন

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

যদি দুটি ঠিকানা মিলে যায়, এখানেই থামুন: NAT আপনার সমস্যা নয় এবং এই তালিকার বাকিটা কাজে আসবে না।

টিকিটে দুটি ঠিকানা আর অনুবাদকের মডেল লিখে রাখুন। ওই এক লাইনই পরের দফায় কেন কনফিগার করা পিয়ার উত্তর দেয় না সেই প্রশ্ন আটকে দেয়।

ধাপ 2: কে শুরু করবে তা ঠিক করুন

Azure VPN Gateway FAQ NAT-T সমর্থনের কথা বলে এবং যোগ করে যে অন-প্রিমাইজ ডিভাইস NAT-এর পিছনে থাকলে তারই IPsec টানেল শুরু করা উচিত। এটি স্টেটফুল অনুবাদ যেভাবে কাজ করে তার সঙ্গে মেলে, কারণ ভেতরের ডিভাইস প্রথম প্যাকেট পাঠানোর কারণেই অনুবাদক ম্যাপিং ধরে রাখে। যদি Azure-র শুরু করার কথা থাকে আর সেই ম্যাপিং তৈরি করার মতো কিছু না আসে, টানেল কখনোই শুরু হয় না।

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

ম্যানুয়াল শুরুর সময় ডিভাইসে IKE বিনিময় দেখুন; সেখানে নীরবতা মানে রাউটিং বা ফায়ারওয়ালের উত্তর, Azure-র উত্তর নয়।

ধাপ 3: পিয়ারের ঠিকানা ঠিকভাবে দিন

Azure-র লোকাল নেটওয়ার্ক গেটওয়ে অবজেক্টে পিয়ারের জন্য একটি পৌঁছানোযোগ্য পাবলিক ঠিকানা দরকার, সাধারণত ডিভাইসের ভেতরের ঠিকানা নয়, অনুবাদকের পাবলিক ঠিকানা। ডিভাইস যে পরিচয় দিয়ে প্রমাণ করে সেটি আলাদা ক্ষেত্র এবং Azure যে ঠিকানায় ডায়াল করে তার থেকে বৈধভাবে আলাদা হতে পারে। দুটোকে সোজা রাখুন, কারণ এগুলো অদলবদল করলে এমন প্রমাণীকরণ ব্যর্থতা হয় যা হুবহু NAT সমস্যার মতো দেখায়।

পাবলিক ঠিকানা বদলালে সেই অবজেক্টও তার সঙ্গে বদলাতে হবে। যে নাম পুরোনো ঠিকানায় রিজলভ হয়, সেটি হাতে হালনাগাদ করতে হয় এমন স্ট্যাটিক ঠিকানার চেয়েও খারাপ।

তিনটি মানই লিখে রাখুন: ডিভাইসের লোকাল ঠিকানা, অনূদিত পাবলিক ঠিকানা, কনফিগার করা পিয়ার পরিচয়।

ধাপ 4: NAT-T-এর যেসব পোর্ট দরকার কেবল সেগুলোই খুলুন

NAT-T UDP-র ভেতরে ESP বহন করে, এবং RFC 3948 সেই এনক্যাপসুলেশন বর্ণনা করে যেখানে পোর্ট 500-এ প্রাথমিক দরকষাকষির পরে পোর্ট 4500 ব্যবহৃত হয়। আপনার ফায়ারওয়াল ও অনুবাদক দুটোকেই বিনিময় এবং তার ফেরত ট্রাফিক অনুমোদন করতে হবে। অসম্পর্কিত একটি TCP পোর্ট খোলা এই পথ সম্পর্কে কিছুই প্রমাণ করে না, আর যে নিয়ম বাইরের ট্রাফিক অনুমোদন করে কিন্তু উত্তরে নয়, সেটিও ব্যর্থ হবে।

পিয়ার শুরু করলে এবং অনুবাদক স্টেট রাখলে স্ট্যাটিক ইনবাউন্ড পোর্ট ফরওয়ার্ড স্বয়ংক্রিয়ভাবে দরকার হয় না। এটি দরকার হয় যখন ম্যাপিং অস্থির হয় বা পথের কোনো কিছু স্টেট জোরালোভাবে মেয়াদোত্তীর্ণ করে।

অনুবাদকের দুই পাশে একবার ক্যাপচার করুন; এনক্যাপসুলেশনের পার্থক্য সঙ্গে সঙ্গেই চোখে পড়বে।

ধাপ 5: বাইরের ট্রান্সপোর্টকে ভেতরের রাউটিং থেকে আলাদা করুন

যে টানেল তৈরি হয় কিন্তু কিছু বহন করে না, সেটি রাউটিং সমস্যা, NAT-T সমস্যা নয়। সাইটগুলোর এখনও সামঞ্জস্যপূর্ণ ট্রাফিক সিলেক্টর, মিলে যাওয়া ঠিকানা ক্ষেত্র, অ্যাক্সেস নিয়ম এবং অ্যাপ্লিকেশন নেটওয়ার্কের জন্য ফেরত পথ দরকার। সফল IKE বিনিময়ের মাধ্যমে এর কোনোটিই আসে না।

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

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