क्या रोमिंग VPN क्लाइंट ऑफ़िस के लिए सेवा होस्ट कर सकता है?

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

डायल-इन की दिशा सेवा की दिशा के बारे में कुछ नहीं कहती

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

ऐसी इन्वेंटरी प्रणाली की कल्पना करें जो रोमिंग लैपटॉप पर एजेंट से पूछताछ करती है, या ऐसे डेवलपर की जिसे घर के वर्कस्टेशन से परीक्षण API चाहिए। दोनों चाहते हैं कि ऑफ़िस पक्ष बातचीत शुरू करे, जो सामान्य क्लाइंट-से-सर्वर पैटर्न का उल्टा है।

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

पोर्ट खोलने से पहले उत्तर का मार्ग अपनाएँ

मार्ग के तीन भाग हैं: गेटवे पर एक मार्ग जो क्लाइंट के भीतरी पते की ओर इशारा करता है, विशिष्ट कॉलर को अनुमति देने वाली नीति, और लक्ष्य पर सुनने वाली सेवा। हर भाग अलग तरह से विफल होता है, इसलिए «VPN चालू है» लगभग कुछ नहीं बताता।

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

लक्ष्य पक्ष भी जाँचें। केवल 127.0.0.1 से बँधी सेवा टनल इंटरफ़ेस पर आने वाला कनेक्शन स्वीकार नहीं कर सकती, चाहे गेटवे के मार्ग कितने भी सही हों। जो होस्ट फ़ायरवॉल नियम पोर्ट की अनुमति केवल स्थानीय सबनेट से देता है, वह भी ऑफ़िस ट्रैफ़िक गिरा देगा, और वह नियम ऊपर की VPN नीति से स्वतंत्र है।

नाम और पते डिज़ाइन के निर्णय हैं

टनल के भीतर का पता अपने आप नाम नहीं बन जाता। आपका नियंत्रित निजी DNS रिकॉर्ड इस आशा से स्पष्ट है कि कोई डिस्कवरी प्रोटोकॉल टनल पार करेगा, क्योंकि लिंक-लोकल मल्टीकास्ट नाम विश्लेषण स्थानीय खंड पर ही रहता है और सबनेट-पार DNS नहीं बनता।

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

नाम उस व्यक्ति के साथ तय करें जिसके पास VPN पहचान है, ताकि रिकॉर्ड, पता आवंटन और पहुँच नीति तीन अलग टिकटों के बजाय साथ बदलें।

सदस्यता नहीं, सेवा परखें

लक्ष्य से पुष्टि करें कि क्या सुन रहा है और किस पते पर, फिर वापसी मार्ग पर गेटवे का दृष्टिकोण पुष्टि करें:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

अब ऑफ़िस पक्ष से गूँज के बजाय वास्तविक अनुरोध से परखें। सेवा के विरुद्ध सफल curl एक साथ मार्ग, नीति और श्रोता सिद्ध करता है, जबकि सफल पिंग केवल यह सिद्ध करता है कि ICMP की अनुमति है। यदि अनुरोध विफल हो, तो फ़ायरवॉल चौड़ा करके आशा करने के बजाय तीन भागों से पीछे चलें।

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

संसाधन को जानबूझकर प्रकाशित करें, नाम, अनुमत कॉलरों की सूची और एक स्वामी के साथ, और दूर का उपकरण आकस्मिक सर्वर के बजाय समर्थित सेवा बन जाता है।