OpenVPN Access Server আসলে কোন পোর্টে শোনে?
Access Server হোস্টে সকেট তালিকা ধরে হাঁটুন: ডিফল্ট লিসেনার চিনুন, লুপব্যাক ও প্রকাশিত পোর্ট আলাদা করুন, এবং পোর্ট বন্ধ করার আগে ফরওয়ার্ডিং যাচাই করুন।
আপনি ss -lntup Access Server হোস্টে চালান এবং প্রত্যাশার দ্বিগুণ দীর্ঘ একটি তালিকা পান। অর্ধেক এন্ট্রি ডেমন-আকৃতির পোর্ট যা সেটআপের সময় কেউ উল্লেখ করেনি। প্রতিক্রিয়া হলো 443 বা 1194 নয় এমন সবকিছু বন্ধ করা, আর এভাবেই মানুষ নিজেদের ক্লায়েন্ট পোর্টাল ভেঙে ফেলে।
Access Server একটি মাত্র লিসেনার নয়। এটি একটি VPN সেবা, একটি ওয়েব সেবা এবং একটি ক্লাস্টার অংশগ্রহণকারী, এবং আপনি কতগুলো TCP ডেমন কনফিগার করেছেন তার ওপর নির্ভর করে এটি অতিরিক্ত ডেমন-নির্দিষ্ট পোর্ট ও ফায়ারওয়াল রিডাইরেকশন তৈরি করতে পারে।
তালিকাটি ক্রমে হাঁটুন: সকেটগুলো পড়ুন, পরিচিতগুলো ম্যাপ করুন, বাকিগুলো মালিক ও বাইন্ড অনুযায়ী শ্রেণিবদ্ধ করুন, তারপর যাচাই করুন আসলে কী সেগুলো প্রকাশ করছে।
একটি শুধু-পঠনযোগ্য কমান্ড দিয়ে শুরু করুন
sudo ss -lntup প্রতিটি শোনা সকেটের জন্য ট্রান্সপোর্ট, স্থানীয় ঠিকানা, পোর্ট ও মালিক প্রসেস দেয়। ফ্ল্যাগগুলো গুরুত্বপূর্ণ: -l শোনা, -n সংখ্যাসূচক, -t TCP, -u UDP, -p প্রসেস। রুট ছাড়া আপনি সকেট পান কিন্তু প্রসেসের নাম পান না, আর শ্রেণিবিন্যাসের জন্য ঠিক সেই কলামটিই দরকার।
মতামত গঠনের আগে প্রতি সারিতে চারটি ক্ষেত্র লিখুন: প্রোটোকল, বাইন্ড ঠিকানা, পোর্ট ও কমান্ড। Access Server সংস্করণ ও কনফিগার করা ডেমন সংখ্যা ওই তালিকার পাশে রাখুন, কারণ দুটোই প্রত্যাশা বদলে দেয়।
একই দেখতে দুটি সারি এক নয়। একই নম্বরে TCP ও UDP আলাদা এক্সপোজারযুক্ত আলাদা সকেট, আর 0.0.0.0 এবং :: আলাদা অ্যাড্রেস ফ্যামিলির জন্য আলাদা বাইন্ড। কেবল 127.0.0.1 -এ বাঁধা একটি সেবা অন্য হোস্ট থেকে সরাসরি পৌঁছায় না, যদিও স্থানীয় রিডাইরেক্ট এখনও তা প্রকাশ করতে পারে।
যে লিসেনারগুলো আপনার চেনা উচিত
এই ডিফল্টগুলো বেশিরভাগ ডিপ্লয়মেন্ট কভার করে এবং তুলনার জন্য একটি ভিত্তি দেয়। এগুলো ডিফল্ট, পূর্ণ অনুমোদিত তালিকা নয়।
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
এর বাইরের সবকিছুর ব্যাখ্যা দরকার, অনুমান নয়। প্রায়ই আপনি কেবল-স্থানীয় লিসেনার দেখবেন যা পণ্যটি নিজের জন্য ইনস্টল করা উপাদানের। এগুলো মুখস্থ পোর্ট নম্বরের বদলে PID ও সেবা কনফিগারেশন দিয়ে নিশ্চিত করুন, এবং অপরিচিত পোর্টকে কেবল অপরিচিত বলে শত্রু ভাববেন না।
পরিচিত জোড়ার বাইরের সকেটও স্বয়ংক্রিয়ভাবে অবশিষ্টাংশ নয়। একাধিক TCP ডেমন কনফিগার করা থাকলে Access Server প্রতি ডেমনের জন্য লিসেনার তৈরি করে ও ট্রাফিক সেগুলোতে রিডাইরেক্ট করে, তাই তাদের সংখ্যা ও পোর্ট মান সেই কনফিগারেশন অনুসরণ করে।
কিছু বন্ধ করার আগে শ্রেণিবদ্ধ করুন
প্রতিটি অনিশ্চিত সারির জন্য এই ক্রমে তিনটি প্রশ্নের উত্তর দিন।
- মালিক ও উদ্দেশ্য। PID-কে একটি ইউনিট বা প্রসেসের সঙ্গে মেলান এবং সেই সেবার কনফিগারেশন পড়ুন। মালিকের নাম বলতে না পারলে সকেট সম্পর্কে কোনো সিদ্ধান্ত নেওয়ার জন্য আপনি প্রস্তুত নন।
- বাইন্ড পরিধি। লুপব্যাক নেমস্পেসের জন্য স্থানীয়। ওয়াইল্ডকার্ড বাইন্ড কেবল তখনই পৌঁছানো যায় যখন রাউটিং, হোস্ট ফিল্টারিং ও কোনো ক্লাউড-স্তরের নিয়ম তা অনুমোদন করে, তাই বাইন্ড ঠিকানা প্রয়োজনীয় কিন্তু যথেষ্ট নয়। IPv4 ও IPv6 আলাদা সিদ্ধান্ত হিসেবে যাচাই করুন।
- প্রকাশিত পথ। সেবা ফরওয়ার্ডিং, ডেমন-নির্দিষ্ট রিডাইরেক্ট, বাহ্যিক প্রক্সি ও কার্যকর ফায়ারওয়াল নীতি খুঁজুন। মানুষ এই ধাপটিই এড়িয়ে যায়, আর এটিই নিরীহ দেখতে ব্যাকএন্ড পোর্টকে পৌঁছানোর যোগ্য প্রশাসনিক পথে পরিণত করে।
একই প্রশ্ন হোস্টের বাইরে থেকে ভিন্নভাবে পড়া যায়। হোস্ট ফায়ারওয়াল নিয়মহীন একটি পোর্টও ক্লাউড সিকিউরিটি গ্রুপ বন্ধ করতে পারে, আর অনুমতিমূলক হোস্ট নিয়মযুক্ত পোর্ট পৌঁছানোর অযোগ্য হতে পারে কারণ কিছুই সেখানে রুট করে না। তালিকার সিদ্ধান্ত লেখার আগে দুই প্রান্তই দেখুন।
যেখানে প্রকাশিত পথ সকেট তালিকা থেকে আলাদা
Access Server-এর নিজস্ব ডকুমেন্টেশন সেই ক্ষেত্রটি কভার করে যা সবচেয়ে বেশি বিভ্রান্তি ঘটায়: একাধিক TCP ডেমন চললে সামনের পোর্ট ডেমন-নির্দিষ্ট পোর্টে ফরওয়ার্ড করে, আর দৃশ্যমান বিন্যাস সকেট তালিকার সঙ্গে মিলতে থাকে না। ওয়েব ইন্টারফেস ফিল্টারিং টিউটোরিয়াল সেই নিয়মগুলো ব্যাখ্যা করে এবং কেন কেবল সুস্পষ্ট পোর্টের জন্য লেখা ফিল্টার রিডাইরেক্ট করা পথ সম্পূর্ণ মিস করতে পারে।
ক্লাস্টার নিয়ন্ত্রণ হলো দ্বিতীয় জায়গা যেখানে সংস্করণ গুরুত্বপূর্ণ। 3.0 ও পরবর্তীতে এটি 943 ভাগ করে; পুরনো ক্লাস্টার কনফিগারেশন 945 ব্যবহার করত। সংস্করণ যাচাই না করে এগুলোর একটি খোলা বা ব্লক করা একটি পরিচ্ছন্ন দেখতে কিন্তু ভুল তালিকা তৈরি করে।
তাই বাহ্যিকভাবে দৃশ্যমান পৃষ্ঠ হলো তিনটি জিনিসের সমন্বয়: শোনা সকেট, সেগুলো পুনঃপ্রকাশকারী ফরওয়ার্ডিং নিয়ম, এবং হোস্টের সামনে নেটওয়ার্ক নিয়ন্ত্রণ। কেবল প্রথমটি লিপিবদ্ধ করা তালিকা অসম্পূর্ণ, আর কেবল প্রথমটি বিবেচনা করা পরিবর্তন হয় পথ খোলা রাখবে নয়তো একটি সেবা কেটে দেবে।
যেকোনো পরিবর্তনের পরে যাচাই করুন
সমর্থিত কনফিগারেশন মালিকের মাধ্যমে লিসেনার সেটিংস বদলান এবং তা করার সময় একটি পুনরুদ্ধার কনসোল খোলা রাখুন। দূরের হোস্টে একটি ওয়েব UI-তে প্রশাসনিক প্রবেশ হারানো আপনি এইমাত্র নিষ্ক্রিয় করা VPN দিয়ে পুনরুদ্ধারযোগ্য নয়।
তারপর একটি ডিপ্লয়মেন্টের সাধারণত প্রয়োজনীয় চারটি জিনিস যাচাই করুন: একটি VPN ক্লায়েন্ট সংযোগ করে, ক্লায়েন্ট পোর্টাল লোড হয়, প্রশাসনিক প্রবেশ কাজ করে, এবং একাধিক নোড চালালে ক্লাস্টার যোগাযোগ এখনও কাজ করে। শুধু-VPN পরীক্ষা আরামে পাস করে যখন পোর্টাল ভাঙা থাকে।
শেষ করুন প্রতিটি সেবার অনুমোদিত পথ লিখে: কোন সকেট, কোন বাইন্ড, কোন ফরওয়ার্ডিং নিয়ম, কোন নেটওয়ার্ক নিয়ন্ত্রণ। সেই নথিই উপকারী নিরাপত্তা আউটপুট। ন্যূনতম সকেট সংখ্যা নয়, আর যে গণ-রিসেট এমন লিসেনার বন্ধ করে যা কেউ শনাক্ত করা শেষ করেনি, সেটিও নয়।