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

चाचणी एकाच अरुंद प्रश्नाचे उत्तर देते: या संक्रमणादरम्यान हे अनुप्रयोग बोगद्याबाहेरील नेटवर्कपर्यंत पोहोचू शकतात का? उर्वरित धोरण समजूतदार आहे का याबद्दल ते काहीच सांगत नाही। व्याप्ती एवढी लहान ठेवा आणि निकाल लिहून ठेवण्यासारखा असेल।

क्लायंटमध्ये स्विच आणि त्याची व्याप्ती शोधा

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

नंतर तुमचा क्लायंट प्रत्यक्षात करू शकणारी संक्रमणे यादी करा। वापरकर्त्याने सुरू केलेले डिस्कनेक्ट, अनुप्रयोगातून बाहेर पडणे आणि सर्व्हरशी संपर्क तुटणे हे बहुतेक क्लायंटमध्ये तीन वेगवेगळे कोड मार्ग आहेत, आणि ते एकच अडव धोरण वाटून घेत नाहीत। काही अनुप्रयोग बंद झाल्यावर अडव सोडतात। इतर काही काढण्यापर्यंत गाळणी नियम सोडतात। गृहीत धरण्याऐवजी तुम्ही चालवत असलेल्या बिल्डसाठी उत्पादकाचे सेटिंग संदर्भ वाचा आणि तीनपैकी कशाची चाचणी करता ते लिहा।

प्रोफाइलही नोंदवा: प्रोटोकॉल, पत्ता कुटुंबे आणि विभाजित बोगदा सुरू आहे का। प्रोफाइल जाणूनबुजून काही अनुप्रयोग वगळत असेल तर संपूर्ण उपकरणाचा दावा निरर्थक आहे, आणि तुम्हीच केलेला अपवाद म्हणजे गळती नाही। OpenVPN Connect चे सेटिंग संदर्भ कोणता स्विच कोणते वर्तन बदलतो हे सांगणारे असे पान आहे, जरी लेबल क्लायंटनुसार बदलतात।

बोगद्याशिवायही चालणारे फसवे गंतव्य निवडा

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

तुम्ही नियंत्रित करता त्या होस्टवरील स्थिर पान सर्वात स्वच्छ पर्याय आहे। साधा HTTP सर्व्हर चालवणारे राखीव आभासी यंत्र जवळपास तितकेच चांगले आहे, आणि त्याची उपलब्धता तुमच्या नियंत्रणाबाहेर आहे हे मान्य असेल तर सार्वजनिक कनेक्टिव्हिटी तपासणी पानही चालते। पत्ता, पोर्ट, पत्ता कुटुंब आणि विनंतीला नाव शोध आवश्यक आहे का हे नोंदवा, कारण यापैकी प्रत्येक नंतर वेगळे करावे लागू शकणारे चल बनते।

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

संक्रमणे ठरलेल्या क्रमाने चालवा

संक्रमणे एका वेळी एक करा आणि प्रत्येकाला काही सेकंद स्थिरावायला द्या, कारण क्लायंट बहुतेकदा त्याच अंतरात नियम मोडून पुन्हा बांधतात। दर वेळी तीच छोटी तपासणी चालवल्याने निरीक्षणे तुलनात्मक होतात:

curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"
TransitionExpected with the block onFailure signature
Manual disconnectDecoy stops answering within secondsDecoy still returns 200
Server or path failureBlocked, with no exemption for the old endpointDirect access during the gap
Quit the appClient-dependent; record what happensBlock disappears with the process
Wi-Fi to EthernetBlock holds until the tunnel returnsTraffic flows mid-change

अनुप्रयोगातून बाहेर पडण्याची ओळ, सामान्य वापरात क्लायंट कधीच बंद न केला तरी, स्वतंत्रपणे चालवण्यास पात्र आहे। बाहेर पडताना अडव सुटत असेल, तर क्रॅश किंवा सक्तीचे अद्ययावत तुम्हाला तेच उघडपण देते, आणि हे तुमच्या संयमाबद्दल नाही, तैनातीबद्दलचे सत्य आहे। Windows वर समतुल्य चाचण्या Resolve-DnsName decoy.example आणि curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/ आहेत।

अडव आणि बिघडलेला रिझॉल्व्हर वेगळे करा

न लोड होणाऱ्या पानाला अनेक कारणे असतात, आणि त्यातील फक्त एक म्हणजे स्विच चालू असणे। नाव सुटत नसेल, तर डेटा मार्ग अडवला आहे हे नाही, DNS अडवले आहे किंवा बिघडले आहे हे समजले। अक्षरशः पत्ताही तपासा, म्हणजे उत्तर नाव सोडवण्यावर अजिबात अवलंबून राहणार नाही।

curl चे एक्झिट कोड ही प्रकरणे वेगळी करतात। 6 म्हणजे नाव सोडवण्यातील अपयश, 7 म्हणजे जोडणी नाकारली गेली, 28 म्हणजे वेळ संपली। अडवलेला मार्ग सामान्यतः अक्षरशः पत्त्यासाठी वेळ संपणे किंवा नकार म्हणून दिसतो, तर फक्त DNS अडवल्यास 6 राहतो आणि बाकी सर्व लपते। कॅशे केलेले पान किंवा कॅप्टिव्ह पोर्टल डोळ्याची फसवणूक करते, म्हणून पुरावा स्क्रीन नाही, एक्झिट कोड आहे।

अक्षरशः पत्त्यासह IPv6 वर तपासणी पुन्हा करा। IPv4 व्यापून IPv6 दुर्लक्षणारा अडव तुमच्या टिपांमध्ये स्वतंत्र ओळीस पात्र अशा प्रमाणात सामान्य आहे, आणि बोगद्याबाहेर IPv6 बंद करणारा क्लायंट दोन्ही कुटुंबांवर स्वच्छपणे अपयशी व्हावा।

निकाल जी व्याप्ती व्यापतो ती नोंदवा

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

एका फेरीत एक क्लायंट बिल्ड, एक प्रोफाइल, एक संक्रमण आणि एक पत्ता कुटुंब येते। ती चार निकालासह लिहा:

  • क्लायंट बिल्ड आणि प्लॅटफॉर्म, आणि सेटिंग प्रोफाइलनुसार आहे की सार्वत्रिक।
  • प्रोफाइल, प्रोटोकॉल आणि विभाजित बोगद्याचे कोणतेही अपवाद।
  • चाचणी केलेले संक्रमण आणि ते तुम्ही कसे घडवले।
  • पत्ता कुटुंबे आणि DNS, अडवलेल्या व न-अडवलेल्या स्थितींसाठी curl एक्झिट कोडसह।

कोणतीही ओळ रिकामी असेल तर चाचणी पूर्ण झालेली नाही। रोमिंग म्हणजे नेटवर्क बदलाची ओळ पुन्हा करणे। देखरेखीविना पुनरारंभ म्हणजे नियम परत येतात का हे तपासणे, आणि हा स्विचबद्दलचा प्रश्न नाही, पुनर्संचयितीच्या क्रमाबद्दलचा आहे। क्लायंट अद्ययावतानंतर क्रम पुन्हा चालवा, कारण स्विच क्वचित बदलतात, त्यांच्यामागील वर्तन बदलते। फसवे पान जवळ ठेवा: फिरवायचे काही नाही आणि पुढील तपासणीला पाच मिनिटे लागतात।

संबंधित लेख