প্রোটোকল 47 বনাম TCP পোর্ট 47: দুটি হেডার, দুটি নিয়ম
প্রোটোকল নম্বর ও পোর্ট আলাদা হেডারে থাকে, তাই একটি নিয়ম অন্যটির জায়গা নিতে পারে না। PPTP দুটিকে আলাদা করে, আর পোর্টের ঘর GRE প্রকাশ করতে পারে না।
হোটেলের নেটওয়ার্ক আর সম্মেলনের ফায়ারওয়ালে প্রায়ই একটি কাস্টম অনুমতি-বাক্স থাকে, আর কেউ সেখানে 47 লিখে দেয় এই ভেবে যে PPTP কাজ করবে। নিয়মটি তৈরি হয়, টানেল তবু ব্যর্থ হয়, আর পরের চেষ্টায় অন্য নম্বর ব্যবহৃত হয়। ভুলটা প্যাকেটের ভেতরেই থাকে: IPv4-এ একটি প্রোটোকল ফিল্ড আছে যা বলে IP হেডারের পরে কী আসছে, অন্যদিকে TCP ও UDP-এ পোর্ট ফিল্ড আছে যা কেবল সেই হেডারগুলোর একটির ভেতরে থাকলেই বিদ্যমান। এগুলো একই অনুমতির দুটি বানান নয়।
IPv4 হেডার পরের প্রোটোকলের নাম বলে
প্রোটোকল ফিল্ড IPv4 হেডারে এক বাইট, আর এটি পেলোড বর্ণনা করা একটি সংখ্যা ধরে রাখে: TCP-র জন্য 6, UDP-র জন্য 17, GRE-র জন্য 47, ESP-র জন্য 50। প্যাকেট ফিল্টার করে এমন যা কিছু আরও গভীরে তাকানোর আগে ওই মান পড়ে, কারণ গভীরতর হেডার কেবল টাইপ জানার পরেই অর্থবহ হয়। কথোপকথনের পরে একটি পোর্ট বদলান, এই ফিল্ড নড়েনি।
তাই প্রোটোকল 47-এর বিপরীতে লেখা নিয়ম IP স্তরকেই বর্ণনা করে। সিদ্ধান্তে কোনো পোর্টই অংশ নেয় না।
পোর্ট কেবল TCP ও UDP-এর ভেতরে থাকে, আর কোথাও নয়
পোর্ট হলো TCP ও UDP হেডারের ভেতরের ষোলো-বিট শনাক্তকারী, আর তাদের কাজ একই ঠিকানা ভাগ করা কথোপকথনগুলোকে আলাদা করা। GRE হেডার একটি প্রোটোকল টাইপ মান বহন করে, প্রায়ই EtherType, সঙ্গে মাল্টিপ্লেক্সিংয়ের জন্য ঐচ্ছিক কী। তাই পোর্ট 47 বাক্যাংশটি এমন কিছুকে নাম দেয় না যা কোনো GRE প্যাকেট মেলাতে পারে।
ফায়ারওয়াল ইন্টারফেসগুলো এর কতটা দেখায় তা নিয়ে ভিন্ন। কিছু প্রোটোকল নম্বর গ্রহণ করে, কিছু নামের তালিকা দেয়, আর অল্প কিছু কেবল পোর্টসহ TCP বা UDP গ্রহণ করে।
PPTP একসঙ্গে দুই স্তরই ব্যবহার করে
PPTP সবচেয়ে পরিষ্কার উদাহরণ, কারণ এটি সচেতনভাবে নিজের কাজ দুটি স্তরে ভাগ করে। নিয়ন্ত্রণ সংযোগটি 1723 পোর্টে একটি TCP সেশন, আর ডেটা পথ হলো GRE, প্রোটোকল 47, কোথাও কোনো পোর্ট জড়িত নয়। যে ফায়ারওয়াল 1723 অনুমোদন করে আর কিছুই নয়, সে দর-কষাকষি শুরু হতে দেয়, তারপর পেলোড ফেলে দেয়। টানেল সংযোগে ব্যর্থ হওয়ার বদলে প্রমাণীকরণের পরে আটকে থাকা মনে হয়, আর তাই উপসর্গটি প্রায়ই পাসওয়ার্ডের সমস্যা হিসেবে রিপোর্ট হয়।
| Path | Outer protocol | Port |
|---|---|---|
| Control channel | TCP, protocol 6 | 1723 |
| Data channel | GRE, protocol 47 | None |
নিয়ম লেখার সময় দুটি সারি আলাদাভাবে পড়ুন, আর প্রতিটিকে প্রস্তুতকারকের সিনট্যাক্সের সঙ্গে মিলিয়ে দেখুন। এক সারিতে পোর্ট দরকার, অন্যটিতে প্রোটোকল নম্বর দরকার, আর কোনো একক এন্ট্রি দুটোই ঢেকে দেয় না।
কেন পোর্ট-ফরোয়ার্ড পাতায় GRE প্রকাশ করা যায় না
যে ফরোয়ার্ডিং ফর্ম কেবল TCP ও UDP গ্রহণ করে, সে GRE বর্ণনা করতে পারে না, ফর্মটির নাম যাই হোক। ঠিকানা রূপান্তর দ্বিতীয় একটি অসুবিধা যোগ করে, কারণ GRE-র কোনো পোর্ট নেই আর রূপান্তরককে বদলে কল শনাক্তকারী অনুসরণ করতে হয়। কিছু গ্রাহক রাউটারে একটি সহায়ক থাকে যা এটি সামলায়; অনেকগুলোতে থাকে না, আর কোনো অতিরিক্ত TCP অনুমতি-এন্ট্রি ওই আচরণ তৈরি করবে না।
যেখানে আধুনিক টানেলই প্রকৃত প্রয়োজন, সেখানে রূপান্তরক ঠিক অনুমান করবে বলে আশা না করে সচেতনভাবে TCP বা UDP ব্যবহার করে এমন নকশা বেছে নিন।
এনক্যাপসুলেশন ঠিক করে ফিল্টার কী দেখবে
এনক্যাপসুলেশন বাইরের প্যাকেট বদলায়, আর নিয়ম মেলে বাইরের প্যাকেটের সঙ্গেই। নেটিভ ESP হলো প্রোটোকল 50, অন্যদিকে NAT ট্রাভার্সাল ESP-কে UDP 4500-এর ভেতরে মোড়ে যাতে এটি ঠিকানা রূপান্তর থেকে বেঁচে যায়। যে ফিল্টার UDP 4500 অনুমোদন করে সে কখনও প্রোটোকল 50 দেখে না, আর প্রোটোকল 50-এর জন্য লেখা ফিল্টার কখনও মোড়ানো রূপের সঙ্গে মেলে না।
ক্লায়েন্ট ও গেটওয়ে কোন এনক্যাপসুলেশনে একমত হয়েছে জিজ্ঞাসা করুন, তারপর ঠিক ওই বাইরের আকৃতির জন্য নিয়ম লিখুন, তার বেশি কিছু নয়।
নিয়মটি এমনভাবে লিখুন যাতে কেউ যাচাই করতে পারে
প্রতিটি নিয়ম ঠিকানা পরিবার, বাইরের প্রোটোকল, থাকলে পরিবহন পোর্ট, দিক এবং দুই প্রান্ত হিসেবে প্রকাশ করুন। সমালোচক ওই বাক্যটিকে প্যাকেট ক্যাপচারের সঙ্গে মিলিয়ে রায়ে পৌঁছাতে পারেন। 47 খুলে দেওয়ার নির্দেশ কেউ যাচাই করতে পারে না, আর এভাবেই সেটি বছরের পর বছর রানবুকে টিকে থাকে।
প্রমাণ করার পরীক্ষাটি যোগ করুন: বাইরের ইন্টারফেসে ক্যাপচার চালু রেখে সংযোগ করুন, আর ট্রেসে সত্যিই যে বাইরের প্রোটোকল ও পোর্ট দেখা যায় তা নিশ্চিত করুন।