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 प्राधिकरण लिहून ठेवा। तीन रेषांचा आराखडा पुरतो, आणि नियम कुठे येतो याबद्दलचे बहुतेक वाद तो मिटवतो।