के रोमिङ 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 अनुमति छ भन्ने मात्र सिद्ध गर्छ। अनुरोध असफल भए फायरवाल फराकिलो पारेर आशा गर्नुको सट्टा तीन भागबाट पछाडि जानुहोस्।

उपलब्धता त्यही कुराकानीको भाग हो। ल्यापटप सुत्छ, सञ्जालहरूबीच घुम्छ र दिनको अन्त्यमा विच्छेद हुन्छ। कुनै पनि घडीमा जवाफ दिनुपर्ने सेवा सधैँ खुला रहने होस्टमा हुनुपर्छ, जबकि उत्तम-प्रयास सेवा यो सीमा लेखेर क्लाइन्टमै रहन सक्छ।

स्रोतलाई जानाजान प्रकाशित गर्नुहोस्, नाम, अनुमत कलरहरूको सूची र एक मालिकसहित, र टाढाको उपकरण आकस्मिक सर्भरको सट्टा समर्थित सेवा बन्छ।