NAT VPN सर्व्हरवर की राउटरवर? दोन्ही काम करू शकतात

लॅपटॉपवर कनेक्शनला डीफॉल्ट मार्ग म्हणून चिन्हांकित करणे हे प्रत्येकाला आठवणारे पाऊल आहे, आणि गेटवेवर काहीही बदलत नाही तेच। क्लायंट आता इंटरनेट विनंत्या सुरंगात पाठवतो; त्या इमारतीबाहेर पडतील का हे फॉरवर्डिंग, एक भाषांतर बिंदू आणि क्लायंटच्या खाजगी पत्त्यापर्यंत पोहोचणाऱ्या परतीच्या मार्गावर अवलंबून आहे। दोन रचना तिन्ही देऊ शकतात, त्या काम वेगवेगळ्या ठिकाणी ठेवतात, आणि उत्तराच्या दिशेची जबाबदारी कोणीही न घेतल्यास दोन्ही त्याच शांत पद्धतीने अपयशी होतात। त्यांच्यातील निवड हा क्लायंट पूल कोणी पाहावा हा प्रश्न आहे।

समजूत: क्लायंट मार्गच बाहेर जाण्याचे दार बनवतो

सक्तीचे टनेलिंग हे क्लायंट-बाजूचे धोरण आहे: ट्रॅफिक भौतिक अडॅप्टरऐवजी VPN अडॅप्टरकडे जाईल असे ते ठरवते। Microsoft चे VPN राउटिंग दस्तऐवज ते विभाजन आणि सक्तीचे वर्तन वर्णन करते, आणि ते क्लायंटच्या मार्ग सारणीबद्दलचे विधान आहे, सर्व्हरच्या फॉरवर्डिंग नियमांबद्दल नाही। क्लायंटच्या दृष्टीने सुरंग म्हणजे इंटरनेट राहतो ते ठिकाण; गेटवेच्या दृष्टीने एक पॅकेट वरच्या कोणीही कधीही न ऐकलेल्या पत्त्यावरून आले। कोणतीही बाजू एकटीच चुकीच्या पद्धतीने संरचित नाही, आणि म्हणूनच लॅपटॉपजवळच्या व्यक्तीला हे अपयश तुटलेल्या सर्व्हरसारखे दिसते।

ती विसंगती ही संपूर्ण समस्या आहे जी या लेखाचा उर्वरित भाग सोडवतो। काहीतरी क्लायंटच्या खाजगी पत्त्याला परत करण्यायोग्य बनवले पाहिजे, आणि निवड ही आहे की कुठे।

आधी उत्तराचा मार्ग काढा

कोणत्याही सेटिंगला स्पर्श करण्यापूर्वी मार्ग खऱ्या पत्त्यांसह लिहा, आणि त्यावर दोन संभाव्य भाषांतर बिंदू चिन्हांकित करा। ही प्रयोगशाळा 10.70.0.0/24 चा VPN पूल वापरते, ज्यात एक क्लायंट 10.70.0.37 वर, सर्व्हरचा LAN पत्ता 172.16.40.10, राउटर 172.16.40.1 वर आणि सार्वजनिक बाहेर पडण्याचे दार 203.0.113.40 वर आहे।

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

आधीपासून इंटरनेट ब्राउझ करणारा सर्व्हर फक्त स्वतःचा मार्ग सिद्ध करतो। क्लायंटच्या वतीने पुढे पाठवलेले पॅकेट हा वेगळा निर्णय आहे, जो त्याच मशीनवरील फॉरवर्डिंग धोरण घेते, आणि सहसा तेच गहाळ असते। आकृतीवर तीन निर्णय बिंदू चिन्हांकित केल्याने संभाषण एका वेळी त्यापैकी एकावर राहते।

पर्याय A: VPN सर्व्हरवर भाषांतर

येथे सर्व्हर पॅकेट राउटरला देण्यापूर्वी क्लायंटचा स्रोत आपल्या LAN पत्त्यात भाषांतरित करतो, आणि राउटर बाहेर जाताना आपले नेहमीचे भाषांतर लागू करतो। उत्तरावर राउटरचे मॅपिंग सर्व्हरचा पत्ता पुनर्संचयित करते आणि सर्व्हरचे मॅपिंग क्लायंटचा पत्ता पुनर्संचयित करते। क्रमाने दोन स्थितीयुक्त भाषांतरे सामान्य आणि व्यवहार्य आहेत, दोन्ही नोंदवली गेल्यास; राउटरला कधीही पूलापर्यंत मार्गाची आवश्यकता नसते, आणि हेच या रचनेचे आकर्षण आहे।

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

