SMB 2240 VPN मार्फत: लगअन वर्कस्टेशन सूची जाँच गर्नुहोस्

टनेल हुँदै साझा फोल्डर खोल्दा त्रुटि 2240 फर्किन्छ, र पहिलो प्रवृत्ति राउटिङ हेर्ने हो। संख्या त्योभन्दा विशिष्ट छ। Windows भन्छ कि खाता यो वर्कस्टेशनबाट लगअन गर्न नसक्न सक्छ, जुन एउटा खाताबारे नीति कथन हो, पहुँचबारे कथन होइन।

त्रुटि नम्बर टिकटमा राख्नुहोस्। यसले जाँचलाई एउटा विशेषता र एउटा घटनामा सीमित गर्छ।

2240 ले वास्तवमा के जनाउँछ

नेटवर्क व्यवस्थापन त्रुटि सूचीले 2240 लाई NERR_InvalidWorkstation का रूपमा पहिचान गर्छ, यो नाम शब्दशः पढ्न लायक छ। खाता अनुमत लगअन कम्प्युटरहरूको सेटमा सीमित छ, र प्रमाणहरू प्रस्तुत गर्ने मेसिन तिनीहरूमा छैन। त्यो परिभाषामा टनेल, फाइल साझेदारी वा पासवर्डको उल्लेख छैन। विशेषता खातामा रहन्छ र लगअन प्रयास गर्दा मूल्याङ्कन गरिन्छ।

एउटै परिवारका अन्य संख्याले अरू केही जनाउँछन्। अनुमत लगअन घण्टाको उल्लंघन फरक कोड हो, र गलत पासवर्ड पनि। सबैलाई पहुँच समस्या भनी रिपोर्ट गर्दा अपरेटिङ सिस्टमले भर्खर दिएको विशिष्टता खेर जान्छ।

प्रतिबन्ध खातामा बस्छ, त्यसैले यसले पहिचानलाई जहाँ प्रमाणित भए पनि पछ्याउँछ। जो प्रयोगकर्ता हरेक दिन अफिसमा काम गर्छ र ल्यापटप घर लैजान्छ, उसले यो मेसिनको नाम बदलिँदा मात्र भेट्छ, र त्यसैले कसैले ढाँचा चिन्नुअघि यो असफलता महिनौंसम्म VPN समस्याजस्तो देखिन सक्छ।

दुई सम्बन्धित तथ्यले यसलाई व्याख्या गर्दैनन्। NAT उपकरणले खाताको विशेषतालाई छोए बिना देखिएको स्रोत ठेगाना बदल्न सक्छ, र DNS प्रत्ययको परिवर्तनले छोटो नाम सुधार्न सक्छ जबकि लगअन प्रतिबन्ध ठ्याक्कै जहाँ थियो त्यहीँ रहन्छ। दुवैलाई बाहिर राख्न लायक छ, र कुनै पनि विशेषता पढ्ने विकल्प होइन।

पहिले असफल लगअन रेकर्ड पढ्नुहोस्

फाइल सर्भरले कुन पहिचान प्रमाणित गर्यो र कुन मेसिनले त्यो प्रस्तुत गर्यो भनी निर्धारण गर्नुहोस्। डोमेन खाता, समान छोटो नाम भएको स्थानीय खाता र छुट्टै VPN खाता आपसमा बदल्न मिल्दैन, र ठ्याक्कै कुन हो थाहा भएपछि मात्र त्रुटिको अर्थ हुन्छ।

सुरक्षा लगले प्रयासलाई खाता र कल गर्ने वर्कस्टेशनको नामसँग रेकर्ड गर्छ, र प्रतिबन्ध ठ्याक्कै त्यही जोडीको विरुद्ध मूल्याङ्कन गरिन्छ:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-2)} |
  Select-Object TimeCreated,Message | Format-List
Get-ADUser -Identity jdoe -Properties LogonWorkstations |
  Select-Object SamAccountName,LogonWorkstations

