VPN সংযুক্ত থাকলেও লোকাল নেটওয়ার্কে পৌঁছানো যাচ্ছে না? চারটি পরীক্ষা

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

প্রথমে, ক্লায়েন্ট যে রুট টেবিল বসিয়েছে তা দেখুন

VPN সংযুক্ত থাকার সময় ক্লায়েন্টের রুট টেবিল খুলুন। লিনাক্সে ip route, উইন্ডোজে route print বা Get-NetRoute, আর ম্যাকওএসে netstat -rn ব্যবহার করুন। আপনি খুঁজছেন টানেল দিয়ে যাওয়া একটি ডিফল্ট রুট এবং শারীরিক ডিফল্ট রুটের কী হয়েছে।

ফুল-টানেল ক্লায়েন্ট প্রায়ই 0.0.0.0/0 প্রতিস্থাপন না করে দুটি অর্ধ-ডিফল্ট রুট যোগ করে, 0.0.0.0/1 এবং 128.0.0.0/1। আসল ডিফল্ট রুট দৃশ্যমান থাকে কিন্তু প্রতিটি লুকআপ হারায়, তাই টেবিল অক্ষত দেখালেও সাবনেটের বাইরের সব ট্রাফিক সরে যায়। VPN ক্লায়েন্ট যদি স্প্লিট-টানেল বিকল্প দেয় এবং নীতি অনুমতি দেয়, সেটিই সবচেয়ে পরিষ্কার সমাধান।

টানেলকেই ডিফল্ট থাকতে হলে বরং লোকাল সাবনেট পিন করুন। লিনাক্সে রুটটি শারীরিক ইন্টারফেস ও গেটওয়ে উল্লেখ করে; উইন্ডোজে স্থায়ী করতে -p যোগ করুন এবং অনুমান না করে route print থেকে ইন্টারফেস নম্বর পড়ুন:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

পিন করা রুট কেবল ততক্ষণ টেকে যতক্ষণ এটি যে ঠিকানা উল্লেখ করে তা একই থাকে। যে ল্যাপটপ প্রতিবার সংযোগে নিজের Wi-Fi অ্যাডাপ্টারের নম্বর বদলায়, সে নিয়মটি আবার ভাঙবে, তাই সমাধান ব্যর্থ হয়েছে বলে সিদ্ধান্ত নেওয়ার আগে ইন্টারফেস ঠিকানা দেখে নিন।

দ্বিতীয়ত, নিশ্চিত করুন ঠিকানাটি প্রথম থেকেই লোকাল ছিল

গন্তব্যটি যদি সংযুক্ত সাবনেটের ভিতরে থাকে, টানেলের ডিফল্ট রুট কখনোই প্রযোজ্য হয় না এবং VPN কারণ নয়। 192.168.1.0/24 নেটওয়ার্কের ক্লায়েন্টে 192.168.1.40-এ থাকা প্রিন্টার সংযুক্ত রুট ব্যবহার করে; ওই ঠিকানা ব্যর্থ হলে VPN নয়, ডিভাইস, সুইচ বা ক্লায়েন্টের ফায়ারওয়াল দেখুন।

যে ঘটনাটি মানুষকে বিভ্রান্ত করে তা হলো লোকাল সার্ভারের জন্য একটি পাবলিক ঠিকানা। লোকাল নেটওয়ার্কের ভিতর থেকে রাউটারের WAN ঠিকানায় পৌঁছে ফিরে আসতে হেয়ারপিন NAT দরকার, আর অনেক রাউটার পোর্ট ফরওয়ার্ডের জন্য এটি সহজভাবে বাস্তবায়নই করে না। পাবলিক ঠিকানার পাশে প্রাইভেট ঠিকানাটি পরীক্ষা করুন। প্রাইভেট ঠিকানা কাজ করলে আর পাবলিক না করলে, VPN কেবল আগে থেকেই থাকা একটি NAT সীমাবদ্ধতা প্রকাশ করেছে।

হোস্টনেম পরিস্থিতি আরও খারাপ করে। লোকাল নামটি যদি এখন পাবলিক ঠিকানায় রিজলভ হয়, ক্লায়েন্ট এমন পথ চেষ্টা করতে থাকবে যা ফিরে আসতে পারে না। পরীক্ষার জন্য প্রাইভেট ঠিকানা ব্যবহার করুন, তারপর আরেকটি পোর্ট ফরওয়ার্ড যোগ না করে নামটি ঠিক করুন।

তৃতীয়ত, দেখুন এখন কে নামের উত্তর দেয়

