OpenVPN क्लायंट एकमेकांना पाहू शकत नाहीत: सबनेट की net30?
क्लायंट सर्व्हरपर्यंत पोहोचतात पण एकमेकांपर्यंत नाही. एका ping ने दोष वेगळा करा, नंतर सबनेट टोपोलॉजी, client-to-client किंवा ब्रिज केलेला TAP विभाग निवडा.
दोन असंबंधित दोष एकच तक्रार निर्माण करतात. पहिल्यात एक क्लायंट दुसऱ्यापर्यंत टनेल पत्त्यानेही पोहोचत नाही, कारण पत्ते एकाच सबनेटमध्ये नाहीत किंवा सर्व्हर सहकारी रहदारी पुढे पाठवत नाही. दुसऱ्यात ping चालते पण अ‍ॅपची उपकरण यादी रिकामी राहते, कारण शोध 3 थराची टनेल वाहू शकत नाही अशा broadcast वर अवलंबून आहे. एक ping दोन्हींना वेगळा करते, आणि प्रत्येकाची दुरुस्ती दुसऱ्याच्या दुरुस्तीसारखी अजिबात नाही.
एक ping समस्या दोन भागांत विभागते
एका क्लायंटवरून दुसऱ्या क्लायंटच्या टनेल पत्त्यावर ping करा, त्याच्या नावावर नाही आणि त्याच्या LAN पत्त्यावर नाही. ते अयशस्वी झाल्यास पुढे पाठवणे किंवा पत्ता निश्चिती ही समस्या आहे आणि ती दुरुस्त होईपर्यंत शोध अप्रासंगिक आहे. ते यशस्वी झाल्यास पुढे पाठवणे आधीच चालू आहे आणि उरलेली तफावत broadcast किंवा नाव निराकरण आहे.
ip addr show tun0सर्वांआधी क्लायंटचा इंटरफेस वाचा, कारण नेटमास्क टोपोलॉजीचे नाव सांगते. /24 किंवा दुसरे सबनेट मास्क म्हणजे सामायिक पूल; सहकाऱ्याच्या पत्त्यासह /30 म्हणजे जुनी बिंदू-ते-बिंदू रचना, जिथे प्रत्येक क्लायंटला नेमका एक शेजारी असतो, सर्व्हर.
net30 विरुद्ध सबनेट, क्लायंटच्या बाजूने वाचलेले
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
net30 मध्ये सर्व्हर प्रत्येक क्लायंटला लहान ब्लॉक देतो, त्यामुळे सर्व्हर पुढे पाठवत नाही तोपर्यंत दुसऱ्या क्लायंटच्या टनेल पत्त्यापर्यंत मार्ग नसतो. सबनेटमध्ये संपूर्ण पूल एकच जाळे असते, प्रत्येक क्लायंट कोणालाही संबोधू शकतो, आणि सर्व्हर त्यांच्यामध्ये पुढे पाठवतो. म्हणूनच सर्व्हरचे एक रूपण निरोगी दिसू शकते पण सहकाऱ्यांमधील ping अयशस्वी होते: काहीच तुटलेले नाही, क्लायंट एकाच जाळ्यात नाहीत इतकेच. क्लायंटला चालणारी जोड आणि उत्तर न देणारा सहकारी पत्ता दिसतो, जे firewall सारखे वाचले जाते पण प्रत्यक्षात पत्ता निश्चितीची रचना असते.
निर्देश बदलणे म्हणजे सर्व्हर बाजूचे संपादन आणि पुन्हा सुरुवात, आणि ते आधीच उघडलेल्या सत्रांवर नाही तर पुढील जोडणीवर लागू होते. बदलाचे मूल्यांकन करण्यापूर्वी क्लायंट पुन्हा जोडा. उपकरण वेब इंटरफेसवरून रूपण पुन्हा तयार करत असेल, तर निर्देश, फाइल आणि तारीख नोंदवा, आणि इंटरफेस असेल तेव्हा त्यातूनच संपादन करा, कारण पुनर्निर्मिती पुढील जतनात हाताने केलेले संपादन पुसून टाकेल.
client-to-client हे वेगळे द्वार आहे
एकाच सबनेटमध्येही सर्व्हर एका क्लायंटकडून येऊन दुसऱ्यासाठी पाठवलेली पॅकेट client-to-client सेट नसेल तर टाकून देतो. तो कीवर्ड सर्व्हरला केवळ स्वीकारणाऱ्या टोकाऐवजी सहकारी रहदारीचा पुढे पाठवणारा बनवतो. टोपोलॉजी दुरुस्त केल्यानंतर लोक जी दुसरी अट चुकवतात ती हीच.
हे broadcast पर्यंत विस्तारत नाही. हा सेटिंग क्लायंटमध्ये unicast पुढे पाठवते; तो टनेलला सामायिक विभाग बनवत नाही, आणि त्याच्या कोणत्याही प्रमाणात multicast शोध प्रश्न प्रत्येक सहकाऱ्यापर्यंत पोहोचणार नाही.
TUN विरुद्ध TAP, आणि प्रत्येक काय वाहू शकते
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
tap उपकरण LAN मध्ये ब्रिज केल्याने दूरस्थ क्लायंट कार्यालयाच्या broadcast डोमेनमध्ये येतात, ज्यामुळे शोध पूर्णपणे सुटतो. किंमत म्हणजे TAP लागू न करणारे प्लॅटफॉर्म, सर्व्हरवर असावा लागणारा ब्रिज, आणि कार्यालयाच्या केबलवरील broadcast वादळ प्रत्येक दूरस्थ लॅपटॉपपर्यंत पोहोचणारे अयशस्वी क्षेत्र.
नाव निराकरण आवश्यक असलेल्या दोन किंवा तीन कार्यस्थानांसाठी hosts नोंद किंवा unicast पत्ता ब्रिजपेक्षा खूप स्वस्त आहे. तुम्ही बदलू शकत नाही असा प्रोटोकॉल 2 थराच्या शोधावर अवलंबून असेल तेव्हाच TAP कडे वळा, आणि त्यापूर्वी नाही.
ब्रिज नसलेले एकाच सबनेटचे क्लायंट
LAN श्रेणीतून पत्ता देणे क्लायंटला केबलवर आणत नाही. सर्व्हर टनेल आणि इथरनेटमध्ये मार्गस्थ करतो, त्यामुळे त्या पत्त्यासाठीचे ARP सर्व्हरच्या इंटरफेसवर थांबते आणि उरलेल्या LAN ला तो कुठे राहतो हे कधीच कळत नाही.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP ती तफावत भरून काढतो, सर्व्हर क्लायंटच्या वतीने उत्तर देतो. श्रेणीसाठी parpd नोंदी सांभाळतो जेव्हा क्लायंट येतात-जातात, तर sysctl net.ipv4.conf.eth0.proxy_arp=1 इतरत्र मार्गस्थ होणाऱ्या सर्वांना उत्तर देतो, जे गर्दीच्या विभागात स्वतःची आश्चर्ये निर्माण करण्याइतके विस्तृत आहे.
तुम्ही कोणताही मार्ग निवडा, टनेल आणि केबलमधील NAT काढून टाका. MASQUERADE नियम तुम्ही उत्तर देऊ पाहत असलेला पत्ता निश्चितीचा प्रश्न नेमका लपवतो. तो पुढच्या व्यक्तीसाठी क्लायंटच्या बाजूने विचार करता येणार नाही अशी टोपोलॉजीही ठेवतो.
काहीही बदलण्यापूर्वी सर्व्हरवर tcpdump -ni tun0 ने एक प्रयत्न पकडा आणि सहकाऱ्याचे पॅकेट येते का हे तपासा. येऊन टाकून दिले जाणे client-to-client कडे निर्देश करते; कधीच न येणे टोपोलॉजी किंवा मार्गस्थतेकडे. OpenVPN 2.6 हस्तपुस्तिका दोन्ही कीवर्ड आणि मूलभूत टोपोलॉजीची नोंद करते, आणि फोरम पोस्टमधून ओळ कॉपी करण्यापूर्वी तुमच्या आवृत्तीशी पडताळून पाहणे योग्य आहे.
- tun इंटरफेस /30 सहकारी जोडीऐवजी पूल मास्क दाखवतो.
- शोध तपासण्यापूर्वी दुसऱ्या टनेल पत्त्यावर थेट ping यशस्वी होते.
- सहकाऱ्यांना पॅकेटची देवाणघेवाण करायची असताना सर्व्हर रूपणात
client-to-clientअसतो. - अ‍ॅप अयशस्वी होते असे म्हणण्याऐवजी तुम्ही तपासत असलेल्या शोध प्रोटोकॉलचे नाव सांगा.
- गटातील प्रत्येक क्लायंट प्लॅटफॉर्मने आधार दिल्यासच TAP वापरा.
- एकाच सबनेटमधील पोहोच महत्त्वाची असताना NAT टनेल आणि LAN मधील मार्गाबाहेर ठेवा.