OpenVPN र HTTPS पोर्ट 443 मा: श्रोता कसको हो?
TCP र UDP 443 छुट्टाछुट्टै सकेट हुन्। एउटा TCP श्रोता साझा गर्न मालिक चाहिन्छ, र OpenVPN को पोर्ट साझेदारी एउटा साँघुरो व्यवस्था हो, प्रोक्सीको चाल होइन।
दुई सेवाले कहिल्यै प्रतिस्पर्धा नगरी दुवै पोर्ट 443 मा जवाफ दिन सक्छन्, किनभने श्रोता केवल संख्याले होइन, यातायात, ठेगाना र पोर्ट तीनवटै मिलेर निर्धारण हुन्छ। एउटै मेसिनमा वेब सर्भर र OpenVPN राख्नुहोस्, र पहिले जवाफ दिन लायक एउटै प्रश्न यो हो कि प्रत्येक प्रक्रियाले कर्नेलसँग कुन सकेट माग्छ। कन्फिगरेसन सम्पादन गर्नु अघि त्यो सूची लेख्नुहोस्, र «ठेगाना पहिल्यै प्रयोगमा छ» भन्ने अधिकांश त्रुटिले आफैं व्याख्या गर्छन्। सूचीपछिको सबैथोक UDP श्रोता, साझा TCP सकेट वा प्रोटोकल अनुसार मार्गनिर्देशन गर्ने फ्रन्ट एन्डबीचको छनोट हो।
प्रत्येक प्रक्रियाले माग्ने सकेटबाट सुरु गर्नुहोस्
bind त्यही त्रिकमा सफल वा असफल हुन्छ, त्यसैले दुई डेमन तीनवटै भाग मिल्दा मात्र ठोक्किन्छन्। त्यसैले TCP 443 मा रहेको वेबसाइट UDP 443 मा रहेको OpenVPN श्रोतासँग अनिश्चितकालसम्म सहअस्तित्वमा रहन्छ, र त्यसैले तीमध्ये एउटालाई त्यही होस्टको दोस्रो स्थानीय ठेगानामा सार्दा पनि विवाद टुंगिन्छ। जीवित श्रोताहरू पढ्नुहोस्, तिनीहरूलाई बनाउनुपर्ने फाइलहरू होइन, किनभने पुरानो include वा बिर्सिएको unit फाइलले तपाईंले सम्झेको सम्पादनभन्दा लामो समय टिक्छ।
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
root को रूपमा ss -lntup चलाउनुहोस् र 443 उल्लेख गर्ने प्रत्येक लाइन, IPv6 प्रविष्टिहरू सहित पढ्नुहोस्। सामान्यतया वाइल्डकार्ड v6 श्रोताले v4 ट्राफिक पनि स्वीकार गर्छ, र यसरी बिर्सिएको श्रोताले तपाईंले जिम्मेवार ठानेको फाइल बदलेपछि पनि पोर्ट ओगटिरहन्छ। प्रक्रियाको नामले तपाईंलाई छक्क पार्छ भने, केही छुनु अघि ss -lntup 'sport = :443' ले आउटपुट साँघुरो पार्नुहोस्।
नेटवर्कले अनुमति दिँदा टनेल UDP मा सार्नुहोस्
UDP श्रोताले ठोक्किने समस्या पूर्ण रूपमा छल्छ र सामान्यतया सबैभन्दा छोटो उपचार हो, किनभने कुनै सकेट साझा हुँदैन र बाटोमा कुनै थप उत्पादन आउँदैन। तर यो निःशुल्क होइन। केही क्लाइन्ट नेटवर्कले reset नपठाई UDP 443 छोडिदिन्छन्, त्यसैले टनेल bind मा असफल हुनुको सट्टा स्थापित हुन छोड्छ, र प्रयोगकर्ताले पढ्ने कुनै त्रुटि बिना VPN बन्द भएको रिपोर्ट गर्छ। UDP श्रोताले वेब तहको पुनःसुरुवात पनि सहन्छ, जुन साइट बारम्बार पुनःतैनात हुने मेसिनमा महत्त्वपूर्ण हुन्छ। प्रयोगकर्ता बसेको नेटवर्कबाट परीक्षण गर्नुहोस्, किनभने सर्भरमा रहेको shell ले सर्भर आफैंसम्म पुग्न सक्छ भन्ने मात्र प्रमाणित गर्छ।
सर्भर कन्फिगरेसन र क्लाइन्ट प्रोफाइलमा यातायात एकैसाथ बदल्नुहोस्। अझै TCP माग्ने प्रोफाइल UDP मात्र भएको श्रोतासामु पुनःजडान चक्रमा घुम्छ, र दुवै फाइल तुलना नगरेसम्म त्यो नेटवर्क खराबीजस्तो देखिन्छ।
VPN प्रक्रियालाई TCP 443 को मालिक बनाउनुहोस् र बाँकी अगाडि पठाउनुहोस्
TCP सर्भर मोडमा Community OpenVPN आउँदो जडानको पहिलो बाइट पढ्छ र आफ्नो प्रोटोकल नभएको सबै HTTPS ब्याकएन्डमा पठाउँछ, port-share निर्देश यसैका लागि हो। ब्याकएन्ड TLS सक्षम साधारण वेब सर्भर हो, त्यो निर्देशमा यसलाई URL ले होइन, होस्ट र पोर्टले नाम दिइन्छ।
port-share 10.0.0.5 8080
साइटको दोस्रो निजी ठेगाना भएको मेसिनमा त्यो लाइनले VPN नभएको ट्राफिक 10.0.0.5:8080 मा पठाउँछ, त्यसैले HTTPS भर्चुअल होस्ट त्यहीँ बाइन्ड हुनुपर्छ र फायरवालले स्थानीय उफ्रन अनुमति दिनुपर्छ। वेब सर्भरले TLS आफैं अन्त्य गर्नुपर्छ, किनभने आउने बाइट ब्राउजरको मूल ह्यान्डशेक हुन् र बीचमा कसैले तिनलाई डिक्रिप्ट गरेको छैन। निर्देश साधारण HTTP श्रोतातिर फर्काउनुभयो भने ब्राउजरले अवैध विधिको त्रुटि पाउँछ, जुन ब्याकएन्ड गलत ठाउँमा भएकोजस्तो होइन, बिग्रिएको साइटजस्तो पढिन्छ। निर्देश TCP सर्भर मोडमा मात्र हुन्छ, र UDP श्रोतासँग जाँच्ने कुनै स्ट्रिम छैन।
VPN प्रक्रियाले प्रत्येक जडान स्वीकार गर्ने भएकाले, वेब अनुप्रयोगले अगाडि पठाइएको अनुरोध आगन्तुकबाट होइन, होस्टको आफ्नै ठेगानामध्ये एकबाट आएको देख्छ। साँचो क्लाइन्ट ठेगाना चाहिने सबै ब्याकएन्डमा PROXY प्रोटोकल समर्थन वा त्यो थप्ने फ्रन्ट एन्डमा निर्भर छ। ब्याकएन्डलाई अर्को स्थानीय ठेगानामा सार्दा आगन्तुकको ठेगाना फर्कंदैन; यसले साइटले होस्टका कुन ठेगाना रेकर्ड गर्छ भन्ने मात्र बदल्छ। विश्लेषण प्रतिवेदनले प्रश्न उठाउनु अघि यो सीमा तैनाथी टिप्पणीमा लेख्नुहोस्।
रिभर्स प्रोक्सी गलत औजार हो; लेयर-चार राउटर होइन
HTTP रिभर्स प्रोक्सीले अनुरोध पढ्न TLS अन्त्य गर्छ, अर्थात् यसले OpenVPN स्ट्रिमलाई नछोई पार गर्न सक्दैन। SNI वा पहिलो प्याकेटको निरीक्षणअनुसार अगाडि पठाउने लेयर-चार राउटरले VPN निर्भर रहेको सत्र अन्त्य नगरेसम्म दुवैको अगाडि उभिन सक्छ। दुवै उपकरण रेखाचित्रमा उस्तै देखिन्छन् र सकेटमा पूर्ण रूपमा फरक व्यवहार गर्छन्।
व्यावसायिक Access Server आफ्नै पोर्ट साझेदारी सेटिङसँग आउँछ, र ती समुदाय निर्देशसँग एक-एक मिल्दैनन्। अर्कोका लागि लेखिएको मार्गदर्शन अपनाउनु अघि उत्पादन र संस्करण पहिचान गर्नुहोस्। चुपचाप बेवास्ता गरिएको प्रतिलिपि सेटिङ सेटिङ नहुनुभन्दा पनि नराम्रो हुन्छ, किनभने त्यसपछि पनि श्रोताहरूको सूची विश्वसनीय देखिन्छ।
वेबसाइट र टनेललाई दुई छुट्टाछुट्टै मार्गका रूपमा परीक्षण गर्नुहोस्
साइट लोड गर्नुहोस् र टनेल जोड्नुहोस्, त्यसपछि 443 अब कुन प्रक्रियाको मालिकीमा छ हेर्न श्रोताहरूको सूची फेरि पढ्नुहोस्। लोड हुने पृष्ठले VPN बारे केही प्रमाणित गर्दैन, र जोडिने टनेलले साइटबारे केही प्रमाणित गर्दैन, दुवैले एउटै संख्या प्रयोग गरे पनि। तलका तीन आदेशले क्रमशः साझा सकेट, वेब मार्ग र VPN सेवा जाँच्छन्।
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
त्यही क्षणका लागि ब्याकएन्डको पहुँच लगमा रहेको क्लाइन्ट ठेगानालाई VPN लगको ठेगानासँग तुलना गर्नुहोस्। साइटले प्रत्येक आगन्तुकलाई होस्ट आफैंका रूपमा रेकर्ड गर्छ भने अगाडि पठाउने काम गर्छ र ठेगाना व्यवस्थापन गर्दैन। दुवै लग चुप रहे भने फ्रन्ट एन्डले कहिल्यै जडान सुम्पिएन। जे भए पनि, सकेट कसले स्वीकार गर्छ भन्ने श्रोताहरूको सूचीले निर्धारण गर्छ, र अर्को फाइल बदल्नु अघि पुष्टि गर्नुपर्ने तथ्य त्यही हो।
त्यो श्रोता-नक्सा कन्फिगरेसनको छेउमा राख्नुहोस् ताकि 443 छुने अर्को व्यक्तिलाई कुन प्रक्रियाले स्वीकार गर्छ र अर्को प्रोटोकल कहाँ गयो भन्ने थाहा होस्। सम्पादनले के गर्न खोजेको थियो भन्नेमा भर पर्नुको सट्टा परिवर्तनपछि मालिकी पुष्टि गर्नुहोस्।