VPN পোর্ট চুপ? লিসেনার, বাইন্ড ঠিকানা নাকি হোস্ট ফায়ারওয়াল
বন্ধ সার্ভিস আর ফায়ারওয়ালের ড্রপের মেরামত আলাদা। আগে লোকাল সকেট দেখুন, তারপর একটি অনুমোদিত বাইরের প্রচেষ্টাকে লগের সঙ্গে মিলিয়ে দেখুন।
VPN তার পোর্টে কিছুই উত্তর দেয় না, আর দুটি সম্ভাব্য কারণের মেরামত পরস্পরবিরোধী: হয় কোনো প্রসেস সকেটটি খোলেনি, নয়তো সকেট আছে এবং মেশিন দুটির মাঝে কিছু প্যাকেট থামিয়ে দিচ্ছে। একটি কমান্ডই সেই প্রশ্নের প্রথম অর্ধেক মিটিয়ে দেয়, তাই কোনো ফায়ারওয়াল নিয়ম ছোঁয়ার আগেই এটি আসে। নিচের ক্রমটি আরেকটি অনুমান যোগ না করে প্রতি ধাপে একটি ব্যাখ্যা সরিয়ে দেয়। দুটির মধ্যে অনুমান করাই দশ মিনিটের রোগনির্ণয়কে সারা সন্ধ্যায় পরিণত করে।
ধরে নিন আপনি সার্ভারে লগইন করতে পারেন এবং ক্লায়েন্টটি স্ক্যানার নয়, সত্যিকারের প্রোফাইল। দুটি ধারণাই জরুরি, কারণ সাধারণ প্রোব প্রোটোকল-নির্দিষ্ট প্রশ্নের উত্তর দিতে পারে না।
সকেটটি আদৌ আছে কি
সার্ভিসটি নিজের সম্পর্কে যা বলে তা দিয়ে শুরু করুন: এটি উঠেছিল কি না এবং আরও কাজের কথা, তার প্রথম স্টার্টআপ ত্রুটি কী ছিল। পার্স ব্যর্থতা, অনুপস্থিত কী বা বাইন্ড ত্রুটি লিসেনারকে কখনো অস্তিত্ব পেতে দেয় না, আর প্রসেসটি এত চুপচাপ বেরিয়ে যেতে পারে যে স্ট্যাটাস লাইন দ্ব্যর্থক পড়ায়। যে ইউনিট নিজেকে সক্রিয় বলে তা একা প্রমাণ নয়, কারণ মূল প্রসেস বেঁচে থাকতে পারে অথচ যে কম্পোনেন্টটি পোর্ট বাইন্ড করার কথা ছিল সে আগেই হাল ছেড়েছে।
systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp
সকেট তালিকাই সেই তথ্য যার ওপর বাকি রোগনির্ণয় দাঁড়িয়ে আছে। শুধু পোর্ট নয়, লোকাল অ্যাড্রেস কলামটি পড়ুন, কারণ ওই কলামেই লুপব্যাক বাইন্ড আর ভুল ইন্টারফেসের বাইন্ড ধরা পড়ে। 127.0.0.1-এ থাকা লিসেনার নিখুঁতভাবে চলছে, তবুও আপনার ল্যাপটপের কাছে অদৃশ্য।
সকেটটি কোন ঠিকানায় ও কোন ফ্যামিলিতে উত্তর দেয়
দুটি ভুল ক্লায়েন্টের দিক থেকে একই দেখায় এবং বেশিরভাগ "পৌঁছানো যাচ্ছে না" রিপোর্টের কারণ। লুপব্যাক ঠিকানায় বাইন্ড করা সার্ভার কখনো অন্য মেশিন থেকে ট্রাফিক নেয় না, আর শুধু IPv4 ঠিকানায় বাইন্ড করা সার্ভার একই হোস্টের IPv6 ঠিকানায় ডায়াল করা ক্লায়েন্টকে কখনো উত্তর দেয় না। নীতিমালা সম্পর্কে কিছু ধরে নেওয়ার আগে সকেট টেবিলের ঠিকানাটি ক্লায়েন্ট আসলে যে ঠিকানায় ডায়াল করছে তার সঙ্গে অক্ষর ধরে ধরে মিলিয়ে দেখুন।
তালিকাটি একটি পোর্টে সীমিত রাখলে হোস্টে কয়েকটি সার্ভিস চললেও এটি পড়ার যোগ্য থাকে। sport ফিল্টার আপনার পরীক্ষা করা ট্রান্সপোর্টসহ পোর্টটি নেয়:
ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'
প্রোটোকল কলামটি গোটা উত্তর বদলে দেয়
সকেট টেবিল পোর্টের পাশাপাশি প্রোটোকল অনুসারেও সূচিবদ্ধ, আর এরা দুটি স্বতন্ত্র এন্ট্রি। 1194-এ TCP-তে উত্তর দেওয়া সার্ভিস UDP 1194-এ কিছু শুনছে কি না তা বলে না, আর ক্লায়েন্ট কেবল একটি-ই ব্যবহার করবে। সার্ভার কনফিগারেশন কোন ট্রান্সপোর্ট বেছে নেয় এবং ক্লায়েন্ট প্রোফাইল কোনটি পাঠায় তা নিশ্চিত করুন, তারপর ঠিক সেই সারিটি খুঁজুন।
UDP-এর আরেকটি ভাঁজ আছে: অননুমোদিত প্রোব কোনো ত্রুটি নয় যার উত্তর সার্ভিসকে দিতে হয়। যে স্ক্যান পোর্টকে চুপ বলে রিপোর্ট করে সে সার্ভিসের উপলব্ধতা নয়, তার সংযম মেপেছে, তাই সত্যিকারের ক্লায়েন্ট ও প্রোফাইল দিয়ে পরীক্ষা করুন।
একটি প্রচেষ্টা, দেখার তিনটি জায়গা
অনুমোদিত ক্লায়েন্ট থেকে ঠিক একটি প্রচেষ্টা করুন এবং সময়টি সেকেন্ড পর্যন্ত লিখে রাখুন। তারপর সেই সময়কালের জন্য তিনটি উৎস পড়ুন: প্রোভাইডারের নেটওয়ার্ক নিয়ম বা কনসোল, হোস্টের ফায়ারওয়াল কাউন্টার বা লগ, এবং সার্ভিসের নিজের লগ। একবার এটি করাই তিনটি বিবরণকে তুলনাযোগ্য করে, আর যার টাইমস্ট্যাম্প কেউ লেখেনি এমন প্রচেষ্টা পুনরাবৃত্তি করার চেয়ে কম খরচে পড়ে।
দুটি ফলাফল বিপরীত দিকে ইঙ্গিত করে। যদি কোনো প্যাকেট হোস্টে না পৌঁছায়, পথটি সেটি ফেলে দিচ্ছে এবং লিসেনার অপ্রাসঙ্গিক। যদি প্যাকেট সকেটে পৌঁছে সার্ভিস তা প্রত্যাখ্যান করে, পথ ঠিক আছে এবং উত্তর প্রোটোকল, ক্রিপ্টোগ্রাফি বা ক্রেডেনশিয়ালে। যে সার্ভিস ইতিমধ্যে একটি সংযোগ গ্রহণ করেছে তার জন্য পোর্ট খুললে পরের রোগনির্ণয় সহজ নয়, কঠিন হয়।
নিয়ম বদলানোর আগে ধাপটির নাম দিন
শুরু হওয়া নেগোশিয়েশন আর ব্যর্থ হওয়া প্রমাণীকরণ একটি ব্যর্থতা, আর যে টানেল প্রতিষ্ঠিত হয় অথচ ফরওয়ার্ডিং আটকে যায় সেটি সম্পূর্ণ আলাদা। আগে ধাপের নাম দিলে মেরামত সংকীর্ণ থাকে: ক্রেডেনশিয়ালের সমস্যা ফায়ারওয়াল নিয়মে সারেনি, আর ডেটা-পথের সমস্যা রিস্টার্টে সারেনি।
প্রশ্নের উত্তর দেয় এমন সংকীর্ণতম রোগনির্ণয় ব্যবহার করুন। প্রশাসকের নিয়ন্ত্রণে একটি পোর্টে সাময়িক প্যাকেট পর্যবেক্ষণ যুক্তিসঙ্গত যন্ত্র; পুরো ফায়ারওয়াল বন্ধ করা নয়, কারণ ফলাফলকে দায়ী করা অসম্ভব হয়ে পড়ে। ss-এর ডকুমেন্টেশন ওপরে ব্যবহৃত ফিল্টারগুলো কভার করে, আর এটি যেকোনো ক্যাপচারের চেয়ে সস্তা প্রথম ধাপ। দুটি শাখার কোনটি আপনি প্রমাণ করেছেন তা লিখে রাখুন, পরের ঘটনা শুরু হবে একটি জানা উত্তর থেকে।