কর্পোরেট রিজলভার ইন্ট্রানেট জানে আর সাধারণত NAS হোস্টনেম, প্রিন্টারের Bonjour নাম বা রাউটারের লোকাল উপনাম কিছুই জানে না। VPN যখন তার DNS সার্ভার ঠেলে দেয়, তখন ঠিকানাগুলো এখনো পৌঁছানোর মতো থাকলেও ওই নামগুলো রিজলভ হওয়া বন্ধ করে। নামটি সরাসরি জিজ্ঞাসা করুন এবং উত্তরটি ডিভাইসের কাছে যে ঠিকানা আছে বলে জানেন তার সঙ্গে মিলিয়ে দেখুন।

লিনাক্সে resolvectl query nas.local দেখায় কোন রিজলভার উত্তর দিয়েছে। উইন্ডোজে nslookup nas.local সার্ভারের নাম বলে, আর ipconfig /all রিজলভারের ক্রম দেখায়। লোকাল সাফিক্স এখন কর্পোরেট রিজলভার সামলালে হয় সেই সাফিক্সটি লোকাল রিজলভারে ফিরিয়ে দিন, নয়তো ডিভাইসের জন্য IP ঠিকানা ব্যবহার করুন।

ডিসকভারি আলাদা স্তর। mDNS ও ব্রডকাস্ট রাউটেড টানেল পেরোয় না, তাই ডিভাইস ঠিকানা দিয়ে পৌঁছানোর মতো হতে পারে অথচ তার নাম অদৃশ্য থাকে। রিফ্লেক্টর বা লোকাল DNS এন্ট্রি এটি সমাধান করে; রুট করে না।

চতুর্থত, অন্য মেশিনটিও VPN-এ আছে কি না দেখুন

আপনি যে মেশিনে পৌঁছাতে চান সেটিও যদি VPN ক্লায়েন্ট চালায়, আপনার সেশন পৌঁছাতে পারে অথচ তার উত্তর অন্য টানেল দিয়ে বেরিয়ে যায়। এতে এমন সংযোগ তৈরি হয় যা প্রতিষ্ঠিত হয়ে আটকে যায়, বা RDP ও SSH চেষ্টা আপনার দিকে কোনো ত্রুটি ছাড়াই সময় শেষ করে। নিজের ক্লায়েন্টকে দোষ দেওয়ার আগে অন্য হোস্টের রুট টেবিল ও তার ডিফল্ট পথ দেখুন।

সার্ভিসটি যে ঠিকানায় শোনে সেটিও দেখুন। কেবল টানেল ঠিকানায় বাঁধা লিসেনার VPN থেকে সংযোগ গ্রহণ করে আর লোকাল নেটওয়ার্ক থেকে প্রত্যাখ্যান করে, এমনকি রাউটিং নিখুঁত হলেও। এটি সার্ভিস কনফিগারেশন, নেটওয়ার্ক পথ নয়, এবং VPN ঠিকানায় আটকানো ম্যানেজমেন্ট ইন্টারফেসে এটি সাধারণ।

টানেলের উপর নির্ভর করে না এমন একটি ম্যানেজমেন্ট পথ রাখুন: আপনার উৎস নেটওয়ার্ক উল্লেখ করা স্ট্যাটিক রুট, লোকাল নেটওয়ার্কে যুক্ত আরেকটি ইন্টারফেস, বা টানেল পুরোপুরি এড়িয়ে যাওয়া একটি কনসোল। সেশন ছিঁড়ে যাওয়ার পর সেই পথ ডিজাইন করা পরের সংযোগের আগে যোগ করার চেয়ে অনেক কঠিন।

যে পরীক্ষা ব্যর্থ হয়েছে তার সঙ্গে মেলে এমন সমাধান প্রয়োগ করুন

রুট টেবিল অর্ধ-ডিফল্ট দখল দেখালে নীতি অনুমতি দিলে স্প্লিট টানেল, না দিলে পিন করা লোকাল রুট বেছে নিন। ঠিকানাটি পাবলিক প্রমাণিত হলে পরীক্ষা ও নাম প্রাইভেট ঠিকানায় সরান। রিজলভার হাত বদলালে লোকাল সাফিক্স সীমিত করুন বা ঠিকানাটি ব্যবহার করুন। অন্য হোস্ট টানেলের ভিতরে থাকলে তার ফেরার পথ বা লিসেনার বাঁধন ঠিক করুন।

একটি জিনিস বদলান, তারপর একই পরীক্ষা আবার করুন। ভুল সাবনেটের জন্য যোগ করা রুট, বানান ভুলযুক্ত রিজলভার সাফিক্স আর নম্বর বদলানো ইন্টারফেসে পিন করা রুট—সবই আসল ব্যর্থতার মতো দেখায়। পুনরাবৃত্তিই সমাধানকে কাকতালীয়তা থেকে আলাদা করে।

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