OpenVPN क्लाइंट एक-दूसरे को नहीं देख पाते: सबनेट या net30?
क्लाइंट सर्वर तक पहुँचते हैं पर एक-दूसरे तक नहीं। एक ping से खराबी अलग करें, फिर सबनेट टोपोलॉजी, client-to-client या ब्रिज किया गया TAP सेगमेंट चुनें।
दो असंबंधित खराबियाँ एक ही शिकायत पैदा करती हैं। पहली में एक क्लाइंट दूसरे तक टनल पते से भी नहीं पहुँचता, क्योंकि पते एक ही सबनेट में नहीं हैं या सर्वर सहकर्मी ट्रैफ़िक अग्रेषित नहीं करता। दूसरी में ping काम करता है और ऐप की डिवाइस सूची खाली रहती है, क्योंकि खोज उस ब्रॉडकास्ट पर निर्भर है जिसे परत 3 की टनल ले जा नहीं सकती। एक ping दोनों को अलग करता है, और हर एक का उपाय दूसरे के उपाय जैसा बिल्कुल नहीं है।
एक ping समस्या को दो हिस्सों में बाँटता है
एक क्लाइंट से दूसरे क्लाइंट के टनल पते पर ping करें, उसके नाम पर नहीं और उसके LAN पते पर नहीं। अगर वह विफल हो, तो अग्रेषण या पता-निर्धारण समस्या है और ठीक होने तक खोज अप्रासंगिक है। अगर वह सफल हो, तो अग्रेषण पहले से काम कर रहा है और बची खाली जगह ब्रॉडकास्ट या नाम विश्लेषण है।
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 विफल होते हैं: कुछ टूटा नहीं है, क्लाइंट बस एक ही नेटवर्क में नहीं हैं। क्लाइंट काम करता लिंक और जवाब न देने वाला सहकर्मी पता देखता है, जो फ़ायरवॉल जैसा लगता है पर असल में पता-निर्धारण का लेआउट है।
डायरेक्टिव बदलना सर्वर पक्ष का संपादन और पुनःआरंभ है, और यह पहले से खुली सत्रों पर नहीं बल्कि अगले कनेक्शन पर लागू होता है। बदलाव का फ़ैसला करने से पहले क्लाइंट फिर से जोड़ें। अगर कोई उपकरण वेब इंटरफ़ेस से कॉन्फ़िगरेशन दोबारा बनाता है, तो डायरेक्टिव, फ़ाइल और तारीख़ दर्ज करें, और इंटरफ़ेस होने पर उसी से संपादन करें, क्योंकि पुनर्निर्माण अगली बार सहेजते समय हाथ से किया संपादन मिटा देगा।
client-to-client एक अलग द्वार है
एक ही सबनेट के भीतर भी सर्वर उन पैकेटों को गिरा देता है जो एक क्लाइंट से आते हैं और दूसरे के लिए संबोधित हैं, जब तक client-to-client सेट न हो। वह कीवर्ड सर्वर को केवल स्वीकार करने वाले अंतिम बिंदु के बजाय सहकर्मी ट्रैफ़िक का अग्रेषक बना देता है। टोपोलॉजी ठीक करने के बाद लोग जो दूसरी शर्त चूक जाते हैं, वह यही है।
यह ब्रॉडकास्ट तक नहीं फैलता। सेटिंग क्लाइंट के बीच यूनिकास्ट अग्रेषित करती है; यह टनल को साझा सेगमेंट नहीं बनाती, और इसकी कोई भी मात्रा मल्टीकास्ट खोज क्वेरी हर सहकर्मी तक नहीं पहुँचाएगी।
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 में ब्रिज करने से दूरस्थ क्लाइंट दफ़्तर के ब्रॉडकास्ट डोमेन में आ जाते हैं, जो खोज को पूरी तरह हल कर देता है। कीमत वे प्लेटफ़ॉर्म हैं जो TAP लागू नहीं करते, सर्वर पर मौजूद होना ज़रूरी एक ब्रिज, और विफलता का वह क्षेत्र जहाँ दफ़्तर के केबल पर ब्रॉडकास्ट तूफ़ान हर दूरस्थ लैपटॉप तक पहुँचता है।
नाम विश्लेषण चाहने वाले दो या तीन वर्कस्टेशन के लिए hosts प्रविष्टि या यूनिकास्ट पता ब्रिज से कहीं सस्ता है। TAP की ओर तभी जाएँ जब आप जिसे बदल नहीं सकते वह प्रोटोकॉल परत 2 की खोज पर निर्भर हो, और उससे पहले नहीं।
ब्रिज के बिना एक ही सबनेट के क्लाइंट
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 के बीच के मार्ग से बाहर रखें।