पहिलो आदेशले असफलता र सर्भरले पाएको वर्कस्टेशन स्ट्रिङ देखाउँछ, र दोस्रोले खातामा अनुमत सूची देखाउँछ। क्लाइन्टको आफ्नै कम्प्युटरको नाम नै सर्भरले रेकर्ड गरेको हो भनी मान्नुको सट्टा दुवैको तुलना गर्नुहोस्। लगमा गलत देखिने नाम सामान्यतया उपयोगी खोज हो, किनकि यसले सर्भरले साँच्चै कुरा गरिरहेको ठान्ने मेसिनको नाम बताउँछ। प्रतिबन्ध ठ्याक्कै त्यही विश्वासको विरुद्ध जाँचिन्छ।

ट्राफिक त्यसबाट जान्छ भनेर VPN गेटवेको नाम नथप्नुहोस्। गेटवे प्रमाणित कलर होइन, र यसलाई सूचीमा थप्दा केही बदलिँदैन, बरु खाताको समीक्षा कठिन हुन्छ।

प्रतिबन्ध सबैभन्दा सानो दायरामा सुधार्नुहोस्

यदि मेसिनलाई अनुमति दिनुपर्छ भने, ठ्याक्कै त्यही प्रविष्टि खाताको वर्कस्टेशन सूचीमा थप्नुहोस् र बाँकी सबै जस्ताको तस्तै राख्नुहोस्। यदि होइन भने, सही उत्तर प्रतिबन्ध हटाउनु होइन, अनुमोदित मेसिन हो, किनकि यी प्रमाणहरू कहाँ प्रयोग गर्न सकिन्छ भनेर सीमित गर्न प्रतिबन्ध छ।

ठूला सम्पादन यहाँ सामान्य छन् र सामान्यतया गलत हुन्छन्। लामो अनुमत मेसिन सूची भएको खाता त्यस्तो खाता हो जसको प्रतिबन्धले अर्थ राख्न छोडेको छ।

पहिचान साझा छ कि छैन थाहा पाउनु पनि उपयोगी हुन्छ। जब धेरै मानिसले धेरै ल्यापटपबाट एउटै सेवा खाता प्रयोग गर्छन्, नीति अर्थहीन नहुन्जेल वर्कस्टेशन सूची बढ्छ, जुन डिजाइन समस्या हो, प्रशासनिक होइन।

अर्को नतिजा पढ्नुहोस्, त्यसको अनुपस्थिति होइन

अनुमोदित परिवर्तनपछि इच्छित खातासँग नयाँ अनुरोध गर्नुहोस् र के हुन्छ लेख्नुहोस्। फरक त्रुटि प्रगति हो, किनकि यसले अघिल्लो दोहोर्याउनुको सट्टा अर्को चरणको नाम बताउँछ।

DFS बाटोले धेरै सर्भर र धेरै पहुँच निर्णय ल्याउन सक्छ। एउटा खाता विशेषता सफा गर्दा तिनीहरूमध्ये एउटा टुंगिन्छ। रेफरल लक्ष्यहरू अझै पुग्न सकिने हुनुपर्छ, र ती प्रत्येकमा साझेदारी र फाइलसिस्टम अनुमतिले अझै खातालाई स्वीकार्नुपर्छ। अर्को त्रुटिलाई पनि त्यही तरिकाले पार गर्नुहोस्, पहिलो सुधारले सबै ढाक्यो भनी नमान्नुहोस्।

Windows ले वर्कस्टेशन प्रतिबन्ध रिपोर्ट गरिरहेको बेला VPN प्रोफाइल पुनः निर्माण गर्न वा पासवर्ड रिसेट गर्न कुनै कारण छैन। Microsoft को नेटवर्क त्रुटि सूची ठ्याक्कै यही कारणले खुला राख्न लायक छ: कोडले केही पनि छुनुअघि कुन विशेषता जाँच्ने भनी बताउँछ।