गेस्ट Wi-Fi मुख्य मार्ग वापरत राहतो: त्याला स्वतःचे स्वतंत्र बाहेर जाण्याचे मार्ग द्या
SSID हा मार्ग नाही. मेहमान WAN मधूनच बाहेर पडत राहतात, जोपर्यंत स्वतंत्र सबनेट, स्रोत-आधारित नियम आणि जुळणारा प्रत्युत्तर मार्ग सर्व सुरंगाकडे निर्देश करत नाहीत.
तुम्ही गेस्ट नेटवर्क तयार केले, त्यासाठी मार्ग जोडला, तरीही मेहमान तुमच्या नेहमीच्या इंटरनेट कनेक्शनमधूनच बाहेर पडत आहेत. सुरंग सुरू आहे, मुख्य 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 हे लोकांना शेवटी चकित करणारे प्रकरण आहे. मेहमान राउटरला त्यांचा रिझोल्व्हर म्हणून वापरत असतील, तर राउटरच्या स्वतःच्या क्वेऱ्या गेस्ट नियमाऐवजी राउटरच्या मार्गाचे अनुसरण करतात, त्यामुळे अनुप्रयोग रहदारी बाहेर न जाता शोध नेहमीच्या कनेक्शनमधून बाहेर जाऊ शकतात. सेगमेंट, रिझोल्व्हर आणि अपयश धोरण एका टिपात ठेवा, आणि पुढची व्यक्ती डिझाइन पुन्हा काढल्याशिवाय तीनही तपासू शकेल.