NAT आहे असे गृहीत धरण्याऐवजी सर्व्हरकडे आधीच काय आहे हे पाहण्यासाठी ही वाचने वापरा। ब्लॉगवरून कॉपी केलेला Linux masquerade नियम Windows संरचना नाही, आणि VPN श्रोत्यासाठी होस्ट फायरवॉलमधील परवानगी क्लायंटची विनंती पुढे फॉरवर्ड करण्याच्या परवानगीइतकीच नाही। सर्व्हरची फॉरवर्डिंग भूमिका त्याच्या स्वतःच्या व्यवस्थापन इंटरफेसवरून पुष्टी करा, नंतर भाषांतर स्वतंत्रपणे पहा, कारण दोन्ही बऱ्याचदा तैनातीच्या वेगवेगळ्या भागांद्वारे सक्षम केले जातात।

पर्याय B: पूल राउटरकडे नेणे

दुसऱ्या रचनेत सर्व्हर क्लायंटचा खरा स्रोत पत्ता पुढे पाठवतो, आणि राउटर त्याचे भाषांतर करतो। यामुळे क्लायंट पूल काठावर दृश्यमान राहतो, जे राउटर हेच ट्रॅफिक धोरण, लॉगिंग किंवा तपासणीचे ठिकाण असल्यास उपयुक्त ठरते। याचा अर्थ असाही की राउटरला 10.70.0.0/24 साठी 172.16.40.10 कडे निर्देश करणारा परतीचा मार्ग आणि त्या उपसर्गाचा खरोखर समावेश करणारे इंटरनेट धोरण आवश्यक आहे; LAN उपजाळासाठी लिहिलेला नियम शांतपणे पूलापर्यंत विस्तारत नाही।

काठावरील उपकरण हे इच्छित धोरण मालक असेल आणि त्याच्या राउटिंग व भाषांतर सारण्यांमध्ये अजून एक उपसर्ग स्वीकारू शकत असेल तेव्हा हे निवडा। पूल वर अदृश्य राहिला पाहिजे आणि राउटर त्याच संघाद्वारे व्यवस्थापित होत नसेल तेव्हा सर्व्हर-बाजूचे भाषांतर निवडा। कोणताही पर्याय क्लायंटवरील कोणत्याही चेकबॉक्समधून सुचवला जात नाही, आणि कोणताही सर्वसाधारणपणे अधिक सुरक्षित नाही; ते दृश्यमानता आणि देखभाल वेगवेगळ्या ठिकाणी ठेवतात।

DNS, IPv6 आणि स्वीकृती स्पष्ट करा

पत्ता भाषांतर नाव निराकरण दुरुस्त करत नाही। क्लायंट VPN प्रोफाइलसोबत दिलेला रिझॉल्व्हर, विशिष्ट नावस्थानांसाठी खाजगी रिझॉल्व्हर, किंवा मंजूर सार्वजनिक रिझॉल्व्हर वापरू शकतो, आणि त्या धोरणाखाली पोहोचता न येणारा रिझॉल्व्हर राउटिंग काम केल्यानंतरही अपयशी होत राहील। नाव आणि पत्ता स्वतंत्रपणे तपासा, जेणेकरून दोन्ही अपयश कधीही एका अहवालात विलीन होणार नाहीत।

IPv6 ला रचनेत स्वतःचा परिच्छेद हवा। काम करणारे IPv4 भाषांतर IPv6 क्लायंटकडे मार्ग, वैध सार्वजनिक स्रोत किंवा सुरंग पडल्यावर त्यांना अडवणारे धोरण आहे का याबद्दल काहीही सांगत नाही। हे न सांगता सोडणे म्हणजे अर्धे क्लायंट शांतपणे गेटवे टाळतात आणि उर्वरित अर्धे काम करतात।

स्वीकृतीसाठी, मंजूर केलेली एक क्लायंट विनंती आणि तिचे उत्तर दोन्ही सीमांवरून पाठपुरावा करा, आणि त्या क्षणी प्रत्येक सीमेला कोणता पत्ता दिसावा ते लिहा। तीच नोंद पुढील पूल बदलाला, गहाळ परतीच्या मार्गाचा मालक कोण हा वाद न होता पाच मिनिटांचे संपादन बनवते। नोंद तिकिटात नाही तर क्लायंट प्रोफाइलसोबत ठेवा, कारण पुढील अभियंत्याला पहिल्यांदा प्रोफाइलच सापडेल।