तुम्ही जवळ वाटणारा सर्व्हर निवडता, कनेक्ट दाबता, आणि नवीन टनेल उभे राहण्यापूर्वीच ब्राउझर लोड होणे थांबवतो. आयकॉन कनेक्ट होण्याच्या स्थितीत जातो आणि प्रत्येक टॅबची वेळ संपेपर्यंत तिथेच राहतो. हा खंड सहसा kill switch चं डिझाइननुसार काम असतं: क्लायंटकडे ट्रॅफिक पाठवण्यासाठी टनेल नसल्यास तो अडवला जातो. खंड स्वीकारार्ह आहे का, हे त्या सेकंदांत क्लायंट काय करतो आणि ब्लॉक काढला असे म्हटल्यावर खरंच काढला जातो का यावर ठरतं.

दोन सर्व्हरमध्ये क्लायंट काय करतो

एंडपॉइंट बदलणं एक स्विच नाही, अनेक टप्पे आहेत. क्लायंट सध्याचं टनेल तोडतो, आपले ब्लॉकिंग नियम अद्ययावत करतो, नवीन एंडपॉइंट सोडवून टनेलबाहेरून त्याच्यापर्यंत पोहोचतो, नंतर नवीन मार्ग बसवतो आणि ब्लॉक उचलतो. तुम्हाला जाणवणारं अंतर पहिल्या आणि शेवटच्या टप्प्यामध्ये असतं.

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

नवीन एंडपॉइंटला ब्लॉकमध्ये भोक हवं

टनेल बांधण्यासाठी क्लायंटने भौतिक इंटरफेसवरून नवीन सर्व्हरच्या पत्त्या आणि पोर्टवर पॅकेट पाठवावी लागतात, उदाहरणार्थ नेहमीच्या WireGuard प्रोफाइलसाठी UDP 51820 किंवा OpenVPN साठी 1194 आणि 443, तुमचं प्रोफाइल जे सांगेल ते. ते ट्रॅफिक येऊ घातलेल्या टनेलच्या आत नाही, म्हणून जुळणारा परवानगी नियम नसेल तर संपूर्ण उपकरणासाठीचा ब्लॉक ते गिळून टाकतो.

होस्टनावावर आधारित प्रोफाइल दुसरी अट जोडतात: शोध स्वतः. ब्लॉक उचलण्यापूर्वी क्लायंटने एंडपॉइंट सोडवला, तर तो कॅशेमधील पत्ता वापरू शकतो, पण प्रोफाइल पत्ते फिरवल्यावर किंवा कॅशे नोंद जुनी झाल्यावर हातमिळवणी अशा पत्त्याकडे जाते जो परवानगी नियम व्यापत नाही. IPv6 हे दिसतं करतं, कारण दुहेरी स्टॅकचा एंडपॉइंट A आणि AAAA दोन्ही रेकॉर्ड प्रकाशित करू शकतो, आणि फक्त v4 पत्ता व्यापणारा परवानगी नियम क्लायंटला अडवलेल्या v6 पत्त्याविरुद्ध पुन्हा प्रयत्न करत ठेवतो.

पर्यायांची नावं आणि डीफॉल्ट मूल्यं क्लायंट व आवृत्तीनुसार बदलतात, म्हणून स्क्रीनशॉटवरून अंदाज न करता तुमच्यासाठीची दस्तऐवजी यादी वाचा. OpenVPN Connect च्या सेटिंग्ज संदर्भ openvpn.net/connect-docs/app-settings-windows वर एक उदाहरण आहे की क्लायंट आपले ब्लॉक व विभाजित टनेल पर्याय कसे वर्णन करतो.

Fail-closed ही स्थिती यंत्रणा आहे, स्विच नाही

बहुतेक क्लायंट ब्लॉकला फायरवॉल धोरण म्हणून तीन स्थितींमध्ये व्यक्त करतात: टनेल वर, ट्रॅफिक टनेलमधून जातं आणि ब्लॉक नाही; टनेल खाली, ब्लॉक सक्रिय; आणि संक्रमण, ब्लॉक सक्रिय अधिक एंडपॉइंटसाठी तात्पुरते अपवाद. तिसऱ्या स्थितीतच बग राहतात, कारण तिला काही सेकंदांत दोनदा बदलावं लागतं, आणि त्यातून बाहेर न पडणं कायमच्या ब्लॉकसारखंच दिसतं.

