OpenVPN क्लायंटच्या मागील सबनेट का पोहोचण्यायोग्य नाही?

सर्व्हरच्या टनेल पत्त्यावर ping यशस्वी होतो, क्लायंटची स्वतःची रूट टेबल बरोबर दिसते, तरीही त्या क्लायंटमागील LAN पोहोचण्यायोग्य नाही। क्लायंटची राउटिंग टेबल बरोबर दिसते, सर्व्हरवर टनेलकडे निर्देश करणारा मार्ग आहे, आणि पॅकेट तरीही गायब होतात। हे layer-3 टनेलचे क्लासिक लक्षण आहे, ज्याला माहीत नाही की त्याच्या एका क्लायंटच स्वतः गेटवे आहे।

tun इंटरफेसमध्ये प्रत्येक क्लायंटसाठी पुढील हॉप नसतो। कर्नेल अनेक पीअर असलेला एकच इंटरफेस पाहते, म्हणून दूरच्या LAN साठी कोणता क्लायंट पॅकेट घेईल हा निर्णय OpenVPN प्रक्रियेच्या आत घ्यावा लागतो। तो निर्णय iroute ने कॉन्फिगर केला जातो, आणि त्याशिवाय पॅकेटला जाण्याचे ठिकाण नाही।

सर्व्हर इंटरफेसनुसार नाही, क्लायंटनुसार राउट करतो

सर्व्हरला क्लायंटच्या टनेल पत्त्यावर पॅकेट पाठवायचे असते तेव्हा उत्तर निःसंदिग्ध आहे: पत्ता त्या क्लायंटच्या सेशनचा आहे। पण गंतव्य त्या क्लायंटमागील संपूर्ण सबनेट असते तेव्हा पत्ता सर्व्हरला माहीत असलेल्या कोणाचाही नसतो, आणि टनेलकडे जाणारा कर्नेल मार्ग फक्त "या इंटरफेसने" असे म्हणतो, कोणता पीअर ते सांगत नाही।

OpenVPN हे गंतव्य प्रीफिक्सला विशिष्ट क्लायंटशी जोडणाऱ्या अंतर्गत राउटिंग टेबलने सोडवते। ती टेबल iroute नोंदींपासून बनते, म्हणून सर्व्हर होस्टवरील साधारण मार्ग पुरेसा नाही। कर्नेल मार्ग पॅकेटला टनेल इंटरफेसपर्यंत आणतो; अंतर्गत मॅपिंग कोणते सेशन ते घेईल हे ठरवते। म्हणूनच दुरुस्ती कधीही कर्नेलच्या मार्ग आउटपुटमध्ये दिसत नाही।

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

क्लायंटचे नाव घेणारी iroute नोंद लिहिणे

iroute सर्व्हरच्या मुख्य कॉन्फिगरेशनमध्ये नाही, क्लायंट-विशिष्ट कॉन्फिगरेशन फाइलमध्ये असते। client-config-dir पर्यायाने सर्व्हरला एका डिरेक्टरीकडे निर्देश करा, नंतर ज्याचे नाव क्लायंटच्या प्रमाणपत्राचे सामान्य नाव आहे अशी फाइल तयार करा आणि त्यात प्रीफिक्स ठेवा।

ज्या शाखेचे LAN 10.20.0.0/24 आहे आणि प्रमाणपत्राचे सामान्य नाव branch-router आहे, त्या पथावरील फाइलमध्ये iroute 10.20.0.0 255.255.255.0 सारखी ओळ असते। मुख्य कॉन्फिगरेशनला फक्त डिरेक्टरी पर्याय लागतो; प्रीफिक्स क्लायंटकडे असते।

सामान्य नाव हाच नाजूक भाग आहे। वेगळ्या subject सह जारी केलेले प्रमाणपत्र, किंवा वापरकर्त्यांची वापरकर्तानावाने ओळख पटवणारी पण फाइल प्रमाणपत्राच्या नावाने असलेली तैनात, कधीही न वाचली जाणारी फाइल तयार करते। सर्व्हर सेशनसाठी प्रत्यक्षात कोणते नाव सांगतो ते तपासा, आणि जुळत नसलेल्या क्लायंटला त्याच्या मार्गांशिवाय शांतपणे जोडण्याऐवजी अपयशी होऊ देणाऱ्या पर्यायाचा विचार करा। प्रमाणपत्राशी जुळण्यासाठी फाइलचे नाव बदलणे ही खूप लांब संध्याकाळ टाळणारी पाच मिनिटांची दुरुस्ती आहे।

