બે VPN ક્લાયન્ટ સાથે સાથે ચાલી શકે છે, પણ તેમના kill switch એક નીતિમાં ભળતા નથી. દરેક ક્લાયન્ટ પોતાની ટનલ માટે નિયમો મૂકે છે, અને કોઈને પણ બીજાના હોવાની ખબર નથી. મને આ પહેલા જોડાયેલા કામના ક્લાયન્ટ સાથે થયું: બીજી એપ પોતાનું હેન્ડશેક પૂરું કરી શકી નહીં, દસ મિનિટ „Connecting“ પર રહી, અને પહેલી ટનલે બધું ચૂપચાપ લઈ લીધું. બીજી એપ સુરક્ષિત થશે કે નહીં તે ત્રણ શરતો પર આધારિત છે, એના પર નહીં કે બંને આઇકન જોડાયેલું બતાવે છે.

kill switch ખરેખર શું સુધી મર્યાદિત છે

ઓપરેટિંગ સિસ્ટમમાં એક પણ kill switch ધ્વજ નથી. આવો ધ્વજ જાહેર કરતો ક્લાયન્ટ નિયમોનો સમૂહ મૂકે છે: જે મારી ટનલમાંથી બહાર ન નીકળે તેને પડતું મૂકો, અને ટનલ ગાયબ થાય ત્યારે ઘણી વાર fail closed વર્તન કરો. Linux પર આ સામાન્ય રીતે nftables અથવા iptables શૃંખલા હોય છે, Windows પર Windows Filtering Platform ફિલ્ટરનો સમૂહ, Android અને iOS પર ટનલ સેવાનું પોતાનું રાઉટિંગ અને એ સિસ્ટમ સેટિંગ જે VPN વગરના કનેક્શન રોકે છે. Android VPN માર્ગદર્શિકા આ સેવા મોડેલનું વર્ણન કરે છે જો તમને પ્લેટફોર્મનો દૃષ્ટિકોણ જોઈએ.

વ્યાપ્તિ એ જ મહત્વનો ભાગ છે. „ફક્ત wg0 આઉટપુટ ઇન્ટરફેસ પર પેકેટની પરવાનગી આપો“ જેવો નિયમ એ વાતની પરવા કરતો નથી કે બીજી ટનલ છે કે નહીં. જો બીજો ક્લાયન્ટ wg1 ઉપાડે, તો પહેલા ક્લાયન્ટના નિયમો એ પેકેટને સામાન્ય ટ્રાફિક ગણે છે: સામાન્ય રીતે પડતા મૂકાય છે, ક્યારેક પરવાનગી મળે છે. દરેક હાલમાં નિર્ણય પહેલો ક્લાયન્ટ લે છે, અને તેને ખબર પણ નથી કે બીજી એપ રાહ જોઈ રહી છે.

ત્રણ શરતો જે નક્કી કરે છે કોને આવરી લેવાશે

દરેક સંયોજન ગણવાની જરૂર નથી. ત્રણ પ્રશ્નો થોડી મિનિટમાં આ નક્કી કરી દે છે.

  1. શું પ્લેટફોર્મ બીજી ટનલની પરવાનગી જ આપે છે? મોટાભાગના Android ફોન અને iPhone વપરાશકર્તા પ્રોફાઇલ દીઠ ફક્ત એક સક્રિય VPN સેવા સ્વીકારે છે, તેથી બીજી એપ પાસે ક્યારેય ટનલ હોતી નથી અને તે કંઈ લાગુ કરતી નથી. તમને એક જ નીતિ મળે છે, એ એપ પાસેથી જેણે જગ્યા જીતી.
  2. ડિફોલ્ટ રૂટ કઈ પ્રક્રિયા પાસે છે? Windows, macOS અને Linux બે ટનલ સહેલાઈથી ઉપાડે છે. ડિફોલ્ટ રૂટ એ ક્લાયન્ટનો હોય છે જેણે તેને છેલ્લે અથવા વધુ સારા મેટ્રિક સાથે સેટ કર્યો, અને બીજો ક્લાયન્ટ જોડાયેલો પણ નિષ્ક્રિય હોય છે. Linux પર wg-quick નો ડિફોલ્ટ રૂટ મોડ ખાનગી ટેબલ અને fwmark નિયમ સાથે નીતિ-આધારિત રાઉટિંગ વાપરે છે, તેથી બીજી wg-quick ટનલ પહેલીને બદલવાને બદલે સ્પર્ધાત્મક નિયમ ઉમેરે છે.
  3. શું બીજો ક્લાયન્ટ પોતાના જ સર્વર સુધી પહોંચે છે? જો પહેલો kill switch ડિફોલ્ટ નકાર હોય, તો બીજી એપનું બહારનું એન્ડપોઇન્ટ ફક્ત બીજું પડતું મૂકાયેલું લક્ષ્ય છે. તે ચૂપચાપ ફરી પ્રયાસ કરે છે અને ક્યારેય ભૂલ જણાવતું નથી.

