आपका प्रिंटर एक घंटे पहले काम कर रहा था। फिर आपने VPN चालू किया, और अब काम कतार में पड़े रहते हैं जब तक वे विफल न हो जाएँ। संभावित कारण प्रिंटर नहीं, किल स्विच है: यह उस ट्रैफ़िक को गिरा देता है जो मशीन को सुरंग के बाहर छोड़ता, और LAN प्रिंटर ठीक वैसा ही ट्रैफ़िक है। असली फ़ैसला यह नहीं है कि प्रिंटिंग कैसे ठीक करें, बल्कि यह है कि क्या इस डिवाइस को स्थानीय नेटवर्क तक पहुँचना चाहिए। तीन शर्तें यह तय करती हैं, और उनमें से कोई भी बहस को जल्दी ख़त्म कर सकती है।

किल स्विच क्या गिराता है और क्यों

किल स्विच एक रूटिंग नियम है जिसके साथ विफलता का तरीका जुड़ा है। सुरंग चालू होने पर मेल खाते पैकेट एन्क्रिप्ट होकर बाहर जाते हैं; सुरंग गिरने पर क्लाइंट डिफ़ॉल्ट रूट को ब्लैकहोल में भेज देता है ताकि कुछ भी सादे टेक्स्ट में बाहर न जाए। एक ही सबनेट पर प्रिंटर कभी सुरंग के रूट से नहीं मिलता, इसलिए उसे भागने की कोशिश माना जाता है, भले ही ट्रैफ़िक कभी इमारत न छोड़े।

खोज लक्षण को उलझा देती है। प्रिंटर पोर्ट 5353 पर मल्टीकास्ट DNS के ज़रिए खुद का विज्ञापन करते हैं, और प्रिंटर जोड़ें संवाद में दिखने वाली कतार उन्हीं विज्ञापनों से बनती है। जब तक अवरोध सक्रिय है, विज्ञापन न आए, इसलिए प्रिंटर सूची से गायब हो जाता है, भले ही उसका पता अभी भी जवाब दे। 631 पर IPP, 9100 पर कच्ची प्रिंटिंग और 445 पर SMB बिना किसी सुरंग मार्ग के सामान्य LAN सेवाएँ हैं।

पहले साबित करें कि प्रिंटर पहुँच में है

कोई भी नीति बदलने से पहले पुष्टि करें कि प्रिंटर ठीक है और उस पते की पुष्टि करें जो आपके अनुसार उसका है। पता प्रिंटर के पैनल या उसके अपने वेब पेज से पढ़ें। ऑपरेटिंग सिस्टम की सूची में पुरानी प्रविष्टि ऐसे पते की ओर इशारा कर सकती है जो DHCP ने हफ़्तों पहले किसी दूसरे डिवाइस को दिया था।

VPN डिस्कनेक्ट करें, फिर पता और दो सामान्य प्रिंट पोर्ट जाँचें:

nc -vz 192.168.1.50 9100
nc -vz 192.168.1.50 631

Windows में समकक्ष Test-NetConnection 192.168.1.50 -Port 9100 है। VPN फिर से जोड़ें और दोहराएँ। अगर पोर्ट VPN बंद होने पर जवाब देते हैं और चालू होने पर समय समाप्त हो जाता है, तो आपने अवरोध दोहरा लिया है और बाकी नीति का सवाल है। अगर वे दोनों स्थितियों में विफल होते हैं, तो रुकें: प्रिंटर, Wi-Fi सेगमेंट या क्लाइंट आइसोलेशन दोषी है, और VPN अपवाद केवल जोखिम बढ़ाएगा।

अनुमति या अवरोध तय करने वाली तीन शर्तें

इन्हें क्रम से चलाएँ। पहली शर्त जो विफल होती है वही नतीजा तय करती है, इसलिए बाद वालों को जाँचने की ज़रूरत नहीं।

ConditionAllow a scoped exceptionKeep the block
Who owns the networkHome or single-tenant office where you control the segmentHotel, cafe or shared Wi-Fi where the printer is not yours
Who owns the device policyPersonal device with no enforced profileManaged profile that enforces always-on VPN
What the device carriesNothing another LAN peer must not reachClient data that must not touch an untrusted segment

अतिथि नेटवर्क सबसे स्पष्ट 'नहीं' हैं। होटल सेगमेंट में स्थानीय रेंज हर दूसरा मेहमान है, इसलिए जो अपवाद आपके प्रिंटर तक पहुँचता है वह उनके लैपटॉप तक भी पहुँचता है। जो प्रिंटर आपका नहीं है वह उस सेगमेंट को खोलने का कारण नहीं है।

