ફેલ-ઓપન vs ફેલ-ક્લોઝ્ડ: VPN કિલ સ્વિચ શું નક્કી કરે છે
બંને શબ્દો ટનલ ગયા પછી શું થાય તે વર્ણવે છે, એન્ક્રિપ્શન કેટલું મજબૂત છે તે નહીં. તમે પસંદ કરેલો વ્યાપ નક્કી કરે છે કે ટ્રાફિક ખરેખર લીક થાય છે કે નહીં.
દંતકથા એ છે કે ફેલ-ક્લોઝ્ડ સુરક્ષિત સેટિંગ છે અને ફેલ-ઓપન બેદરકાર. બંને વર્ણવે છે કે ટનલ જતા રહ્યા પછી ટ્રાફિક સાથે શું થાય છે, અને બંમાંથી કોઈ એ બદલતું નથી કે તે ટનલ કેટલું સારું એન્ક્રિપ્ટ કરે છે. વિશાળ અપવાદ-યાદી સાથેની ફેલ-ક્લોઝ્ડ નીતિ એવા ઉપકરણ પર ફેલ-ઓપન નીતિ કરતાં વધુ લીક કરી શકે છે જે ક્યારેય ઓફિસ નેટવર્ક છોડતું નથી. એવું પરિણામ પસંદ કરો જે તમે ટ્રાફિકના માલિકને સમજાવી શકો.
લેબલ પરિણામ વર્ણવે છે, તાકાત નહીં
શબ્દભંડોળ નિયંત્રણ પ્રણાલીઓમાંથી આવે છે: ઘટક નિષ્ફળ જાય ત્યારે ફેલ-ઓપન કામગીરીની પરવાનગી આપે છે, ફેલ-ક્લોઝ્ડ તેને નકારે છે. VPN પર લાગુ કરતાં, નિષ્ફળ થતો ઘટક ટનલ છે, અને પ્રશ્ન એ છે કે ટ્રાફિકને બીજા માર્ગે ચાલુ રાખવાની પરવાનગી છે કે નહીં. સાઇફરની પસંદગી, કીની લંબાઈ અને પ્રોટોકોલ અલગ નિર્ણયો છે.
મૂંઝવણ ટકી રહે છે કારણ કે કિલ સ્વિચ સુરક્ષા સુવિધા જેવું લાગે છે, અને વિક્રેતાઓ તેને એ રીતે માર્કેટિંગ કરે છે. યાંત્રિક રીતે તે રૂટિંગ અને ફાયરવોલ નિયમ છે જે ટનલે લઈ જવાના હતા તે ટ્રાફિકને અવરોધે છે, જે ક્લાયન્ટમાં, ઓપરેટિંગ સિસ્ટમમાં કે ગેટવે પર લાગુ થાય છે. જે સ્તર તેને લાગુ કરે છે તે તેની કવરેજ પણ નક્કી કરે છે, અને એક સ્તરનો નિયમ બીજાને આવરી લેતો નથી. ગેટવે પરનો નિયમ એ લેપટોપને બચાવી શકતો નથી જે પહેલેથી બીજા નેટવર્ક પર જઈ ચૂક્યું છે.
દરેક પરિણામ કેવું દેખાય છે
સમાન નીતિ તમે કઈ નિષ્ફળતાનો સામનો કરો છો તેના આધારે ઘણી અલગ રીતે વર્તી શકે છે, તેથી લેબલ નહીં, ઘટનાઓની તુલના કરો.
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
છેલ્લી પંક્તિ એ છે જે એવું માનનારાઓને પકડે છે કે કિલ સ્વિચ એક જ સ્વિચ છે. IPv4 રૂટ ટેબલ માટે લખાયેલો નિયમ IPv6 ડિફોલ્ટ રૂટને અસ્પૃશ્ય રાખે છે, અને એપ્લિકેશન તેનો આનંદથી ઉપયોગ કરી શકે છે.
વ્યાપ નક્કી કરે છે કે લીક થાય છે કે નહીં
કઈ મોડ છે તે પૂછતાં પહેલાં પૂછો કે નીતિ શું આવરી લે છે. પ્રતિ-એપ્લિકેશન નિયમ એક એપનું રક્ષણ કરે છે અને બીજું કંઈ નહીં, ઉપકરણ-વ્યાપી નિયમ અપવાદો સિવાય બધું રક્ષે છે, અને ગેટવે નિયમ ફક્ત એ ટ્રાફિકનું રક્ષણ કરે છે જે તે ગેટવે સુધી પહોંચે છે. DNSને પોતાનો નિર્ણય જોઈએ, કારણ કે સ્થાનિક રિઝોલ્વરને મોકલેલી ક્વેરી પેલોડ અવરોધિત હોય ત્યારે પણ નામો જાહેર કરી શકે છે.
સ્થાનિક-નેટવર્ક અપવાદો પ્રિન્ટર, કાસ્ટિંગ અને કેપ્ટિવ પોર્ટલ માટે છે, અને દરેક બ્લોકમાં એક છિદ્ર છે. તેમને નીતિની બાજુમાં દસ્તાવેજ કરો, કારણ કે રૂપરેખા વારસામાં મળનાર વ્યક્તિ અન્યથા ફેલ-ક્લોઝ્ડને નિરપેક્ષ તરીકે વાંચશે.
ફરી જોડાવું અને અવરોધિત કરવું પણ અલગ નિયંત્રણો છે. ક્લાયન્ટ ક્યારેય અવરોધ્યા વિના આપમેળે ફરી જોડાઈ શકે છે, અથવા ફરી જોડાયા વિના અવરોધિત કરી શકે છે, અને સંયોજન નક્કી કરે છે કે વિક્ષેપ દરમિયાન વપરાશકર્તા શું અનુભવે છે.
સંક્રમણ દરમિયાન તેને સાબિત કરો
સ્થિર સ્થિતિનું પરીક્ષણ કંઈ સાબિત કરતું નથી. જાણી જોઈને ટનલ પાડી નાખો અને જે એપ્લિકેશન સુરક્ષિત હોવી જોઈએ તે અજમાવો, પછી તપાસો કે તે નેટવર્ક સુધી પહોંચી છે કે નહીં. ક્લાયન્ટના સૂચકની પરિણામ સાથે તુલના કરો, કારણ કે હજી પણ જોડાયેલું કહેતું સૂચક એ જ કેસ છે જેના માટે નીતિ અસ્તિત્વમાં છે. જો સુરક્ષિત એપ્લિકેશન સફળ થાય, તો મોડના નામની કોઈ ફરક પડતી નથી; તમારી પાસે લીક છે.
સાઇન-ઇન પહેલાં કોલ્ડ બૂટથી પુનરાવર્તન કરો, Wi-Fi થી સેલ્યુલર પર જતી વખતે, અને સુરક્ષિત એપ બેકગ્રાઉન્ડમાં રાખીને. જો બ્લોક ક્લાયન્ટ પ્રોસેસ દ્વારા લાગુ થતો હોય, તો તે પ્રોસેસ સાફ રીતે બંધ થવાને બદલે માર્યા જાય ત્યારે શું થાય તે પણ ચકાસો.
છેલ્લે, સફાઈનો માર્ગ તપાસો. જો ક્લાયન્ટના નિયમો સક્રિય હોય ત્યારે તેને અનઇન્સ્ટોલ કરવામાં આવે, તો ઓપરેટિંગ સિસ્ટમનો ફાયરવોલ બંધ કરવાને બદલે વિક્રેતાની દસ્તાવેજીકૃત દૂર કરવાની પ્રક્રિયા વાપરો, જે બાકી રહેલા નિયમનો માલિક કોણ છે તેનો જવાબ આપ્યા વિના અસંબંધિત સુરક્ષા દૂર કરે છે.