ટૂંકું સંસ્કરણ, સહાય થ્રેડો માટે:

SetupWhat you actually get
Second client cannot hold a tunnelOne active policy; the other app only reports that it is waiting
Both tunnels up, second took the default routeThe first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad
First kill switch allows only its own endpoint and interfaceSecond client never connects; first tunnel unaffected
Both up, DNS written by whichever client ran lastName resolution breaks for one side when either tunnel drops

એમાંથી બે લીટીઓ સિસ્ટમ ટ્રેના આઇકનથી એકસરખી દેખાય છે, તેથી આઇકન અહીં ઉપલબ્ધ સૌથી ખરાબ પુરાવો છે.

પહેલા શું નિષ્ફળ જાય છે, અને તે કેવું દેખાય છે

બીજું સ્વસ્થ હોય અને એક ક્લાયન્ટ „Connecting“ પર અટકી જાય, તો લગભગ હંમેશા એન્ડપોઇન્ટની ભૂખ હોય છે: ચાલતું kill switch બીજા ક્લાયન્ટનું તેના પોતાના સર્વર તરફનું હેન્ડશેક પડતું મૂકે છે. આને સસ્તામાં એમ ચકાસો કે પહેલા ક્લાયન્ટના બ્લોક નિયમો એક પ્રયાસ માટે થોભાવો. જો બીજું તરત જોડાઈ જાય, તો પ્રશ્નનો જવાબ મળી ગયો.

DNS બીજી નિષ્ફળતા છે. ક્લાયન્ટ પોતાના ઇન્ટરફેસ માટે રિઝોલ્વર રૂપરેખાંકન સેટ કરે છે, અને કેટલાક સીધું વૈશ્વિક યાદી ઉપર લખી દે છે. બંને ટનલ ઉપર હોય તો ક્વેરી એક બાજુથી નીકળી શકે જ્યારે રિઝોલ્વર બીજી બાજુનું હોય. કોઈપણ એપ ડિસ્કનેક્ટ કરો અને બચેલી એપ અગમ્ય નેમસર્વર રાખે છે: પાનાં એક મિનિટ અટકે છે અને પછી ફરી ઉકેલાય છે, જ્યારે VPN હજી પણ જોડાયેલું બતાવે છે.

ત્રીજી રૂટની લહેર છે. ફરી કનેક્શન ડિફોલ્ટ રૂટને ફરી ગોઠવે છે, અને ઇન્ટરફેસ સાથે બંધાયેલો kill switch તેને અનુસરતો નથી. જે ટ્રાફિક હમણાં જ ટનલમાં હતો તે હવે કોઈ પડતું મૂકવાના નિયમ સાથે મેળ ખાય છે, જે વપરાશકર્તાની બાજુથી એવી VPN તરીકે વંચાય છે જે અચાનક કામ કરવાનું બંધ કરી દે છે.

ચકાસો કે ખરેખર કઈ નીતિ લાગુ છે

આ નિરુપદ્રવી ટ્રાફિક સાથે કરો, એવી વસ્તુ સાથે નહીં જેની તમને ખોટ પડે.

