VPN-এর ডেডিকেটেড ঠিকানায় আসলে কে উত্তর দেয়?

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

ঠিকানার পেছনের প্যাকেট পথ

পিয়ার যে ঠিকানা পেয়েছে সেখানে IKE পাঠায়, UDP 500-এ, অথবা NAT ট্রাভার্সাল চালু থাকলে UDP 4500-এ। পথে ওই ঠিকানার মালিক যে ডিভাইসই হোক, সে হয় ডেটাগ্রামটি স্থানীয়ভাবে গ্রহণ করে উত্তর দেয়, নয়তো তা অন্যত্র ফরওয়ার্ড করে। এটিই একমাত্র দুটি সম্ভাবনা, আর এই নিবন্ধের বাকি সবকিছু নির্ভর করে কোনটি সত্য তার ওপর।

স্থানীয়ভাবে গ্রহণ মানে ওই ডিভাইসে ওই ঠিকানায় বাঁধা একটি সকেট আছে। ফরওয়ার্ড করা মানে ডেটাগ্রামটি পুনর্লিখিত হয়ে অন্য একটি প্রান্তবিন্দুতে পাঠানো হয়, যার কাছে তখন সকেটটি থাকে। UDP 500 অনুমোদনকারী ফায়ারওয়াল নিয়ম এই দুটির মধ্যে কোনটি ঘটছে সে সম্পর্কে আপনাকে কিছুই বলে না।

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

মডেল A: গেটওয়ে ঠিকানার মালিক

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

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

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

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

টোপোলজির অন্য কোথাও ইতিমধ্যে বিদ্যমান সাবনেটে দ্বিতীয় ইন্টারফেস বসিয়ে প্ল্যাটফর্ম ঠিক করে দেবে এমন ধরে নেবেন না। ওভারল্যাপিং ইন্টারফেস সাবনেট অস্পষ্ট উৎস নির্বাচন ঘটায় এবং অনেক প্ল্যাটফর্মে কনফিগার করতেই অস্বীকার করে।

মডেল B: আপস্ট্রিম ডিভাইস এটি অনুবাদ করে

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

এটি প্রমাণ নয় যে আপস্ট্রিম ডিভাইস স্থানীয় VPN সকেট পেয়েছে। অনুবাদ প্যাকেট ফরওয়ার্ড করে; এটি আপস্ট্রিম বাক্সকে IKE উত্তরদাতা বানায় না। আপস্ট্রিম নিয়ম সরানো হলে বা তার ফেরত পথ ভাঙলে VPN বন্ধ হয়ে যায়, যদিও গেটওয়ে সুস্থ এবং তার নিজের শ্রোতারা অক্ষত।

দুটি ঠিকানাই লিখুন: পিয়াররা যে ঠিকানায় যোগাযোগ করে এবং গেটওয়ে আসলে যা দেখে। তারপর পরিবহন ও ফেরত পথ লিখুন, কারণ UDP 500-এ কাজ করে কিন্তু এনক্যাপসুলেটেড ESP-এ কাজ করে না এমন অনুবাদ সংযোগ স্থাপন করবে, তারপর ট্রাফিক বহনে ব্যর্থ হবে, যা পরে ডিবাগ করার জন্য বিভ্রান্তিকর ব্যর্থতা।

পরিচয় বাইরের ঠিকানা নয়

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

প্রমাণিত পরিচয় আবার আলাদা। IKEv2 একটি পরিচয় পেলোড ও প্রমাণীকরণ বিনিময় বহন করে যার বাইরের প্যাকেট ঠিকানার সঙ্গে মিল থাকা আবশ্যক নয়, আর ঠিক এ কারণেই অনূদিত নকশা সঠিকভাবে প্রমাণীকরণ করতে পারে।

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

একটি সংযোগ দেখে নকশাটি গ্রহণ করুন

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

ঋণাত্মক ক্ষেত্রটিও রাখুন: যে পিয়ার গ্রহণ করা উচিত নয়, বা যে অভ্যন্তরীণ প্রিফিক্সে পৌঁছানো উচিত নয়, তা পরিবর্তনের পরে যাচাই করুন। শুরুতে লেখা রেকর্ডটিই স্মৃতি থেকে নকশা পুনর্গঠন না করে ওই পরীক্ষা সম্ভব করে।

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