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 बीचको मार्गबाट बाहिर राख्नुहोस्।