તમારા સાચા ખાતા વગર VPN કિલ સ્વિચ કેવી રીતે ચકાસવી
ડિકોય પૃષ્ઠ અને વૈકલ્પિક પ્રોફાઇલ સાથે કિલ સ્વિચ પરીક્ષણ ચલાવો: દરેક વિક્ષેપનો પ્રકાર આવરી લો, curl ના નિકાસ કોડ વાંચો અને સાચા બ્લોકને DNS નિષ્ફળતાથી અલગ કરો।
કિલ સ્વિચ ટકી રહે છે કે નહીં તે જાણવા માટે તમને સાચા ખાતાની જરૂર નથી; પરીક્ષણ બરાબર એ જ વસ્તુને જોખમમાં મૂકે છે। ચકાસણી ટૂંકી વિંડો બનાવે છે જેમાં ટ્રાફિક ટનલની બહાર જઈ શકે કે ન પણ જાય, તેથી પેલોડ એવી વસ્તુ હોવી જોઈએ જે તમે ગુમાવી શકો। હવે હું આ ડિકોય પૃષ્ઠ અને વૈકલ્પિક બ્રાઉઝર પ્રોફાઇલ સાથે કરું છું, અને તે પહેલાં વાપરેલી બ્રાઉઝર-અને-વેબમેલ રીત કરતાં વધુ સ્પષ્ટ જવાબ આપે છે। નીચેનું તે જ ક્રમમાં ચાલે છે જે ક્લાયન્ટ રજૂ કરે છે: સેટિંગ, ગંતવ્ય, સંક્રમણ અને પછી પુરાવા।
પરીક્ષણ એક સાંકડા પ્રશ્નનો જવાબ આપે છે: આ સંક્રમણ દરમિયાન, શું આ એપ્લિકેશન ટનલની બહારના નેટવર્ક સુધી પહોંચી શકે છે? બાકીની નીતિ વાજબી છે કે નહીં તે વિશે તે કંઈ કહેતું નથી। અવકાશ આટલો નાનો રાખો, અને પરિણામ લખવા લાયક છે।
ક્લાયન્ટમાં સ્વિચ અને તેનો અવકાશ શોધો
કોઈપણ નેટવર્ક સ્થિતિ બદલતા પહેલાં ક્લાયન્ટ ખોલો અને બ્લોકિંગ સેટિંગ શોધો। વેન્ડરો તેને જુદા જુદા નામે કહે છે: કિલ સ્વિચ, લૉકડાઉન મોડ, નેટવર્ક લૉક, ટનલની બહાર ટ્રાફિક બ્લોક કરો। લેબલ અંદરના વિકલ્પો કરતાં ઓછું કહે છે। મહત્ત્વનું એ છે કે બ્લોક હંમેશા લાગુ પડે છે કે ફક્ત ત્યારે જ જ્યારે એપ્લિકેશન નક્કી કરે કે ટનલ હમણાં જ નિષ્ફળ ગઈ, અને તે દરેક એપ્લિકેશનને આવરી લે છે કે પસંદ કરેલી યાદીને।
પછી તમારો ક્લાયન્ટ ખરેખર કરી શકે તેવા સંક્રમણોની યાદી બનાવો। વપરાશકર્તા દ્વારા શરૂ કરાયેલ ડિસ્કનેક્ટ, એપ્લિકેશનમાંથી બહાર નીકળવું અને સર્વર સાથેનો સંપર્ક ગુમાવવો એ મોટાભાગના ક્લાયન્ટમાં ત્રણ જુદા કોડ પથ છે, અને તેઓ એક જ બ્લોકિંગ નીતિ વહેંચતા નથી। કેટલાક એપ્લિકેશન બંધ થાય ત્યારે બ્લોક છોડી દે છે। અન્ય ફિલ્ટર નિયમો સ્થાપિત રાખે છે જ્યાં સુધી કંઈક તેમને દૂર ન કરે। ધારવાને બદલે તમે ચલાવો છો તે બિલ્ડ માટે વેન્ડરની સેટિંગ્સ સંદર્ભ વાંચો, પછી ત્રણમાંથી કયું ચકાસો છો તે લખો।
પ્રોફાઇલ પણ નોંધો: પ્રોટોકોલ, સરનામાં પરિવારો અને સ્પ્લિટ ટનલિંગ ચાલુ છે કે નહીં। જો પ્રોફાઇલ જાણી જોઈને થોડી એપ્લિકેશનોને બાકાત રાખે તો આખા ઉપકરણનો દાવો અર્થહીન છે, અને તમે ગોઠવેલી બાકાત લીક નથી। 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=$?"| Transition | Expected with the block on | Failure signature |
|---|---|---|
| Manual disconnect | Decoy stops answering within seconds | Decoy still returns 200 |
| Server or path failure | Blocked, with no exemption for the old endpoint | Direct access during the gap |
| Quit the app | Client-dependent; record what happens | Block disappears with the process |
| Wi-Fi to Ethernet | Block holds until the tunnel returns | Traffic 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 નિકાસ કોડ સાથે।
જો કોઈ લાઇન ખાલી હોય, તો પરીક્ષણ પૂરું નથી। રોમિંગ એટલે નેટવર્ક-ફેરફાર પંક્તિનું પુનરાવર્તન। દેખરેખ વગરનું રીબૂટ એટલે નિયમો પાછા આવે છે તેની ચકાસણી, જે સ્વિચ વિશે નહીં, પુનઃસ્થાપન ક્રમ વિશેનો પ્રશ્ન છે। ક્લાયન્ટ અપડેટ પછી ક્રમ ફરી ચલાવો, કારણ કે ટૉગલ ભાગ્યે જ બદલાય છે જ્યારે તેમની પાછળની વર્તણૂક બદલાય છે। ડિકોય નજીક રાખો: ફેરવવા જેવું કંઈ નથી, અને આગલી ચકાસણી પાંચ મિનિટ લે છે।