गेस्ट Wi-Fi मुख्य मार्ग का उपयोग करता रहता है: इसे अपना अलग निकास दें

आपने एक गेस्ट नेटवर्क बनाया, उसके लिए एक मार्ग जोड़ा, और मेहमान अब भी आपके सामान्य इंटरनेट कनेक्शन से बाहर जाते हैं। सुरंग चालू है, मुख्य LAN काम करता है, और गेस्ट डिवाइस आपके द्वारा दिए गए रेंज में पता बताते हैं, इसलिए कुछ भी टूटा नहीं दिखता। आमतौर पर जो कमी होती है वह मार्ग नहीं बल्कि एक चयनकर्ता है: राउटर यह विचार करने से पहले कि पैकेट किस इंटरफ़ेस से आया, पथ तय कर देता है, और जब तक कुछ स्पष्ट रूप से गेस्ट ट्रैफ़िक से मेल न खाए, वह ट्रैफ़िक डिफ़ॉल्ट विरासत में ले लेता है। समाधान एक सेगमेंट, एक नीति नियम और एक प्रत्युत्तर पथ है, इसी क्रम में।

लक्षण: मेहमान अब भी WAN से बाहर जाते हैं

संकेत निकास पता है। सुरंग के माध्यम से इंटरनेट तक पहुंचने वाला गेस्ट डिवाइस सुरंग प्रदाता का पता बताएगा, और जिसने डिफ़ॉल्ट विरासत में लिया वह आपके सामान्य कनेक्शन का पता बताएगा। एक गेस्ट डिवाइस और एक मुख्य LAN डिवाइस की साथ-साथ तुलना करें, क्योंकि दिलचस्प मामला तब है जब वे आपके कॉन्फ़िगर किए गए से अलग हों और आपस में मेल खाएं।

दूसरा संकेत यह है कि मेहमानों के ब्राउज़ करते समय सुरंग इंटरफ़ेस पर कोई ट्रैफ़िक नहीं होता। यदि काउंटर नहीं हिलते, तो नीति कभी लागू नहीं हुई, और सुरंग को स्वयं समायोजित करना मदद नहीं कर सकता।

चरण 1: एक वास्तविक सेगमेंट, केवल नाम नहीं

SSID नाम अलगाव नहीं बनाता। जांचें कि गेस्ट नेटवर्क अपने स्वयं के इंटरफ़ेस, VLAN या ब्रिज पर समाप्त होता है, और पता रेंज विश्वसनीय LAN से अलग है। कई उपभोक्ता एक्सेस पॉइंट पर, गेस्ट SSID को बाकी सब के साथ उसी सेगमेंट में ब्रिज किया जाता है, जो उसे ठीक किए बिना इस काम के बाकी हिस्से को असंभव बना देता है।

फिर गेस्ट रेंज और उसके DHCP सर्वर की पुष्टि करें, और रिज़ॉल्वर सेटिंग्स को उसी सेगमेंट से जोड़े रखें, पूरे राउटर से नहीं। फ़ायरवॉल नियम में केवल टिप्पणी के रूप में मौजूद गेस्ट सबनेट सेगमेंट नहीं है, और राउटर के पास मिलान करने के लिए कोई इंटरफ़ेस नहीं होगा।

VPN को कॉन्फ़िगर करना आसान बनाने के लिए मेहमानों को मुख्य LAN में ब्रिज न करें। यह उस अलगाव को रूटिंग शॉर्टकट से बदल देता है जो आप चाहते थे, और यही सामान्य कारण है कि गेस्ट नेटवर्क प्रिंटर और NAS तक पहुंच जाता है।

चरण 2: स्रोत के अनुसार सुरंग चुनें

रूटिंग तालिकाएं गंतव्य के अनुसार चुनी जाती हैं, इसलिए «0.0.0.0/0 को सुरंग में भेजें» कहने वाला नियम सभी पर लागू होता है। नीति रूटिंग एक दूसरा आयाम जोड़ती है: स्रोत पते के अनुसार तालिका चुनें। Linux-आधारित राउटर पर, यह एक अतिरिक्त नियम और एक समर्पित तालिका है, और क्रम मायने रखता है क्योंकि पहला मेल खाने वाला नियम जीतता है:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

वह अंतिम कमांड सवाल का सीधा जवाब देता है: यह स्रोत इस गंतव्य के लिए कौन सा इंटरफ़ेस इस्तेमाल करेगा। इसे बदलाव से पहले और बाद में चलाएं और आप बिना ब्राउज़र छुए जान जाएंगे कि नीति लागू हुई या नहीं।

