একটি OpenVPN পোর্ট, তিনটি সেবা: ভেতরের পোর্ট কেন গুরুত্বপূর্ণ

এক টানেল, তিন সেবা, এক প্রকাশ্য পোর্ট। বাইরের VPN শ্রোতাকে ভেতরের অ্যাপ্লিকেশন পোর্ট থেকে আলাদা করুন, তারপর প্রতিটি ভেতরের অনুমতি আলাদাভাবে পরীক্ষা করুন।

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

বহিঃপ্রবাহ কী বহন করে এবং কী লুকায়

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

তাই WAN ইন্টারফেসে ক্যাপচার একটি কথোপকথন দেখায়, তিনটি নয়। ডিক্যাপসুলেশনের পরেই ভেতরের পোর্টগুলো দেখা যায়। এজন্যই একটি একক ফায়ারওয়াল ফাঁক একই সঙ্গে SSH, HTTPS ও DNS বহন করতে পারে।

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

TUN/TAP ডকুমেন্টেশন সেই হস্তান্তরটি বর্ণনা করে যেখানে একটি রাউটেড TUN ডিভাইস কার্নেল ও ব্যবহারকারী-স্পেস প্রসেসের মধ্যে IP প্যাকেট পাস করে। এই হস্তান্তরই গেটওয়ের রাউটিং ও ফায়ারওয়াল কোডের কাছে ভেতরের হেডার দৃশ্যমান করে। এটি আরও ব্যাখ্যা করে কেন বাইরের পোর্ট কোন সেবাগুলো অনুমোদিত তা নিয়ে কিছু বলে না।

NAT ফরোয়ার্ড শ্রোতার, অ্যাপ্লিকেশনগুলোর নয়

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

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

অভ্যন্তরীণ নীতি হলো যেখানে প্রবেশাধিকার সত্যিই নির্ধারিত হয়

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

টানেলের মধ্য দিয়ে প্রতিটি সেবা আলাদাভাবে পরীক্ষা করুন। সফল অনুসন্ধান ওয়েব পোর্ট সম্পর্কে কিছু বলে না, আর সফল ওয়েব অনুরোধ SSH সম্পর্কে কিছু বলে না।

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

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

WireGuard একই সীমারেখা টানে

WireGuard তার বাইরের শ্রোতাকে ListenPort নামে ডাকে, আর ভেতরের অ্যাপ্লিকেশন তার প্রয়োজনীয় যেকোনো সেবা পোর্ট ব্যবহার করে। AllowedIPs হলো রাউটেড প্রিফিক্সের একটি সেট, অনুমোদিত সেবা পোর্টের তালিকা নয়। এটিকে পোর্ট অনুমোদনের তালিকা হিসেবে পড়লে এমন নিয়ম তৈরি হয় যা টানেল যা করে তার সঙ্গে মেলে না। নামকরণ ভিন্ন; স্তরবিন্যাস নয়।

সেবাটি স্থানীয়-ইনপুট নীতিতে অনুমোদন করুন যখন এটি এন্ডপয়েন্টেই চলে, অথবা ফরোয়ার্ডিং নীতিতে যখন এটি সেই এন্ডপয়েন্টের পেছনে থাকে। এই পার্থক্যই ঠিক করে কোন নিয়ম-সেট প্যাকেটটি দেখে।

সাধারণ রূপটি হলো একটি বাইরের পরিবহন যার ভেতরে অনেক কথোপকথন। যে পণ্যগুলোর একাধিক বাইরের বিনিময় বা ভিন্ন IP প্রোটোকল দরকার, তারা মনে করিয়ে দেয় যে একক-প্রকাশ্য-পোর্ট প্যাটার্নটি এই নকশাকে বর্ণনা করে, প্রতিটি VPN-কে নয়।

সম্পর্কিত নিবন্ধ