আপনি কনফিগার করতে পারেন না এমন NAT-এর পেছনে VPN: কী এখনও কাজ করে

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

ম্যাপিং টেবিলই সবকিছু ঠিক করে

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

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

রেন্ডেজভু সার্ভিস কী করতে পারে আর কী পারে না

UDP হোল পাঞ্চিং ফিল্টারকে হারানোর বদলে বহির্গামী রেকর্ডকে একটি অস্থায়ী খোলার পথ হিসেবে ব্যবহার করে। উভয় পিয়ার একটি রেন্ডেজভু সার্ভিসের সঙ্গে যোগাযোগ করে, যা প্রতিটি পাবলিক এন্ডপয়েন্ট জেনে নেয় এবং অন্য পক্ষের এন্ডপয়েন্ট ফিরিয়ে জানায়। তারপর উভয়েই একে অপরের দিকে পাঠায়, আর প্রতিটি বহির্গামী প্যাকেট সেই রেকর্ড তৈরি বা সতেজ করে যা উত্তরটিকে ভেতরে ঢুকতে দেয়। ক্রমটাই এটি কাজ করায়, আর ক্রমটাই এটি ভঙ্গুর করে: যে পিয়ার অন্য পক্ষ তার রেকর্ড তৈরির আগেই পাঠায় সে কেবল বাদ পড়ে, অথচ এক মুহূর্ত পরে পুনরায় চেষ্টা সফল হয়। সার্ভিসটি নিজে কোনো VPN ট্রাফিক বহন করে না, তাই এর একমাত্র প্রভাব হলো যে সময়সূচি এটি সমন্বয় করে।

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

কিপঅ্যালাইভ, রিবুট এবং যে এন্ডপয়েন্ট সরে যায়

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

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

অনুপস্থিত ফরওয়ার্ড এড়ানোর তিন উপায়

প্রথম উপায় রাউটারকে নিজেই এন্ট্রি তৈরি করতে বলে, UPnP IGD, NAT-PMP বা PCP-এর মাধ্যমে, যখন ফিচারটি থাকে ও চালু থাকে। দ্বিতীয়টি ট্রাফিক পাবলিক ঠিকানাযুক্ত রিলেতে দেয়, যা সবসময় কাজ করে এবং সবসময় ব্যান্ডউইথের সঙ্গে ভিন্ন এক বিশ্বাস-সীমার খরচ নেয়। তৃতীয়টি দিক উল্টে দেয়: অভ্যন্তরীণ হোস্ট একটি পাবলিক সার্ভারের দিকে বহির্গামী টানেল খোলে এবং বাকি সবকিছু তার ভেতরে চড়ে।

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

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

রাউটারের মালিক কে তার সঙ্গে সমাধানটি মিলিয়ে নিন

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

আপনি যে পথে পৌঁছেছেন তা সরাসরি ছিল না রিলে হয়ে, তা লক্ষ্য করুন, কারণ এই একক তথ্যই লেটেন্সি ও ব্যর্থতার আচরণ দুটোই পূর্বানুমান করে। RFC 4787 এসবের নিচের ম্যাপিং আচরণের রেফারেন্স হিসেবে থাকে, আর এর ম্যাপিং অংশ পড়া তিনটি সমাধান পরপর পরীক্ষা করার চেয়ে দ্রুত। টেবিল আপনার বাছাই নিয়ে মাথা ঘামায় না; এটি কেবল লিপিবদ্ধ করে পরের প্যাকেট কী করতে পারবে।