VPN कनेक्ट होताच प्रिंटर ऑफलाइन? रूट टेबल तपासा

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

पहिली पायरी: प्रिंटर अजूनही LAN वर पोहोचण्यायोग्य आहे हे सिद्ध करा

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

हा लॅपटॉप सोडून सर्वत्र प्रतिसाद देत असेल, तर लॅपटॉपमध्येच राहणारी राउटिंग किंवा नाव-निराकरणाची समस्या आहे, आणि पुढची पायरी दोन्हीपैकी कोणती आहे हे सांगेल।

दुसरी पायरी: Windows प्रत्यक्षात कोणता रूट निवडतो ते शोधा

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

Find-NetRoute -RemoteIPAddress 192.168.1.50
route print -4
tracert -d 192.168.1.50

Find-NetRoute विजयी रूट आणि त्याचा इंटरफेस छापतो, आणि बाकी सर्व या दोन तथ्यांवर अवलंबून आहे। route print -4 आसपासच्या नोंदी दाखवतो, त्यात पूर्ण-टनेल क्लायंट स्थापित करतात ते दोन अर्ध-डीफॉल्टही आहेत: 0.0.0.0/1 आणि 128.0.0.0/1, जे एकत्रितपणे संपूर्ण IPv4 जागा व्यापतात पण 0.0.0.0/0 ला कधीही बदलत नाहीत। /1 हा /0 पेक्षा लांब आहे, पण तुमचा 192.168.1.0/24 त्याहूनही लांब आहे, म्हणूनच गहाळ LAN रूट टनेलच्या दाव्यापेक्षाही महत्त्वाचा आहे।

उत्तर दोन नियम ठरवतात। सर्वात लांब जुळणारा प्रीफिक्स पहिला जिंकतो, आणि एकाच प्रीफिक्सच्या नोंदींमध्ये कमी एकूण मेट्रिक जिंकते, जिथे एकूण रूट मेट्रिक आणि इंटरफेस मेट्रिक एकत्र करते। निवडलेला इंटरफेस टनेल असेल तर पुढे जा। तो भौतिक अडॅप्टर असेल आणि रहदारी तरीही अपयशी ठरेल, तर इथेच थांबा: तुमची समस्या नाव-निराकरण किंवा प्रिंटरची स्वतःची प्रवेश यादी आहे, VPN रूट नाही।

तिसरी पायरी: गेटवे आणि इंटरफेस नाव देणारा सर्वात अरुंद रूट जोडा

दुरुस्ती म्हणजे प्रिंटरचा पत्ता स्थानिक अडॅप्टरवरील स्थानिक राउटरकडे वळवणारी एक नोंद। ती एलिव्हेटेड प्रॉम्प्टमध्ये चालवा आणि नुकतीच वाचलेली मूल्ये भरा।

route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 if 12 -p

if चे मूल्य भौतिक अडॅप्टरचा इंटरफेस इंडेक्स आहे। ते वगळणे हेच कमांड यशस्वी वाटूनही काहीही न बदलण्याचे सर्वात सामान्य कारण आहे, कारण एकाच पुढच्या हॉपपर्यंत पोहोचू शकणारे दोन अडॅप्टर असतील तर Windows तुम्हाला नको असलेला निवडण्यास मोकळा आहे। -p फ्लॅग नोंद कायमची करतो, त्यामुळे ती सत्रासोबत मरण्याऐवजी रीबूटनंतरही टिकते।

एका उपकरणासाठी संपूर्ण 192.168.1.0/24 साठीच्या रूटपेक्षा होस्ट रूटला प्राधान्य द्या। सबनेट रूट कामाला आवश्यकतेपेक्षा रुंद आहे, आणि कॉर्पोरेट बाजूही तोच प्रीफिक्स वापरते त्या क्षणी तो टकरतो: मग एका प्रीफिक्सचे दोन मालक असतात, आणि कोणती नोंद जिंकते यावर ठरते की तुम्ही प्रत्यक्षात कोणत्या नेटवर्कपर्यंत पोहोचू शकता।

उलट दिशेने, जर तुम्ही डीफॉल्ट-गेटवे पर्याय पुसला असेल LAN चे संरक्षण करण्यासाठी VPN कनेक्शनवर, तर दूरचे खाजगी प्रीफिक्सही सोडवले जाणे थांबते। त्यांच्यासाठी VPN इंटरफेसद्वारे त्याच पद्धतीने रूट जोडा, नाहीतर टनेल काहीही न वाहणारी कडी होईल।

चौथी पायरी: अपवाद पुढच्या कनेक्शनपर्यंत टिकेल याची खात्री करा

अनेक कॉर्पोरेट क्लायंट प्रत्येक कनेक्शनला त्यांचा संपूर्ण रूट संच पुन्हा स्थापित करतात आणि तसे करताना इंटरफेस मेट्रिक पुन्हा मोजतात, त्यामुळे काल काम करणारा रूट आज मागे पडू शकतो। पुन्हा कनेक्ट झाल्यावर प्रिंटरसाठी Find-NetRoute पुन्हा चालवा आणि इंटरफेस अजूनही भौतिक अडॅप्टरशी जुळतो का ते तपासा। नोंद गेली असेल, तर काहीतरी ती हटवत आहे; कायमचा रूट टेबल झाडणाऱ्या एजंटपासून तुमचे रक्षण करत नाही। VPN जोडल्यानंतर रूट पुन्हा जोडणारी नियोजित कार्ये हा नेहमीचा उपाय आहे, आणि डॉक किंवा ड्रायव्हर अद्ययावतनंतर अडॅप्टर इंडेक्स बदलल्यावर तुटणारा उपायही तोच आहे।

IPv6 कडे स्वतंत्रपणे लक्ष द्या। फक्त IPv4 डीफॉल्टचा दावा करणारा क्लायंट IPv6 डीफॉल्ट रूट भौतिक अडॅप्टरवर ठेवू शकतो, त्यामुळे IPv6 ने पोहोचण्यायोग्य प्रिंटर IPv4 अपयशी ठरत असतानाही चालू राहतो, किंवा उलट। रूट टेबल निर्दोष आहे असे ठरवण्यापूर्वी ping -4 आणि ping -6 ने चाचणी करा।

स्थानिक शॉर्टकट तुम्हाला किती महाग पडतो

टनेलला बगल देणारा कोणताही रूट टनेलच्या वचनातील छिद्र आहे। त्या पत्त्याकडची रहदारी आता कॉर्पोरेट गेटवेमधून जात नाही, म्हणजे त्यावर कोणतीही तपासणी, लॉगिंग किंवा धोरण अंमलबजावणी नाही। व्यवस्थापित उपकरणावर ते पसंतीऐवजी अनुपालनाची समस्या असू शकते, म्हणून स्वतःहून एक जोडण्यापूर्वी अधिकृत स्प्लिट-टनेल अपवाद आहे का ते विचारा। तुमचा रूट कामाइतका अरुंद आणि परिस्थिती परवानगी देईल तितका अल्पकालीन ठेवा।

बदलानंतर प्रिंटरने प्रतिसाद दिला तर दुरुस्ती टिकली असे गृहीत धरण्याऐवजी पुढच्या पुनःजोडणीनंतर चारही तपासण्या पुन्हा करा। प्रतिसाद दिला नाही तर जोडणीपूर्वी आणि नंतर Find-NetRoute चे आउटपुट घ्या; फरक सांगेल की क्लायंटने नोंद हटवली की फक्त पुनर्रचना केली।