pfSense OpenVPN: दुसऱ्या राउटरच्या मागील नेटवर्कपर्यंत पोहोचणे

तुमचा लॅपटॉप VPN द्वारे pfSense LAN पर्यंत पोहोचतो आणि तरीही दोन हॉप अधिक आत असलेल्या सेवेपर्यंत पोहोचू शकत नाही, आणि फरक प्रत्येक मालकासाठी एक राउटिंग निर्णय आहे. पॅकेटची ये-जा पूर्ण होण्यापूर्वी तीन उपकरणांनी सहमती दर्शवणे आवश्यक आहे: क्लायंट, फायरवॉल आणि गंतव्य नेटवर्कचा खरा मालक असलेला राउटर. यापैकी कोणतेही चुकले तर लक्षण सारखेच दिसते.

नियम बदलण्यापूर्वी एक पॅकेट या तीन निर्णयांमधून पाठवून पहा, कारण प्रत्येक मालकाचे नियंत्रण वेगळे आणि अयशस्वी होण्याची पद्धत वेगळी असते.

एक पॅकेट, तीन राउटिंग निर्णय

गंतव्य टनेलमध्ये येते का हे क्लायंट ठरवतो, आणि तो फक्त आपल्याला माहीत असलेल्या गोष्टींवरून ठरवू शकतो: ढकललेला मार्ग, स्थानिक मार्ग किंवा आधीच सर्व काही व्यापणारा डीफॉल्ट. pfSense पॅकेट पुढे कुठे पाठवायचे हे ठरवते, आणि दुसऱ्या राउटरच्या मागील नेटवर्कसाठी याचा अर्थ योग्य इंटरफेसवरील पोहोचण्यायोग्य गेटवेमार्फत स्थिर मार्ग. खालचा राउटर VPN पूलकडे परतण्याचा मार्ग माहीत आहे का हे ठरवतो, आणि माहीत नसेल तर उत्तर टाकून दिले जाते किंवा निरुपयोगी जागी पाठवले जाते. प्रत्येक निर्णय इतर दोनपासून स्वतंत्र आहे.

यापैकी कोणत्याही एकाची अयशस्वीता तोच वापरकर्ता अहवाल देते. म्हणूनच डीबगिंगचा क्रम साधनांपेक्षा महत्त्वाचा आहे.

क्लायंटला प्रीफिक्स द्या, अंदाज नाही

IPv4 टनेल नेटवर्क /30 पेक्षा मोठे असलेल्या pfSense SSL/TLS सर्व्हरवर, IPv4 Local network(s) फील्ड कनेक्ट होताना क्लायंटना मार्ग वितरित करते. क्लायंट स्वतः एक तयार करेल यावर विसंबून न राहता खालचा प्रीफिक्स तिथे जोडा. नंतर कनेक्ट झाल्यावर क्लायंटचा प्रत्यक्ष तक्ता वाचा, कारण route-nopull असलेली प्रोफाइल किंवा मार्ग फिल्टर सर्व्हरने पाठवलेले दुर्लक्षित करू शकतात. सर्व्हर पूर्णपणे बरोबर असू शकतो तर क्लायंट काहीही स्थापित करत नाही.

इतर सर्व्हर मोड आणि टोपोलॉजींच्या मर्यादा वेगळ्या असतात, आणि प्रति-क्लायंट किंवा कनेक्शन धोरण विशिष्ट क्लायंटला काय मिळते ते बदलू शकते. आपण प्रथम चाचणी केलेल्या क्लायंटवर नाही, तर महत्त्वाच्या क्लायंटवर पडताळणी करा.

pfSense ला अंतर्गत राउटरकडे निर्देश करा

pfSense मधील स्थिर मार्गाला परिभाषित आणि पोहोचण्यायोग्य गेटवे आवश्यक आहे, आणि त्या गेटवेसाठी निवडलेला इंटरफेस तोच असावा जो प्रत्यक्षात तिथे पोहोचतो, जसे Netgate चे स्थिर-मार्ग मार्गदर्शक वर्णन करते. एका उदाहरणात्मक मांडणीत ट्रान्झिट लिंक फायरवॉलवर 192.168.77.1 आणि अंतर्गत राउटरवर 192.168.77.2 आहे, आणि सेवा नेटवर्क त्याच्या मागे 172.16.30.0/25 वर आहे. मग मार्ग प्रीफिक्स आणि पुढील हॉपचे नाव देतो, सेवेच्या पत्त्याचे नाही. दूरच्या नेटवर्कचा पत्ता गेटवे म्हणून वापरणे हा बरोबर दिसणारा आणि कुठेही फॉरवर्ड न करणारा मार्ग तयार करण्याचा सामान्य मार्ग आहे.

इंटरफेसला नाव देणे त्याच्या मागील नेटवर्कचे वर्णन करत नाही. स्थिर मार्ग हेच ते वर्णन आहे.

दूरच्या बाजूला पूल माहीत असणे आवश्यक आहे

खालच्या राउटरला पूलसाठी परतीचा मार्ग आवश्यक आहे, या उदाहरणात 192.168.77.1 मार्फत 10.55.0.0/24, जर डीफॉल्ट मार्ग किंवा गतिशील प्रोटोकॉल आधीच एक देत नसेल. सेवा होस्टच्या स्वतःच्या गेटवेने त्या राउटरकडे नेले पाहिजे, जे सहसा राउटर त्याचे डीफॉल्ट गेटवे असेल तेव्हा खरे असते आणि होस्ट हाताने संरचित केले असेल तेव्हा खोटे असते. फायरवॉलवरील धोरण-आधारित राउटिंग विशिष्ट रहदारीसाठी तक्ता ओलांडू शकते, म्हणून मार्ग चुकीचा आहे असे ठरवण्यापूर्वी एखादा नियम वेगळा गेटवे निवडतो का ते तपासा.

या रचनेसाठी भाषांतर आवश्यक नाही, आणि क्लायंटचा स्रोत पत्ता दृश्यमान ठेवल्यास खालच्या नेटवर्कला स्वतःचे धोरण लागू करता येते.

स्वीकृतीसाठी, एक नवीन विनंती टनेल प्रवेश, फायरवॉलचा अंतर्गत निर्गम आणि गंतव्याकडून येणारे उत्तर यातून पाठवून पहा. त्याऐवजी जाणूनबुजून भाषांतर वापरले जात असेल, तर खालचे नेटवर्क कोणता स्रोत पाहते आणि उत्तर कसे परत येणे अपेक्षित आहे ते नोंदवा.

तीन मालकांची योजना परवानगी दिलेल्या ॲप्लिकेशनसोबत जतन करा, जेणेकरून पुढील प्रशासक मार्ग पुन्हा शोधण्याऐवजी पुनर्रचित करू शकेल.