यंत्रणा प्लॅटफॉर्मनुसार बदलते, आणि अपयशही. Windows Filtering Platform च्या फिल्टरना वजन असतं, म्हणून तुमच्या परवानगीला मागे टाकणारा ब्लॉक फिल्टर परवानगी असूनही पॅकेट टाकत राहतो, आणि मारल्या गेलेल्या क्लायंट प्रक्रियेने सोडलेले फिल्टर अ‍ॅप गेल्यावरही यंत्र ऑफलाइन ठेवू शकतात. macOS क्लायंट सहसा pf नियम अँकरमध्ये लिहितात, जिथे नियमांचा क्रम आणि झटपट निर्णय कोणता नियम लागू होतो हे ठरवतात. Linux क्लायंट सहसा drop धोरणासह nftables किंवा iptables शृंखला चालवतात आणि एंडपॉइंट, टनेल इंटरफेस व लूपबॅकसाठी स्पष्ट परवानग्या देतात. Android चं always-on VPN, VPN शिवाय कनेक्शन अडवण्याच्या पर्यायासह, गटातील सर्वात कडक आहे, कारण संचालन प्रणाली ब्लॉक अ‍ॅपनिहाय नव्हे तर संपूर्ण उपकरणावर लागू करते.

WireGuard ला स्वतःची नोंद हवी, कारण AllowedIPs हा मार्ग निवडक आहे, अडवणारा नाही. कोणती गंतव्यं टनेलमध्ये जातात हे तो ठरवतो; अजून टनेल नसलेलं पॅकेट Wi-Fi वरून बाहेर जाण्यापासून रोखण्यासाठी तो काहीच करत नाही. फक्त WireGuard आणि फायरवॉल नियम नसलेल्या रचनेत kill switch म्हणजे प्रत्यक्षात मार्गाचा अभाव, आणि टाकलेल्या हातमिळवणीनंतर भौतिक इंटरफेसवरून खरं पॅकेट बाहेर जाऊ शकतं.

आयकॉन पाहण्याऐवजी अंतर मोजा

स्थिती दिव्याकडे नाही, पॅकेटकडे लक्ष द्या. Linux मध्ये एका टर्मिनलमध्ये सार्वजनिक पत्त्यावर संथ ping सुरू करा आणि दुसऱ्यात भौतिक इंटरफेसवर टनेलचा वाहतूक पोर्ट पकडा:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

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

Windows मध्ये netsh wfp show state एक स्नॅपशॉट लिहितो, ज्यात क्लायंट स्वतःला डिस्कनेक्टेड सांगत असतानाही अजून असलेले ब्लॉक फिल्टर शोधता येतात. macOS मध्ये sudo pfctl -sr लोड झालेले नियम आणि त्यांचा क्रम सूचीबद्ध करतो. कोणताही स्नॅपशॉट क्लायंटच्या स्वतःच्या लॉगशी जोडा; तुमच्या ping ची कालरेषा सांगते की ब्लॉक उशिरा संपला की कधीच नाही.

सामान्य अंधार बनाम अडकलेला ब्लॉक

थोडा व्यत्यय हा या वैशिष्ट्याचा उद्देश आहे, म्हणून कोणतीही सेटिंग बदलण्यापूर्वी वर्गीकरण करा:

What you seeUsually meansNext check
Two or three seconds of timeouts, then normal browsingExpected fail-closed gapNothing to fix
State says connected, traffic stays deadBlock filter or route left behindFirewall snapshot, client log
One app dead while others workTCP session bound to the old exit addressRestart the app
LAN devices unreachable after the switchLAN exception not reappliedAllow-LAN or split-tunnel setting
New server hangs, the old one reconnectsPermit covers only the old addressResolved address of the new host, including AAAA

दुसऱ्या किंवा पाचव्या ओळीत पडलात तर तपासण्यासाठी kill switch बंद करू नका, कारण त्यामुळे मार्गातील दोष गळतीत बदलतो. क्लायंटची सेवा पुन्हा सुरू करा, किंवा प्रक्रिया मारल्यावरही फिल्टर टिकतात तिथे यंत्र रीबूट करा, नंतर ब्लॉक निघून जातो का पाहा. निघून गेला तर दोष ब्लॉकमध्ये नसून बदलाच्या वेळच्या स्वच्छतेत आहे.

पुढच्या बदलापूर्वी चार गोष्टी निश्चित करा: एंडपॉइंट परवानगी तुमचं प्रोफाइल सोडवणाऱ्या प्रत्येक पत्ता कुटुंबाला व्यापते, क्लायंट लॉग संक्रमण पूर्ण झाल्याचं दाखवतो, तुमची ping चाचणी आयकॉन नव्हे तर अंतर मोजते, आणि क्लायंट बंद केल्यावर सामान्य कनेक्टिव्हिटी परते. बदलाच्या काळात टिकून नंतर सोडणारा kill switch आपलं काम करतो. लवकर किंवा कधीच न सोडणारा डीबग करण्यासारखा आहे.

संबंधित लेख