VPN जोडलेला असताना स्थानिक नेटवर्क उपलब्ध नाही? चार तपासण्या

टनेल वर येतो, इंट्रानेट दिसते आणि प्रिंटर उत्तर देणे थांबवतो। LAN वर काहीच बिघडलेले नाही; क्लायंटने आता स्थानिक न मानल्या जाणाऱ्या पत्त्यांसाठी कोणता मार्ग वापरायचा ते बदलले। खालील चार तपासण्या क्रमाने करा आणि एखादी ठोस विसंगती दाखवेल तिथे थांबा, कारण एकाच लक्षणाला चार सामान्य कारणे असतात आणि त्यापैकी एकच VPN संपादित करून सुटते।

प्रथम, क्लायंटने बसवलेले रूटिंग टेबल पाहा

VPN जोडलेला असताना क्लायंटचे रूटिंग टेबल उघडा। Linux वर ip route, Windows वर route print किंवा Get-NetRoute, आणि macOS वर netstat -rn वापरा। तुम्ही टनेलमधून जाणारा डीफॉल्ट मार्ग आणि भौतिक डीफॉल्टला काय झाले हे शोधत आहात।

पूर्ण टनेल क्लायंट 0.0.0.0/0 बदलण्याऐवजी बऱ्याचदा दोन अर्धे-डीफॉल्ट मार्ग जोडतो: 0.0.0.0/1 आणि 128.0.0.0/1। मूळ डीफॉल्ट दिसत राहतो पण प्रत्येक शोधात हरतो, म्हणून टेबल निरोगी दिसू शकते तर सबनेटबाहेरील सर्व रहदारी सरकते। VPN क्लायंटने स्प्लिट टनेल पर्याय दिला आणि धोरण परवानगी देत असेल, तर तेच सर्वात स्वच्छ निराकरण।

टनेल डीफॉल्ट राहणे आवश्यक असेल तर त्याऐवजी स्थानिक सबनेट पिन करा। Linux वर मार्ग भौतिक इंटरफेस आणि गेटवे नाव देतो; Windows वर -p जोडून तो कायमचा करा आणि इंटरफेस क्रमांक अंदाज न लावता route print मधून वाचा:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

पिन केलेला मार्ग तो नाव देतो तो पत्ता तसाच राहील तोपर्यंतच टिकतो। प्रत्येक कनेक्शनला Wi-Fi अडॅप्टरला नवीन क्रमांक मिळणाऱ्या लॅपटॉपवर नियम पुन्हा मोडेल, म्हणून दुरुस्ती अयशस्वी ठरली असे ठरवण्यापूर्वी इंटरफेसचा पत्ता तपासा।

दुसरे, तो पत्ता सुरुवातीलाच स्थानिक होता याची खात्री करा

गंतव्य जोडलेल्या सबनेटमध्ये असेल तर टनेलचा डीफॉल्ट कधीच लागू होत नाही आणि VPN कारण नाही। 192.168.1.0/24 असलेल्या क्लायंटवर 192.168.1.40 वरचा प्रिंटर जोडलेला मार्ग वापरतो; तो पत्ता अयशस्वी झाला तर VPN नाही, तर उपकरण, स्विच किंवा क्लायंटचा फायरवॉल पाहा।

लोकांना दिशाभूल करणारी परिस्थिती म्हणजे स्थानिक सर्व्हरसाठी सार्वजनिक पत्ता। LAN च्या आतून राउटरच्या WAN पत्त्यावर जाऊन परत येण्यासाठी हेअरपिन NAT लागते आणि अनेक राउटर पोर्ट फॉरवर्डिंगसाठी ती अंमलात आणतच नाहीत। खाजगी पत्ता सार्वजनिक पत्त्याच्या शेजारी तपासा। खाजगी पत्ता चालत असेल आणि सार्वजनिक चालत नसेल, तर VPN ने आधीपासून असलेली NAT मर्यादा उघड केली इतकेच।

होस्टनेम हे अधिक बिघडवते। स्थानिक नाव आता सार्वजनिक पत्त्यावर रिझॉल्व्ह होत असेल, तर क्लायंट परत येऊ न शकणारा मार्गच प्रयत्न करत राहील। चाचणीसाठी खाजगी पत्ता वापरा, नंतर आणखी एक पोर्ट फॉरवर्डिंग जोडण्याऐवजी नाव दुरुस्त करा।

तिसरे, आता नावांना कोण उत्तर देत आहे ते पाहा

