VPN ચાલુ હોય ત્યારે એપ ચાલવી જોઈએ નહીં: તેને કોણ લાગુ કરે છે

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

દંતકથા: kill switch પ્રોગ્રામ શરૂ થવાથી રોકે છે

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

પ્રોગ્રામ શરૂ થઈ શકે કે નહીં તે ખરેખર નક્કી કરતી ગોઠવણ એ એપ્લિકેશન નિયંત્રણ છે. Windows પર તેનો અર્થ AppLocker કે WDAC, અને મેનેજ્ડ macOS પર ડિવાઇસ પ્રોફાઇલ દ્વારા લાગુ કરાયેલી મંજૂર યાદી. બંને ટનલથી સ્વતંત્ર છે, તેથી બે આવશ્યકતાઓ એક જ ટિકિટમાં ભળી જાય છે અને પછી બંનેમાંથી એક પણ પૂરી થતી નથી.

સાધનનું નામ આપતાં પહેલાં મોડનું નામ આપો

નિયમને ત્રણ સ્થિતિવાળા સ્ટેટ મશીન તરીકે લખો: સામાન્ય વપરાશ, VPN કાર્ય સત્ર અને નિકાસ. પ્રતિબંધિત ઓવરલેપ વચ્ચેની સ્થિતિનો છે, ક્લાયન્ટ સોફ્ટવેરનો નહીં.

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

દ્વિ-માર્ગી સંઘર્ષ ખરેખર શું કરે છે

systemd દ્વારા ખરેખર સંચાલિત બે સેવાઓ માટે Conflicts= સમમિત છે: એક શરૂ કરવાથી બીજી બંધ થાય છે. યુનિટ સંદર્ભ આ વર્તનનું દસ્તાવેજીકરણ કરે છે અને અલગથી સ્પષ્ટ ક્રમ માંગે છે જ્યારે એકનું બંધ થવું બીજી શરૂ થવાના પહેલાં પૂરું થવું જોઈએ. તે ક્રમ-એન્ટ્રીઓ વિના બંધ થવું અને શરૂ થવું સ્પર્ધા કરે છે, અને પરિણામ સમય પર આધાર રાખે છે.

આ નકાર યાદી નથી. અવલંબન ઊંધું જોડો તો એપ શરૂ થવાથી ઊલટું VPN બંધ થશે, અને જ્યારે ટનલ અનુમાનિત ક્ષણે જાતે ડિસ્કનેક્ટ થાય ત્યારે આ જ ખામીની શંકા કરવી જોઈએ. ડેસ્કટોપ એપ્લિકેશન systemd યુનિટ નથી, અને NetworkManager જોડાણ પણ યુનિટ નથી, તેથી આ પેટર્ન ફક્ત તમે જાતે લપેટો છો તેવી સેવાઓ માટે કામ કરે છે.

ફક્ત પહેલી લોન્ચ નહીં, સંક્રમણો ચકાસો

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

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

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

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