Windows-এর VPN 255.255.255.255 দেখাচ্ছে: মাস্ক কি ভুল?
পয়েন্ট-টু-পয়েন্ট টানেলে হোস্ট মাস্ক স্বাভাবিক। ইন্টারফেসের মডেল নিশ্চিত করুন, ব্যর্থ হোস্টের রুট পড়ুন এবং DNS-কে সেবা প্রবেশ থেকে আলাদা করুন।
টানেল সংযুক্ত হয়, আপনি অ্যাডাপ্টারের বিবরণ খোলেন এবং মাস্ক 255.255.255.255 দেখায়। অফিসের LAN-এর 255.255.255.0-এর তুলনায় এটি ভাঙা দেখায়, এবং ভুল সাধারণত এখান থেকেই শুরু হয়। পয়েন্ট-টু-পয়েন্ট লিংকে হোস্ট মাস্ক স্থানীয় প্রান্তের সঠিক বর্ণনা, এবং দূরের নেটওয়ার্কগুলি সংযুক্ত সাবনেটের বদলে রুট হিসেবে আসে। নিচের পদ্ধতি দুটি প্রশ্ন আলাদা করে যাতে কেবল দেখানো মান ঠিক করতে চালু DHCP স্কোপ আবার না বানান।
পয়েন্ট-টু-পয়েন্ট লিংক Ethernet খণ্ড নয়
Ethernet ইন্টারফেসের সাবনেট মাস্ক দরকার কারণ ওই পরিসরের প্রতিটি ঠিকানা একই কেবলে সম্ভাব্য পৌঁছনোযোগ্য। PPP ধাঁচের টানেলের অন্য প্রান্তে ঠিক একটি সঙ্গী থাকে। এখানে কোনো ব্রডকাস্ট ডোমেন নেই, ARP নেই এবং স্থানীয় ঠিকানার একটি পরিসর বর্ণনা করার কোনো কারণ নেই।
ওই মডেলের জন্য ঠিকানা আলোচনা RFC 1332-এ সংজ্ঞায়িত, যা বলে দুই প্রান্ত তাদের ঠিকানা নিয়ে কীভাবে সম্মত হয়। এটি যা করে না তা হল ক্লায়েন্টকে অফিসের LAN সরাসরি সংযুক্ত নেটওয়ার্ক হিসেবে দেওয়া। ক্লায়েন্ট শেখে অফিস কোথায়, লিংক দিয়ে রুট ইনস্টল করে, এবং সেই রুটগুলিই আসলে পৌঁছনো নির্ধারণ করে।
এর মানে এই নয় যে আপনি যে মাস্ক দেখবেন তা সঠিক। ভুলভাবে কনফিগার করা ক্লায়েন্টও অদ্ভুত ঠিকানা তৈরি করতে পারে। বিষয়টি সংকীর্ণ: এই ধরনের অ্যাডাপ্টারে হোস্ট মাস্ক প্রত্যাশিত, তাই এটি নিজে থেকেই ত্রুটির প্রমাণ নয়।
ধাপ 1: ইন্টারফেস মডেল নিশ্চিত করুন
এটি কী বলে তা বিচার করার আগে দেখুন অ্যাডাপ্টারটি কী। বিবরণ স্ট্রিং ড্রাইভার শনাক্ত করে, এবং বরাদ্দ করা ঠিকানায় প্রিফিক্সের দৈর্ঘ্য নিশ্চিত করে ক্লায়েন্ট কী নিয়ে সম্মত হয়েছে:
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtuতৃতীয় কমান্ডটিই বেশিরভাগ বিতর্ক শেষ করে। কম সর্বোচ্চ ট্রান্সমিশন ইউনিট এনক্যাপসুলেটেড লিংকের বৈশিষ্ট্য, যখন Ethernet-এর মতো মান আলাদা ভার্চুয়াল অ্যাডাপ্টার মডেলের দিকে ইঙ্গিত করে। যদি বিবরণে PPP বা RAS ড্রাইভারের নাম থাকে এবং প্রিফিক্স 32 হয়, আপনি উপরে বর্ণিত ডিজাইনটিই দেখছেন এবং মাস্ক নিয়ে চিন্তা ছাড়তে পারেন।
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
ধাপ 2: ব্যর্থ গন্তব্যের রুট পড়ুন
পৌঁছনো প্রতিটি গন্তব্যের জন্য নির্ধারিত হয়, এবং একটি সংযুক্ত ইন্টারফেস এ সম্পর্কে কিছু বলে না। রাউটিং টেবিলকে সরাসরি সেই ঠিকানাটি জিজ্ঞাসা করুন যেখানে ব্যবহারকারী সত্যিই পৌঁছাতে চাইছে:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute সরাসরি উত্তর: এটি সেই ইন্টারফেস ও উৎস ঠিকানা বলে যা সিস্টেম ওই গন্তব্যের জন্য ব্যবহার করবে। যদি এটি টানেল ফেরত দেয়, ওই হোস্টের ট্রাফিক টানেল দিয়ে যায় এবং মাস্ক কখনোই সমস্যা ছিল না।
যদি এটি ভৌত অ্যাডাপ্টার ফেরত দেয়, দুটি সম্ভাব্য রুট ও তাদের মেট্রিক তুলনা করুন। আরও নির্দিষ্ট স্থানীয় রুট, অন্য ক্লায়েন্ট থেকে বেঁচে যাওয়া এন্ট্রি বা ভৌত পথে কম মেট্রিক সবই চওড়া টানেল রুটকে হারায়। দৃশ্যমান ফল এমন একটি সম্পদ যা পৌঁছনোয় নয়, যখন বাকি সব কাজ করছে। দীর্ঘ প্রিফিক্স সবসময় জেতে, তাই বিজয়ী প্রায়ই এমন হোস্ট রুট যা কেউ মাস কয়েক আগে যোগ করেছিল আর ভুলে গিয়েছিল।
এখানে দুই দিকও যাচাই করুন। সার্ভারের দিকে রুট প্রয়োজন কিন্তু যথেষ্ট নয়, কারণ উত্তরও টানেল দিয়ে ফিরতে হবে। যখন একটি অভ্যন্তরীণ হোস্ট কাজ করে আর অন্যটি করে না, পার্থক্য সাধারণত এই টেবিলেই থাকে, অ্যাডাপ্টারের কনফিগারেশনে নয়।
ধাপ 3: নাম সমাধানকে সেবা প্রবেশ থেকে আলাদা করুন
যে অ্যাপ্লিকেশন শেয়ার খোলে না তা দুটি খুব আলাদা ধাপের একটিতে ব্যর্থ হতে পারে। নাম সমাধান করুন, তারপর ঠিকানায় পৌঁছান। যদি প্রথমটি ব্যর্থ হয় আর দ্বিতীয়টি কাজ করে, টানেল ঠিক আছে আর সমাধানকারী নয়:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445সফল ঠিকানা পরীক্ষার সঙ্গে ব্যর্থ নাম পরীক্ষা সমস্যাটিকে সমাধানে স্থানীয়করণ করে, এবং দ্বিতীয় কমান্ড দেখায় টানেল ইন্টারফেস সত্যিই সার্ভার পেয়েছে কি না। অনেক ক্লায়েন্ট DNS-কে টানেল কনফিগারেশনের অংশ হিসেবে ঠেলে দেয়, এবং যে প্রোফাইল ওই ঠেলা অপশনগুলি উপেক্ষা করে তা মেশিনটিকে এমন সমাধানকারীর সঙ্গে রেখে দেয় যা ব্যক্তিগত অঞ্চল দেখে না।
কাজ করা ঠিকানাকে স্থায়ী সমাধান ভাববেন না। ঠিকানা দিয়ে সংযোগ নাম সমাধান এড়িয়ে যায় এবং অ্যাপ্লিকেশন যা অন্যথায় করত সেই সার্ভার পরিচয় যাচাই দুর্বল করতে পারে। এটি সাময়িক সমাধানের ছদ্মবেশে নিরাপত্তা পতন। এটি ত্রুটি চিহ্নিত করতে ব্যবহার করুন, তারপর সমাধান ঠিক করুন।
প্রত্যাবর্তন: দেখানো মানের কারণে DHCP আবার তৈরি করবেন না
যদি আপনি ঠিকানা সেবা বদলানো শুরু করে থাকেন, থামুন এবং দেখুন আপনি যা বদলেছেন তার কিছু ভারবাহী কি না। স্কোপ আবার তৈরি করা, লিজ আবার জারি করা বা পুল সরানো এমন অবস্থা বদলায় যার উপর অন্য ক্লায়েন্ট নির্ভর করে, এবং এর কোনোটিই পয়েন্ট-টু-পয়েন্ট অ্যাডাপ্টারে হোস্ট মাস্ক দিয়ে ন্যায্য নয়।
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445এই তিনটি যেকোনো লক্ষ্যভিত্তিক পরিবর্তনের পরে চালান এবং আগের রানের সঙ্গে তুলনা করুন। উপকারী ফল হল সম্পদ পর্যন্ত নথিভুক্ত পথ, এমন অ্যাডাপ্টার নয় যার মাস্ক অফিসের LAN-এর মতো দেখায়।
তারপর লিখুন মাস্কের আসলে কী অর্থ ছিল, কারণ পরের ব্যক্তি একই সংলাপ খুলবে এবং একই ভুল সিদ্ধান্তে পৌঁছাবে। প্রোফাইল নোটে একটি বাক্য, যে টানেল পয়েন্ট-টু-পয়েন্ট এবং দূরের সাবনেট রুট হিসেবে আসে, পরের বার পুরো তদন্ত বাঁচায়।