pfSense VPN सर्व्हर आणि क्लायंट म्हणून: दोन मार्ग, एक राउटर

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

कोणतेही सेटिंग हाताळण्यापूर्वी दोन्ही भूमिकांना नावे द्या

प्रत्येक प्रतिसाठी चार तथ्ये लिहा: त्याचा दूरचा जोडीदार, त्याची प्रमाणीकरण सामग्री, तो वाटणारा पत्ता-संच, आणि त्याच्या मागील जाळी। दोन्ही प्रती उपकरणावर वेगळ्या वस्तू आहेत आणि तुमच्या टिपांमध्येही वेगळ्या राहिल्या पाहिजेत। पुढे येणारी जवळजवळ प्रत्येक गोंधळात टाकणारी लक्षणे त्यांच्या मूल्यांच्या मिसळण्यातून येतात, आणि दोन प्रती एकाच टिपांचा संच वाटून घेतल्यास चुकीचा संच चुकीच्या रकान्यात पोहोचतो।

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

वाटून घेतलेल्या हार्डवेअरचा अर्थ वाटून घेतलेली ओळखपत्रे असा नाही, आणि दूरस्थ प्रवेश संचातील क्लायंट प्रमाणपत्र एक्झिट पुरवठादाराविरुद्ध वापरण्यायोग्य नसावे। वेगळी सामग्री रद्द करण्यालाही संपूर्ण ताफ्याच्या घटनेऐवजी स्थानिक निर्णय बनवते।

सर्व्हरची उत्तरे WAN मार्गावर ठेवा

उपकरण स्वतः तयार करत असलेली उत्तरे ही निष्काळजी डीफॉल्ट मार्गाची पहिली बळी असतात। फिरत्या वापरकर्त्याचे आवेष्टित पॅकेट आले की, उत्तर स्थानिकरीत्या तयार झालेला रहदारा असते आणि ते त्या वापरकर्त्याने आलेल्या इंटरफेसनेच बाहेर पडले पाहिजे। बाहेर जाणाऱ्या क्लायंटने ते पकडणारा डीफॉल्ट मार्ग बसवला असेल, तर उत्तर चुकीच्या बोगद्यात जाते आणि सेवा अजूनही निरोगी दिसत असतानाच सत्र अडकते।

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

मार्ग-नकाशा सर्वात लांब जुळणीने वाचा, तुम्ही काही संरचीत केल्याच्या क्रमाने नाही। प्रश्न असा आहे की एक्झिट जोडीदाराच्या पत्त्यासाठी कोणती नोंद जिंकते आणि आत येणाऱ्या सेवेच्या उत्तरासाठी कोणती नोंद जिंकते, आणि ती दोन उत्तरे वेगळी असू शकतात।

बाहेर जाणाऱ्या बोगद्याला स्वतःचा शेवटचा टप्पा खाऊ देऊ नका

बाहेर जाणाऱ्या क्लायंटला बोगदा उभारण्यासाठी आपल्या जोडीदाराच्या सार्वजनिक पत्त्यापर्यंत पोहोचावेच लागते। तो पत्ताच बोगद्यात मार्गस्थ केला गेला तर क्लायंट स्वतःच्या शेपटाच्या मागे धावतो: वाहतूक कधीच वर येत नाही, किंवा वर येते आणि मार्ग बसताच त्या क्षणी पडते। नोंदवही मार्ग बिघाडापेक्षा प्रमाणीकरणाची मुदत संपल्यासारखी दिसते, म्हणूनच मार्गाची तपासणी आधी करावी।

ओळखपत्रांपूर्वी मार्ग तपासा आणि बोगदा वर आल्यावर पुन्हा, कारण नोंद सुरुवातीला बरोबर आणि एका मिनिटानंतर चुकीची असू शकते। जोडीदाराचा पत्ता नेहमीच्या WAN मार्गाकडे दाखवला पाहिजे, कधीही बोगदा उपकरणाकडे नाही। वाहतूक स्थिर झाली की मनोरंजक प्रश्न पुढे पाठवलेल्या रहदाऱ्याकडे सरकतो, आणि तोच पुढचा निर्णय।

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

