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