সিমেট্রিক NAT ও VPN: লেবেল নয়, ম্যাপিং যাচাই করুন
এন্ডপয়েন্ট-নির্ভর ম্যাপিং পিয়ার-টু-পিয়ার আবিষ্কারকে প্রভাবিত করে, সাধারণ ক্লায়েন্ট-থেকে-সার্ভার টানেলকে নয়। পোর্ট মাপুন, তারপর সরাসরি পথ ব্যর্থ হলে রিলে ব্যবহার করুন।
একটি সাপোর্ট থ্রেড “সিমেট্রিক NAT, এখানে VPN কাজ করবে না” রায়ে শেষ হয়, আর তারপর ক্লায়েন্টকে কোনো কারণ ছাড়াই তিনবার পুনরায় ইনস্টল করা হয়। লেবেলটি ক্ষতি করে কারণ এটি এমন প্রশ্নের উত্তর দেয় যা কেউ করেনি। যে ক্লায়েন্ট বাইরের দিকে একটি নির্দিষ্ট সার্ভারে সংযোগ করে, সে প্রথম প্যাকেট পাঠানোর মুহূর্তেই একটি ম্যাপিং তৈরি করে, এবং উত্তরটি ফিরে আসতে দেওয়া হয় এমন নিয়মে যা প্রায় প্রতিটি নেটওয়ার্ক প্রয়োগ করে। এন্ডপয়েন্ট-নির্ভর ম্যাপিং আসলে যা জটিল করে তা হলো দুটি পিয়ারের একই সময়ে একে অপরের কাছে পৌঁছানোর চেষ্টা, এবং সেটি ভিন্ন একটি পরীক্ষা।
একটি লেবেলের পেছনে দুটি প্রশ্ন লুকিয়ে আছে
প্রথম প্রশ্ন হলো এই নেটওয়ার্কের পেছনের কোনো হোস্ট পরিচিত পাবলিক ঠিকানা ও পোর্টে সেশন খুলতে পারে কি না। টানেল ক্লায়েন্টের জন্য এটি স্বাভাবিক ঘটনা, এবং উত্তর প্রায় সবসময়ই হ্যাঁ। রাউটার অভ্যন্তরীণ উৎস লিপিবদ্ধ করে, একটি বাহ্যিক পোর্ট বরাদ্দ করে, এবং উত্তরটি যেতে দেয় কারণ এটি ভেতর থেকে শুরু হওয়া একটি সেশনের অন্তর্গত।
দ্বিতীয় প্রশ্ন হলো ভিন্ন ভিন্ন নেটওয়ার্কের পেছনের দুটি হোস্ট মাঝখানে সার্ভার ছাড়া কোনো সাধারণ পথ আবিষ্কার করে একে অপরকে পাঠাতে পারে কি না। এটি নির্ভর করে প্রতিটি নেটওয়ার্ক কীভাবে সেই বাহ্যিক পোর্টগুলো বরাদ্দ করে তার উপর, এবং ম্যাপিংয়ের আচরণের গুরুত্ব কেবল এখানেই।
দুটিকে মিশিয়ে ফেললে সেই চিরাচরিত ভুল নির্ণয় তৈরি হয়: কোনো পিয়ার-টু-পিয়ার বৈশিষ্ট্য ব্যর্থ হয়, কেউ একটি NAT-ধরনের পরীক্ষা চালায়, সবচেয়ে খারাপ শ্রেণি দেখে, এবং সিদ্ধান্ত নেয় সাধারণ টানেলও কাজ করতে পারে না। ব্যর্থ হওয়া জিনিসটি কখনোই টানেল ছিল না।
ম্যাপিং ও ফিল্টারিং আলাদা দুটি ধর্ম
RFC-এর পরিভাষা বিক্রেতাদের ব্যবহৃত নামের চেয়ে বেশি নিখুঁত, এবং এটি টিকিটে নিয়ে যাওয়া উচিত কারণ এটি বিতর্ক নিষ্পত্তি করে। ম্যাপিং হলো বাহ্যিক পোর্ট কীভাবে বরাদ্দ হয় তা। ফিল্টারিং হলো কোন আগত প্যাকেটগুলোকে যেতে দেওয়া হয় তা। একটি নেটওয়ার্ক একটিতে কঠোর ও অন্যটিতে উদার হতে পারে, এবং এই সমন্বয়টাই সেই জিনিস যা একটি পিয়ার-টু-পিয়ার প্রোটোকলকে টিকে থাকতে হয়।
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
তৃতীয় সারিটি হলো যাকে বেশিরভাগ ভোক্তা রাউটার ও মোবাইল অপারেটর সিমেট্রিক বলে বোঝায়। লক্ষ করুন লেবেলটি কেবল বরাদ্দের বর্ণনা দেয়। এমন ম্যাপিং ও উদার ফিল্টারিংয়ের নেটওয়ার্ক এখনো সেই পোর্টে আগত প্যাকেট গ্রহণ করতে পারে যা সে এইমাত্র বরাদ্দ করেছে, তাই হোল-পাঞ্চিং কয়েকটিতে সফল হয় আর কয়েকটিতে ব্যর্থ।
ফিল্টারিংয়ের নিজস্ব তিনটি ঘটনা আছে এবং প্রতিটির জন্য নিজস্ব নাম আছে। টিকিটে “সিমেট্রিক NAT” লেখা যখন আপনি বোঝাচ্ছেন “ঠিকানা ও পোর্ট-নির্ভর ফিল্টারিং”, পরবর্তী ব্যক্তিকে ম্যানুয়ালের ভুল অধ্যায়ে পাঠায়। পরীক্ষায় দুটি ভিন্নভাবে আচরণ করে, তাই ভুলটি নিছক তাত্ত্বিক নয়।
ম্যাপিংয়ের নাম দেওয়ার বদলে তা মাপুন
আপনি যে কোনো UDP সেবার সার্ভার দিক থেকে বরাদ্দকৃত পোর্ট সরাসরি পর্যবেক্ষণ করতে পারেন। পাবলিক হোস্টে ক্যাপচার শুরু করুন, ক্লায়েন্ট থেকে পাঠান, এবং প্যাকেট যে উৎস পোর্ট নিয়ে এসেছে তা পড়ুন:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820এন্ডপয়েন্ট লাইনটি তিনটির মধ্যে সবচেয়ে উপকারী, কারণ WireGuard প্রতিটি পিয়ার থেকে পাওয়া শেষ ঠিকানা ও পোর্ট লিপিবদ্ধ করে। সেই পোর্টটিকে ক্লায়েন্ট যে পোর্ট ব্যবহার করছে বলে মনে করে তার সঙ্গে তুলনা করুন। যখনই কোনো অনুবাদ ঘটছে তারা আলাদা হবে, এবং গুরুত্বপূর্ণ প্রশ্ন হলো মানটি স্থির থাকে কি না।
দ্বিতীয় গন্তব্য পোর্ট বা দ্বিতীয় সার্ভারের বিপরীতে পর্যবেক্ষণটি পুনরাবৃত্তি করুন এবং আবার তুলনা করুন। যদি বাহ্যিক পোর্ট গন্তব্য অনুযায়ী বদলায়, তবে ম্যাপিং ঠিকানা ও পোর্ট-নির্ভর। যদি এটি একই থাকে, নেটওয়ার্ক আপনাকে একটি ম্যাপিং দেয় এবং আবিষ্কারের সুযোগ থাকে।
STUN-ভিত্তিক সরঞ্জাম এক ধাপেই একই শ্রেণিবিন্যাস জানায়, এবং যখন নেটওয়ার্ক কোনো পাবলিক STUN সার্ভারে বহির্গামী UDP অনুমোদন করে তখন সেগুলো ব্যবহার করা ঠিক। যখন অনুমোদন করে না, উপরের ক্যাপচার পদ্ধতি তখনো কাজ করে এবং আপনার নিয়ন্ত্রণে থাকা একটি হোস্ট ছাড়া আর কিছুই দরকার হয় না।
ব্যর্থতার সঙ্গে মেলে এমন সমাধান বেছে নিন
যদি ব্যর্থ বৈশিষ্ট্যটি পিয়ার-টু-পিয়ার হয়, তবে সমর্থিত উত্তরগুলো হলো রিলে, উভয় পিয়ার যে মিলন সেবায় পৌঁছাতে পারে, বা ভিন্ন টোপোলজি। TURN ঠিক এজন্যই আছে, এবং যে পণ্য নিজের রিলে সরবরাহ করে সে আপনাকে বলছে যে সে কিছু নেটওয়ার্কের শত্রুতাপূর্ণ আচরণ আশা করে।
যদি ব্যর্থ বৈশিষ্ট্যটি সাধারণ টানেল হয়, ম্যাপিংয়ের আচরণ আপনার সমস্যা নয় এবং উপরের কোনোটিই প্রযোজ্য নয়। যাচাই করুন ক্লায়েন্ট সত্যিই পাঠাচ্ছে, সার্ভার প্যাকেট দেখছে, এবং উত্তর ফিরে আসছে। সেই ক্রমটি তিনটি পর্যবেক্ষণ এবং এতে রাউটারের NAT শ্রেণি সম্পর্কে কিছু জানার দরকার নেই।
যা কাজ করে না তা হলো কিছু সংযুক্ত হওয়ার আগ পর্যন্ত স্থানীয় পোর্ট বদলাতে থাকা। ক্লায়েন্টের উৎস পোর্ট বদলালে নেটওয়ার্ক কীভাবে ম্যাপিং বরাদ্দ করে তা বদলায় না। পঞ্চম চেষ্টায় আকস্মিক সাফল্য একটি মিথ্যা ধনাত্মক, এবং মাসের পর মাস এটি সমাধান হিসেবে উদ্ধৃত হবে।
রায় নয়, স্থাপত্য লিপিবদ্ধ করুন
একটি উপকারী টীকা বলে কোন প্রোটোকল, কোন দিকে সেশন শুরু হয়, পথে রিলে আছে কি না, এবং তারে কী পর্যবেক্ষণ করা হয়েছে। “সিমেট্রিক NAT, কাজ করে না” অব্যবহারযোগ্য, কারণ এটি একই সঙ্গে টানেল সম্পর্কে ভুল এবং পিয়ারের পথ সম্পর্কে কোনো তথ্য দেয় না।
আপনি যদি সেগুলো পরীক্ষা করে থাকেন তবে মাপা পোর্ট স্থিরতা ও ফিল্টারিংয়ের আচরণ অন্তর্ভুক্ত করুন। এই দুটি তথ্য অন্য কাউকে পূর্বাভাস দিতে দেয় যে কোনো নতুন বৈশিষ্ট্য ওই নেটওয়ার্কে কাজ করবে কি না, পুরো তদন্ত পুনরাবৃত্তি না করেই। প্রতিটি সহায়তা পাতায় সামান্য ভিন্ন অর্থ বহন করা বিক্রেতা-শ্রেণির চেয়ে এগুলো বুড়িয়েও ভালো হয়।
শেষে, এটি লেখার সময় RFC 4787-এর পরিভাষা হাতের কাছে রাখুন। সুনির্দিষ্ট পরিভাষা ব্যবহারে একটি বাক্যের খরচ, আর তা পরবর্তী পাঠককে একই ভুল নির্ণয় পুনরাবৃত্তি থেকে বিরত রাখে, এবং টীকাটি লেখার পুরো উদ্দেশ্যই তা।