Windows वर VPN स्थानिक LAN अडवते: रूट की क्लायंट धोरण?
Windows वर स्थानिक LAN प्रवेश दोन वेगळ्या कारणांनी तुटतो: गहाळ रूट, किंवा सबनेट टाकून देणारे गेटवे धोरण. तीन तपासण्या कोणते ते सांगतात.
तुमच्या स्वतःच्या डेस्कवरील प्रिंटर, NAS किंवा डेव्हलपमेंट बॉक्स कामाचे VPN जोडले जाते त्या क्षणी प्रतिसाद देणे थांबवते। कधी एका रूट कमांडमुळे ते काही सेकंदात ठीक होते; कधी तोच रूट बरोबर असतो आणि पॅकेट तरीही गायब होतात, म्हणजे तुम्ही सारख्याच लक्षणांची दुसरी समस्या पाहत आहात। निर्णय तीन प्रश्नांवर येतो, आणि ते चुकीच्या क्रमाने विचारणे हेच लोक संपूर्ण संध्याकाळ रूट काढून पुन्हा जोडण्यात घालवण्याचे कारण आहे।
कोणत्याही कमांडपूर्वी तीन प्रश्न
पहिला: स्थानिक प्रीफिक्ससाठी नोंद आहे का, आणि ती भौतिक अ‍ॅडॉप्टरकडे निर्देश करते का? दुसरा: जोडताना क्लायंटला गेटवेकडून स्थानिक नेटवर्कची परवानगी की नकार मिळतो? तिसरा: तुम्हाला फक्त LAN मध्ये बाहेर जाण्याचा प्रवेश हवा आहे, की इंटरनेटवरील काहीही तुमच्या मशीनवर चालणाऱ्या सेवेपर्यंत पोहोचले पाहिजे?
पहिला प्रश्न राउटिंग दोषाला फिल्टरिंग दोषापासून वेगळा करतो। दुसरा सांगतो की रूट दुरुस्तीला अजिबात काम करण्याची परवानगी आहे का। तिसरा दुरुस्ती बदलतो: रूट बाहेर जाणारा रहदारी सुधारतो, तर पोहोच न होणारी आत येणारी सेवा सामान्यतः लिसनर बाइंडिंग आणि परतीच्या मार्गाची समस्या असते, जी रूट अधिक बिघडवते।
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
प्रश्न एक: रूट, फिल्टर की नाव
काहीही जोडण्यापूर्वी तक्ता वाचा। इंटरफेस इंडेक्स महत्त्वाचा आहे, कारण खालील प्रत्येक रूट कमांड त्यालाच जोडलेली आहे:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricथेट जोडलेले सबनेट टनेल सुरू असतानाही सामान्यतः ऑन-लिंक रूट ठेवते, त्यामुळे नोंद असूनही रहदारी अयशस्वी होऊ शकते। हे संयोजन राउटिंगनंतर चालणाऱ्या फिल्टरची खूण आहे, आणि दुसरा, अधिक विशिष्ट रूट काहीच बदलत नाही अशी हीच स्थिती।
पत्त्यानुसार आणि नावानुसार वेगवेगळे तपासा। जर ping 192.168.1.50 प्रतिसाद देत असेल आणि net view 192.168.1.50 देत नसेल, तर राउटिंग तक्ता कधीच समस्या नव्हता: टनेलने रिझॉल्व्हर बदलला आणि स्थानिक नाव आता सुटत नाही। त्यासाठी रूट जोडणे व्यर्थ काम आहे।
प्रश्न दोन: गेटवे स्थानिक LAN प्रवेशाला परवानगी देतो का?
व्यावसायिक क्लायंट केवळ रूटपेक्षा जास्त स्थापित करतो। त्याला जोडताना धोरण मिळते, आणि त्या धोरणात स्थानिक नेटवर्कची स्पष्ट परवानगी असू शकते। Cisco IPsec तैनातीत गट धोरण split-tunneling सेटिंग आणि स्थानिक LAN प्रवेशाचा वेगळा ध्वज वाहते; क्लायंटमधील चेकबॉक्स ही गेटवे नाकारू शकणारी विनंती आहे। AnyConnect मध्ये प्रोफाइल split च्या समावेश आणि वगळण्याच्या याद्या आणि तीच परवानगी नियंत्रित करते। Windows RRAS वर समतुल्य म्हणजे प्रोफाइलमधील डीफॉल्ट गेटवे पर्याय आणि सर्व्हर देत असलेले स्थिर रूट।
ध्वज बंद असताना, दस्तऐवजीकृत वर्तन असे आहे की वैध, अधिक विशिष्ट रूट असूनही क्लायंट थेट जोडलेल्या सबनेटकडे जाणारी रहदारी अडवतो। म्हणूनच क्लायंटच्या मालकीचे नसलेले रूटही जोडल्यानंतर काही सेकंदात गायब होऊ शकतात: क्लायंटला सांगितलेली स्थिती पुन्हा तयार करत आहे, तुमच्याशी भांडत नाही।
क्लायंट लॉग जोडताना निर्णय नोंदवतो, आणि तो वाचणे मशीनवरील कोणत्याही प्रयोगापेक्षा वेगवान आहे। लॉग सांगत असेल की स्थानिक प्रवेश अडवला आहे, तर थांबा: कोणतीही कमांड-लाइन दुरुस्ती त्यावर मात करत नाही, आणि उरलेले मार्ग म्हणजे धोरण बदल, टनेलमधून संसाधनापर्यंत पोहोचणे, किंवा क्लायंटला व्हर्च्युअल मशीनमध्ये ठेवून होस्ट स्थानिक नेटवर्कवर सोडणे।
प्रश्न तीन: तुम्हाला कोणती दिशा हवी आहे?
जवळच्या उपकरणाकडे जाणारी बाहेरची रहदारी हा राउटिंगचा प्रश्न आहे। LAN प्रीफिक्स स्थानिक गेटवेकडे टनेलच्या डीफॉल्ट रूटला हरवण्याइतक्या कमी मेट्रिकसह वळवा:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pदुसरे स्वरूप एकच उपकरण पिन करते, आणि एकच पत्ता संपूर्ण गरज असताना तुम्हाला तेच हवे असते। netsh समतुल्य तोच निर्णय इंडेक्सऐवजी इंटरफेस नावाने नोंदवते:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentपत्ता आणि मास्क जुळत नसल्यास रूट कमांड पॅरामीटर चुकीचा आहे ने अयशस्वी होतात, उदाहरणार्थ /24 मास्क असलेला होस्ट पत्ता। सबनेट रूटसाठी नेटवर्क पत्ता आणि एका होस्टसाठी होस्ट मास्क वापरा।
आत येणारी रहदारी वेगळी आहे। त्याच मशीनवरील VNC किंवा SSH सर्व्हर पोहोच न होणारा होतो जेव्हा आत येणाऱ्या कनेक्शनची उत्तरे VPN गेटवेमधून बाहेर जातात आणि कधीही परत येत नाहीत। रूटला हात लावण्यापूर्वी सेवा कशावर ऐकते ते तपासा:
netstat -ano | findstr :5900एका विशिष्ट पत्त्याला बांधलेला लिसनर दुसऱ्या इंटरफेसवर प्रतिसाद देणार नाही। त्याला सर्व इंटरफेसना बांधणे हा जाणीवपूर्वक निर्णय आहे, जो तुम्ही विश्वास ठेवता त्या नेटवर्कपर्यंत मर्यादित फायरवॉल नियमासोबत घेतला जातो। त्यानंतरच रूट दुरुस्ती परतीचा मार्ग पुनर्संचयित करते।
जुळणारा सर्वात लहान बदल लागू करा
दुसरी सामान्य चाल IPv4 प्रगत गुणधर्मांमध्ये “दूरस्थ नेटवर्कवर डीफॉल्ट गेटवे वापरा” वरील टिक काढणे आहे। यामुळे इंटरनेट रहदारी स्थानिक राहते, पण एकाच वेळी दोन गोष्टी घडतात: VPN डीफॉल्ट मार्ग राहत नाही, आणि क्लायंट दूरस्थ नेटवर्कसाठी रूट, multicast सह, घेणे थांबवतो। टिक काढा आणि दूरस्थ LAN नाहीशी होते, जोपर्यंत सर्व्हर प्रत्येक क्लायंटला आवश्यक असलेले विशिष्ट दूरस्थ प्रीफिक्स ढकलत नाही।
ही विषमता कामाचा क्रम ठरवते। दूरची बाजू पूर्णपणे पोहोचण्यायोग्य राहिली पाहिजे असेल, तर सर्व्हरकडून दूरस्थ सबनेट ढकला आणि स्थानिक डीफॉल्टला हात लावू नका। सर्व्हर बदलता येत नसेल, तर टनेलने दिलेल्या पत्त्याद्वारे दूरस्थ प्रीफिक्सवर कायमस्वरूपी रूट जोडा, आणि route print ने तपासा की प्रीफिक्स VPN इंटरफेसकडे आहे तर डीफॉल्ट अजूनही भौतिक गेटवेकडे आहे।
नंतर दुरुस्ती पुन्हा जोडणीत टिकते याची खात्री करा, कारण कायमस्वरूपी नसलेले रूट अ‍ॅडॉप्टरसोबत मरतात आणि प्रत्येक जोडणीनंतर चालणारी स्क्रिप्ट ही त्यांच्यासाठी प्रामाणिक जागा आहे। त्याच सत्रात एक स्थानिक उपकरण आणि एक दूरस्थ संसाधन तपासा, डिस्कनेक्ट करा, पुन्हा जोडा आणि पुन्हा तपासा। रूट बरोबर दिसत असतानाही स्थानिक उपकरण अयशस्वी झाले, तर प्रश्न दोनकडे परत जा: क्लायंट फिल्टर करत आहे, आणि उत्तर धोरण बदल आहे, दुसरा स्पर्धात्मक रूट नाही।