VPN-এ NAS-এ পৌঁছানো যাচ্ছে না: ঠিকানা, ফেরার পথ নাকি সেবা?
একটি ব্যক্তিগত টানেলের NAS পর্যন্ত পথ, উত্তর ফেরার পথ এবং অনুমোদিত সেবা দরকার। পরিচয়পত্র বদলানোর আগে তিনটির মধ্যে কোনটি ব্যর্থ হয়েছে তা নির্ধারণ করুন।
টানেল ওঠে, ক্লায়েন্টরা ঠিকানা পায়, আর NAS কিছুতেই উত্তর দেয় না। এই একটিমাত্র লক্ষণ তিনটি আলাদা ত্রুটি ঢেকে রাখে, আর সেগুলো যে ক্রমে পরীক্ষা করবেন তা মেরামত কত সময় নেবে তা ঠিক করে। ঠিকানাকরণ আগে আসে, কারণ একটি ওভারল্যাপিং সাবনেট আপনার অনুরোধ অচেনা ডিভাইসে পাঠাতে পারে। ফেরার পথ দ্বিতীয়, কারণ উত্তর ছাড়া আসা অনুরোধ বন্ধ সেবার মতোই দেখায়। সেবা ও অনুমতি শেষে আসে, আর কেবল প্রথম দুটি প্রমাণিত হওয়ার পরে।
তিনটি ত্রুটি যেগুলো সবই অপ্রাপ্য হিসেবে পড়া হয়
ঠিকানা নির্বাচন, ফেরার রাউটিং এবং সেবা অনুমোদন একই দৃশ্যমান বার্তা দেয়: কিছুই ঘটে না। তাদের প্রমাণ, দায়িত্বপ্রাপ্ত এবং সমাধান আলাদা, তাই সেগুলোকে আলাদা করাই পুরো কাজ। ব্যর্থ ping একা খুব কম প্রমাণ করে, আর সফল TCP প্রত্যাখ্যান আসলে ভালো খবর।
| Observation | Most likely conclusion |
|---|---|
| Route to the NAS address leaves the wrong interface | Overlapping or missing private route |
| Request visible on the server, no reply seen | Return path, gateway forwarding or translation |
| TCP connection refused rather than dropped | Reachable host, service not listening or filtered |
| TCP works, login or file access fails | Share permission, account or protocol version |
সারণিটি কারণের তালিকা নয়, পরীক্ষার ক্রম হিসেবে পড়ুন। প্রতিটি সারি পরেরটিকে সীমাবদ্ধ করে, কারণ প্রত্যাখ্যান আগেই প্রমাণ করে যে ঠিকানাকরণ ও ফেরার পথ কাজ করে। রুট কোন ইন্টারফেস বেছেছে তা যাচাই করার আগে ফায়ারওয়াল নিয়মের ভেতরে বিশ মিনিট কাটানো বিকেল হারানোর সবচেয়ে সাধারণ উপায়। উপরে থেকে নিচে কাজ করুন এবং প্রথম মিলে যাওয়া সারিতে থামুন।
শর্ত এক: সেই ঠিকানাটি কি সঠিক ডিভাইস?
NAS-এর সাবনেট এবং VPN ক্লায়েন্টদের যে পরিসর দেয় তা লিখে রাখুন, তারপর দুটোই আপনার ল্যাপটপ এখন যে নেটওয়ার্কে আছে তার সঙ্গে মিলিয়ে দেখুন। এই আলোচনায় NAS আছে 10.40.7.25-এ এবং VPN পুল 10.40.9.0/24, একটি সাইট পরিকল্পনার ভেতরে দুটি আলাদা ব্যক্তিগত পরিসর; যে পরিবার 192.168.0.0/24 বা 10.0.0.0/24 ব্যবহার করে তাদের এগুলোর একটির সঙ্গে সংঘর্ষের সম্ভাবনা অনেক বেশি।
যখন স্থানীয় নেটওয়ার্ক ও NAS নেটওয়ার্ক ওভারল্যাপ করে, ক্লায়েন্ট সেই ট্রাফিক নিজের গেটওয়েতে পাঠায় এবং ভাগ্যক্রমে একই ঠিকানা আছে এমন অসম্পর্কিত ডিভাইসে পৌঁছাতে পারে। উত্তর দেয় এমন কিছুর মধ্যে পরিচয়পত্র লেখার আগে পথটি যাচাই করুন।
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25প্রথম কমান্ড কার্নেল যে ইন্টারফেস ও গেটওয়ে ব্যবহার করত তা বলে, আর দ্বিতীয়টি প্রথম যে হপগুলো সত্যিই উত্তর দেয় তা দেখায়। দুটো না মিললে সন্ধানকে বিশ্বাস করুন, কারণ প্যাকেট এই পথেই যাবে। NAS-এর এক হপ আগে থামা হপ-তালিকাও একটি প্রাপ্তি, ব্যর্থতা নয়। যে সন্ধান টানেলের বদলে ভৌত অ্যাডাপ্টারে মীমাংসা হয় তা এই বিন্দুতেই তদন্ত শেষ করে।
শর্ত দুই: উত্তর কি ফিরে আসে?
ক্লায়েন্টের NAS-এর দিকে পথ দরকার, আর NAS নেটওয়ার্কের VPN পুলের দিকে ফেরার পথ দরকার। গেটওয়ে ফরওয়ার্ডিং, ফায়ারওয়াল নিয়ম এবং ইচ্ছাকৃত অনুবাদ প্রত্যেকে ওই জোড়াকে প্রভাবিত করে। strongSwan-এর ফরওয়ার্ডিং-নোট গেটওয়ের পেছনে ব্যক্তিগত সাবনেটের জন্য ফেরার রুট ও অনুবাদের বিকল্প বর্ণনা করে।
যখন অনুরোধ আসে আর উত্তর অন্য গেটওয়ে দিয়ে বেরোয়, কোনো DNS পরিবর্তন সেই অসমতা সারায় না। দুই দিকে ক্যাপচার এক প্রচেষ্টায় তা নিষ্পত্তি করে, আর এটাও দেখায় অনুবাদ সেই উৎস পুনর্লিখন করেছে কি না যেটিতে NAS উত্তর দিয়েছিল। প্রশাসক এই সীমার মালিক: কেবল প্রয়োজনীয় সেবা ও VPN ক্লায়েন্ট পরিসর অনুমোদন করুন, এবং রাউটিং নাকি অনুবাদ বেছে নেওয়া হয়েছে তা লিখে রাখুন।
শর্ত তিন: সেবাটি কি আছে এবং অনুমোদিত?
একটি ব্যবস্থাপনা পাতা আর একটি ফাইল শেয়ারিং সেবা একই মেশিনে আলাদা প্রান্তবিন্দু, আর একটি সংযোগ নিতে পারে যখন অন্যটি হোস্ট ফায়ারওয়াল, সেবা কনফিগারেশন বা শেয়ার অনুমতি দ্বারা অবরুদ্ধ থাকে। যে ডিভাইস প্রত্যাখ্যান দিয়ে উত্তর দেয় সে প্রথম দুটি শর্ত আগেই প্রমাণ করেছে, যা তৃতীয়টিকে অনেক সংকুচিত করে।
যে অ্যাকাউন্টের সত্যিই ফাইলগুলো দরকার সেই অ্যাকাউন্ট দিয়ে পরীক্ষা করুন, ইনস্টলের সময় ব্যবহৃত প্রশাসক অ্যাকাউন্ট দিয়ে নয়, কারণ প্রশাসনিক অধিকার অনুপস্থিত রুট সারাতে পারে না আর রুট শেয়ার অনুমতি দিতে পারে না। নামও এখানে প্রযোজ্য: বাড়িতে আবিষ্কৃত NAS নাম প্রায়ই স্থানীয় multicast-এর উপর নির্ভর করে, যা রাউটেড টানেল বহন করে না, তাই নামকরণকে প্রবেশ থেকে আলাদা করতে প্রস্তুতকারকের নথিভুক্ত ব্যক্তিগত হোস্টনাম বা ঠিকানাটি নিজেই চেষ্টা করুন।
NAS নেটওয়ার্কের বাইরে থেকে পরীক্ষা করুন, তারপর ধীরে ধীরে বাড়ান
একই LAN-এ করা পরীক্ষা দূরের পথের প্রতিটি অসম্পূর্ণ অংশ লুকায়, তাই প্রথম সফল দূরবর্তী প্রচেষ্টা পরিবর্তন-লগে এক টীকা পাওয়ার যোগ্য। এমন ক্লায়েন্ট থেকে পরীক্ষাগুলো চালান যে কেবল টানেল দিয়েই NAS-এ পৌঁছায়, এবং প্রতিটি প্রচেষ্টার মূল ত্রুটির লেখা সংরক্ষণ করুন।
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guestপথ কাজ করার পর একটি নিরীহ ফাইল স্থানান্তর করুন এবং আপনার সত্যিই প্রয়োজনীয় পড়া বা লেখার আচরণ নিশ্চিত করুন। বড় স্থানান্তর আটকে গেলে আর ছোটগুলো পার হলে বাকি সমস্যা প্যাকেটের আকার নিয়ন্ত্রণ বা সংযোগের স্থিতিশীলতা, ঠিকানাকরণ নয়।
ব্যাখ্যাহীন ত্রুটি এড়াতে ফাইল শেয়ারিং বা প্রশাসনের পোর্ট ইন্টারনেটে প্রকাশ করবেন না। ব্যক্তিগত পথ মেরামত করুন, NAS সফটওয়্যার সমর্থিত রাখুন, এবং সেই ব্যাকআপের উপর নির্ভর করার আগে তার ভেতর দিয়ে ব্যাকআপ করা সবকিছুর পুনরুদ্ধার পরীক্ষা করুন।