प्रबंधित डिवाइस दूसरा 'नहीं' हैं। जब प्रशासक प्रोफ़ाइल लॉकडाउन के साथ हमेशा-चालू VPN थोपता है, तो क्लाइंट किसी भी स्थानीय बदलाव के बाद अवरोध फिर लागू कर देता है, और यह उपाय आपकी स्वीकार की गई नीति का उल्लंघन कर सकता है। ऐसी सेटिंग्स बदलने के बजाय जो फिर लिख दी जाएँगी, समर्थित स्थानीय-संसाधन मार्ग माँगें।

आपका क्लाइंट जो सबसे छोटा अपवाद समर्थित करता है

आप एक प्रिंटर पते के लिए गंतव्य-सीमित नियम चाहते हैं, व्यापक allow-local टॉगल नहीं। व्यापक टॉगल आमतौर पर पूरी निजी रेंज और लिंक-लोकल ट्रैफ़िक को कवर करता है, जो एक प्रिंट कतार की ज़रूरत से कहीं अधिक है, और यह सेगमेंट के हर डिवाइस को आपका स्वीकार किया हुआ साथी बना देता है।

Windows स्प्लिट टनलिंग देता है, और कुछ बिल्ड स्थानीय-नेटवर्क विकल्प भी देते हैं। जहाँ एकमात्र समर्थित मार्ग होस्ट प्रविष्टि है, वहाँ सुरंग बनने के बाद भौतिक गेटवे से एक ही पता जोड़ें, उदाहरण के लिए route add 192.168.1.50 mask 255.255.255.255 192.168.1.1, और सत्र खत्म होने पर उसे हटा दें। WireGuard अलग तरह से काम करता है: AllowedIPs तय करता है कि सुरंग में क्या प्रवेश करेगा, इसलिए पूर्ण-सुरंग 0.0.0.0/0 प्रोफ़ाइल प्रिंट कार्य को अंतिम बिंदु तक ले जाता है, जब तक कोई अधिक विशिष्ट रूट उसे नहीं बचाता, और wg-quick ऐसे फ़ायरवॉल नियम स्थापित कर सकता है जो बाकी सब कुछ अवरुद्ध कर दें।

Android में जो हमेशा-चालू सेटिंग VPN के बिना कनेक्शन रोकती है वही किल स्विच है, और उस अवरोध के भीतर किसी ऐप से प्रिंटर खोजने का कोई LAN मार्ग नहीं है। प्रति-ऐप और अपवाद मॉडल Android VPN पृष्ठ पर प्रलेखित है, और कुछ भी बदलने से पहले वहीं देखना चाहिए: Android VPN कनेक्टिविटी गाइड। हाल के macOS संस्करण सुरंग से अलग स्थानीय नेटवर्क अनुमति माँगते हैं, और iOS स्थानीय नेटवर्क पहुँच के लिए वही करता है, फिर भी सुरंग चालू होने पर कतार विफल हो सकती है क्योंकि विक्रेता का क्लाइंट सबनेट को उसके भीतर रूट करता है।

आप जो भी क्लाइंट इस्तेमाल करें, अपवाद को एक ही पते तक सीमित रखें और उन दो या तीन पोर्ट तक जो प्रिंटर वास्तव में इस्तेमाल करता है। नियम को पूरे सबनेट तक बढ़ाने के बजाय DHCP लीज़ आरक्षित करें, क्योंकि पता बदल सकता है।

अपवाद को सत्यापित करें और जानें कि इसे कब हटाना है

बदलाव के बाद फिर से जुड़ें और क्रम से तीन चीज़ें जाँचें। प्रिंटर अपने पोर्ट पर जवाब देता है, एक हानिरहित परीक्षण पृष्ठ छपता है, और पता खोज अब भी आपके ISP के बजाय VPN अंतिम बिंदु लौटाती है। अगर प्रिंटिंग काम करती है लेकिन खोज आपका ISP दिखाती है, तो आपने प्रिंटर से अधिक खोल दिया है और पीछे हटना चाहिए।

रीबूट के बाद और किसी भी क्लाइंट या प्रोफ़ाइल अपडेट के बाद परीक्षण दोहराएँ, क्योंकि अपडेट डिफ़ॉल्ट को इतनी बार बहाल करते हैं कि वह मायने रखता है। जो अपवाद अगले पुनःकनेक्शन तक ही टिके वह निर्णय नहीं, अस्थायी छेद है। सटीक नियम लिख लें ताकि आप उसे जानबूझकर हटा सकें।

अगर डिवाइस केवल सुरंग के लिए है, यात्रा का लैपटॉप या ग्राहक डेटा वाली मशीन, तो सही जवाब है अवरोध रखना और कहीं और छापना: PDF में सहेजें और फ़ोन या दूसरी मशीन से छापें, या ऐसे प्रिंट सर्वर तक पहुँचें जिसे सुरंग रूट कर सके। एक काम के लिए किल स्विच बंद करना असली सुरक्षा को थोड़ी सुविधा से बदल देता है।

संबंधित लेख