stunnel मागे OpenVPN: पोर्ट 1194 नाही, रॅपर फॉर्वर्ड करा
दोन श्रोते, तीन पोर्ट. फॉर्वर्ड कुठे उतरतो, रॅपर कुठे बांधतो, कुठे जोडतो, स्थानिक चाचणीने काय वगळले आणि दोन्ही ओळखी तपासा.
TLS रॅपर OpenVPN समोर ठेवा आणि उपयोजनाला दुसरा श्रोता मिळतो, त्यापैकी फक्त एकानेच कधीही इंटरनेटकडे पाहावे। सुरंग त्याच मशीनवरून चालतो आणि बाहेरून अयशस्वी होतो तेव्हा फॉर्वर्ड सहसा दोनपैकी चुकीच्याकडे निर्देशित असतो। जुळायला हवे ते एक साखळी आहे: सार्वजनिक नियम रॅपरपर्यंत पोहोचतो, आणि रॅपरचे स्वतःचे बॅकएंड कनेक्शन खऱ्या VPN सॉकेटपर्यंत पोहोचते। चार उड्या ही साखळी वाहतात, आणि त्यातील कोणतीही तपासणी लवकर संपवू शकते।
दोन सॉकेट, दोन मालक, एक सार्वजनिक
रॅपर बाहेरील कनेक्शनसाठी TLS संपवतो आणि डिक्रिप्ट झालेला बाइट प्रवाह साध्या OpenVPN TCP श्रोत्याकडे देतो। हे वेगवेगळ्या कॉन्फिगरेशन फाइलींसह वेगवेगळे सॉकेट आहेत, त्यामुळे एक संपादित केल्यास दुसरे अस्पर्शित आणि तरीही दिसण्यात निरोगी राहते। याचा अर्थ असाही की एक दुसऱ्याशिवाय बदलल्यास दोन्ही दूर जाऊ शकतात।
मशीनवरूनच काम करणे म्हणून सार्वजनिक मार्गाबद्दल फार थोडे सिद्ध करते। मूळ पोर्टवर थेट कनेक्शन रॅपर वगळते, रॅपरच्या LAN पत्त्यावरचे कनेक्शन भाषांतर वगळते, आणि बाहेरील वापरकर्ता काय करतो हे फक्त क्लायंट-बाजूची पूर्ण मांडणीच सरावते। नावेही काळजीपूर्वक वाचली पाहिजेत, कारण localhost तो विशिष्ट घटक चालवणारे होस्ट सूचित करते, आणि तुम्ही अपघाताने टाइप करत असलेले होस्ट नाही। हा फरक तुमच्या टिपांमध्ये ठेवा, कारण तिने झाकलेली उडी न नोंदवता केलेली चाचणी दोन वेगळ्या गोष्टींची तुलना करायला बोलावते।
फॉर्वर्ड प्रत्यक्षात कुठे उतरतो
साखळी तीन पोर्ट क्रमांकांपेक्षा चार उड्या म्हणून धरून ठेवणे सोपे आहे, कारण तोच क्रमांक प्रत्येक टोकाला वेगळा अर्थ देतो। तक्ता ओळीओळीने वाचा: प्रत्येक ओळ एक सॉकेट आहे ज्याला कनेक्शन स्वीकारून नंतर पुढचे उघडायचे आहे। एखादी ओळ चुकीच्या साथीदाराकडे निर्देशित असेल, तर शेवटच्या स्तंभातील लक्षण वापरकर्ता नोंदवतो तेच असते।
| Hop | Listens on | Must reach | Symptom when it points elsewhere |
|---|---|---|---|
| Client machine | A local plaintext port | The wrapper's public TLS address | Plain text offered to a TLS endpoint |
| Router forward | Public TCP 443 | The wrapper host on its translated port | Wrapper records no connection at all |
| Wrapper, server mode | Its accepted port, 8443 here | The native VPN socket on loopback | Handshake completes, then silence |
| Native VPN listener | Loopback TCP port | Its peer, over TCP only | A UDP socket behind a byte-stream relay |
रॅपरऐवजी मूळ VPN पोर्टला लक्ष्य करणारा नियम TLS समाप्ती पूर्णपणे वगळतो, हा या चुकीचा सर्वात सामान्य प्रकार आहे: क्लायंट OpenVPN फ्रेमिंगची अपेक्षा करणाऱ्या श्रोत्यासोबत हातमिळवणी उघडतो, त्यामुळे कनेक्शन उघडून नंतर अडकू शकते। भाषांतरित पोर्ट स्मृतीऐवजी रॅपरच्या कॉन्फिगरेशन फाइलशी पडताळा, कारण ती फाइल पुढील वेळी संपादित करणाऱ्याने वेगळा क्रमांक निवडला असेल। खालील दोन आदेश त्या प्रश्नाच्या दोन्ही बाजू एकाच वेळी दाखवतात।
grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'तुम्हाला नाकारणारा बाइंड पत्ता
127.0.0.1 ला बांधलेली accept ओळ फक्त होस्टलाच उत्तर देते, त्यामुळे LAN पत्त्यावर येणारा फॉर्वर्ड जोडू शकत नाही आणि क्लायंटला पॅकेट-फिल्टर समस्येसारखा वाटणारा नकार दिसतो। फायरवॉलला हात लावण्यापूर्वी सॉकेट पहा, कारण सॉकेट स्वस्त उत्तर आहे। एकतर रॅपर फॉर्वर्ड ज्या इंटरफेसला लक्ष्य करतो त्याला बांधा, किंवा तो loopback वर ठेवा आणि खरोखर काम करणाऱ्या एखाद्या गोष्टीतून फॉर्वर्ड loopback पर्यंत पोहोचेल असे करा। हे दोन आराखडे आहेत, आणि प्रत्येकाला स्वतःचा नियम हवा।
दोन्ही मिसळणे म्हणजे कार्यरत रॅपर बाहेरून अगम्य होण्याचा मार्ग, तर प्रत्येक फाइल बरोबर दिसते। खालील तपासणी एक आदेश आहे, आणि फायरवॉल नियमांचा आढावा देऊ शकत नाही अशा प्रश्नाचे उत्तर ती देते। आउटपुट loopback पत्ता दाखवत असेल आणि फॉर्वर्ड LAN पत्त्याला लक्ष्य करत असेल, तर दुरुस्ती accept ओळीत आहे, पॅकेट फिल्टरमध्ये नाही।
ss -lntp '( sport = :8443 )'स्थानिक चाचणीने प्रत्यक्षात काय सिद्ध केले
ज्या उडीचे तिने आवरण केले ती न नोंदवता झालेले यश इतर उड्यांबद्दल पुरावा नाही। चाचणीने कोणता पत्ता वापरला आणि कोणत्या प्रक्रियेने उत्तर दिले ते नोंदवा। नंतर त्याच Wi-Fi वरील फोनवरून नाही तर नेटवर्कबाहेरून पुन्हा करा, कारण हेअरपिन वर्तन राउटरनुसार बदलते आणि LAN कधीही न सोडलेले कनेक्शनही फॉर्वर्ड अजिबात सहभागी न होता ग्राहकाला समाधान देऊ शकते। फक्त तोच दुसरा प्रयत्न बाहेरच्या माणसाने घेतलेला मार्ग सरावतो।
प्रयत्न अयशस्वी झाल्यास एकच कनेक्शन दोन्ही लॉगमध्ये अनुसरा: रॅपरच्या स्वीकारलेल्या व जोडलेल्या ओळी, नंतर VPN डीमनचा स्वतःचा सत्र लॉग। काहीही नोंदवत नसलेली पहिली सीमा ही पुढील बदलाची जागा आहे। OpenVPN साथीदाराच्या पर्यायांची तुलना करू लागल्यावर त्या संदेशांचे मूल्यमापन त्या अंमलबजावणीच्या नियमांनी करा। link-mtu विसंगतीचा इशारा आपोआप घातक नाही, link-mtu 1500 वर पिन केल्याने विभाजन थांबले हे सिद्ध होत नाही, आणि सिफर वाटाघाटी राउटरच्या फॉर्वर्डची नाही तर आतील OpenVPN कॉन्फिगरेशनची गोष्ट आहे।
nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pagerती प्रोब बॅकएंड सॉकेट आणि रॅपर लॉग व्यापतात, जे नाकारलेल्या बॅकएंडला नाकारलेल्या हातमिळवणीपासून वेगळे करते। एक प्रयत्न सुरू असतानाच ते चालवा, नंतर नाही। एकाच प्रयत्नाच्या वेळमुद्राच तुलना विश्वासार्ह करतात।
दोन ओळखी, दोन अयशस्वी क्रम
बाहेरील प्रमाणपत्र रॅपरचे आहे आणि आतील ओळख OpenVPN ची आहे, आणि ती वेगवेगळ्या प्राधिकरणांकडून येऊ शकतात। मार्ग निरोगी दिसावा म्हणून कोणतीही एक तपासणी बंद करणे हे खऱ्या संरक्षणाची दिसण्याच्या निकालाशी अदलाबदल आहे। दोन्ही पडताळण्या ठेवा आणि क्रमाने डीबग करा, कारण संदेशांचा क्रम स्तराचे नाव सांगतो: रॅपर प्रमाणपत्राची समस्या कोणत्याही VPN पर्यायाच्या वाटाघाटीपूर्वी दिसते, तर आतील ओळखीचा अपयश प्रवाह स्थिरावल्यावरच दिसते।
stunnel पुस्तिका accept, connect आणि क्लायंट मोड अचूकपणे परिभाषित करते, आणि ते विभाग सॉकेटच्या प्रश्नाचे उत्तर अंदाजापेक्षा जलद देतात। कोणत्या स्तराने उत्तर दिले हे अजून सांगता येत नसेल, तर खालील आदेशाने सार्वजनिक पोर्ट सादर करणारे प्रमाणपत्र वाचा। आउटपुटमध्ये रॅपरचे प्रमाणपत्र असणे म्हणजे फॉर्वर्ड रॅपरपर्यंत पोहोचला, आणि शांतता किंवा प्रोटोकॉल त्रुटी म्हणजे पोहोचला नाही। तो एकच फरक इथल्या इतर कोणत्याही तपासणीपेक्षा जास्त वेळ वाचवतो।
openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer