SMB ফায়ারওয়াল নিয়মে LocalSubnet VPN ক্লায়েন্টদের কভার করবে না
একটি LocalSubnet অনুমতি নিয়ম সার্ভারের নিজের সাবনেট কভার করে, রাউট করা VPN পুল নয়। পরিধি বাড়ানোর আগে সার্ভার যে সোর্স ঠিকানা দেখে তা তুলনা করুন।
অফিস ডেস্কটপগুলো শেয়ারে পৌঁছায়, VPN ব্যবহারকারীরা টাইম আউট পান, আর একই অ্যাকাউন্ট ফোনের হটস্পট থেকে কাজ করে। শেয়ার অনুমতিগুলোই বিরলভাবে পার্থক্য হয়; সাধারণত ফাইল সার্ভারে পৌঁছানো ঠিকানাটিই পার্থক্য। LocalSubnet-এ সীমাবদ্ধ একটি নিয়ম সার্ভারের নিজের সংযুক্ত সাবনেটগুলোকে অনুমতি দেয়, আর আলাদাভাবে রাউট করা VPN পুল তাদের একটি নয়। দুটি ডিজাইন এই ফাঁক বন্ধ করে, আর এরা খুব ভিন্ন রেকর্ড রেখে যায়।
দুটি ডিজাইন, একটি লক্ষণ
প্রথম ডিজাইন নিয়মের রিমোট ঠিকানা শর্তে VPN পুল যোগ করে। তখন সার্ভার প্রতিটি ক্লায়েন্টের টানেল ঠিকানা দেখে, তাই এর লগ একটি রিমোট ব্যবহারকারীকে অন্যজন থেকে আলাদা করতে পারে। দ্বিতীয় ডিজাইন VPN ট্র্যাফিককে একটি গেটওয়ে দিয়ে রাউট করে যা সার্ভার দেখার আগেই তা LAN ঠিকানায় অনুবাদ করে। এটি সংযোগ ফিরিয়ে আনে এবং একই ধাপে পার্থক্যটি সরিয়ে দেয়।
সারণিটি ঠিকানার বদলে ভূমিকা বর্ণনা করে, আর আপনার নিজের প্রিফিক্সই ঠিক করে কোন সারি প্রযোজ্য। ব্লগ পোস্ট থেকে উদাহরণ কপি না করে সার্ভারের প্রকৃত মান প্রিন্ট করুন:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthসারণিটি একটি সিদ্ধান্তের সহায়ক, প্রতিটি স্থাপনা সম্পর্কে দাবি নয়। অতিরিক্ত ইন্টারফেস, দ্বিতীয় সাইট লিংক বা ভিন্ন মাস্কযুক্ত হোস্টের স্থানীয় সেট ভিন্ন হয়।
| Path the packet takes | Address the server records | Filter scope that admits it | What the log can still tell you |
|---|---|---|---|
| Desktop on the server LAN | Its own LAN address | LocalSubnet or the LAN prefix | Which workstation connected |
| Client on the routed VPN pool | Its tunnel address | The VPN pool as a remote address | Which VPN account connected, if the pool is logged |
| Client behind source NAT at the gateway | The gateway's LAN address | The gateway address | Only that some VPN user connected |
| Site-to-site gateway | The remote gateway's tunnel address | The remote site's prefix | Which site connected, not which user |
Microsoft-এর New-NetFirewallRule রেফারেন্স রিমোট ঠিকানা শর্ত এবং LocalSubnet কীওয়ার্ড নথিভুক্ত করে। কীওয়ার্ডটির অর্থ সব প্রাইভেট ঠিকানা — এমন সিদ্ধান্ত নেওয়ার আগে এটি পড়ুন, কারণ তা নয়।
সার্ভার আসলে কী পায় তা তুলনা করুন
কেউ মনে করে তৈরি করেছে এমন নিয়মের বদলে কার্যকর নিয়মটি পড়ুন। এটি সক্রিয় কিনা, সক্রিয় প্রোফাইলে প্রযোজ্য কিনা, এবং এর রিমোট ঠিকানা শর্ত সার্ভারের দেখা সোর্সের সঙ্গে মেলে কিনা যাচাই করুন। শুধু ডোমেইন প্রোফাইলে সক্রিয় নিয়ম নেটওয়ার্ক পরিবর্তনের পর অ্যাডাপ্টার পাবলিকে চলে গেলে কিছুই করে না।
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionপ্রথম কমান্ড ফাইল-শেয়ারিং নিয়মের সঙ্গে যুক্ত ঠিকানা ফিল্টার প্রিন্ট করে, আর দ্বিতীয়টি দেখায় কোন প্রোফাইল সক্রিয় এবং অমিল ইনবাউন্ড ট্র্যাফিক কীভাবে সামলানো হয়। একটি ব্লকিং নিয়ম এবং কেন্দ্রীয়ভাবে পরিচালিত নীতিও খুঁজুন। ব্লক নিয়মগুলো অনুমতি নিয়মের ওপর অগ্রাধিকার পায়, আর স্থানীয় নিয়ম একীভূতকরণ নিষ্ক্রিয় করা নীতি নতুন স্থানীয় ব্যতিক্রমকে নিষ্ক্রিয় করতে পারে।
এটি সেই ক্ষেত্রে যেখানে নিয়মটি কনসোলে সঠিক দেখায় কিন্তু ট্র্যাফিকে কোনো প্রভাব নেই। একই সঙ্গে প্রোফাইল নির্ধারণ যাচাই করুন, কারণ ভিন্ন নেটওয়ার্কে যোগ দেওয়া ল্যাপটপ কেউ ফায়ারওয়াল স্পর্শ না করেও পাবলিক প্রোফাইলে চলে যেতে পারে।
লগইনের আগে ট্রান্সপোর্ট পরীক্ষা করুন
পৌঁছানোর ক্ষমতাকে প্রমাণীকরণ থেকে আলাদা করুন। TCP 445-এ একটি লিসেনার প্রমাণ করে একটি সেবা পোর্টে বাঁধা আছে; এটি প্রমাণ করে না যে একটি রিমোট প্যাকেট সেখানে পৌঁছাতে পারে। সম্পূর্ণ TCP সংযোগ আবার SMB সেশন সেটআপ বা শেয়ার অনুমতি সম্পর্কে এখনো কিছুই বলে না। নিয়ম সম্পাদনার আগে উভয় দিক থেকে হ্যান্ডশেক পরীক্ষা করুন।
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailedপ্রথম কমান্ড জানায় আপনি যে মেশিনে চালাচ্ছেন সেখান থেকে TCP হ্যান্ডশেক সফল হয় কিনা, আর দ্বিতীয়টি সমাধান করা ঠিকানা ও ইন্টারফেসের বিবরণ যোগ করে। VPN ক্লায়েন্ট এবং অফিস ডেস্কটপ থেকে এটি চালিয়ে তুলনা করুন। Ping দুই প্রশ্নের কোনোটিরই উত্তর দেয় না, কারণ SMB খোলা থাকলেও ICMP ব্লক থাকতে পারে, বা ফায়ারওয়াল 445 বাদ দিলেও ICMP অনুমোদিত থাকতে পারে।
হ্যান্ডশেক শুধু VPN থেকে ব্যর্থ হলে সোর্স পরিধিই প্রধান সন্দেহভাজন। এটি সফল হয়েও শেয়ার আপনাকে প্রত্যাখ্যান করলে, ফায়ারওয়াল নিয়ম সম্পাদনার বদলে SMB সেশন ও অনুমতি নির্ণয়ে যান।
যখন সোর্স NAT পার্থক্যটি সরিয়ে দেয়
পথে অনুবাদ থাকলে সার্ভার আলাদা VPN ক্লায়েন্টদের ঠিকানা দিয়ে চিনতে পারে না। প্রত্যেক রিমোট ব্যবহারকারী গেটওয়ে হিসেবে আসে। তাদের আলাদা করার ওপর নির্ভর করা যেকোনো অনুমোদন সেখানে প্রয়োগ করতে হবে যেখানে তাদের পরিচয় এখনো দৃশ্যমান, যার অর্থ সাধারণত VPN কনসেন্ট্রেটর বা প্রমাণীকরণকারী প্রক্সি। ফায়ারওয়াল নিয়ম ট্র্যাফিক অনুমতি দিতে পারে; অনুবাদ যে পার্থক্য সরিয়েছে তা ফিরিয়ে আনতে পারে না।
একবার ওই গেটওয়ে ঠিকানা অনুমোদিত হলে প্রত্যেক রিমোট ব্যবহারকারী একক ঠিকানার অধীনে রেকর্ড হয়, তাই নিয়মটি গেটওয়েতে পৌঁছাতে পারে এমন সবাইকে পুরো পুল দিয়ে দেয়। ব্যবহারকারীভিত্তিক সিদ্ধান্ত গুরুত্বপূর্ণ হলে মূল ঠিকানাগুলো দৃশ্যমান রাখুন বা সিদ্ধান্তটি এমন স্তরে সরান যা এখনো ব্যবহারকারীকে চেনে। নাহলে প্রত্যেক রিমোট ব্যবহারকারী সার্ভারের দেখা একমাত্র ঠিকানার অনুমতি উত্তরাধিকারে পায়, আর অডিট ট্রেইল পরে তাদের আলাদা করতে পারে না। এটি নকশার সিদ্ধান্ত, ফায়ারওয়ালের খুঁটিনাটি নয়।
দুটি ডিজাইনের মধ্যে সচেতনভাবে বেছে নিন। সার্ভারকে কে সংযুক্ত হয়েছে দেখতে হলে নিয়মটি প্রকৃত VPN পুলে সীমাবদ্ধ করুন, আর অনূদিত পথটি কেবল তখনই গ্রহণ করুন যখন সার্ভারের সত্যিই সেই তথ্য দরকার নেই। বাছাই করা সোর্স রেঞ্জ নিয়মের পাশে লিখে রাখুন, কারণ পরেরবার যে এটি ডিবাগ করবে সে প্রথমে ঠিকানা সারণিতেই তাকাবে।