येणारा टनेल कोणते 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 रचना वगळते अशा सेवेविरुद्ध, आणि दूरस्थ प्रवेश घटना पुन्हा वाचा. आपल्या इच्छित उपसर्गांपेक्षा जास्त वाहून नेणारी, किंवा धोरण वगळते अशा सेवेला उत्तर देणारी साइट लिंक ही अशी राउटिंग चूक आहे जी कोणतीही स्थिती-तपासणी उघड करणार नाही.
प्रमाणीकरण पद्धत, निवड किल्ली आणि परवानगी असलेले उपसर्ग साइटच्या संचालन पुस्तिकेत एकत्र नोंदवा. पुढील अभियंत्याला तीच तीन-मूल्यांची तक्ता भेटेल, आणि नामकरणाची प्रथा तो संदर्भ लिहिल्यावरच अर्थपूर्ण होते.