फक्त वेब नेटवर्कवर VPN ब्लॉक? थरांवर काम करा

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

कोणता थर कनेक्शन नाकारतो हे सिद्ध करा

VPN क्लायंटपासून सुरुवात करू नका। त्याच होस्टला साध्या HTTPS विनंतीपासून सुरुवात करा आणि वेळेचे टप्पे वाचा, कारण जो टप्पा अयशस्वी होतो तो कोणते उपकरण जबाबदार आहे ते सांगतो:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

कोणतेही उत्तर नाही आणि connect वेळ नाही म्हणजे TCP कधीच पूर्ण झाला नाही, त्यामुळे फायरवॉल, प्रॉक्सीची मागणी किंवा चुकीचे लक्ष्य खेळात आहे। connect वेळ आहे पण tls वेळ नाही म्हणजे मधल्या कशाने कनेक्शन स्वीकारून हातमिळवणी थांबवली, तपासणारी प्रॉक्सी क्लायंटच्या बाजूने अशीच दिसते।

आता तुम्हाला खरोखर मिळणारे प्रमाणपत्र तपासा। सर्व्हरशी बोलत आहात की सत्रावर पुन्हा स्वाक्षरी करणाऱ्या मधल्या पेटीशी, हे जाणून घेण्याचा हा सर्वात वेगवान मार्ग आहे:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

जारीकर्त्याची ओळ वाचा। तुमचे स्वतःचे CA म्हणजे सेवेपर्यंत पोहोचलात; कॉर्पोरेट किंवा उपकरण जारीकर्ता म्हणजे फिल्टरने कनेक्शन संपवले आणि पुढे काय होईल हे ठरवत आहे। दोन्ही आउटपुट वेळेच्या शिक्क्यासह नोंदवा, कारण एका तासानंतर गेस्ट नेटवर्कवर तीच चाचणी वेगळे उत्तर देऊ शकते।

प्रॉक्सीची जाणीव असलेला क्लायंट पहिले पॅकेट बदलतो, धोरण नाही

नेटवर्क प्रमाणित प्रॉक्सीद्वारे CONNECT मागत असेल, तर VPN क्लायंटला सांगावे लागेल, नाहीतर तो मार्ग न देणाऱ्या पत्त्यावर सॉकेट उघडण्याचा प्रयत्न करेल। प्रॉक्सी क्लायंटपासून वेगळी तपासा, जेणेकरून अपयशाला एकच स्पष्टीकरण असेल:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

पहिला आदेश प्रॉक्सी लक्ष्य वाहून नेईल हे सिद्ध करतो। दुसरा क्लायंटला 443 वर TCP वापरण्यास सांगतो, बहुतेक फक्त-वेब मार्ग जे काही पुढे पाठवतात ते हेच एकमेव वाहन आहे। पहिला यशस्वी आणि दुसरा तरीही अयशस्वी असेल, तर प्रॉक्सी अडथळा नाही।

काही क्लायंट ओव्हरराइडऐवजी ऑपरेटिंग सिस्टमची प्रॉक्सी वाचतात, काही दोन्ही वाचत नाहीत। सिस्टम-व्यापी सेटिंग लागू आहे असे गृहीत धरण्यापूर्वी अनुप्रयोगाचे स्वतःचे दस्तऐवज पाहा। प्रॉक्सी सेवा न देणाऱ्या रिझोल्व्हरद्वारे एंडपॉइंट सोडवणारा क्लायंटही इथे अयशस्वी होईल, म्हणूनच DNS बदल हा केवळ वळसा असतानाही उपाय वाटू शकतो।

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

पोर्ट 443 पोहोचण्यायोग्य आहे, परवानगी नाही

443 वर टनल TLS मध्ये गुंडाळल्याने पोहोचण्याची क्षमता सुटते, इतर काहीही नाही। पोर्ट तपासणारा फिल्टर तिला पुढे जाऊ देईल; हातमिळवणीचे बोटचेपे घेणारा फिल्टर देणार नाही, आणि एन्क्रिप्टेड क्लायंट हॅलो सर्व्हरचे नाव दोन्ही टोकांनी आधार दिल्यासच लपवते। चाचणी चालवा आणि आशा धरण्याऐवजी तुम्ही कोणत्या प्रकारच्या फिल्टरमागे आहात ते जाणून घ्या।

लोकांना नंतर सापडणारा कार्यक्षमतेचा खर्चही आहे। विश्वासार्ह वाहनाच्या आत विश्वासार्ह वाहन तोटा वाढवते, कारण आतील स्टॅक बाहेरील स्टॅकने आधीच पुन्हा पाठवलेले विभाग पुन्हा पाठवतो। स्वच्छ दुव्यावर कोणालाही जाणवत नाही। गर्दीच्या कॅम्पस वायरलेसवर टनल हवी असते त्याच क्षणी निरुपयोगी होते, आणि हेतुपुरस्सर काहीही टाकले जात नसले तरी आलेख पॅकेट तोट्यासारखा दिसतो।

UDP सामान्यतः पहिला बळी, आणि अंदाज करण्याऐवजी ते पुष्टी करणे योग्य। TCP 443 चालू असताना WireGuard किंवा डीफॉल्ट OpenVPN हातमिळवणी कधीच पूर्ण करत नसेल, तर नेटवर्क UDP टाकत आहे, आणि की पुनरुत्पादनाने ते बदलणार नाही:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

काल चालत असलेल्या पीअरच्या शेजारी रिकामा हातमिळवणीचा वेळशिक्का हे UDP चे उत्तर आहे। दोन DNS प्रश्न वेगळ्या प्रश्नाला उत्तर देतात: स्थानिक रिझोल्व्हर आणि सार्वजनिक रिझोल्व्हर एंडपॉइंट पत्त्यावर एकमत नसतील, तर तुम्हाला स्टीयर केले जात आहे आणि वाहनाचा युक्तिवाद चुकीचा आहे।

मशीनमधून खरोखर काय गेले ते पडताळा

क्लायंट लॉग क्लायंट काय मानतो ते वर्णन करतात। कॅप्चर नेटवर्कने काय पाहिले ते वर्णन करते, आणि या दोन्हींतील फरक हाच या बहुतेक प्रकरणांचा निकाल लागण्याचे ठिकाण आहे:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

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

सॉकेट यादी अधिक सूक्ष्म प्रकरण पकडते: डीफॉल्ट मार्ग आधीच धरून ठेवणारी दुसरी टनल। राउटिंग टेबलसाठी भांडणारे दोन क्लायंट ब्लॉक झालेल्या नेटवर्कसारखेच दिसणारे अधूनमधून अपयश निर्माण करतात, आणि कॅप्चर तुम्ही अपेक्षा न केलेल्या इंटरफेसने बाहेर जाणारा रहदारी दाखवेल।

परतफेड, आणि ठेवण्यायोग्य टीप

बदल ज्या क्रमाने केले त्याच्या उलट क्रमाने परत करा। प्रॉक्सी चल काढा, हाताने सुरू केलेला क्लायंट थांबवा, आणि जोडलेला कोणताही मार्ग किंवा रिझोल्व्हर ओव्हरराइड काढा:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

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

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