आउने टनेलले कुन RRAS साइट इन्टरफेस रोज्छ?
RRAS आउने साइट इन्टरफेसलाई पियर ठेगाना, प्रयोगकर्ता नाम वा प्रमाणपत्रको विषयका आधारमा रोज्छ, त्यसैले त्यो कुञ्जी यसको सक्षम र जोडिएका अवस्थाहरूबाट अलग पढ्नुहोस्।
धेरै साइट-देखि-साइट इन्टरफेस भएको Windows सर्भरमा कन्सोलको लेबल मानिसहरूका लागि मात्र टिप्पणी होइन। RRAS ले आउने जडानको कुनै निश्चित फाँट प्रयोग गरेर कुन तार्किक इन्टरफेसले जवाफ दिने निर्णय गर्छ, र त्यो फाँट प्रमाणीकरण विधिसँगै बदलिन्छ। कुञ्जी गलत भयो भने कुनै कुरा संयोगले जोडिएसम्म तपाईं इन्टरफेसका नाम फेर्दै जानुहुन्छ। छनोट नियम, प्रशासनिक अवस्था र सत्र अवस्था तीन अलग तथ्य हुन्, र तीमध्ये एउटा मात्र नामकरणसँग सम्बन्धित छ।
भ्रम: नाम फेरिएको इन्टरफेस जुनसुकैसँग मिल्छ
शाखा जोडिन नसकेको बेला लोभ्याउने उपाय भनेको कल गर्नेजस्तै देखिने बनाउन साइट इन्टरफेस बनाउनु वा नाम फेर्नु हो। त्यो एउटा प्रमाणीकरण विधिका लागि काम गर्छ र अरूका लागि चुपचाप असफल हुन्छ, त्यसैले त्यही प्रक्रिया विरोधाभासी परिणामसहित सर्छ। साइट इन्टरफेस आफ्नै गन्तव्य, संरक्षित उपसर्ग र अवस्था भएको तार्किक जडान वस्तु हो। यो इन्क्रिप्टेड प्याकेट बोक्ने भौतिक एडाप्टर होइन, त्यसैले नेटवर्क एडाप्टरतिर हेर्दा कुन साइट वस्तु छानियो भन्ने थाहा हुँदैन।
छनोटको सामान्य टाढा-पहुँच प्रयोगकर्तासँग पनि कुनै सम्बन्ध छैन। कर्मचारीका VPN क्लाइन्टले डायल गर्छन् भने तिनको भूमिका फरक हुन्छ, र तिनका प्रयोगकर्ता नाम यो म्यापिङमा कहिल्यै सहभागी हुँदैनन्। चिनजानको नामबाट केही अर्थ निकाल्नुअघि कल गर्ने को भूमिकाको हो भनी पुष्टि गर्नुहोस्।
तीन प्रमाणीकरण रूप, तीन छनोट कुञ्जी
पूर्व-साझा कुञ्जीसँग, इन्टरफेसको कन्फिगर गरिएको गन्तव्य ठेगाना आउने पियरको ठेगानासँग तुलना गरिन्छ। लेबल जे पनि हुन सक्छ, किनभने निर्णय ठेगानाले बोक्छ। प्रयोगकर्ता नाममा आधारित प्रमाणीकरणमा, इन्टरफेसको नाम कल गर्नेले प्रस्तुत गरेको प्रयोगकर्ता नामसँग तुलना गरिन्छ। यहाँ लेबल नै कुञ्जी हो, र नाम फेर्दा एउटा साइट सुधारेर अर्को बिग्रिएजस्तो देखिनुको ठ्याक्कै कारण यही हो।
प्रमाणपत्रसँग, इन्टरफेसको नाम प्रस्तुत प्रमाणपत्रको विषय नामसँग तुलना गरिन्छ। नाम त्यो विषयसँग मिल्नुपर्छ, र अपरेटरले कल्पना गरेको सुन्दर लेबलले पुग्दैन।
यसबाट दुई परिणाम आउँछन्। पूर्व-साझा कुञ्जीको व्यवस्थामा दिइएको गन्तव्यका लागि एउटा मात्र इन्टरफेस सक्षम गर्न सकिन्छ, त्यसैले एउटै देखिएको सार्वजनिक ठेगाना साझा गर्ने दुई शाखालाई नक्कली प्रविष्टिले दुवैलाई सेवा दिन सकिँदैन। र कन्सोलले जे सुझाव दिए पनि तपाईंले वास्तवमै कन्फिगर गरेको विधि नै लागू हुन्छ।
| Authentication in use | The field RRAS compares | Symptom when the two disagree |
|---|---|---|
| Pre-shared key | The peer address in the incoming connection against the interface destination | Renaming the interface changes nothing; a destination that does not match the caller stays unused |
| Username | The caller login against the interface name | A site with a friendly label never answers, while a differently named site may answer instead |
| Certificate | The subject name in the presented certificate against the interface name | An interface named after the office rather than the subject CN is never selected |
सक्षम हुनु जोडिएको हुनु होइन
प्रशासनिक स्थितिले तार्किक इन्टरफेसलाई काम गर्न अनुमति छ कि भन्छ। जडान स्थितिले अहिले सत्र छ कि भन्छ। सत्र नभएको सक्षम इन्टरफेस मागअनुसार डायल हुने लिंकका लागि सामान्य विश्राम अवस्था हो, र यसलाई खराबी भनी रिपोर्ट गर्दा मानिसहरू नभएको अवरोधको पछि दौडन्छन्।
नाम दिइएको खोज वा कागजात गरिएको राउटिङ-डोमेन खोज प्रयोग गर्नुहोस्, तर दुवै प्यारामिटर सँगै होइन, र यसलाई अभिप्रेत सर्भर सन्दर्भमा चलाउनुहोस्। तपाईंले अपेक्षा गरेको इन्टरफेस पहिलो सूचीमा छैन भने समस्या अवस्थाभन्दा अघि छ: केही पनि छानिएको छैन।
जोडीलाई अलग होइन, सँगै पढ्नुहोस्। स्थापित रहनुपर्ने र विच्छेद देखिने लिंक जाँचको योग्य छ, जबकि मागअनुसार जोडिने निष्क्रिय लिंक डिजाइनअनुसार चल्छ। यसैबीच प्रशासनिक रूपमा अक्षम गरिएको इन्टरफेस विपक्षीले आफ्नो राउटर जतिपटक पुनःसुरु गरे पनि अँध्यारै रहन्छ।
दुई मानमध्ये कुनैले पनि प्रमाणीकरण सफल भयो, वार्ता गरिएको सुरक्षा मिल्यो, मार्ग स्थापित भए वा निजी अनुप्रयोगलाई अनुमति छ भनी प्रमाणित गर्दैन। ती चार फरक प्रश्न र चार फरक उत्तर हुन्।
Get-VpnS2SInterface | Select-Object Name, Destination, AdminStatus, ConnectionState
Get-VpnS2SInterface -Name 'Branch-A' | Format-List Name, Destination, AdminStatus, ConnectionStateकेही सक्षम गर्नुअघि पहिचानको कारोबार पढ्नुहोस्
आउने कल गर्ने अपेक्षा नगरेको इन्टरफेसमा म्याप हुँदा, उपयोगी प्रमाण उसले प्रस्तुत गरेको पहिचान हो, अक्षम इन्टरफेसको सूची होइन। हालैका टाढा पहुँच घटना झिकेर कल गर्नेको ठेगाना, प्रमाणीकरणको नतिजा र छानिएको इन्टरफेसको नाम पढ्नुहोस्। अक्षम इन्टरफेस जानाजान अवकाश दिइएको साइट वा निषेधित साझेदार हुन सक्छ। एउटा लगइन त्रुटि हट्छ कि भनी त्यसलाई सक्षम गर्नु राउटिङ र पहुँचका परिणाम भएको कन्फिगरेसन परिवर्तन हो, त्यसैले निर्णय त्यो साइट सम्बन्धको मालिकमार्फत पुर्याउनुहोस्, त्यसको गन्तव्य, संरक्षित उपसर्ग र नीतिसहित।
म्यापिङ साँच्चै गलत भए लक्षण होइन, कुञ्जी सुधार्नुहोस्: प्रमाणपत्रको विषय वा प्रयोगकर्ता नामको हकमा इन्टरफेसको नाम सुधार्नुहोस्, र पूर्व-साझा कुञ्जीको हकमा गन्तव्य सुधार्नुहोस्। त्यसपछि एकपटक पुनःजोड्नुहोस् र त्यही कल गर्नेले अब अभिप्रेत वस्तु छानिरहेको पुष्टि गर्नुहोस्।
Get-WinEvent -LogName Application -MaxEvents 50 | Where-Object { $_.ProviderName -like '*RemoteAccess*' }अनुमत कार्यबाट चक्र बन्द गर्नुहोस्
हरियो अवस्था स्वीकृति होइन। सही इन्टरफेस छानिएपछि, डिजाइनले अनुमति दिने ट्राफिक एउटा संरक्षित उपसर्गको होस्टबाट अर्कोको होस्टसम्म उत्पन्न गर्नुहोस्, र जवाफ त्यही मार्गबाट फर्किएको पुष्टि गर्नुहोस्। अस्वीकार हुनुपर्ने होस्टबाट पनि त्यही प्रयास गर्नुहोस्, यो प्रयोग गरेर Test-NetConnection -ComputerName 10.44.2.10 -Port 445 डिजाइनले बाहिर राख्ने सेवाविरुद्ध, र टाढा पहुँच घटना फेरि पढ्नुहोस्। आफ्ना अभिप्रेत उपसर्गभन्दा बढी बोक्ने, वा नीतिले बाहिर राख्ने सेवाको जवाफ दिने साइट लिंक त्यस्तो राउटिङ गल्ती हो जो कुनै अवस्था-जाँचले उजागर गर्दैन।
प्रमाणीकरण विधि, छनोट कुञ्जी र अनुमत उपसर्ग सँगै साइटको सञ्चालन पुस्तिकामा लेख्नुहोस्। अर्को इन्जिनियरले त्यही तीन-मानको तालिका भेट्नेछ, र नामकरण परम्पराको अर्थ त्यो सन्दर्भ लेखिएपछि मात्र बन्छ।