अधिकांश राउटर फर्मवेयर वही बात इंटरफ़ेस नियम या स्रोत-आधारित गेटवे चयन के रूप में व्यक्त करते हैं। आपका प्लेटफ़ॉर्म जो भी सिंटैक्स इस्तेमाल करे, सिद्धांत एक ही है: इनपुट इंटरफ़ेस या स्रोत प्रीफ़िक्स से मेल करें, फिर केवल उसी मिलान के लिए मार्ग को ओवरराइड करें। गंतव्य पर मेल खाने वाला नियम मेहमान को घरेलू डिवाइस से अलग नहीं कर सकता।

चरण 3: प्रत्युत्तर पथ और अनुवाद

सुरंग से बाहर जाने वाले पैकेट को वापस आना होगा। या तो सुरंग साथी गेस्ट प्रीफ़िक्स तक वापसी मार्ग जानता है, या राउटर गेस्ट स्रोत को सुरंग पते में अनुवादित करता है। एक चुनें और लिख लें, क्योंकि विफलता के तरीके अलग दिखते हैं: गायब वापसी मार्ग ऐसा कनेक्शन देता है जो स्थापित होता है और कभी जवाब नहीं देता, जबकि गायब अनुवाद अक्सर कुछ भी उत्पन्न नहीं करता।

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

यदि आप अनुवाद चुनते हैं, तो याद रखें कि साथी अब हर मेहमान के लिए एक पता देखता है, इसलिए दूर के छोर पर प्रति-क्लाइंट कोई भी नीति चली जाती है। यदि आप इसके बजाय पते सुरक्षित रखते हैं, तो दोनों सिरों को अपने रूटिंग और नीति में गेस्ट प्रीफ़िक्स चाहिए, जो अधिक काम है और अधिक पूर्वानुमेय।

IPv6 को अपना नियम चाहिए। IPv4 के लिए लिखी नीति दूसरे परिवार को कवर नहीं करती, और काम कर रहे IPv6 वाला गेस्ट डिवाइस उसका आनंद से उपयोग करेगा जबकि आपका सावधानी से रूट किया गया IPv4 पथ बेकार पड़ा रहेगा। दोनों परिवारों को रूट करें या गेस्ट सेगमेंट पर IPv6 अक्षम करें, लेकिन यह न मानें कि आपके द्वारा लिखा गया संयुक्त नियम वह कवर करता है जो डिवाइस वास्तव में करता है। ऐसे क्लाइंट के साथ परीक्षण करें जिसमें दोनों परिवार सक्षम हों, क्योंकि यही वह मामला है जिसे डिज़ाइन को झेलना है। IPv6 पसंद करने वाला लैपटॉप केवल IPv4 परीक्षण में सही दिखता है और वास्तविक में लीक करता है।

अलगाव का परीक्षण करें, केवल ब्राउज़िंग का नहीं

ब्राउज़िंग साबित करती है कि निकास बदला। यह साबित नहीं करती कि सेगमेंट अलग है, और अलगाव ही गेस्ट नेटवर्क होने का कारण है। गेस्ट डिवाइस से, राउटर के प्रशासन इंटरफ़ेस, विश्वसनीय LAN होस्ट और ऐसी सेवा तक पहुंचने का प्रयास करें जिसे अस्वीकार किया जाना चाहिए; तीनों विफल होने चाहिए, और विफलता नीति का निर्णय होनी चाहिए, न कि ऐसा टाइमआउट जिसे कोई समझा न सके।

फिर मुख्य LAN डिवाइस का परीक्षण करें और पुष्टि करें कि उसका निकास नहीं बदला। यही वह रिग्रेशन है जो यह डिज़ाइन सबसे अधिक बार करता है: मेहमानों के लिए बनाया गया व्यापक नियम, हर इंटरफ़ेस पर लागू, क्योंकि मिलान गंतव्य पर लिखा गया था।

अंत में, तय करें कि सुरंग बंद होने पर क्या होता है। मेहमानों को या तो इंटरनेट नहीं मिलता या वे आपके अनुमोदित मार्ग पर लौट जाते हैं, और इसे अनिर्णीत छोड़ने का अर्थ है सामान्य कनेक्शन पर चुपचाप लौटना, जो ठीक वही लीक है जिसे गेस्ट नीति रोकना चाहती थी। इंटरनेट ट्रैफ़िक के रूटिंग की विधि pfSense-आधारित राउटर के लिए उसी पथ चयन से गुजरती है।

राउटर से उत्पन्न DNS वह मामला है जो लोगों को अंत में चौंकाता है। यदि मेहमान राउटर को अपने रिज़ॉल्वर के रूप में उपयोग करते हैं, तो राउटर की अपनी क्वेरी गेस्ट नियम के बजाय राउटर के मार्ग का पालन करती हैं, इसलिए खोजें सामान्य कनेक्शन से बाहर जा सकती हैं जबकि एप्लिकेशन ट्रैफ़िक नहीं जाता। सेगमेंट, रिज़ॉल्वर और विफलता नीति को एक ही नोट में रखें, और अगला व्यक्ति डिज़ाइन को फिर से निकाले बिना तीनों की जांच कर सकेगा।