VPN गेटवे पछाडि Wi-Fi पहुँच बिन्दु: एउटै LAN राख्नुहोस्

वायरलेस ग्राहकहरू VPN पछाडि बस्न सक्छन्, पहुँच बिन्दुलाई टनेलको बारेमा केही थाहा नहुँदै। रेडियोलाई गेटवेको LAN मा ब्रिज गर्नुहोस्, ठेगाना र टनेल गेटवेकै राख्नुहोस्, र Wi-Fi मा भएको हरेक यन्त्रले त्यही नीति उत्तराधिकारमा पाउँछ। विकल्प, आफ्नै गेटवे भएको दोस्रो रुट गरिएको खण्ड, फरक असफलता विधि भएको फरक डिजाइन हो।

दुवैलाई भ्रममा पारिन्छ किनभने दुवैले इन्टरनेट र तपाईंका यन्त्रहरूबीच एउटा बाकस राख्छन्। प्रत्येकसँग के छ भन्ने तुलना गर्नु छनोट गर्ने सबैभन्दा छिटो बाटो हो।

Wi-Fi अगाडि VPN राख्ने दुई तरिका

ब्रिज गरिएको व्यवस्थामा पहुँच बिन्दुले रेडियो र तार भएको खण्डबीच फ्रेम बोक्छ र अरू केही गर्दैन: एउटा सबनेट, एउटा ठेगाना अधिकार, नीति कार्यान्वयन गर्ने एउटा राउटर। रुट गरिएको व्यवस्थामा दोस्रो बाकससँग आफ्नै ठेगाना, आफ्नै DHCP दायरा र आफ्नै पूर्वनिर्धारित मार्ग हुन्छ, त्यसैले ट्राफिक टनेलसम्म पुग्नुअघि अर्को सीमा पार गर्छ। ब्रिज डिजाइनले हरेक वायरलेस यन्त्रलाई गेटवेका लागि स्थानीय देखाउँछ, त्यसैले नियमको एउटा सेटले सबैलाई समेट्छ। रुट गरिएको डिजाइनले सोच्न खण्ड र नीति बिग्रन सक्ने दोस्रो ठाउँ दिन्छ।

internet
  -> vpn-capable gateway: routing, tunnel, dns, failure policy
  -> bridged access point: radio onto the same lan
  -> wifi clients

वायरलेस यन्त्रहरूले तार भएका यन्त्रजस्तै उही टनेल प्रयोग गर्नुपर्ने आवश्यकता हुँदा ब्रिज छान्नुहोस्। अलग गर्न सकिने खण्ड चाहिँदा, वा दोस्रो बाकस पहिले नै राउटरका रूपमा भएमा रुट गरिएको छान्नुहोस्।

ब्रिज व्यवस्थाले वास्तवमा के बदल्छ

ब्रिजिङले अनुवादको तह र प्रतिस्पर्धी पूर्वनिर्धारित गेटवे हटाउँछ, र व्यवस्थापनको समस्या थप्छ। पहुँच बिन्दुलाई अझै पुग्न सकिने ठेगाना चाहिन्छ, जुन विक्रेताको कार्यप्रवाहले सामान्यतया मुख्य LAN मार्फत मिलाउँछ। यसको DHCP सेवा बन्द हुनुपर्छ, नत्र दुई अधिकारले विरोधाभासी भाडामा दिनेछन्। गेटवेले टनेल, रिजोल्भरका सेटिङ र टनेल खस्दा के हुन्छ भन्ने निर्णय राख्छ, त्यसैले नीति ठ्याक्कै एउटै ठाउँमा बस्छ।

रेडियोले यीमध्ये केही पनि टनेलबाट स्वतः उत्तराधिकारमा पाउँदैन। यसले केवल त्यसलाई छोप्ने तह थप्न छोड्छ।

दोस्रो रुट गरिएको खण्ड कहाँ मिल्छ

रुट गरिएको खण्डले आफ्नो जटिलता त्यतिबेला जायज ठहराउँछ जब यसको पछाडिका यन्त्रहरूलाई बाँकी LAN भन्दा फरक व्यवहार चाहिन्छ। अतिथि सञ्जाल, प्रयोगशाला, वा सधैं कुनै निश्चित देशबाट बाहिर जानुपर्ने ग्राहकहरूको समूह—यी सबै बाटोमा राउटर राख्ने कारण हुन्। मूल्य दोस्रो ठेगाना अधिकार, सुसंगत राख्नुपर्ने दोस्रो फायरवाल, र त्यहाँका कसैले खण्डसम्म पुग्नुपरे मुख्य LAN बाट फर्किने मार्ग हो। यी कन्फिगरेसनका विवरण होइनन्, दायित्व हुन्।

सामान्य गल्ती यो हो कि रुट गरिएको संस्करण दुर्घटनावश बनाइन्छ, अझै आफ्नै DHCP र अनुवाद चलाइरहेको राउटर पुनः प्रयोग गरेर। त्यसले दोहोरो अनुवाद र कसैले पत्ता लगाउन नसक्ने नीति बनाउँछ।

गेटवेबाट होइन, Wi-Fi ग्राहकबाट परीक्षण गर्नुहोस्

गेटवेमा सफल अनुरोधले टनेल गेटवेका लागि काम गर्छ भनी प्रमाणित गर्छ। वास्तविक प्रश्न यो हो कि वायरलेस ग्राहकको अगाडि पठाइएको ट्राफिकले त्यसलाई प्रयोग गर्छ कि गर्दैन, र त्यो ग्राहकबाटै अवलोकन गर्नुपर्छ। तलका आदेशहरूले ग्राहकको ठेगाना, यसको मार्ग र टाढाको सेवाले देख्ने ठेगाना जाँच्छन्।

ip -4 addr show wlan0
ip route get 1.1.1.1
curl -sS https://api.ipify.org; echo
traceroute -n -m 4 1.1.1.1

गेटवेको LAN भित्रको ठेगानाले पुलले फ्रेमहरू अनुवाद नगरी पार गराइरहेको पुष्टि गर्छ। पहिलो हप गेटवे भएको मार्गले ग्राहकले अन्यत्रबाट दोस्रो पूर्वनिर्धारित मार्ग लिएको छैन भनी पुष्टि गर्छ। निकास ठेगानाको जाँचले वास्तविक प्रश्नको उत्तर दिन्छ, र छोटो ट्रेसले पहिला हपहरू अपेक्षित हुन् कि हुन् देखाउँछ। ग्राहकको ठेगाना फरक दायराबाट आएको भए पहिलो शङ्कास्पद भड्किएको DHCP सर्भर हो।

हरेक बाकसको भूमिका, यसको ठेगाना र DHCP अधिकार लेख्नुहोस्। तीन रेखाको रेखाचित्र पर्याप्त छ, र नियम कहाँ पर्छ भन्ने अधिकांश बहस यसले टुङ्ग्याउँछ।