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 प्रशिक्षण तीच सेटिंग्ज उत्पादन क्रमाने सूचीबद्ध करते; आपल्या प्रीफिक्सनुसार रचना बदलण्यापूर्वी एकदा पाहणे योग्य.