Explorer-এর নেটওয়ার্ক পেজ স্থানীয় সেগমেন্টে নিজেদের ঘোষণা করা ডিভাইস দেখায়, আর রাউটেড টানেল সেই ঘোষণাগুলোর একটিও বহন করে না। এজন্যই সার্ভার পুরোপুরি পৌঁছানোযোগ্য হতে পারে, অথচ ব্যবহারকারীর সামনের উইন্ডো খালি থাকে। নামযুক্ত UNC পথ আবিষ্কারের উপর একেবারেই নির্ভর করে না, আর সমাধান হলো নামটি সমাধান হওয়া এবং পোর্টটির উত্তর দেওয়া। খালি উইন্ডো ভুল স্তরের লক্ষণ, নষ্ট শেয়ারের নয়।

আবিষ্কার আর পৌঁছানো এক নয়

Windows কাছের মেশিনগুলো ব্রডকাস্ট ডোমেনের জন্য তৈরি প্রোটোকল দিয়ে খুঁজে বের করে, তারপর যা পেয়েছে তা সুবিধার তালিকা হিসেবে দেখায়। ওই তালিকার কিছুই SMB ফাইল অ্যাক্সেসের জন্য দরকার নেই। যে ক্লায়েন্ট সার্ভারের নাম জানে এবং TCP 445-এ পৌঁছাতে পারে, সে শেয়ারটি খুলবে, মেশিন কখনো নেটওয়ার্কে দেখা দিক বা না দিক।

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

শেয়ার ম্যাপ করার আগে সার্ভারের নাম দিন

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

পরিবেশ Active Directory ব্যবহার করলে নাম সমাধানও প্রমাণীকরণের অংশ: ক্লায়েন্টকে Kerberos-এর জন্য ডোমেন কন্ট্রোলারে পৌঁছাতে হয়, আর খুব বেশি অমিল ঘড়ি টিকিট বিনিময় ব্যর্থ করবে। এটি SMB পৌঁছানোর চেয়ে আলাদা সমস্যা এবং শংসাপত্রের ত্রুটির মতো দেখায়। পাসওয়ার্ড আবার লেখার আগে ডোমেন কন্ট্রোলার পরীক্ষা করুন।

LayerWhat it needsSymptom when missing
Name resolutionA DNS answer for the server namePath cannot be found, ping by IP still works
TransportTCP 445 open in both directionsConnection times out or is refused
AuthenticationA reachable domain controller and correct clockAccess is denied after the port connects
AuthorizationShare permission and filesystem permissionThe share opens but the folder is inaccessible

দুই দিকেই রাউটিং ও ফিল্টারিং

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

WireGuard-এ পিয়ারের অনুমোদিত IP এবং অপারেটিং সিস্টেমের রুট ওই নকশার সঙ্গে মিলতে হবে। টানেল প্যাকেট বহন করে; এটি DNS রেকর্ড বা শেয়ার অনুমতি দেয় না কোনও পাশেই।

ফায়ারওয়াল নিয়মটি যে প্রকৃত সোর্স নেটওয়ার্ক সংযুক্ত হবে তার উপর ভিত্তি করুন এবং ব্যতিক্রমটি লিখে রাখুন। নকশা যদি পথের কোথাও ঠিকানা অনুবাদ করে, নিয়মটিকে অনূদিত সোর্স ব্যবহার করতে হবে, আর মূল ক্লায়েন্ট ঠিকানা আর লগে দেখা যায় না।

প্রমাণীকরণ করুন, তারপর ড্রাইভ ম্যাপ করুন

Explorer উইন্ডোর বদলে কমান্ড দিয়ে স্তরগুলো পার হোন:

Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:no

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

SMB সাইনিং এবং বিদ্যমান প্রমাণীকরণ নীতি অক্ষত রাখুন। স্পষ্ট পথের জন্য SMB1 আবার চালু করা বা আবিষ্কার ব্রডকাস্ট টানেল দিয়ে পাঠানো দরকার নেই, আর TCP 445 ব্যক্তিগত পথেই থাকা উচিত, ইন্টারনেটমুখী ফরওয়ার্ডে নয়। ব্যবহারকারীদের অনুমোদিত নামে ব্যবস্থাপিত শর্টকাট বা ম্যাপ করা ড্রাইভ দিন, আর খালি নেটওয়ার্ক পেজ আর গুরুত্বপূর্ণ থাকবে না।

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