স্থির UDP পোর্ট ফরওয়ার্ডিং এড়াতে পারে, কিন্তু প্রতিটি NAT নয়

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

ফায়ারওয়াল যে তুলনা করে

প্রতিটি বহির্গামী ডেটাগ্রাম একটি স্বল্পস্থায়ী এন্ট্রি তৈরি করে: উৎস ঠিকানা, উৎস পোর্ট, গন্তব্য ঠিকানা, গন্তব্য পোর্ট। এন্ট্রির সঙ্গে মেলে এমন যা কিছু আসে তা উত্তর হিসেবে ধরা হয় এবং পার হতে দেওয়া হয়। ইনবাউন্ড নিয়মগুলোর এতে কোনো ভূমিকা নেই।

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

স্থানীয় উৎস পোর্টটি স্থির করুন, আর একই নম্বরটি বিনিময়ের দুই দিকেই দেখা যাবে। এটাই পুরো প্রক্রিয়া, এবং এটাই ব্যাখ্যা করে কৌশলটি রহস্যময় নয় বরং ভঙ্গুর কেন।

প্রতিটি প্রান্তে একটি পোর্ট স্থির করা

OpenVPN-এর ডিফল্ট UDP পোর্ট হলো 1194, এবং lport যে উৎস পোর্ট থেকে এটি পাঠায় তা নির্ধারণ করে। দুই পিয়ারকেই স্থির করুন, তাহলে প্রত্যেকের বহির্গামী টুপল অন্য পক্ষ যে পোর্টে শুনছে সেদিকে নির্দেশ করবে:

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

এটি কেবল ততক্ষণ কাজ করে যতক্ষণ তাদের মাঝের কোনো রাউটার উৎস পোর্ট পুনর্লিখন না করে। ক্যাপচারে প্যাকেট দেখা গেল কিন্তু টানেল উঠল না, তাহলে পুনর্লিখনই প্রথম সন্দেহভাজন।

যেখানে টুপল আর মেলে না

যে NAT গন্তব্য অনুযায়ী ম্যাপ করে সে প্রতিটি পিয়ারকে আলাদা বাহ্যিক পোর্ট দেয়। আপনার পিয়ারকে যে ঠিকানা ব্যবহার করতে বলা হয়েছিল সেটি তার কাছে পৌঁছানো ঠিকানা নয়, তাই আগত প্যাকেটটি কিছুর সঙ্গে মেলে না এবং নীরবে বাদ পড়ে।

ক্যারিয়ার-গ্রেড অনুবাদ, স্তূপীকৃত NAT এবং পোর্ট র‍্যান্ডমাইজেশন—সবই একইভাবে শেষ হয়। ঠিকানাগুলো অপরিবর্তিত রেখে পোর্ট পুনর্লিখন করা যেকোনো মিডলবক্সও তাই।

স্ট্রিম ট্রান্সপোর্টের অবস্থা আরও খারাপ। TCP হ্যান্ডশেক ধাপে ধাপে অনুসরণ করা হয়, তাই TCP-ভিত্তিক VPN এভাবে আদৌ পাঞ্চ করা যায় না এবং পথের কোথাও একটি লিসেনার দরকার।

সাধারণত এক পক্ষ আগে ব্যর্থ হয়

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

প্রোফাইল স্পর্শ করার আগে খুঁজে বের করুন কোন পক্ষ প্যাকেটটি ফেলেছে। দুই প্রান্তের ক্যাপচার এক প্রচেষ্টাতেই এটি নিষ্পত্তি করে: যে ডেটাগ্রাম A ছেড়ে B-তে কখনো পৌঁছায় না তার মানে ফ্লোটি পথে পুনর্লিখিত হয়েছে, আর যে ডেটাগ্রাম B-তে পৌঁছে কোনো উত্তর ফেরে না তার মানে ফায়ারওয়াল সেগুলোকে সম্পর্কিত হিসেবে গ্রহণ করেনি।

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

কখন চেষ্টা বন্ধ করবেন

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

এর কোনোটিরই বন্ধ ফায়ারওয়াল দরকার নেই। সরাসরি সংযোগ জিততে সুরক্ষা বন্ধ করা সরাসরি প্রচেষ্টাকে আকর্ষণীয় করে তোলা কারণটি ফেলে দেয়, আর পরীক্ষার পুরো সময় মেশিনটি খোলা রেখে দেয়।

প্রথমে সরাসরি বিন্যাসটি চেষ্টা করুন, তারপর যা দেখলেন তা লিখে রাখুন। NAT-এর আচরণ এবং তা যে ক্যাপচারে ধরা পড়েছে, সেগুলো শেষে যে পোর্ট জোড়া ব্যবহার করলেন তার চেয়ে বেশি মূল্যবান, কারণ পরের নেটওয়ার্কটি ভিন্ন হবে। OpenVPN 2.6 ম্যানুয়াল নথিভুক্ত করে lport এবং এটি যে remote অপশনগুলোর ওপর নির্ভর করে।