OpenVPN क्लायंट गेटवेचे IPsec सिलेक्टर का चुकवतात

गेटवेवरून दूरच्या IPsec बोगद्यामागील होस्टला ping केल्यास तो स्वच्छ उत्तर देतो, त्यामुळे बोगदा निरोगी दिसतो आणि तिकीट पुढे जाते। मग जोडलेला क्लायंट तोच होस्ट वापरून पाहतो आणि काहीच परत मिळत नाही। तो ping कधीही क्लायंटच्या प्रवाहाचा पुरावा नव्हता, कारण तो गेटवेच्याच स्रोत पत्त्यासह निघाला होता आणि वेगळ्या IPsec सिलेक्टरशी जुळला होता। ही दोन प्रकरणे का वेगळी पडतात हे समजून घेणे हाच उपायाचा मोठा भाग आहे।

गेटवेचा ping असा प्रवाह तपासतो जो तुमचा क्लायंट कधीही वापरत नाही

कोणती धोरणे लागू होतील हे स्रोत पत्ता ठरवतो। गेटवेवर तयार झालेला पॅकेट त्याच्या स्थानिक LAN किंवा बोगद्याच्या टोकाच्या पत्त्यासह बाहेर पडतो, आणि त्याला जुळणारे धोरण नेमके त्याच प्रकरणासाठी लिहिलेले होते। क्लायंटचे पॅकेट OpenVPN इंटरफेसवर क्लायंट पूलमधील पत्त्यासह येते, जो पूर्णपणे वेगळा सिलेक्टर आहे।

म्हणूनच बिघाड मार्गनिर्देशनाची समस्या वाटतो, पण प्रत्यक्षात ती धोरणाच्या व्याप्तीची समस्या आहे। गेटवेवरून पोहोच सिद्ध करते की पीअर सुरू आहे आणि प्रस्तावांवर बोलणी झाली, आणि पूल संरक्षित आहे की नाही याबद्दल ते काहीही सिद्ध करत नाही।

अप्लिकेशनला खरोखर आवश्यक असलेला दूरचा प्रीफिक्स पुश करा

जोडलेल्या क्लायंटसाठी 10.8.0.0/24 आणि संरक्षित दूरच्या नेटवर्कसाठी 172.30.239.0/25 ही उदाहरण जोडी घ्या। क्लायंटला त्या दुसऱ्या प्रीफिक्सचा मार्ग हवा, गेटवेच्या LANचा नाही आणि दुसऱ्या बोगदा पत्त्याचाही नाही। पूलमध्ये पुश केलेला मार्गच क्लायंटला तो रहदारी गेटवेकडे सोपवायला लावतो। त्याशिवाय पॅकेट तुम्ही डीबग करत असलेल्या धोरण-निर्णयापर्यंत कधीही पोहोचत नाही।

पुश केलेले मार्ग स्वीकारणाऱ्या Community सर्व्हरवर निर्देश खरा मास्क घेतो: push "route 172.30.239.0 255.255.255.128"। Access Server तेच गंतव्य स्थापित आवृत्तीच्या खाजगी-नेटवर्क किंवा प्रवेश-नियम सेटिंग्जद्वारे कॉन्फिगर करतो, आणि राउटेड किंवा भाषांतरित मोड जाणीवपूर्वक निवडला जातो। मालक कॉन्फिगरेशनऐवजी निर्मित फायरवॉल साखळ्या संपादित करणे हाच कार्यरत सेटअप पुनरुत्पादित करणे अशक्य करणारा मार्ग आहे।

जोडल्यानंतर सर्व्हरचा हेतू नव्हे तर क्लायंटची मार्गनिर्देशन सारणी वाचा। फक्त पूल व्यापणारा मार्ग म्हणजे पुश कधीच पोहोचला नाही, आणि बोगद्यातून जाणारा डीफॉल्ट मार्ग या गरजेपेक्षा मोठा आहे आणि पुढे तुम्हाला चकित करेल। मास्क आणि प्रीफिक्स दोन्ही तपासा, कारण /25 ला /24 म्हणून पुश केल्यास शेजारच्या पत्त्यांची रहदारी ती वाहू शकत नाही अशा मार्गावर जाते। मग क्लायंटने त्या गंतव्यासाठी बोगदा इंटरफेस निवडला आहे याची खात्री करा।

सिलेक्टरमध्ये क्लायंट पूल समाविष्ट करा

