रोमिंग VPN क्लायंट ऑफिससाठी सेवा होस्ट करू शकतो का?

तुमचा ऑफिस लॅपटॉप घरून डायल इन करू शकतो आणि तरीही ऑफिसला आवश्यक असलेली गोष्ट पुरवू शकतो, पण तेव्हाच जेव्हा तीन वेगळे निर्णय एकत्र येतात। टनेल हे वाहतूक आहे, आंतरिक पत्ता हे गंतव्य आहे, आणि कोण दरवाजा ठोकू शकतो हे धोरण ठरवते। यापैकी कोणत्याही एकाला संपूर्ण उत्तर मानल्यास तीच परिचित तक्रार येते: होस्ट पिंगला उत्तर देतो पण अॅप्लिकेशन कधीही जोडले जात नाही। भूमिका एकसारख्या नाहीत, आणि फरक नेमका तिथेच आहे जिथे डिझाइनचे काम असते।

डायल-इन दिशा सेवेच्या दिशेबद्दल काहीही सांगत नाही

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

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

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

पोर्ट उघडण्यापूर्वी परतीचा मार्ग अनुसरा

मार्गाचे तीन भाग आहेत: गेटवेवर क्लायंटच्या आंतरिक पत्त्याकडे निर्देश करणारा मार्ग, विशिष्ट कॉलरला परवानगी देणारे धोरण, आणि लक्ष्यावर ऐकणारी सेवा। प्रत्येक भाग वेगळ्या पद्धतीने अयशस्वी होतो, म्हणून «VPN सुरू आहे» जवळपास काहीही सांगत नाही।

चांगली बातमी अशी की आंतरिक मार्गासाठी क्लायंटच्या घरातील राउटरवर पोर्ट फॉरवर्डिंगची गरज नाही। सेवा घरातील WAN पत्त्यावर नाही तर टनेलच्या पत्त्यावर प्रकाशित करण्याचा अर्थ हाच आहे, कारण घरातील 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ला परवानगी आहे हे सिद्ध करते। विनंती अयशस्वी झाल्यास फायरवॉल रुंदावण्याऐवजी तीन भागांतून मागे जा।

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

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