Access Server गेटवे प्रयोगकर्ता: ग्राहकको शाखा LAN को रुटिङ

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

दुई ठेगाना, दुई फरक स्वामित्वका दाबी

ग्राहक जोडिँदा Access Server ले कन्फिगर गरिएको VPN पूलबाट ठेगाना दिन्छ, उदाहरण 10.90.0.0/24। त्यो बाँडफाँट एउटा होस्टका लागि भाडा हो। त्यही ग्राहक 10.60.0.0/24 अगाडि पनि छ भनी जडानले भन्दैन, र सर्भरले अनुमान गर्दैन: प्रशासकले घोषणा गरेमा मात्र LAN प्रिफिक्स निश्चित ग्राहकमार्फत पुग्न सकिन्छ।

त्यसैले अर्को मेसिनमा स्थिर रुटले काम गर्दैन। रुटले 10.60.0.0/24 यो ठेगानामा पठाउ भन्छ, तर ठेगाना गेटवे भनी चिन्ह लगाइएको नभएको ग्राहकको हो भने ती प्याकेट त्यहाँ पुर्याउने कारण सर्भरसँग छैन, र ग्राहकको स्ट्याकले तिनलाई फाल्न सक्छ। घोषणा र रुट एउटै संयन्त्रका दुई आधा हुन्।

गेटवे सेटिङले वास्तवमा के स्थापना गर्छ

Admin Web UI मा घोषणा प्रयोगकर्ता गुण हो: connector प्रयोगकर्तामा Configure VPN gateway सक्रिय गर्नुहोस् र शाखाको वास्तविक प्रिफिक्स Network on the VPN client side मा राख्नुहोस्। त्यो प्रयोगकर्ता अरूजस्तै प्रमाणित हुन्छ, त्यसैले निगरानी नभएको उपकरणका लागि उपयुक्त नीति चाहिन्छ, र स्वतः लगइन प्रोफाइल गोप्य हुन्छ।

त्यो चेकबक्स पछाडि सर्भरले प्रिफिक्सलाई त्यो ग्राहकको पूल ठेगानामार्फत पुग्न सकिने मान्छ, र Access Controls अन्तर्गतको रुटिङले अरूलाई के भन्ने निर्धारण गर्छ: सामान्य ग्राहकलाई पठाइने रुट र मुख्यालयका नेटवर्कबाट ग्राहक ठेगाना तथा सबनेटसम्म ट्राफिक अनुमति दिने नियम। शाखासम्म पुग्नुपर्ने नेटवर्कका लागि रुटिङ सक्रिय गर्नुहोस् र अनुमत सूची छोटो राख्नुहोस्।

बनाइएको फाइलमा टाँसिएको Community शैलीको निर्देशन यो ढाँचामा सहभागी हुँदैन। उत्पादनले पठाउने रुटिङ तालिकाको स्वामी त्यही हो; हातले सम्पादित लाइन अधिलेखन वा बेवास्ता गरिन्छ।

दुवै नेटवर्कका फर्कने बाटो पूरा गर्नुहोस्

ठोस योजना: मुख्यालय 10.40.0.0/24, शाखा 10.60.0.0/24, VPN पूल 10.90.0.0/24, र Access Server मुख्यालयतर्फको निजी ठेगानामा उपलब्ध। राउटरलाई शाखा प्रिफिक्स र पूलका लागि रुट चाहिन्छ, दुवै Access Server तर्फ। नभए जवाफ डिफल्ट गेटवेबाट बाहिर जान्छ, जसले आधा खुला जडान बनाउँछ।

शाखामा connector ले आफूलाई सम्बोधन नगरिएका प्याकेट अगाडि पठाउनुपर्छ: OS मा IP फर्वार्डिङ र टनेल तथा LAN इन्टरफेसमा सीमित अनुमति; Linux मा net.ipv4.ip_forward=1 फर्वार्ड चेन नियमसँग, Windows मा routing and remote access। त्यसपछि होस्टलाई फर्कने बाटो चाहिन्छ: connector तिनको डिफल्ट गेटवे, वा विद्यमान गेटवेले मुख्यालय र पूल प्रिफिक्सका लागि विशेष रुट बोक्छ।

Connector को रुटिङ तालिकाले शाखा LAN का हरेक होस्ट पुनः कन्फिगर गर्दैन। होस्टले अर्को राउटरतर्फ देखाए फर्कने रुट त्यहीँ हुन्छन्, र त्यसले आफूले देख्ने स्रोत ठेगाना स्थानीय सबनेटको छिमेकी होइन भनी स्वीकार्नुपर्छ।

असफलतालाई बाटोका रूपमा पढ्नुहोस्

निश्चित क्रममा परीक्षण गर्नुहोस्। पहिले Access Server बाट शाखाको होस्टमा अनुमति दिइएको सेवा, त्यसपछि मुख्यालयको सामान्य होस्टबाट त्यही सेवा, त्यसपछि नीतिले अनुमति दिए उल्टो दिशा। पहिलो सफल र दोस्रो असफल भए पठाइएका रुट वा पहुँच नियम समस्या हुन्। दुवै सफल तर जवाफ नआए शाखाको फर्वार्डिङ र मुख्यालयको फर्कने रुट जाँच्नुहोस्।

होस्ट फायरवाल अर्को शंकास्पद हो, किनकि रुट गरिएको पहुँचमा गन्तव्यले स्रोतका रूपमा मुख्यालय वा पूलको ठेगाना देख्छ। स्थानीय सबनेटका लागि लेखिएको नियम मिल्दैन र प्याकेट फालिन्छ।

दुई डिजाइनलाई थप चाहिन्छ। साइटबीच ओभरल्याप हुने प्रिफिक्सले गन्तव्य अस्पष्ट बनाउँछ र पुनः-नम्बरिङ वा अनुवाद चाहिन्छ; क्लस्टर Access Server मा हरेक नोडले शाखा connector सम्म काम गर्ने बाटो पाउनुपर्छ। परिवर्तन सामान्य बचत र अद्यावधिक मार्गबाट लागू गर्नुहोस्, connector पुनः जोड्नुहोस् र दुवै छेउबाट फेरि जाँच्नुहोस्; हरेक मेसिन पूर्ण रिबुट गर्नु प्रक्रियाको भाग होइन।

Access Server को site-to-site ट्युटोरियल ले त्यही सेटिङ उत्पादन क्रममा सूचीबद्ध गर्छ; डिजाइन मिलाउनुअघि एकपटक पछ्याउन योग्य छ।