क्लायंट पत्ते जपणाऱ्या राउटेड प्रवेशासाठी IPsec धोरणाने पूल आणि दूरच्या प्रीफिक्समधील रहदारी संरक्षित ठेवली पाहिजे। गेटवेच्या स्वतःच्या LANसाठी लिहिलेले सिलेक्टर ping स्वीकारतात आणि क्लायंटची विनंती टाकून देतात, आणि हीच ती विषमता आहे जिने ही तपासणी सुरू केली।

कॉन्फिगर केलेल्या प्रस्तावांसह वाटाघाटी झालेले धोरणही तपासा, उदाहरणार्थ strongSwanवर ipsec statusall किंवा तुमच्या अंमलबजावणीसाठी समतुल्य स्थिती आदेशाने। धोरण-आधारित IPsecमध्ये सामान्य मार्ग भौतिक इंटरफेसकडे दाखवू शकतो, पण जुळणारी रहदारी तरीही एन्क्रिप्ट होते, त्यामुळे बोगदा उपकरण नसणे काहीही सिद्ध करत नाही। तुम्ही लिहून ठेवलेल्या पूल व प्रीफिक्सशी सिलेक्टर जोड्या तुलना करा।

गेटवेवरील सामान्य स्रोत NAT देखील जुळणी मोडू शकते। धोरण तपासणीपूर्वी masquerade नियम क्लायंटचा स्रोत पुन्हा लिहित असेल, तर पॅकेट आता तुम्ही लिहिलेल्या सिलेक्टरसारखा दिसत नाही। विस्तृत masquerade नियम दुसऱ्या VPNसाठी वाईट उपाय का आहे याचे हे एक कारण आहे: तो कोणते धोरण लागू होईल आणि दूरची बाजू कोणता पत्ता नोंदवेल हे बदलतो। जी रहदारी तुम्हाला राउट करायची आहे ती सूट करा, किंवा जाणीवपूर्वक तिचे भाषांतर करा आणि सिलेक्टर अद्ययावत करा।

जाणीवपूर्वक मार्गनिर्देशन किंवा भाषांतर निवडा

मार्गनिर्देशन क्लायंटचा पत्ता दूरच्या बाजूला दिसण्यासारखा ठेवते, त्यामुळे दूरचे लॉग आणि प्रति-स्रोत नियम अर्थपूर्ण राहतात, आणि दूरच्या गेटवेला पूलकडील परतीचा मार्ग माहीत असणे आवश्यक असते। भाषांतर पूल एका पत्त्यामागे लपवते, ज्यामुळे परतीच्या मार्गाची अडचण दूर होते आणि प्रति-क्लायंट ओळख नष्ट होते।

एक रचना निवडा आणि ती लिहून ठेवा, कारण दोन्हींना वेगळे सिलेक्टर आणि वेगळा फायरवॉल क्रम लागतो। अर्धवट लागू केलेला masquerade त्यांच्यामध्ये पडतो आणि दोन्हींना संतुष्ट करत नाही। लिहिलेली निवडच पुढच्या अभियंत्याला बग आणि जाणीवपूर्वक केलेला निर्णय वेगळा करू देते।

फॉर्वर्डिंग आणि उत्तरेवर हे चक्र बंद करा

गेटवेने तुम्हाला अभिप्रेत असलेला प्रोटोकॉल आणि गंतव्य फॉर्वर्ड करायचे आहे, त्याचा अर्थ IP फॉर्वर्डिंग सुरू असावे आणि जोडीला परवानगी देणारी फॉर्वर्ड साखळी असावी। मग दूरच्या बाजूने उत्तरे IPsec मार्गाने परत पाठवावी लागतात, आणि तो त्यांच्या गेटवेवरील मार्गनिर्देशनाचा निर्णय आहे, तुमच्यावरचा नाही। दोन्ही अर्धे भाग सामान्य कॉन्फिगरेशन आहेत, आणि दोन्ही अर्धवट सोडणे सोपे आहे। ते वेगवेगळे तपासा जेणेकरून गहाळ फॉर्वर्ड नियम तुटलेला बोगदा समजला जाणार नाही।

क्लायंटकडून अप्लिकेशनकडे जाणाऱ्या एका खऱ्या विनंतीने पडताळा, ती OpenVPN इंटरफेस, IPsec निर्णय आणि दूरचा होस्ट ओलांडताना पाहा। उत्तर स्वतंत्र निरीक्षण म्हणून तपासा, कारण पोहोचणारी विनंती आणि कधीही न परतणारे उत्तर क्लायंटच्या जागेवरून सारखीच दिसतात। एका ट्रेस केलेल्या विनंतीचे मोल गेटवेच्या कितीही ping पेक्षा जास्त आहे।

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