Linux પર કર્નલને પૂછો કે કોણ જીતે છે અને ફાયરવોલ શેની સાથે બંધાય છે. ip -4 route show default એ ટનલનું નામ આપે છે જેની પાસે બહાર જવાનો રસ્તો છે. ip rule show બતાવે છે કે નીતિ-આધારિત રાઉટિંગ રમતમાં છે કે નહીં. sudo nft list ruleset | grep -n oifname બતાવે છે કે પડતું મૂકવાની ક્રિયાઓ ઇન્ટરફેસ નામ, માર્ક કે આખી આઉટપુટ શૃંખલા સાથે બંધાયેલી છે.

Windows પર એ જ વાર્તા રૂટ મેટ્રિક અને ફિલ્ટર યાદીમાં રહે છે: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric અને Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOS પર, netstat -rn -f inet | head -5 અને scutil --dns | head -20.

પછી એ પગલું લો જે લોકો છોડી દે છે: ટનલ જાણી જોઈને થોભાવો અને ખાતરી કરો કે જે ટ્રાફિક નિષ્ફળ થવાની અપેક્ષા છે તે ખરેખર નિષ્ફળ થાય છે. જોડાયેલું આઇકન ઇન્ટરફેસની સ્થિતિ છે, લાગુ કરવું નહીં.

ક્યારે બે ક્લાયન્ટ ખોટી રચના છે

જો બીજી એપ પાછળની એકમાત્ર માંગ વધુ સુરક્ષા હોય, તો તેને દૂર કરો. બે પરસ્પર ક્રિયા કરતી બ્લોક નીતિઓ એક કરતાં ઓછી અનુમાનિત હોય છે, અને દરેક ફરી કનેક્શન એવી સ્થિતિમાં પડવાની તક છે જે કોઈ વેન્ડર ચકાસતું નથી.

જો ખરેખર સાંકળ બનાવવી જરૂરી હોય, જેમ કે વ્યાપારી હોપ દ્વારા પહોંચાતું કોર્પોરેટ ગેટવે, તો એક જ લાગુ કરવાના બિંદુવાળી રચના પસંદ કરો. તેનો અર્થ સામાન્ય રીતે એક રાઉટર કે એક ક્લાયન્ટ જે સાંકળને ટેકો આપે, નહીં કે બે ડેસ્કટોપ એપ્સ જે એક જ ડિફોલ્ટ રૂટ માટે હરીફાઈ કરે. સંચાલિત ઉપકરણ પર મંજૂર ક્લાયન્ટ રાખો અને બાકીનું બધું વ્યાપ્તિની બહાર ગણો, ટ્રેમાં શું પણ બતાવે.

બંને રાખવા પહેલાં ચેકલિસ્ટ

યાદી ક્રમમાં પૂરી કરો; પહેલી નિષ્ફળ વસ્તુ એ જ છે જે સુધારવાની છે.

  • ખાતરી કરો કે બરાબર એક ક્લાયન્ટ ડિફોલ્ટ રૂટ અને રિઝોલ્વરનો માલિક છે.
  • જો બીજો ક્લાયન્ટ ઉપર રાખવો હોય, તો તેના સર્વર એન્ડપોઇન્ટને સ્પષ્ટ પરવાનગી આપો અને દરેક ક્લાયન્ટ અપડેટ પછી ફરી ચકાસો.
  • જ્યારે કોઈ ટનલ પડે ત્યારે અપેક્ષિત પરિણામ લખો અને બરાબર એ જ કિસ્સો ચકાસો.
  • રીબૂટ પછી નિષ્ફળતાનો રસ્તો ચકાસો, જ્યારે શરૂઆતનો ક્રમ અલગ હોય.
  • સંચાલિત પ્રોફાઇલ પર થોભો અને કંઈ પણ ઉમેરતા પહેલાં માલિકને પૂછો.

જો ત્રીજું પગલું નિષ્ફળ જાય, તો સાચો જવાબ એ છે કે ફક્ત એક ક્લાયન્ટ તમને નીતિ આપી રહ્યો છે. નક્કી કરો કે કોના પર ભરોસો છે અને બીજાને જવા દો.

સંબંધિત લેખો