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 में घोषणा एक उपयोगकर्ता गुण है: कनेक्टर उपयोगकर्ता पर 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 की ओर। इनके बिना टनल अनुरोध ले जाता है और उत्तर डिफ़ॉल्ट गेटवे से बाहर जाता है, जिससे जाना-माना आधा-खुला कनेक्शन बनता है।

शाखा में कनेक्टर को वे पैकेट आगे भेजने पड़ते हैं जो उसे संबोधित नहीं हैं: उसके ऑपरेटिंग सिस्टम में IP फ़ॉरवर्डिंग और टनल तथा LAN इंटरफ़ेस तक सीमित फ़ॉरवर्डिंग अनुमति; Linux पर यह net.ipv4.ip_forward=1 है फ़ॉरवर्ड चेन नियमों के साथ, Windows पर routing and remote access। फिर शाखा के होस्ट्स को वापसी पथ चाहिए: या तो कनेक्टर उनका डिफ़ॉल्ट गेटवे है, या मौजूदा गेटवे मुख्यालय और पूल के प्रीफ़िक्स के लिए विशिष्ट रूट ले जाता है।

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

विफलता को मार्ग की तरह पढ़ें, अनुमति की तरह नहीं

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

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

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

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