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