एका क्लायंटकडे अनेक प्रीफिक्स असू शकतात। प्रत्येक नेटवर्कसाठी एक iroute ओळ जोडा आणि मॅपिंग ऑडिटयोग्य राहण्यासाठी यादी त्या क्लायंटच्या उर्वरित सेटिंग्जजवळ ठेवा।

दोन्ही दिशांनी परतीचा मार्ग तयार करणे

दूरच्या LAN पर्यंत पॅकेट पोहोचवणे अर्धे काम आहे। क्लायंटने त्या LAN ची रहदारीही टनेलमध्ये पाठवायची असते, जे सहसा क्लायंटला मार्ग ढकलून केले जाते: push "route 10.8.0.0 255.255.255.0" सारखी ओळ प्रत्येक क्लायंटला सर्व्हरच्या बाजूच्या नेटवर्कपर्यंत कसे पोहोचायचे ते सांगते। शाखेसाठी, समतुल्य मार्ग सर्व्हरच्या बाजूने पोहोचावयाच्या सर्व गोष्टींसाठी टनेलकडे निर्देश करतो।

परतीच्या दिशेला दूरच्या बाजूला मालक लागतो। त्या बाजूला कोणालातरी परत जाण्याचा मार्ग माहीत असावा: VPN पूल सर्व्हरकडे निर्देश करणारा LAN राउटरवरील स्थिर मार्ग, किंवा रहदारी LAN मध्ये येण्यापूर्वी सर्व्हरवर पत्ता भाषांतर। स्थिर मार्ग मूळ पत्ते लॉग आणि प्रवेश नियमांमध्ये दिसत ठेवतो पण LAN मालकाच्या सहकार्याची गरज असते; भाषांतर स्वयंपूर्ण आहे पण प्रत्यक्षात कोण जोडले गेले हे लपवते।

सर्व्हर होस्टवर फॉरवर्डिंग सक्षम असणे आवश्यक आहे। त्याशिवाय कर्नेल टनेलमधून पॅकेट स्वीकारते आणि ते LAN इंटरफेसकडे पाठवण्यास नकार देते, जे क्लायंटच्या दृष्टिकोनातून गहाळ iroute सारखेच दिसते।

योग्य प्रोबने पोहोच तपासणे

दूरच्या टोकाला ping करून अंदाज लावण्याऐवजी स्तरानुसार चाचणी करा। सर्व्हरवरून प्रीफिक्ससाठी अंतर्गत मॅपिंग आहे आणि कर्नेल मार्ग टनेलकडे निर्देश करतो हे तपासा। क्लायंटवरून ढकललेला मार्ग स्थापित आहे आणि LAN पत्त्यासाठी त्याचा डीफॉल्ट मार्ग टनेल आहे याची खात्री करा।

मग पॅकेट पहा। टनेल इंटरफेसवरील कॅप्चर सर्व्हर क्लायंटकडे पाठवत आहे का हे दाखवते, आणि LAN इंटरफेसवरील कॅप्चर तो फॉरवर्ड करत आहे का हे दाखवते। पहिले पॅकेट दाखवते आणि दुसरे काहीही दाखवत नाही तर समस्या फॉरवर्डिंग किंवा फिल्टरमध्ये आहे; दोन्हीपैकी काहीही दाखवत नाही तर शोध आधीच अयशस्वी झाला आहे।

टनेलने जोडलेले दोन सर्व्हर दोन्ही बाजूंनी तोच नियम पुन्हा करतात: प्रत्येकाला दुसऱ्याच्या पूलसाठी iroute लागते, आणि प्रत्येकाला मार्ग सममित करणारा मार्ग व फॉरवर्डिंग लागते। इथे राउटिंग आणि धोरण वेगवेगळे विषय आहेत। राउटिंग पॅकेट कुठे जाऊ शकते हे ठरवते, तर FORWARD नियम त्याला परवानगी आहे का हे ठरवते, म्हणून दोन iroute ओळी असलेला क्लायंट फिल्टर वेगळे न सांगता दोन्ही प्रीफिक्सपर्यंत पोहोचू शकतो।