कॉर्पोरेट रिझोल्व्हरला इंट्रानेट माहीत असते आणि NAS चे होस्टनेम, प्रिंटरचे Bonjour नाव किंवा राउटरचे स्थानिक अन्यनाव याबद्दल सहसा काहीच माहीत नसते। VPN त्याचे DNS सर्व्हर ढकलते तेव्हा ती नावे रिझॉल्व्ह होणे थांबते, जरी त्यांचे पत्ते अजूनही पोहोचण्यायोग्य असतात। नाव थेट विचारा आणि उपकरणाकडे आहे असे तुम्हाला माहीत असलेल्या पत्त्याशी उत्तराची तुलना करा।

Linux वर resolvectl query nas.local कोणत्या रिझोल्व्हरने उत्तर दिले ते दाखवते। Windows वर nslookup nas.local सर्व्हरचे नाव देते आणि ipconfig /all रिझोल्व्हरचा क्रम दाखवते। स्थानिक प्रत्यय आता कॉर्पोरेट रिझोल्व्हर हाताळत असेल, तर तो प्रत्यय स्थानिक रिझोल्व्हरकडे परत पाठवा किंवा उपकरणासाठी IP पत्ता वापरा।

शोध हा वेगळा स्तर आहे। mDNS आणि ब्रॉडकास्ट राउटेड टनेल ओलांडत नाहीत, म्हणून उपकरण पत्त्याने पोहोचण्यायोग्य असू शकते तर त्याचे नाव अदृश्य राहू शकते। रिफ्लेक्टर किंवा स्थानिक DNS नोंद ते सोडवते; मार्ग सोडवत नाही।

चौथे, दुसरे मशीनही VPN वर आहे का ते तपासा

तुम्हाला ज्या मशीनपर्यंत पोहोचायचे आहे तीही VPN क्लायंट चालवत असेल, तर तुमचे सत्र पोहोचते पण तिचे उत्तर दुसऱ्या टनेलमधून जाऊ शकते। त्यातून कनेक्शन प्रस्थापित होऊन नंतर अडकते, किंवा RDP आणि SSH प्रयत्न तुमच्या बाजूला त्रुटी न देता वेळ संपते। तुमच्या क्लायंटला दोष देण्यापूर्वी दुसऱ्या होस्टचे रूटिंग टेबल आणि त्याचा डीफॉल्ट मार्ग तपासा।

सेवा कोणत्या पत्त्यावर ऐकते तेही तपासा। फक्त टनेल पत्त्यावर बांधलेला लिसनर VPN मधून येणारी कनेक्शन स्वीकारतो आणि LAN मधून येणारी नाकारतो, राउटिंग अगदी बरोबर असली तरी। हे सेवेचे संरचना आहे, नेटवर्क मार्ग नाही, आणि VPN पत्त्यावर कुलूपबंद केलेल्या व्यवस्थापन इंटरफेसवर हे सामान्य आहे।

टनेलवर अवलंबून नसलेला व्यवस्थापन मार्ग ठेवा: तुमचे स्रोत नेटवर्क नाव देणारा स्थिर मार्ग, LAN ला जोडलेला दुसरा इंटरफेस, किंवा टनेल पूर्णपणे टाळणारा कन्सोल। सत्र कोसळल्यानंतर तो मार्ग रचणे पुढच्या कनेक्शनपूर्वी जोडण्यापेक्षा खूप कठीण आहे।

अयशस्वी तपासणीशी जुळणारी दुरुस्ती लागू करा

रूटिंग टेबलने अर्धा-डीफॉल्ट ताबा दाखवला तर धोरण परवानगी देत असेल तेव्हा स्प्लिट टनेल आणि देत नसेल तेव्हा पिन केलेला स्थानिक मार्ग निवडा। पत्ता सार्वजनिक निघाला तर चाचणी आणि नाव खाजगी पत्त्यावर हलवा। रिझोल्व्हरने हात बदलले तर स्थानिक प्रत्ययात मर्यादित ठेवा किंवा पत्ता वापरा। दुसरा होस्ट टनेलमध्ये असेल तर त्याचा परतीचा मार्ग किंवा लिसनर बाइंडिंग दुरुस्त करा।

एक गोष्ट बदला, नंतर तीच तपासणी पुन्हा करा। चुकीच्या सबनेटसाठी जोडलेला मार्ग, चुकीच्या अक्षरांचा रिझोल्व्हर प्रत्यय आणि नवीन क्रमांक मिळणाऱ्या इंटरफेसवरचा पिन केलेला मार्ग हे सर्व मूळ बिघाडासारखे दिसतात। दुरुस्ती आणि योगायोग यात फरक पुनरावृत्ती करते।

VPN जोडलेला असताना चाललेला मार्ग, पत्ता आणि रिझोल्व्हर लिहून ठेवा। पुढचे पुनर्जोडणी त्यातील किमान एक बदलेल, आणि ती नोंद पुढचा बिघाड नवीन तपासाऐवजी थोडक्यात तुलना बनवेल।