कोणत्या वापरकर्त्यांना एक्झिट मिळेल ते निवडा

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

दूरचे टोक या रचनेतून पुढे पाठवलेला रहदारा परवानगी देत असल्याची खात्री करा, कारण काही पुरवठादार देतात आणि काही देत नाहीत। फरक असा बोगदा म्हणून दिसतो जो जोडतो पण काहीही वाहत नाही, आणि तो स्थानिक बिघाड म्हणून वाचणे सोपे आहे। तीनही प्रवाह वेगवेगळे तपासा, कारण ते स्वतंत्रपणे अपयशी होतात, आणि तीनपैकी दोन म्हणजे अर्धवट बांधलेली रचना।

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

पहिली आज्ञा फिरत्या वापरकर्त्याचे बाहेरील जोडणी आहे, आणि क्लायंटने सुरुवातीचा क्रम पूर्ण झाल्याचे सांगितले की ती चालते। दुसरी त्या जोडलेल्या लॅपटॉपवरून चालवली जाते आणि तिने तुमच्या WAN पत्त्याऐवजी एक्झिट पुरवठादाराचा पत्ता सांगावा। तिसरी उपकरणावर संचातील पत्त्याला बांधलेली चालते, आणि ती कोणताही दूरस्थ वापरकर्ता न जोडता पुढे पाठवलेल्या रहदाऱ्यासाठी स्रोत धोरण तपासते। त्याऐवजी तिने WAN मधून उत्तर दिले तर धोरण जुळले नाही, आणि NAT संपादनाच्या कोणत्याही प्रमाणाने निवडीची अडचण सुटत नाही।

एक्झिट अपयशी झाल्यावर काय होईल ते ठरवा

अपयशाचे वर्तन घडण्यापूर्वी लिहा: बाहेर जाणारा बोगदा पडला की वापरकर्ते नेहमीच्या WAN वर परत जातात की एक्झिट परत येईपर्यंत अडवले जातात? दोन्ही उत्तरे समर्थनीय आहेत, आणि उपकरण तुमच्यावतीने निवडणार नाही। काढलेला मार्ग किंवा मृत प्रवेशद्वाराकडे दाखवणारे धोरण आपोआप पूर्ण अडवणुकीचा निकाल देत नाही। तुम्हाला अडवणूक हवी असेल तर धोरणाने ते स्पष्ट सांगावे, आणि एक्झिट काढूनच त्याची चाचणी करावी, त्याबद्दल विचार करून नाही। तुम्हाला परतीचे हवे असेल तर ते वापरकर्त्यांना जाहीर करा, कारण गपचूप नेहमीचा मार्ग घेणारा रहदाराच हा असा रहदारा आहे जो कोणालातरी झाकला गेला असे वाटत होते।

क्लायंट प्रत निष्क्रिय करा, जोडलेला वापरकर्ता अजून कशापर्यंत पोहोचतो ते पहा, मग ती पुन्हा सुरू करा। मुदत संपणारी विनंती म्हणजे तुम्ही मागितलेला पूर्ण अडवणुकीचा निकाल; WAN पत्त्याने उत्तर देणारी विनंती म्हणजे तुम्ही नोंद न केलेली परतीची सोय। IPv6 आणि DNS साठी तपासणी पुन्हा करा, कारण IPv4 साठी लिहिलेले धोरण AAAA रहदाऱ्याबद्दल काहीच सांगत नाही आणि कोणत्याही बोगद्याने ढकललेला रिझॉल्व्हर चौकशी खरोखर जिथून बाहेर पडते तिथूनच उत्तर देतो।

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Netgate ची मार्गस्थ OpenVPN कृती स्रोत धोरण, इंटरफेस नेमणूक आणि बाहेर जाणारे भाषांतर कसे जुळतात हे दाखवते, आणि तिची साइट-ते-साइट व्याप्ती हाच असा भाग आहे जो पूर्ण कॉपी करू नये। जे ती तुम्हाला सांगणार नाही ते म्हणजे वरच्या तीन अटींपैकी कोणती तुमच्या रचनेने आधीच मोडली आहे।